Update-in-place on iOs

[Justin Close]

Has anyone ever implemented the update-in-place technique from Colibri Solutions? 

http://www.colibrisolutions.com/2011/08/24/one-click-updating-of-a-filemaker-go-solution-on-a-mobile-ios-device/

The general outline is that the infrastructure is all in place in a deployed file and a hosted file.  The deployed file is opened on the iOS device; from inside that file you hit a button to start the update script, which then does all the heavy lifting.  The trick behind this technique is to start an on-timer script on the device, and then close the file on the device.  The on-timer script apparently still has an existence outside the file, and keeps running.  It then downloads the new file from the server, replacing the existing one on the device, and opens that new file.

I was just giving it a try and it almost works...except for one critical part.  When the iOS device tries to download the new file, I get a 'file is locked or in use' error.  There was one time when this worked for me earlier today - my first try of the day, whereas yesterday many attempts had failed.  But I don't know what the conditions were the caused it to work, and an immediate retry failed, and has consistently failed since then.

There was an SSL error at the server that came up, before it succeeded - I just had to log in (not unexpected, although I expected a basic file login prompt, not an SSL error prompt).  But this error has come up again since then, but the update has continued to fail.

 

Thanks,

Justin

[bcooney]

I found it unreliable and went with the EasyDeploy technique in EasySync. Basically, a file is exported that takes control of closing the local file and replacing it. It just seemed that I was fighting external file references and closing the local file would only be reliable with a separate local updater file.

[TrulySimple]

I have been using it successfully for years. Infact the original GoZync from SeedCode was using this same method as well.  The sequence of operation and the fmp12 script steps must be correct.  I use a local intermediary file that has references to my mobile file and to the Host if that file had opened my mobile file instead of my mobile file opening the local intermediary file then I will get that error.  I would have to look at it further to give any more specific answers.  Starting with the Colibri Solutions files it works you might try to use those files again to see if you can get that to work and go from there.

 

[Justin Close]

Well, no dice so far.

I have tried a different server, one that doesn't have a PW protected list of files, and that didn't work.  Just to be sure, I tried the vanilla files on the client's server and that DID work.  I also tried deploying the vanilla 'mobile' file from the client's solution, and that also DID work.

I then copied all of the original scripts in from the vanilla file to my file, only make some minor changes to try and make sure I hadn't messed up anything there.  (I do have to make some changes as the server name is different, I had a different file name for a while, etc.)  That wasn't getting me success, so I even went back to using the vanilla filename.

Then I thought that the external data sources in our deployable file might be causing problems; there was some discussion in the documentation for the sync model (which this file is) about external data sources preventing the file from closing the hosted file, etc.  So I removed the EDSs that where there and tried again:  it failed.

I then tested out file size as a possible contributor; that didn't change anything and stuff still failed on my file, but it DID work OK on the vanilla file even after adding some container data to make it large.

I am going to try a clone and recovered file next; I'm still wondering if the EDSs (even though I deleted them) might still have some hooks in the file.  (This didn't work.)

After that, short of just starting from a completely new file and building it up, I'm not sure what else to try.  Guess I could try the external file approach mentioned above.  I.e. have a 2nd file that is exported from the current file and then does the updating of the current file.

[bcooney]

Actually, I did get one-click to work, but our team felt that this was a bit of a FM "trick" and it was such a critical piece of functionality, and needed to be bullet-proof, that we decided to switch to the local updater file. It helped that EasyDeploy was an integrated part of EasySync.

[Justin Close]

Thanks Barbara for pointing me at EasyDeploy.  I ended up implementing the EasyDeploy parts from EasySync and got it working in our solution.  There are more moving parts but it is working well, where-as One-Click was giving me the errors mentioned in my original posting.

I was able to get One-Click to work using their demo files, so I don't believe that it is a technique.  I actually kind of like it better from the point of view that it has fewer moving parts and less debris (EasyDeploy leaves a stray file on the device that is visible on the 'Recent' and 'Device' file lists in FMGo).  There just appears to be something finicky about it that wasn't working in our solution.  If I had more time I would boil it down and try to figure it out - but I don't.

 

--  Justin

 

Edited September 4, 2015 by Justin Close

[bcooney]

Yep. I asked Tim D. why he didn't delete the EasyDeploy file, but he never responded. Notice, he sets a flag that prohibits its reuse. I never got to deleting it either, but you could use the export a zero found set trick to do that, afaik.

[Justin Close]

Ah, clever!  I was wondering how a file might be deleted from the device.  I like it!