FileMaker And Sencha Touch

UPDATE:   I got re-tweeted by Sencha Inc. it blew out my bandwidth at screencast.com. That is totally cool!

I have been doing a lot of work with JavaScript lately. Specifically looking at how to build cross platform mobile web apps that connect to FileMaker.  There are some pretty cool libraries available out there that significantly reduce the works load. I had some time at LAX waiting to fly out to pause on error. So I whipped up this little demo using SeedCode Complete running on my FileMaker server in the Cloud and local <a href=”https://www.sencha.com/products/touch/”>Sencha Touch</a> Application.  Check it out.

One of the interesting things about this app is that it requires no server side code at all.  There is no PHP, no Groovy, no Java, no nothing, other than FileMaker running on the sever.  You can write server side code and that probably makes sense to do so in the long run for anything complex but it is not required. In this demo we are using javascript to connect directly to the XML gateway on FileMaker Server.

Perhaps the most interesting thing about this application is that it will work on any mobile device that has a webkit baked browser  So we are not limited to just iOS devices, like iPhones and iPads.  This will work in on WebOS, Android, Blackberries. Windows Mobile 7 support is around the corner.

And Perhaps I should mention that this is not limited to Mobile devices either.  SenchaTouch is based on on <a href=”https://www.sencha.com/products/extjs4-preview/”>ExtJS</a>, one of the most powerful libraries around for building rich web based applications.

Here is the movie.  Hope you enjoy!

Speaking at DevCon 2011

After taking a couple of years off,  I am happy to announce that I will once again be speaking at the FileMaker Developer’s conference.  The 2011 conference will be held in San Diego, CA, August 2-5, 2011 (Tuesday-Friday). I am very excited to be doing this again. I thoroughly enjoy speaking about FileMaker and can’t wait get back up on the stage.

In the past my sessions have often focused on how to use Database Transactions with FileMaker scripts.  Transactions can solve some very tricky issues, so I was very focused on the concept of a transaction, what it was, and how to use them in FileMaker, etc.  But over the years that I have been scripting this way I have seen that these same techniques or very similar ones can solve a broader array of problems.  Script triggers and other newer features also have something to add to this conversation as well.  So this time around, I wanted to loosen up a bit and go deeper.

I decided to focus on the very lowest level in this whole process and dig into exactly how FileMaker decides what data to save and exactly when it saves it.  Armed with this understanding, we can solve a wide array of problems that might otherwise plague complex FileMaker systems.

I titled my presentation “Understanding Commit Record”.

Here is the abstract

FileMaker Pro “commits” data to its database. Normally this process happens in the background, without developers worrying about it.  But sometimes it is very useful to take control of this process so we can decide exactly when and exactly what data gets committed to the database.
In this sessions we will learn the nature of the commit record process and we will see how we can control commits to solve some tricky problems. For exampke; how to mitigate the issue of the iPhone ringing and halting a script in a FileMaker Go application,  how to build interfaces that allow the user to “cancel” the changes they have just made to a few records in the database, elegantly handle multi-user record locking, or even how to speed up large batch operations.
A good solid understanding of the commit record process will carry you a long way towards building better, more robust solutions.
I hope to see you all in San Diego.  If you have any topics you would like me to cover, or issues you would like to see addressed in this preso, just post them to the comments.

 

Announcing proSign v1.0

Geist Interactive is proud to announce the release of proSign v1.0. proSignp makes it easy to add signature capture to any FileMaker Pro solution. Signatures can be captured using any touch pad or pen and tablet input device. No special hardware is required. It runs on both Mac and PC. It requires FileMaker Pro version 9 or greater.

Signatures are captured and stored as Base64 encoded data urls which makes them easy to display in web viewers or to embed into HTML email. You can also convert these into PNG files later for storage and display using the free GoSignCompanion plugin.

Geist Interactive founder, Todd Geist, said “proSign is a follow up to our proSign for FileMaker Go product. Many of our GoSign customers asked if we could come up with a version that worked on regular FileMaker Pro. proSign is the result.”

proSign is available by itself for $239 or bundled with GoSign for FileMaker go for $289.00. Existing GoSign customers are eligible to get proSign at a special price of $219.00 For more information on pricing and to try out demos, please visit the GoSign web page, http://www.geistinteractive.com/proSign.

Geist Interactive is a FileMaker consultancy known for its creative outside the box style and for its deep knowledge of the FileMaker environment. Todd Geist, Geist Interactive’s founder, has given presentations and training seminars at conferences and events all over the United States and the United Kingdom. Geist Interactive is located in Newbury Park, CA.

###

Todd Geist – Owner

805-419-9382

todd@geistinteractive.com

Resizing Captured Signatures

This post is a direct response to a support request I got from a customer earlier today.  The question was how do you change the size of the captured signature?  It isn’t too hard, but unless people are real familiar with how the web viewer works they might miss some of the key steps.  So I thought I would throw together a little demo file and screen cast to show how  it is done.

First, here is the idea behind the technique.  Remember GoSign captures signatures as Base64 encoded image URLS.  These are also called “image urls”, since the are a “URL” that has the image data in it instead of the image location.  That means that they work perfectly as the “src’ of an image tag.  Image tags also have “width” and height” attributes that can be used to scale an image up or down.  So to re-size our captured signature, all we need to do is embed our image url in an img tag in a web page and set either the height or image tag.

Apologies, the demo files have gone missing.

And here is a screen cast

ARVE Error: need id and provider
 

Enhanced by Zemanta

Spaces in FileMaker Variable Names

I just came across an interesting little FileMaker quirk.  The “Set Variable” script step does not allow you to begin the variable name with a space. But you can declare variables with the Let Statement can also declare variables and they can start with a Space.

For example:

If you try to use the “Set Variable” script step to declare this variable “$$ StartedWithSpace”, it will not let you.  However if you evaluate the following Let Statement:

Let(
[
   $$ StartedWithSpace = "this will work"
];
   0
)

It will work just fine.

While this is strange, I am not sure that it useful. In fact my gut tells me it is a bad idea to have variable names start with a space. So I am going to avoid them.

Announcing GoSign v1.0 – Signature Capture for FileMaker Go

Nov 22, 2010, Newbury Park, CA.

Geist Interactive is proud to announce the release of GoSign v1.0.  GoSign makes it easy to add signature capture to any FIleMaker Go solution. With GoSign you can incorporate Signature Capture into any FileMaker Go work flow.  It only takes about 15 minutes to integrate into any solution.

Signatures are captured and stored as Base64 encoded data:urls which makes them easy to display in web viewers or to embed into HTML email.  You can also convert these into PNG files later for storage and display using the free GoSignCompanion plugin.

Geist Interactive founder, Todd Geist, said “I am very excited about releasing this product.  As far as I know this is the first commercial, in application extension to FileMaker Go. This solution requires no other application, no plugins, and no server to do its work.  It is 100 percent FileMaker magic! We have been shipping beta versions for about a month now and have gotten tremendous feedback.  We tried to get as much of our users suggestions into this final release as we could.”

For more information on pricing and to try out demos, please visit the GoSign web page, http://www.geistinteractive.com/GoSign. Site licenses and distribution licenses are available.

Geist Interactive is a FileMaker consultancy known for its creative outside the box style and for deep knowledge of the FileMaker engine.  Todd Geist, Geist Interactive’s founder, has given presentations and training seminars at conferences and events all over the United States and the United Kingdom.   Geist Interactive is located in Newbury Park, CA.

Contact

  • info@geistinteractive.com
  • http://www.geistinteractive.com
  • 805-419-9382

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