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.


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.


FileMaker Go is Whole New Platform

I have to say I just love this thing!

FileMaker Go is much more than just a way to access FileMaker Databases on your iOS device. It represents the beginning of a whole new platform.

There is quite simply, no easier way to develop database driven iOS apps than with FileMaker.  I have to believe that the FileMaker market is going to expand quite dramatically as a result of this release.

Consider this:

A FileMaker developer can walk into any corporation that is running MySQL, Oracle, or Microsoft Server, and give them a functioning secure application that access their corporate backend database in a ridiculously short amount of time.  Certainly much faster then they could do it with traditional tools.  I don’t think any toolset out there can beat the combination of FileMaker Go, FileMaker Server and ESS.

Consider this:

There are over 100 million iOS device out there today.  How many will be out there, next year, or the year after? How long before people expect and want there custom business solution to run on an iPhone or iPad?

Consider this:

FileMaker Go’s application development cycle is a way  faster than anyone building custom iOS apps.  Forget even how easy it is to use.  A custom iOS application developer has to wait for Apple to approve their application before rolling it out there users.  A FileMaker Go developer can roll out new versions when ever he or she wants.

I am pretty convinced that we are seeing the end of the “PC” era.  PC’s will be around for a long time, but their time of dominance is coming to an end. The future will be full of iOS devices and iOS devices.  FileMaker Go represents the first step for the FileMaker community towards that brave new world!

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. :>)

Inventory Transactions

Well I am back on my soap box preaching about transactions. :-).  This time I was inspired by the Invoice starter solution that comes with FileMaker 11. I was pleased to see that it does not use an un-stored calculation to keep track of the quantity of inventory items on hand. Instead it uses a script to update inventory. This is great for scalability, but in all but the very lightest of use cases the method employed here will simply fail.

The crazy part is that it only takes about 8 extra script steps to make this method far more robust.  I created a short little movie that describes how I added transactional processing to the script to make it much less likely to fail.

But before the movie, a little more background.

The basic problem is that there are a number of very common scenarios that can stop a script step from working as you think it will. Chief among these is multi-user record locking, but there are many other issues that can stop your scripts cold.  To put it simply, if your business logic depends on a FileMaker script editing more than one record in one or more tables, and you don’t use transactional processing, your data is in trouble. It is only a matter of time before your data is all out of wack!

The good news is that this problem can be dealt with by using database transactions. Database transaction ensure that either all your edits occur or none of them do.  There are no in between states allowed. FileMaker has been able to do database transactions since FileMaker 7, and I have been giving devcon presos on the subject ever since :>).

In the movie I show the basics of getting your FileMaker Scripts to support database transactions.   If you have any questions post them to the comments and I will answer them ASAP.  Thanks!

Watch it BIG on an iPad or iPhone

Teaching FileMaker to Send Alerts to an iPhone

PNS on an ipod/iphone using Prowl

Image by jblyberg via Flickr

Recently I had the need to send alerts to my iPhone from my FileMaker system.  I started using Twitter, and while that works ok, the alerts would get lost in my twitter stream. I needed something that would make different sounds based on what kind of alert was coming in. I found a super simple solution. And it was almost free!

First I discovered Prowl, a Growl client for the iPhone.  Prowl allows you to send Push Notifcations to your iPhone. Prowl can send 5 different levels of alerts, just like the Growl Desktop apps. You can set your Prowl app to play different sounds based on the level alert! Perfect! Then, following a link on Prowls website I discovered a Groovy class for sending Alerts to Prowl from neilspeter. And since my favorite FileMaker plug-in, ScriptMaster, speaks Groovy I was on my way.  I created a ScriptMaster module that installs a new External Function called “prowlSend” the full function call looks like this:

prowlSend( apiKey ; app ; event ; description ; priority )

All you need is a single script step to send the Alert!  This makes it super simple to send  Push Notifications to my  iPhone. Since ScriptMaster runs on FileMaker Server as well, I can even have Server Side scripts sending Push Notifications to my iPhone.  I love this becuase now I have scripts that run throughout the day checking on the state of my System and alerting me if anything warrents my attention.  I can set the level of alert so that my iPhone only vibrates if the alert is not critical, or If something requires my immediate attention, my iPhone will scream like a banshee until I deal with the situation.

If you want to try it out You will need the ScriptMaster plugin from 360works. It is free and is installed automatically by the demo file.  You will also need the Prowl iphone app, which costs three whole dollars. Once you create your account at Prowls website, your API Key will be available on the settings page. The Demo file installs ScriptMaster, installs the Prowl functions, and shows you exactly how to send alerts.  If you want to use it in your own solution, just import the Startup Script, and the Scripts in the ScriptMaster Folder into your own solution and make sure that they are executed on startup, just like in the demo file.

Apologies, the demo file has gone missing.