I can't comment from an engineering point of view, but I believe from my own experience that Go only actually closes the file when the last window of a file is closed in Go.
My experience is also that the closing of Go via the iOS app-closing process still leave any Go file open within the app's settings so it tries to reopen it's window next time Go is launched.
This isn't expected behavior based on Pro on a computer, but it is similar to many other apps trying to restore you to where you were when you last used the app. I make it a point to close each file's open windows before leaving Go for this reason.
I, also, would like to hear from FMI on this peculiarity of Go. It seems more intuitive from a FileMaker experience point of view that closing the app so it's not hibernating or in the iOS background should close the open files. I can see how the nature of iOS means that the onLastWindowClose triggered scripts might have trouble running on closing an App.
We don't have a "close" button on our file - it opens in kiosk mode/full screen so it simulates a native app - we install a home screen icon via an iOS profile so users click that to launch the database and be taken directly to it's home screen, so they never normally see the FileMaker Go interface.
I've been doing some tests to see when the OnFirstWindowOpen script trigger fires and in all my tests so far I've found that the OnFirstWindowOpen script trigger does not run when the file is left open and you:
- open FileMaker Go after it has been quit by double clicking the home button and removing FileMaker Go
- restart the iPad and open FileMaker Go
I gather this is expected behaviour - wondering if there's anyway to get FileMaker Go to "close" the file internally without the user having to click a close button. In our case we don't offer a close button as users will only be using our solution and click the home button when they need to get out of it, but we need the OnFirstWindowOpen script trigger to run more frequently than it is at present (which appears to be only the first time they actually open the file - as they never manually close the file it appears to never close again).
What is your triggered script doing that you would want the file to do when awoken? There might be another way to skin the cat.
P.S. As an aside, it's kinda dangerous never to close the database file. It prevents normal housekeeping from running and can wind up corrupting the database. Might want to reconsider including a "close" function for the users.
The main issue is the counter that counts the number of times the file has been opened. We need to do some authentication after a certain number of launches.
We're using a home screen icon and kiosk mode to hide the FileMaker Go interface to keep things really simply for our users so they can just click the home screen icon to go directly into the database.
When you say “authentication”, what do you mean? Back to a server, perhaps?
Yes the user will be prompted to verify they are a valid current user against a hosted database on a server - they just enter some details which are then validated against their user record on the server.
1 of 1 people found this helpful
Okay, that might give us another route. What about using an OnTimer script to check to see if the user is “in” (by, say, writing a timestamp to a field) periodically? You could then look for a larger-than-normal gap in the timestamp. If there is one, you could pair that with your OnFirstWindowOpen script to count “logins” (which would be a combination of actual logins and longer-than-normal gaps in the timestamp sequence from the OnTimer script).
Might not be perfect, but it could be close.
I am confused about when you mean 'close the application' and 'close the file'. The application will not close, even when the last window is closed, even if you re-start, even if you re-boot. Outside of fiddling with the installations, the only way to entirely unload it is to double-click the Home button and push its graphic representation(s) up. This may not seem like ideal memory management, but it's the way iOS currently works, and has nothing to do with Go. The 'Exit Application' script step is essentially meaningless on iOS and should be greyed out when steps are filtered by platform.
Which left me unsure when you wrote 'if I double click the home button and quit the FileMaker Go app so it's not currently running' if you meant the method I just described-- sliding any iterations of the app up and off the screen. If you did that, the file and the app should be completely closed. If that is not the case, something else is going on.
You might avoid the ambiguity between desktop-think and iOS reality by tracking the file openings to something more permanent-- an audit file, a local table, or the host. That way you can at least remove a global field and the question of its state from the equation. Make your trigger is the file's on-open script, not its closing.
I created a simple demo file that increments a counter in a global number field everytime the OnFirstWindowOpen script is performed. I copied the file to my iPhone and opened the file and it was set to 1. I then tried the following - leaving the file open in FileMaker Go:
- double clicking the home button and sliding FileMaker Go up
- turn the iPhone off completely
Each time I then subsequently opened FileMaker Go my file was still open and the counter remained at 1. It appears that I have to actually "close" the file to get my OnFirstWindowOpen script to fire again.
I may be mistaken, but I don't believe you can post attachments to this list, so I have no way to test your file. As a substitute, I built my own, with one table and one global number field. I created a script to increment that global by 1 OnFirstWindowOpen, and it does so if I close the file and re-open it, or close the file, 'exit' Go by double-clicking the Home button and sliding Go up out of the way, and re-opening the file. I would not expect it to increment if I merely turned off the device and turned it back on, and it did not.
It did not increment when I re-booted the device without first closing Go, and that also makes sense to me, as the file was never closed and re-opened.
So the only difference between what I am seeing and what you are reporting is what happens when you exit the app using the double-click-the-Home-button method. You did not say whether you first closed the file. If you did not, your file is behaving as expected.
On the desktop, a global field in a local file defaults to the value it held when the file was closed, and I assume that is also true for Go. But, given the way iOS handles memory so differently than the desktop that seems a dicey assumption, and even on the desktop I would not rely on the value in a global field's value at file close. Is there some reason you're not writing this counter to a non-global field someplace?
1 of 1 people found this helpful
You'll need a different solution. Maybe have a 30 day check instead of a # of opens. I'd leverage an existing script users run commonly than an onTimer script.
fmdataweb wrote, in part:
... increments a counter in a global number field everytime the OnFirstWindowOpen script is performed. I copied the file to my iPhone and opened the file and it was set to 1. ... Each time I then subsequently opened FileMaker Go my file was still open and the counter remained at 1.
Yes, that's how global fields work: When opened locally they open with the value they held the last time it was opened locally. When hosted, they still open to every individual user with the last value they held when closed Unhosted. So the file is always going to open with the value 1 if that's how you closed it Unhosted.
So the approach of incrementing a global number field won't tell you anything reliably about whether or not the file is closing fully.
I'm aware of how globals work etc - my question was around my expection that when you either turn of your device or double clicking the home button and slide FileMaker Go up that either of those actions would effectively quit the FileMaker Go app and close any open files. This looks like it is not the case - the files remain "open" after a restart/quit of the app so the OnFirstWindowOpen script trigger never fires again unless you manually close the file.
In our solution we are leaving it open in kiosk mode as it's the only FM Go solution the users will be using so there's no need to close it, but that obviously means you can't rely on the OnFirstWindowOpen script trigger to run more than once.
Is there a reason for not including a "Log Out" button in the kiosk mode file? If you are running it as a single-window file interface, setting a "Log Out" button to close the current window should do the trick.