I can confirm that this happens. Oddly, it even happens if you enable alwaysOverwrite.
I think this happens because after the app is opened for the first time it never actually "opens" another window, you're essentially going back to a window that's already open every time you relaunch the app. I assume that the app remembers the window setup when going into the background so it's not really possible to get another "First" window open.
If you run a close window script on the only window in your application, a new window is automatically spawned and your startup script runs, so I'm pretty sure this is what's happening. If so then that's a little problematic as we have no obvious way to perform actions when an app is launched, the user will just always go back to where they were. There may be other techniques that we can use to handle this. Is your launcher file the main application file? Perhaps having the launchSolution file be a file that only opens another file is the correct way to do things. I'll test that and post back my findings here.
thanks for the answer..
I'm digging the idea of a launcher,
My first attempt at a launcher:
- On first Window Open Script, opens TestApp.fmp12 and then closes itself
- Same issue: When reopening the app, even after restarting the device, I am taken to the main app and the launcher file doesn't open.
So the launcher file only seems to run the first time the app is opened after installing. Not ideal, but it does make some sense.
no clue yet for me either...
maybe next Richard Carlton's webinar brings some ideas ???
YannLiqueurSalzedo and alecgregory:
Thank you for your posts and detailed information. I have sent everything to our Development and Testing departments for review. When I receive any feedback, I will let you know.
In my case, I am testing a simple launcher file with a single field and using the url protocol for opening the hosted files, with failure conditions etc.
My findings are the same, in that once the app has successfully launched and connected to the host, each time it is re-launched it returns to where it was last left, bypassing the launcher file (it seems). However... if for any reason it is unable to reconnect to the hosted files, then the launcher file is used again and I am returned to a local layout to enter an IP for the remote host.
Trying an 'exit application' or closing all windows etc just results in what I would describe as a close/resume.
It works, but It's not idea, in my opinion. I would like to see a way to properly close the app and a way to force the launcher's scripts to run each time it is opened fresh, rather than it always resuming from where it last was in the hosted files.
Thank you for your post.
I have attached your comments to the original report.
Development and Testing recognize the issue. If you place a Close File script step on the layout, then you will see OnFirstWindowOpen trigger each time the file is reopened.
Thanks for the reply.
Can you elaborate a little? Which layout do you mean? It sounds like you're saying the user will have to manually close the file, even if when opening the app after a restart of their device. Is that right or am I missing something?
It's not clear from the Tester's notes. I've asked for clarification.
For now, try placing a button on a layout that closes the main file. When the application is re-launched and the file is opened again, it should then trigger the OnFirstWindowOpen script.
I have not had much time to experiment, but thought I would give things another quick try this evening and after reading your post. It seems I have made a mistake because what I was looking for seems to be working.
Just for info, here is the process I am running:
1. My launcher file is scripted to go to a 'connect layout' for user input it's not the default 'on open layout' because the same file has multiple uses, depending on deployment, so the opening sequence is all scripted.
2. On this layout, the user enters the host IP and presses connect.
3. This runs a script which changes layout to a 'connecting...' just to give some visual feedback that its doing something and then attempts to open the remote file via url using the IP entered and calling a script in the remote file.
4. Then some some housekeeping etc etc.
From this point, I had an issue where I couldn't close out of the remote file and get back to steps 1 & 2, no matter what I tried, i.e. buttons for exit app, close window, close files or combo's thereof...each time it would just re-open the remote file.
However I obviously made a mistake somewhere along the lines. I will have to compare my previous attempts to my current one to discover what I did wrong.
In my latest test I am now able 'Exit application' to close the remote file and return to the launcher file, ready for user input to connect again. It must be running the launcher files startup script, otherwise it would leave me stranded on the 'connecting...' layout as it does if I just close the window (as expected). I will keep experimenting, but so far so good
If a user double taps home and then swipes up to close the file, when the app is restarted the OnFirstWIndowOpen script does not launch. Does FM consider this a bug? I would.
thank TSGal for your feedback...
I'll try asap
Something related to this that I have also found is that I typically use a 'Hide Toolbars [Lock; Include Edit Record Toolbar; Hide]' in a script set to run 'OnFirstWindowOpen', and this works when the iOS SDK app is first opened, but then when the app is closed by swiping it up in the app switcher the 'Edit Record Toolbar' re-appears above the keyboard when fields are entered when the app reopens....
To get around this I have to use a script trigger set for 'OnObjectEnter' which runs the 'Hide Toolbars [Lock; Include Edit Record Toolbar; Hide]' script... Quite a bit of overkill having to put that on every field! I could also just trigger it OnRecordLoad or LayoutEnter, but those events don't seem to fire when the app is closed and reopened.
... In any case, I have had to rethink how to best use triggered script steps. No big deal, but does need consideration.