I am so thrilled, amazed and look forward for new opportunities with new FileMaker iOS App SDK. I’ve developed a technique for updating FileMaker Pro Desktop solutions and published it recently. So I thought to try to use the same approach to update the native iOS App created with FileMaker iOS App SDK. And to my surprise, I implemented the same technique with minor modifications and the update works!
Check these resources before reading further:
- iOS App SDK Instructions from FileMaker Inc.
- Important development considerations before using the iOS App SDK from FileMaker Inc.
- Richard Carlton’s and Todd Geist’s Webinar about Making FM Apps for Apple’s App Store (Youtube video, 1:12:42).
This post is about how to update the App when you have created a native iOS App with FileMaker Pro and FileMaker iOS App SDK. Mostly I will be dealing with issues described in the second resource I mentioned above.
There are 2 different architecture strategy considerations for your app which are related to the update:
1. No use of FileMaker Security.
This strategy should be used when you want to create a stand-alone iOS App, which means your App would be installed on a user’s iOS device without any connections to external servers.
When no password is set in *. fmp12 file, everything behaves as a standard iOS App update: the iOS relaunch the App and opens the latest database file. Once the new version is delivered to iOS device, new *. fmp12 file is uploaded to the App as well.
2. FileMaker Security is fully used.
iOS applications created with FileMaker iOS App SDK are designed this way, that if you close the App and then open it again, it reconnects to your old database file asking to enter login and password. You have to delete the App to get a new version of your FileMaker application. The problem here is that every new update is delivered iOS installs new *. fmp file, but it doesn’t launch it until previous file is not closed. When we close the old file and start the new one, we have to transfer data from old file to the new database.
Now, we have to think how to inform the user when a new version is on his iOS device? The easiest way, we can create an Update button and when the user clicks it, update starts up. Here are some other examples where we can put the checking for new versions:
- On entering the particular layout
- When layout changes
- When any button is pressed
- When user comes to a particular place in your app
- And more… You decide!
Once you make a decision where you will add the checking for the new version you have to add this simple script step to your scripts:
If [ ValueCount ( Get ( DocumentsPathListing ) ) > 1 ]
If the answer is “True” that means the new version of your App has been delivered to your iOS device!
FileMaker Script Steps used in the update technique
Only native FileMaker scripts are used in this technique. Scripts should be in the old and new files at the time of updating, so you have to think about this technique before delivering the first version your app.
- Startup Script, it’s the most important and where everything is set to work. Please download Demo file at the end of the post for more details.
- If you chose to use FileMaker Security within your iOS App so you have to close the old *. fmp12 file. The iOS will not close the FileMaker database file until the user will do so. Even closing the iOS App from the background will not help. I decided to use script trigger which will be triggered when user opens the Layout. When the trigger is activated it basically checks if there are more than one database file within iOS App. If the answer is “True”, the hidden text object appears which says:
“New version for this App was released. Update data.“
Place it somewhere where users could see it easily. The button is set for this text, so when the user taps it, current *. fmp12 file is closed. iOS instantly relaunch the file, but it will open the latest version. So, when new version starts up, we have to import records from the old version.
- First of all, we have to open the old file. We use an Open URL script step to open the old file. Then we run “Prepare for update” script which is very important. It goes through all tables and make Show all records in your old file. It requires, because if Found sets has been used, so it may import the last found set instead of all records.
- When the old file is prepared, we run the “Update from old file” script. Which basically imports all data from the old file. At this point we already have all data in our App.
Important. Thinking that it won’t be the last update we have to remove the old file. Because when we’ll deliver update next time our current file will become old file and we’ll have to import from this file. If we’ll keep the old file after next update we’ll have 3 database files and data will be imported from the old file. We don’t want that user will lose his data, right?
- So the latest thing to do, we have to run “Delete old file” script to avoid data import routine problems in the future. I use a very old technique to delete files from FileMaker solution: Export empty found records to the file’s path will delete the file.
That’s it! The native iOS App created with FileMaker iOS App SDK was updated!
Some things has to be kept in mind!
- As FileMaker, Inc. suggests in its development considerations we have to set file names correctly. I use very simple naming for version in my example:
- First App.0001.fmp12
- First App.0002.fmp12
- First App.0003.fmp12
- Make sure you prepare the file for the update correctly:
- Delete all test data.
- Set required Settings, Globals etc. for your App.
- Set Startup Tasks correctly.
Startup Tasks are very important in this technique, because it runs the required scripts at the required time. So, please pay attention on this part!
This is the biggest issue with the FileMaker iOS App SDK, I think there will be no more boundaries why Apps created with FileMaker Pro couldn’t be sold through the Apple App Store. I will test it with my other apps and will write a report if this technique got approved or not.
I’ve built an example file that shows how everything works. Please use it for your purposes and I hope this technique will help you as much as it does for me.
Note. I’ve removed my URL Schema, so please do not forget to add your own URL Schema to custom functions at File > Manage > Custom Functions…
Contact us if you’d like our assistance in turning your FileMaker solution into a native iOS application – we would be happy to help!