5 Replies Latest reply on Dec 18, 2014 11:06 AM by JaredHague

    fmreauthenticate issues

    JaredHague

      I have a client that has a couple solutions that use Go. 

       

      Both file have all accounts with fmreauthenticate10080 enabled.

       

      File1

      Behaviour

      Reconnects the user where they left off when going into another app or sleep mode.  Works great as expected.

      File info

      1. single file.

      2. user sign in.

       

      File2

      Behaviour

      Doesn't appear to even try to reconnect.  When you open Go again it just dumps you to the files screen.  Sometimes crashes Go.

      File Info

      1. Multi file.  -all other files have fmreauthenticate10080 on all acounts. I have also opened them all and reauthenticate works fine.

      I have also tried having the external sources removed.

      2. Auto login is on but has been tested with it off too.

       

      I have been trying all kinds of things to get this working. Everything from testing different server to clearing out the file. Nothing appears to help getting this working.

       

      Any thoughts or suggestions would be appreciated.

        • 1. Re: fmreauthenticate issues
          JaredHague

          After much testing and trial and error it appears I have solved this issue.

          I thought I would post my solution.

           

          On my startup script I had been loading several small graphics into global vars.  After greatly reducing the size of the global vars it worked fine.

          So it appears there is a limitation on how much global storage Go can hold in its frozen state.

           

          If anybody knows where there is some docs mentioning this it would be good to reference.  I didn't find any.

          • 2. Re: fmreauthenticate issues
            Mike_Mitchell

            Jared -

             

            I don't believe it's necessarily a FM Go issue. I've seen some traffic on similar issues before, and I believe it has to do with how iOS manages the memory when applications move to the background. Might be wrong, but I believe that's where the issue lies.

             

            Perhaps consider using global fields instead of variables?

             

            Mike

            • 3. Re: fmreauthenticate issues
              JaredHague

              I figure global fields would be the same because when hosted globals are not saved so if its going to restore it would need to save them the same way.

               

               

              Just thought I would add a little more info...

               

              I had about 1MB total info in all the globals.  Most were custom graphics used in calculated containers.   Case ( setting = 1 ; $$graphic1 ; $$graphic2 ) type of thing.  Thanks to FM13 ability to hide objects I just took the graphics and overplayed them on each other using the hide calc to show the one on top or not.

               

              This kept the size of the globals memory under 500k  where it was a little over 1MB before.

               

              I know when Go will go into the background or any iOS app for that matter there is a method called applicationWillResigActive that runs. Unless its got some background feature enabled like streaming music or whatnot, and Go does not. This gives the program time to save its state to a file like a .plist.

               

              At this point I am wondering if they have a limit in Go on how large the .plist would be.  As far as I know there is not a firm limit on how much data you save to it in xcode     .

               

              Just some thoughts and speculation.

              • 4. Re: fmreauthenticate issues
                Mike_Mitchell

                No, I don't believe it is the same. Global fields are part of the database schema and therefore part of the local disk cache. Variables are memory-only storage.

                 

                Again, could be wrong, but I'm pretty sure the storage is handled differently.

                • 5. Re: fmreauthenticate issues
                  JaredHague

                  I would think only the minimal amount of data would be saved to restore a files state.

                  That would be

                  db name

                  current layout

                  current record

                  global vars names and values

                  global table-field names and values

                   

                  Im sure the cache is dumped. Even so we are really talking about the same thing here its just local saved data.

                   

                  It would be interesting to test out sometime but for now I guess only a FM Go engineer with know for sure.