Posts

Why Go Local?

When FileMaker Go first shipped, I wrote about it being a whole new platform. The opportunity that it presented was so big that I thought FileMaker Go would be come the first Platform that I would build for. But in the months after the release, I didn’t even use it much myself. I was curious about this but I didn’t have an answer. Then at Pause on Error I got my answer. Here is the story.

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:
  • TripIt
  • MiniBooks
  • Runkeeper
  • Contacts
  • iCal
  • Mail
  • Twitter
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!
And thanks again to the guys from Colibri Solutions for inspiring me to “go local”.

GoSign v0.8 Released

I am very excited to announce my first actual product for sale here at Geist Interactive.  GoSign – easy signature capture for FileMaker Go!  Using GoSign you can add signature capture to any FileMaker Go application in about ten minutes.

The core technique involves using a WebViewer to display a jquery based JavaScript/HTML5 application that lets someone scribble their signature directly on to an iPad or iPhone, just like they do in the Apple store’s now. Needless to say this involves a lot of moving parts.

GoSign Packages all the JavaScript, HTML, and FileMaker logic into some scripts and layout objects, that can easily be moved into your solution.  It requires no changes to schema other than the the field need to store the actual signature data. The integration points are few and well defined.

For more info pricing, and to download a demo, check out the GoSign webpage.

A special thanks goes out to Richard Carlton of Richard Carlton Consulting (RCC) for being customer number 1!

FM GO Geolocation

UPDATE: I just added a new screen that shows your location too

So I have come up with a method to get Geolocation data into FileMaker.  I am using only native FileMaker scripting and layouts. 100 percent pure FileMaker goodness, made from all natural organic free range sustainable scripts.  No web services, no FileMaker Server, and of course no plug-ins.

I have put up a demo file and I would love it people would log in and try it out.  Once I make sure the bugs worked out I will release it in some form.   Here is the info.

Server: gogeo.geistinteractive.com

file: Geo.fp7

User name and password it is “demo” and “demo”.

I am not sure if “altitude” is working or not. But you should be able to get latitude and longitude. Oh and by the way you need FileMaker Go :>)

Please give me some feedback on what sort of geo location or map stuff you would like to see. The technique I have come up is pretty flexible. I might be able to extent to even do more stuff.

Please let me know what you would like to see.

One more thing. If any of you do think the location is off, can you please let me know if it is the map that is off or the latitude and longitude is off.  Or both!.  It is conceivable that the map might show the wrong spot, even if the latitude  and longitude is correct.

UPDATE:  Chad Novotny of the Support Group, gave away the secret :>)  The basic trick is to use a Web Viewer to get the geolocation data.  FileMaker Go uses Mobile Safari in its web viewers. Mobile Safari, being chocked  full of HTML 5 goodness, has a Javascript object which has access to the geolocation data.  I’ll make my example file available as soon as I work out a few more issues with altitude.

Thanks

FileMaker Go and Transactions

First let me say I love FileMaker Go. I have been waiting for this for a long time. I can’t wait to start deploying on it but right now I need to get the word out about  what happens when FileMaker Go is sent to the background by an incoming phone call, or by the user tapping the home button.

This is really only a problem for large complex solutions doing lots of scripted data manipulations. Most simple solutions will just plain work.  But if you have a large solution, you really do need to understand where you could run into some problems.  Read on for what to do.

Here is the rub. when FileMaker is sent to the back ground any scripts that are running are simply terminated. Any uncommitted edits are simply lost. Read on for more info.First let me say that all of this is based on some testing I did while flying back to LA. I need to do more testing. But what I have found so far fits with my understanding of how the FileMaker engine works.

The following results apply to both FileMaker files that are stored on the iPhone/iPad, or ones that are accesed on the server. When FM Go is moved to the background either by the phone ringing or touching the Home Button, scripts that are running maybe terminated.

I say maybe because I am not sure if the scripts will have some period of time to complete, or if they are immediately killed. But either way scripts can definitely be terminated. When this happens any uncommitted edits that the script has made is lost. It is as though it never happened. The script just dies. Also important to note is that On Close Scripts do not run. The file is not actually closed.

This means that if you have a script that edits more than one record and does not batch the edits into a single commit, FM Go could cause you some problems. If the phone rings in the middle of that script some of your changes will occur and some will not. There will be no error. It will just leave your data out of whack.

Luckily you can write your scripts in such a way that you can avoid this problem. If you batch all your edits into a single commit then even the phone does ring you data will be ok. It will be as though the script never started.

I have been doing transactional scripting in FileMaker since FileMaker 7 shipped, and I can say that you can almost always re-write a script to be transaction safe. I say “almost” because I have found a few cases that had to be broken into two transactions. These had to do with situations where I had to delete as well as create and modify records at the same time.

I don’t know what other information is forthcoming in the tech briefs tomorrow that may help shed some more light on this but from what I can gather this is the current state of affairs.

Also let me say that I think this is probably the best job that FileMaker could do given the situation. The iPhone OS does not give them a lot of options. Killing the script and discarding any uncommitted edits is the right thing to do given the circumstances I am sure I will have more to say in this later.

Thats all for now. The plane is going to land soon. :>)