ProMaps: Google Maps for FileMaker Pro

We’ve simplified GoMaps to work on desktop versions of FileMaker Pro solutions and named it ProMaps. The relationship graph got dead simple so you can paste the map right on to your existing layouts. (And the map is scriptable, so once you click on a pin, you can run your own scripts from the property detail within the map.)

ProMaps is completely unlocked for you to modify and extend.

promapslarge

And if you need both GoMaps and ProMaps, you can save $100 with our Maps Bundle.

Download the demo and check it out.

Modding Live Files with GoZync

Once you distribute offline files to your users, how do you keep making changes, fix bugs, and re-distribute the files without breaking things or ending up with duplicate files on someone’s iPad?

GoZyncGoZync makes this easy, and this short video shows how. It also demonstrates that GoZync can let you recover from schema errors you might introduce when you’re defining fields. You’ll see how we capture errors (like “the field we’re trying to sync is no longer there”) and let you re-play a sync after you’ve corrected it… without having to ask the remote users to sync again.

This is one of my favorite parts of GoZync. Hope you enjoy it.

Learn more about GoZync at http://www.gozync.com

Webvier “Portals” – preview of SQL Explorer Next

Jason’s swapping out the results portal in our free SQL Explorer with a webviewer so he can take advantage of column resizing and other UI goodies you just don’t see in FileMaker. The second part of the video shows how he lets users easily swap out the styles used in the “portal” as their layouts change.

HTML5 in FileMaker apps. Yummy.

Go Faster

Todd and I have been working on some changes to GoZync, and the latest build offers a substantially faster sync down from hosted files.

In one test, pulling 5,000 new contacts went from 12:52 to 2:00 minutes flat. (Times will be longer on mobile and over shaky connections.) This is a big improvement.

Add this to Your Deployment

Needless to say, we recommend this for all users: only 4 scripts were changed so updating existing deployments is easy, though you will need to distribute new copies of GoZyncMobile, where most of the work was done. Instructions for making this change in deployed copies can be found here.

I’m very proud that GoZync is comprised solely of FileMaker scripts: most of our users are customizing GoZync to match their workflow and it’s important that they can take advantage of new builds like this by just replacing a few scripts.

Backstory

Todd started looking at this with an insight that Position() and Middle() degrade when working with long strings. That is, in a 1M character string (like a sync package)…

Continue reading

SQL and the Found Set, Part 2: RecordID List and Hyperlist

Background: ID Lists

I have one thing (at least) to follow up with on my ExecuteSQL using the Found Set post from a little bit back.  This was to see if I could get the RecordID parsing optimized (or at least faster) using some of the techniques in Todd’s Hyperlist demo.  Although this is not the slow part of the process–feeding the large set of values into the SQL IN clause is the slow part–it still did seem worth pursuing for two reasons:  Firs,t to get my head around Hyperlist and the underlying theory that appending strings (lists) is a costly process and, second, there could be some practical value down the road in  having a fast way of getting RecordIDs.  The RecordID and Hyperlist method does (in theory) work on the Server, as it can save Snapshots to the Documents folder. The ExecuteSQL using the Found Set idea may also have some limited practical value in certain situations, although in 99% of the cases Hyperlist performs significantly faster.  There may be a point where the overhead of adding a lot of additional columns to the process is lighter using the ExecuteSQL method, but just a loose theory.  It does have, for me anyway, significant educational value. For gathering the RecordID List, we’re “scraping” an exported snapshot using InsertFromURL.  This works great and is basically instantaneous.  Unlike using a Web Viewer for the scrape, InsertFromURL can be called directly after the Snapshot is exported.  For the web viewer, you need to Pause for it to refresh, and even then it doesn’t always work.  I’ve banged on the InsertFromURL method a bunch with no Pauses and never a problem!  Reading the RecordID is easy, but they’re in this format of mixing single values and range expressions:

41223
41228
41231-41332

