FileMaker Go worked as advertised. I could connect to my databases on my server. I could build interfaces that fit the iPhone or the iPad. But when it came time to actually enter data, I didn’t do it on my iPhone. I waited until I got to my laptop. Why?
I had a choice. I could wait to use a much faster machine, better keyboard and probably a better network connection. So I waited. This was not a conscious decision. It was just what I did. As a result I used FileMaker Go less and less.
All that changed at pause on error. I attended a session coordinated by John Sindelar of SeedCode
. During that session we heard from J. Sciarra and James Wesolowski from Colibri Solutions
about a system that they built for FileMaker Go. Through trial and error they had come up with a architecture that worked in the real world. And it turns out that the real world doesn’t just involve slower network connections and slower devices. It involves fragile connections and or no connections. They needed something that worked in all of these scenarios.
So what was their solution? Go Local. They created a FileMaker Go application that was designed to work on the local iOS device, completely disconnected from any Filemaker server. If you want to know more about why they did what they did, you can check out their DevCon preview video
, and or attend their session at FileMaker DevCon 2011
Now at first, I thought, “Yeah, but then you have to manage the data exchange back and forth from Server File to Local File. Thats too much work”. But as they talked about how they did it, it started to occur to me that the solution they had come up with was one that many *native* iOS apps used. I started looking at the apps on my iPhone and I found that if it was an app that had a server component, it was almost always caching the data locally. Here are just a few:
All of these cache some or all of the data locally until it needs to be refreshed or sent back. They do it so you can still use them when you have a bad connection or no connection. And they do it for speed and responsiveness. Their UIs are richer and snappier as a result.
Once I realized that Joe and James had independently found the same solution that iOS developers had found I realized that they were almost certainly on to something. My brain literally began to buzz. It just made sense. Building the best FileMaker Go Apps requires building specifically for the device, using best practices that made sense for the device. This is a very different approach then trying to morph a model that works for desktops on a LAN to one to what that works on iOS devices out their in the real world, which is what i had been doing. I was convinced, the answer was to GoLocal.
But there are lots of challenges that have to be over come for this to be a viable method for building FileMaker Go Apps. Some are obvious, like exchanging data and deploying local files. Some are not so obvious, like dealing with shaky 3G connections. This turns out to be quite tricky to do well. The guys at Colibri had decided to use us only iPod touches so they could ensure that the users never had to deal with shaky 3G connecting while exchanging data with the server. This made it easier for them to use import records to exchange data and images with the hosted solution.
I felt that at generalized framework for Going Local would have to work over 3G and be able to gracefully handle sudden disconnects, even in the middle of data transfer. As the discussion continued at pause, a plan began to form in the back of my head. I was pretty certain that I new how to handle the 3G connection issue. I couldn’t wait to try it out.
I left pause convinced that this was the way to build awesome FileMaker Go Apps, and that the challenges could be over come with a well thought through architecture. I had some ideas about how to do it, but I needed some help. So I turned to my long time colleague and collaborator, John Sindelar, and together we have been cooking up some awesome sauce!
Stay tuned for whats next!