By James Currie, 11 April 2016
As you may be aware FileMaker Inc have given developers a toolset ("SDK") for creating standalone apps for iPhone and iPad, from FileMaker databases. The process is a little tricky and there're plenty of things to be aware of...
The key thing is that once you've got a standalone app, it's much easier for users to have your database as an app just like any other app, as an icon sitting on the iPhone or iPad rather than buried away under FileMaker Go.
The other advantages are that it just looks and behaves like a standard native app. It opens quickly, with it's own splash screen and it's easier to install. In fact you can even sell (or give it away) through the App Store if you've built something that you want to distribute widely. More on deployment and distribution options later.
We've turned several existing iOS solutions we've built into standalone apps and based on that experience I've put together four articles that go through the technical "nuts and bolts" of the process. As this is all still very new I may not have everything perfect - let me know if I’ve missed anything and I will update the article/questions as we go.
Before you start it's worth keeping in mind that there are things that will not work as they do in FileMaker Go so you may want to make a few changes to the solution...
The Exit Application script step in FileMaker Go usually takes us back the files interface. In our custom iOS App the files interface does not exist. The effect that the Exit Application script step has is that it will still close our current file (and any hidden but referenced files) and immediately try to re-open the main file. The user will automatically be logged back in if they've saved their password to the keychain or if the file is set to automatically log in with a specified account name and password, otherwise we are presented with the Log in dialog. Any OnFirstWindowOpen script triggers will run again once the login process has completed successfully.
The Get ( ApplicationVersion ) function in FileMaker Go returns the string “Go_iPad 14.0.4”. When we run the Get ( ApplicationVersion ) function in our iOS App we were surprised to see it returned “Go_iPad 1.0.1”. 1.0.1 is a version number that is specified in the Version Number field in Xcode. This makes it difficult to determine if our Custom App is running in FileMaker Go or as our own iOS App. A simple work around is to use the Get ( ApplicationPath ) function and parse out the application name.
Using long application names will cause them to be truncated, for example the app name WindowFurnishing gets truncated to WindowFurni... iOS does not have a fixed maximum for the length of an app name, instead it will display as much of the name as it can. Using wide letters such as C, W, Z etc will reduce the available amount of space for our app name whereas using letters i, j, l etc will maximise the number of characters our app name can have. This limit differs depending on the device, an iPad allows for more visible width in an app name compared to an iPhone or iPod. A quick and easy way to see if an app name will fit completely on screen is to create an app folder and name it the same as our app.
The FileMaker files within a custom app are not automatically updated when the app is updated. The files are either left untouched or they are overwritten with the solution files included with the iOS app. Ideally the app should update leaving the users data intact. This can be achieved by using an additional helper file that downloads the updated FileMaker files and transferring the user data from the old version to the new version.
As we know the FileMaker Go app has a url scheme that can be used to open files, run scripts and set variables. We do this by creating a link with a prefix of fmp. Our native app can take advantage of the url scheme as well; however, we can not use fmp as our prefix. When we setup our project in Xcode we have the ability to specify a prefix of our own choosing.
Part 2 on how to setup Xcode and create a provisioning profile.
Part 3 on how to setup your project directory.
Part 4 on building, compiling and testing
Something to say? Post a comment...
Comments
Jerry 15/06/2017 4:51am (8 years ago)
Hi,
I want to create a iOS App to distribute within our organization using MDM. It's gonna be a very simple App ~~ just point to a server URL FMP://x.x.x.x/abc.fmp12
Can you do this consulting project for us? Thank you.
Bob 12/06/2017 9:37am (8 years ago)
Please explain about the helper files and how we can update the new version of the app with the customers data this is critical. Thank you so much for the information here.
James Currie 02/05/2016 5:47am (9 years ago)
Hi John,
You're quite right, if a file has externally stored containers you'll have to either change them all to internally stored containers or save as a self-contained file. This applies to both FileMaker Go and when building an app using the FileMaker iOS SDK.
John 30/04/2016 1:58am (9 years ago)
Another consideration (that I learned recently) is that if you have container fields that are stored externally you will need to create a self-contained file. Not a huge deal, but something to be aware of.
Johan H 13/04/2016 1:03am (9 years ago)
Looking forward to Part 2. Thanks for sharing your knowledge
No one has commented on this page yet.
RSS feed for comments on this page | RSS feed for all comments