and of course, we have no native way of interpreting that in our available tools.  My first approach to this was to convert this format to something I could use in SQL:

WHERE ROWID IN ( 41223,41228 ) OR BETWEEN 41231 AND 41332

and that does work although it’s super slow depending on the size of the IN clause and number of BETWEEN clauses.  Using this RecordIDList technique,  I’m going for a straight list, so I can still use this for the SQL as a single IN, and who knows?   Maybe it will work better than the combination of clauses.  It also seems like something that may have some value outside of this SQL application.

Applying (and tweaking) Hyperlist

I think the most striking thing with how Hyperlist works is the large $expression variable that Todd builds to combine the record values into chunks of 100:

Substitute(
"GetNthRecord( fieldName; rec ) & $Sep &
GetNthRecord( fieldName; rec + 1  ) & $Sep &
GetNthRecord( fieldName; rec + 2 ) & $Sep &
GetNthRecord( fieldName; rec + 3 ) & $Sep &
GetNthRecord( fieldName; rec + 4 ) & $Sep &
etc. to 100.”

For those of us who feel so clever having “mastered” recursion and the difference between Tail and Stack, this seems strange.  Well there might be a “more clever” way of doing this, the results clearly show us that there’s not a faster way.  As my appreciation for this method grew, I started thinking of it like Jefferson’s Auto-Pen, which is quite an elegant tool when you look at it. My problem is slightly different.  I need to create a list, not from a group of records, but from a range expression.  What I used is actually quite similar to Hyperlist:

“$sc_c & $sc_Sep &
$sc_c + 1 & $sc_Sep &
$sc_c + 2 & $sc_Sep &
$sc_c + 3 & $sc_Sep &
etc. to 10.”

I only did chunks of 10, probably partly out of laziness, but also because it made more sense since the range expressions will almost always be less than 10, with the most common exception being a full normalized found set.  Even then, 10 is still wicked fast compared to the appending method.  I know that Todd did some testing and found that 100 is the sweet spot, but 10 will do in a pinch! The next part of Hyperlist is the combining of the lists of 100 you just created.  Todd uses a very cool algorithm for this, that I imagine may have a name.  It combines two strings into one, so in log2 iterations.  I was so enamored of the Auto-Pen idea at this point that I thought it could be applied to the re-combining problem as well.  I came up with this second $expression variable:

"$sc_subList [ $sc_c ] &
$sc_subList [ $sc_c + 1 * $sc_v ] &
$sc_subList [ $sc_c + 2 * $sc_v ] &
$sc_subList [ $sc_c + 3 * $sc_v ] &
etc. to 10.”

This would combine my lists 10 at a time, so just log10 iterations instead of log2.  Of course, since you’re combining more lists per iteration, there could be no benefit at all, but I can tell you this is now “Hyper” level fast.  I will try and come up with an apples to apples test on the combining methods…soon.  However, I will say my primary reason for wanting to use this method is the chill that I imagine my Middle School teacher’s heart feels every time I talk about or use anything vaguely “logarithmic.”

Weave: Calendar overlay by Intuit

photo-1Weave is cool little app that begins by reading the event kit data from your iPhone and showing your calendar events in a rough todo list.

You can’t do much with these existing events, but you can make new to-do items. And when you go to mark one as “done”, you see the screen at the right.

And you can see how Weave can get you to log your time and track your expenses. Pretty cool. Screenshots of weave on the app store show project income and expenses and the tasks completed by others.

Now you’d think that these income and expense entries would go to Quickbooks online, but you’d be wrong. Weave’s data is completely siloed. And you know, that’s OK, because that’s how you get apps out and see what’s working. And pleasantly surprising from a big org.

Connecting the dots for Weave would mean that users who did have an account could do these things (log time and money) to existing items in event kit (items from iCal, Google Calendar, etc.). Then weave really would be a financial layer over iCal.

Not bad.