Making Your Solution Sync Ready
LCFM Native allows you to sync your data from your Android app back to your FileMaker database and vice versa. If you dont want to sync, you don't need to do this, your app will work without changes. However LCFM Native comes with the ability for your app to run offline and then sync the data online, and for that, you might need to make minor changes to your solution to make it work. Here is how you do it on the Sample Assets solution from FileMaker. Open Sample Assets in FileMaker.
Next we need to make some changes to the fields in the database tables. These are only minor changes.
Still within FileMaker, Click File > Manage > Database
Select the table you want to make sync ready (1). First we need to modify the primary key field in each table to autoenter calc = Get(UUID).
Highlight the primary key field (2):
Then change the type to text, and click Change:
With the primary key field still highlighted, click options.
If the serial number checkbox is already checked, uncheck it (1).
Now check the calculated value checkbox (2) and click specify (3). At this stage enter Get(UUID), then press OK.
That is the first modification complete, two more to make.
In order for sync to work properly, each table must have a modification and a creation timestamp field. The Assets table may already have suitable fields which allows LCFM Native to choose what changes to select in the case a conflict occurs the Modification Timestamp field.
However if it didn't have these fields, here is how you would add them.
Still within manage database, enter the field name Modified Timestamp (1) and set the type to Timestamp (2).
Now click Create (3), then Options, and then check the Modification Checkbox:
Then click OK to close the dialog. We need to repeat the process for adding a Created Timestamp field.
In FileMaker, go to File -> Manage -> Database
Still within manage database, enter the field name Created Timestamp (1) and set the type to Timestamp (2)
Now click Create (3), then Options, and then check the Creation Checkbox:
Finally, click OK to close the dialog.
And that’s it! Your solution is now LCFM Native Sync Ready.
Remember you will have to make these small changes to each table used in your solution.
Notes on syncing
When compiling a solution, LCFM Native will attempt to infer these fields from each basetable's definition. Specifically:
The first field (in creation order) which has an autoenter calculation set to Get(UUID) is taken to be the primary key field.
The first field (in creation order) which is set to autoenter modification timestamp is taken to be the modification timestamp field. The first field (in creation order) which is set to autoenter creation timestamp is taken to be the creation timestamp field.
Important: All three fields must have either have a default index, or be set to auto-index. Without these settings sync will not function.
You can explicitly override these choices by adding an appropriate tag to the relevant field's comment:
- @primary means LCFM Native will treat that field as the primary key field in preference to any other.
- @modification means LCFM Native will treat that field as the modification timestamp field in preference to any other.
- @creation means LCFM Native will treat that field as the creation timestamp field in preference to any other.
In each case, LCFM Native will take the first field (in creation order) it finds which has one of these tags. For the tag to be recognised it must be surrounded by whitespace (or beginning / end of the comment). e.g.
• This field is the @primary key field correct
• @primary correct
• @primary key correct
• Field @primary correct
- This is the primary key field (@primary) wrong
Note: If you tag fields in this way, then the only restriction LCFM Native puts on their settings is that they must be a stored normal field (global, calculated and summary fields are ignored).
Edits made to custom valuelists via the Edit... item in Menu and List fields cannot be synced and so are always entirely local to the device. If valuelist editing is used in the solution(s) and the changes need to be global, then they will have to be replaced by an alternative mechanism using field-based valuelists.