How It Works

(:include NewerDocs:)

Unless you are on wifi and your server is on the same LAN, if you want the best FileMaker Go experience, you have build your files to work offline. Even if you have a wifi/LAN connection, a local file is going to be faster and more like using a native iOS app.

Unless you are on wifi and your server is on the same LAN, if you want the best FileMaker Go experience, you have build your files to work offline. Even then, a local file is going to be faster and more like using a native iOS app.

Once you decide to build for offline access, you're going to have to solve a number of issues:

1. How to push new local files, and new versions of those files, out to folks in the field.
2. How to reliably exchange data so it flows down to the device and back up to the server.
3. How to gracefully handle disconnects while data is in the process of exchanging.
4. How to keep FMGo from continuously looking for served files when no network is available.
5. How to develop Go files that aren't just copies of the hosted files (which are likely too big and slow for Go).

GoZync solves all of these issues in a way that is both robust and simple enough for the average FileMaker user to implement. To maximize ease and simplicity, we set the following guidelines:

1. Must work with regular FileMaker Pro as the host. FileMaker Server is not a requirement.
2. Must minimize interference with how any given solution is built.

GoZync 3.0 is our simplest solution yet, giving developers an interface for managing syncs, logs, and devices.

GoZync uses a loosely coupled data exchange model to pass data back and forth while maintaining transactional integrity. It does that by converting any any related set of FileMaker records, like an Invoice and its related Invoice Lines, into what we call a "Package", and passing the complete Package up to the server or down to the device using normal FileMaker Set Field steps.

Packages are then transactionally processed so either they make it completely into the receiving system or they don't make it all. There is no way to transmit a partial package. This means that should the 3G network drop, or the phone ring in the middle of transferring an invoice to the server, the invoice will remain intact and whole. For example, GoZync will never transfer the invoice but not all of its line items.

Packages can also have "Attachments". Attachments are binary files that can be sent along with the document. This makes it possible to send photos or other files to the server. Attachments are also treated transactionally, so if a package gets passed to the server, it will go with all of its attached photos -- or it won't go at all.

In addition to managing the data, GoZync manages the deployment of your local/remote files and can automatically download new builds of the local file to your Device. There is no need to use iTunes or any other app to get the file on the device. For clarity, you may want to email users their first copy of the mobile file. After that, they can click "check for new version" in the mobile file to automatically retrieve new builds.

All of this is designed to be simple for an intermediate FileMaker person to build and extend.

1. No Plugins
2. It has to work with regular FileMaker Pro as the host. FileMaker Server is not a requirement.
3. It should interfere as little as possible with how any given solution is built.

That was the plan and that is pretty much what we have done. This new version, GoZync 3.0 takes it further, making GoZync much simpler to add to your solutions and giving developers an interface for managing syncs, logs, and devices.

GoZync uses loosely coupled data exchange model to pass data back and forth while maintaining transactional integrity. We do that by converting any any related set of FileMaker records, like an Invoice and its related Invoice Lines, into what we call a "Package", and passing the complete Package up to the server or down to the device using what amounts to normal FileMaker Set Field steps.

Packages are then transactionally processed so either they make it completely into the receiving system or they don't make it all. When a package is sent to the Server it either gets there or it doesn't. There is no way to get a partial package there. This means that should the 3G network drop or the phone ring in the middle of transferring an invoice to the server, its ok, no damage has been done. There is no need to guess or calculate what might have happened to to the data. You'll never transfer the invoice but not all of its line items, for example.

Packages can also have "Attachments". Attachments are binary files that can be sent along with the document. This makes it possible to send photos or other files up to the server. Attachments are also treated transactionally, so if a package gets passed to the server it will go with all of its attached photos or it won't go at all.

All of this is abstracted out so that it is pretty simple for an intermediate FileMaker person to be able to build with and extend.

1. Reliably exchanging data so it flows down to the device and back up to the server.

1. Enabling you to develop Go files that aren't just copies of the hosted files (which are likely too big and slow for Go)

