Hibernate and Scripts

[bcooney]

I don't have an iPad/iPhone to test, yet! However, I'm wondering about the impact of hibernating.

In the fmgo_dev.pdf doc, at the top of page 13 it states:

"1 When you hibernate FileMaker Go, any currently performing scripts are aborted.

If Allow User Abort is on, you can return to the previous state when you resume FileMaker Go.

If Allow User Abort is off, FileMaker Go will close instead of hibernating. "

What does this mean, exactly. What previous state would I be returning to? A script aborting unfinished could be quite a bit of trouble for those who appreciate data integrity. Do I return to FM after hibernate, and the script continues where it left off?

But KB7734 is more explicit. It says, "FileMaker Go will not hibernate if a file that is opened is running a non-abortable script whenever the close action occurs (home button, receive+accept incoming call). This applies to all opened files regardless of whether they were running a script or not. If the script is set to Allow User Abort [on], FileMaker Go will hibernate."

This is certainly better behavior. However, iPhone users who want to answer a call must wait for a script to finish, yes? Has anyone tested this?

[Vaughan]

The Hibernate function basically caches the current state of the data, then disconnects from the host. When FM Go is opened again the previously saved state is restored and connection is re-established using the previous authentication.

However if there is a script running with allow user abort [off] then FM Go cannot hibernate. I assume (haven't tested yet) that FM Go is closed and the connection to the server closed. Bang, gone.

Because of this I'll only be allowing functions on mobile platforms that are short and simple, at least untilI get a handle on what's happening.

I would not run some kind of script that needs to run for more than a couple of seconds.

[Bailey Kessing]

I am loving the reconnect after exiting on the iPad. I wish that the reopen all databases where you left off was also on the desktop.

[Vaughan]

The re-connect is great. It's the unconditional severing of the connection that I'm concerned with. From what I can see there is no way to stop it.

So the user starts a process on the mobile device that will take half a minute to complete... when the phone rings and they answer it. The process is aborted and left incomplete.

[bcooney]

But, Vaughan, as you say, that process abort only happens if the script is set to Allow Abort On. As you say, careful thought must be given to mobile users. Their connection is tenuous. In NY, cell service drops often (tunnels). So, yes, processes that are short and sweet.

Seems to me that I'll be setting up dedicated mLayouts, with carefully selected functionality.

Edit: I see don't see how a previous state of data can be restored (maybe the data has been edited since Jim took his phone call). I'm thinking this is a cousin of SnapShot link. What about record lock?

Edited July 22, 2010 by Guest

[Todd Geist]

This is indeed something you need to be very concerned about.

FileMaker Go is awesome and I love it! But you need to understand a few things otherwise you could get yourself in trouble with scripts that do lots of data processing.

I have already written about this on my Blog

http://www.geistinteractive.com/blog/2010/07/filemaker-go-and-transactions

And it is also covered in the Tech Brief from FileMaker. But basically it comes down to this.

You can't guarantee that a script will complete on iOS. If a phone call comes in while a Script is running, the script is immediately terminated. It will never complete. This could leave your solution in a state that you did not intend, where half of the edits your script made went through and the other half did not. Imagine the problem this would cause in a solution like inventory management where things must balance.

This problem is not as severe on the iPad as it is on the iPhone, but it is still a problem that we developers have to deal with.

There are a few ways that you can deal with this. They boil down to roughly two choices.

1. Don't do complex data processing on FM Go. Offload it to FileMaker Server.

2. Write your script so it doesn't matter if the complete or not. This is possible if you use transaction processing as I discuss on my blog, and is cited in the Tech Brief.

This is by no means the end of the world. It isn't too hard to get your head around.

Todd

Edited July 22, 2010 by Guest

[bcooney]

Todd,

Yes, your transaction technique becomes even more critical. You state that "if a phone call comes in while a Script is running, the script is immediately terminated." That's not what the KB article states. Seems that if User Abort is Off, the script will continue and then the user can answer the call.

I don't have it to test. What have you observed? I'll head over to your blog post...

[Vaughan]

But, Vaughan, as you say, that process abort only happens if the script is set to Allow Abort On.

That's not how I read it. From the FM Go Developer Guide on the top of page 13:

When you hibernate FileMaker Go, any currently performing scripts are aborted. If Allow User Abort is on, you can return to the previous state when you resume FileMaker Go. If Allow User Abort is off, FileMaker Go will close instead of hibernating.

So the script is aborted regardless of the user abort state. The difference is whether FM Go hibernates and the previous state is remembered (user abort = on), or whether FM Go is closed and the previous state is forgotten (user abort = off). I don't know of "return to the previous state" also means "pick up the script where it was interrupted." Testing will be required.

It's worth remembering that all of this applies only when scripts are running. A good plan would be to make the mobile interface as script-free as possible: by that I mean, not keeping the user in a loop or running long processes.

I reckon if you have a FM Go app running processes where the user is browsing records, performing finds etc, then it should all be OK. I'm concerned with processes that modify data and take time to complete. IMHO these would be best left for the desktop client.

[Vaughan]

You state that "if a phone call comes in while a Script is running, the script is immediately terminated." That's not what the KB article states. Seems that if User Abort is Off, the script will continue and then the user can answer the call.

You refer to this article:

http://help.filemaker.com/app/answers/detail/a_id/7734

That's starting to get confusing. The information is conflicting. I'm going to have to do some testing.

[bcooney]

Thank you! Yes, they ARE contradicting themselves. I'm not crazy.

Tech Brief by S. Love:

"Another important reality of working in a mobile world is that scripts can be aborted at any time, regardless of the

Allow User Abort settings and ordinary operations of FileMaker, when a user either switches to the Home screen

(by pressing the Home button) or receives an incoming phone call on the iPhone (which closes FileMaker Go). " Top of p.8.

[Todd Geist]

Hello again

The knowledge base article cited above is definitely confusing, but it does not actually contradict the tech brief. They are really talking about two different things

The confusion comes from the word "hibernate". When FileMaker Go hibernates it saves the current state of the file. Lind of like the "snapshot link" in FileMaker Pro. But it does not pause the running script. So "to hibernate" simply means "to save the state of the file".

FileMaker Go hibernates when the close action occurs and a script is running with User Abort ON.

It does NOT hibernate (ie save the state of the file ) when the close action occurs and a script is running with User Abort Off.

But in BOTH cases the script is simply terminated, and the Phone comes to the front. There is no way to stop this from happening.

I hope this helps clear up some of this confusion.

Todd

Edited July 23, 2010 by Guest

[bcooney]

Thanks, Todd. My, oh, my, how careful we'll need to be.