Jbsherry

Mobile Solution with On-Window Timer causes problems with SDK

Discussion created by Jbsherry on Aug 21, 2018
Latest reply on Aug 22, 2018 by Brian Hamm

Hi all,

I've got a Mobile solution with an On-Window Timer to update time-remaining statuses,  that's been working great for years as an FM-Go app. I've been testing as an iOS app, and the app has problems resuming. It appears to fall into the scenario described in another discussion:

"

Killing the app is equivalent to force quitting the desktop application, so a lot depends on what the file/solution was doing at the time the force quit was initiated.

 

The best action is to close your file before killing the app, or hit the home button once before killing the app.

 

TSGal

FileMaker, Inc."

 

iOS doesn't support closing the app, of course. If you try to use the Close file option or Exit Application, the file will just resume. However, the method of exiting the app effects whether the app resumes or just sits on a grey screen with a spinner, and the description above did help me to identify the different cases more specifically:

1. Closing the app when NOT on a layout with On-Window Timer - the app resumes smoothly no matter how it was closed.

2. Closing the app when ON a layout with On-Window Timer

a. Switching to another app and then switching back - resumes fine

b. Going home ( or another app ) and then double-tapping and swiping the app closed - resumes fine

c. Swiping the app closed while in the app - never resumes, a spinner simply appears. If one single-taps to return to home and then re-opens the app, it resumes immediately.

 

With case 2c, it's almost as if the On-Window Timer prevents the app from resuming properly until the state is first saved properly. If one didn't save it before quitting the app, then one has to save it on re-opening it, in order for it to work. And in case it wasn't completely clear, when the file loads from scratch, it does NOT start on a layout with an OWT. The On First Window Open script does some housekeeping and then conditionally navigates to the layout with the OWT. In case 1 above, the app may not actually be resuming but running the On First Window Open, but that will put the user on the exact same layout, so it's pretty transparent.

 

Has anyone seen this? Are there any workarounds?

 

Thanks,

-jb

Outcomes