Like many in the community we have discovered that if you want the best FileMaker Go experience you are probably going to have build your files to work offline, unless you are on wifi and your server is on the same LAN. And even then a local file is going to be faster and more like the experience of using a native iOS app.

Once you decide to build for offline access you are going to have to solve a number of issues:

1. Getting new local files, and new versions of those files, out to folks in the field.

All of this is abstracted out so that it is pretty simple for an experienced FileMaker person to be able to build with and extend.

Like many in the community we have discovered that if you want the best FileMaker Go Experience you are probably going to have build it to work offline, unless you are on wifi and your server is on the same LAN. And even then a local file is going to be faster. But if you want to build for offline access you are going to have to solve a number of issues:

1. Getting of new Local files, and new versions of those files, out to folks in the field.
2. Exchanging data so it flows down to the device and back up to the server.
3. Gracefully handling disconnects in the middle of data exchange.
4. Keeping FMGo from continuously looking for served files when no network is available.

GoZync is our attempt to solve all of these issues in a way that is both very robust and easy enough for your average FileMaker user to be able to implement. To that end we also set the following guidelines:

In addition to managing the data, GoZync manages the deployment of your local/remote files and can automatically download new builds of the local file to the Device. There is no need to use iTunes or any other app to get the file on the device, though you may want to email users their first copy of the mobile file: after that they can click "check for new version" in the mobile file to get new builds.

1. Data Exchange - data flows down to the device and back up to the server.
2. Gracefully handling disconnects in the middle of data exchange
3. Keeping FM Go from continuously looking for served files when no network is available.

1. Deployment of New Local files, and new versions of those files.

All of this is abstracted out so that it is pretty simple for an average FileMaker person to be able to build with and extend.

GoZync ships with a fully integrated installer that can automatically download new builds of the local file to the Device. There is no need to use iTunes or any other app to get the file on the device, though you may want to email users their first copy of the mobile file: after that they can click "check for new version" in the mobile file to get new builds.

Under the Hood

The Problem

Like many in the community we have discovered that if you want the best FileMaker Go Experience you are probably going to have build it to work offline, unless you are on wifi and your server is on the same LAN. And even then a local file is going to be faster. But if you want to build for offline access you are going to have to solve a number of issues.

Deployment of New Local files Data Exchange - data flows down to the device and back up to the server. Gracefully handling disconnects in the middle of data exchange Keeping FM Go from continuously looking for served files when no network is available.

Our Solution

GoZync is our attempt to solve all of these issues in a way that is both very robust and easy enough for your average FileMaker user to be able to use. To that end we also set the following guidelines:

It has to work with regular FileMaker Pro as the host. FileMaker Server is not a requirement. It should interfere as little as possible with how any given solution is built.

That was the plan and that is pretty much what we have done.

GoZync ships with a fully integrated installer that can automatically download new builds of the local file to the Device. There is no need to use iTunes or any other app to get the file on the device.

GoZync uses loosely coupled data exchange model to pass data back and forth while maintaining transactional integrity. We do that by converting any any related set of FileMaker records, like an Invoice and its related Invoice Lines, into what we call a "Document", and passing the complete Document up to the server or down to the device using what amounts to normal FileMaker Set Field steps. Documents are then transactionally processed so either they make it completely into the receiving system or they don't make it all. When a Document is sent to the Server it either gets there or it doesn't. There is no way to get a partial document there. This means that should the 3G network drop or the phone ring in the middle of transferring an invoice to the server, its ok, no damage has been done. There is no need to guess or calculate what might have happened to to the data.

Documents can also have "Attachments". Attachments are binary files that can be sent along with the document. This makes it possible to send photos or other files up to the server. Attachments are also treated transactionally, so if a Document gets passed to the server it will go with all of its attached photos or it won't go at all.

All of this is abstracted out so that it is pretty simple for an average FileMaker guy to be able to build with and extend.

We have tried to keep the connections that you make between the Server Files and Local files simple and straightforward. There are very few modifications that you have to make to existing schema and really no changes to existing table occurrence groups. You do have to connect up the code to your data but that is done in a nice well isolated way.