I am writing an iOS app that keeps and displays the state of a system. It basically shows a light whose color represents state:
green/yellow/red light <==> OK/warning/danger
I'd prefer to show accurate state even when the app is backgrounded, and its snapshot is viewed thru the iOS multitask viewer (the view that looks like a rolodex, which you get after double-clicking the home button). I REALLY don't want to show a snapshot which displays an inaccurate state.
So my question is: can you change the view (or perhaps the app snapshot) while the app is in the background, so that when it's viewed in the multitask view it shows an accurate state.
I've seen that this is not recommended by Apple: from App Programming Guide for iOS
Avoid updating your windows and views. Because your app’s windows and views are not visible when your app is in the background, you should avoid updating them. The exception is in cases where you need to update the contents of a window prior to having a snapshot of your app taken.
However, Apple's music app does just this...if you start playing a playlist, then put the music app into the background, the cover art gets updated as the music app works thru the playlist. So this functionality must be possible somehow.
The best answer I can come up with after a bunch of searching is to alter my app's view to the splash image prior to entering background operation. This would ensure that inaccurate state isn't displayed, but also prevents showing accurate state.
You can change the snapshot view immediately before the snapshot is taken (A banking app, for example might want to obscure personal information), but you cannot continue to update the snapshot from the background once your app is suspended. You may want to adopt this approach in order to avoid displaying an inaccurate state; show nothing rather than stale data.
You might also want to consider some other options, such as a "today" widget that contains the updated status or posting local notifications when there is a significant change in status (such as entering the "red" state).
Related
Assume a game app, where user loads some contents into memory during first open. Afterwards they can:
Move app into background
Lock device
Close app completely
Get a phone call
etc...
Is there a way to know when our app's contents are no longer in memory or something of similar sorts to determine when re-caching of assets is required?
I studied few game apps and they tend to do one of the following
Show loading screen every time app comes back from background
Show loading screen only if device was locked or closed (app is still in the background)
And I'm interested in achieving no.2 to not show loading screens unnecessarily each time app comes back from the background.
You can use AppDelegate method applicationWillTerminate
https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623111-applicationwillterminate
And notification willTerminateNotification
https://developer.apple.com/documentation/uikit/uiapplication/1623061-willterminatenotification
If Application not terminate you don't need show any loading screen.
I have an ARKit app which allows the user to add a cube to the scene. This works fine and I can see the cube. But when I push the app to the background and then move the device to another location (by walking to a different room) then ARKit session is unable to determine the correct position of my old nodes.
Is there anyway I can find a workaround this problem so that when the app is resumed from coming to foreground from the background then it still remembers the position of the nodes.
UPDATE: I am looking into saving the lat and long for the user and then somehow converting those lat and long to SCNVector3 to put the node.
You probably won't be able to keep the AR running in the background. Apple does not recommend pausing the session or interrupting it and trying to resume:
Avoid interrupting the AR experience. If the user transitions to another fullscreen UI in your app, the AR view might not be an expected state when coming back.
Use the popover presentation (even on iPhone) for auxiliary view controllers to keep the user in the AR experience while adjusting settings or making a modal selection. In this example, the SettingsViewController and VirtualObjectSelectionViewController classes use popover presentation.
The issue is that once the session gets interrupted, the device stops using it's mechanisms that keep track of AR Nodes as well as your location, might have to set up a mechanism that keeps the app running constantly in the background and running the ARSession through that. You might be able to find projects on github that allow for running in the background. Another issue you might face is Apple's limitations with running apps in the background, which is apparently 3 minutes.
If you're at all interested in restarting the AR Session one you came back in, you can see my answer on this thread.
My app works like this - you press an uibutton and it starts appending data inside a tableView with a specific delay, cell by cell. Sometimes it may take hours to append, because of the manually set delay parameter.
The problem is each time i switch it to background - the app gets suspended after several minutes (up to five usually) and the whole process breaks.
Is there any approach to handling this situation?
Thank you.
That's the designed behavior, an app return to background normally only have very short active time, then it will be suspended, but there are some exceptions:
Apps that play audible content to the user while in the background, such as
Music player app
Apps that record audio content while in the background
Apps that keep users informed of their location at all times, such as a navigation app
Apps that support Voice over Internet Protocol (VoIP)
Apps that need to download and process new content regularly
Apps that receive regular updates from external accessories
Basically speaking, if your app need to interact with outside for resource that can not be generated inside your app, you can apply for background running.
Any every app can legally apply a background task to run for a short time when the app enter background mode.
In your case, even if you implemented the background running, your app will possibly be rejected. If your app is doing the adding to table action controlled by a timer, you should be able to simulate the behavior yourself.
save a the system time stamp locally, maybe in UserDefault
when app launch or enter foreground, get the system time, you can calculate the time difference and figure out how many actions you should take and perform that with a batch action.
after that, clear the saved time stamp ensure next time your data won't be messed up.
I am developing an app where I use iOS's "background app fetch" to keep the data of my app up to date. This is working fine except the "snapshot" of the app is not updated with this fetch.
When I say "snapshot" I mean the image that iOS takes when it goes into the background. This is the image that is displayed for the second before your app loads. At the moment this means users (particularly those on older phones) may see old information for a second or so then have it replaced with new information.
Does anybody know more about when the app takes the snapshot and if this can be forced (for example when I fetch new data in the background).
Alternatively can anybody think of a way I can achieve this effect?
Check out the documentations on Managing the State Restoration Behavior. It's not possible to update the snapshot once you loaded new data from the background. What you can do is to just tell the UIApplication to not show the snapshot but the default launch image using -ignoreSnapshotOnNextApplicationLaunch.
In my opinion however, this shouldn't be necessary. I can image that Apple will improve this with iOS 9.
How about resetting your app to a "neutral" state when it is about to enter the background? Displaying an empty table, for example.
You won't have the latest data, but you won't have wrong data either.
I am creating an alarm clock app that requires some user action within the app in order to turn the alarm off. Below is a picture of what another app, Sleep Cycle, does when you turn an alarm on and press the home screen (i.e. background the app).
Here is an image link (I can't post an image yet, no rep despite my many attempts to answer people's questions today) for the effect I want to re-create.
Those that have used iPhone's Personal Hotspot and connected a device will notice that it is the same effect, where a notification appears at the top of the UI - pushing everything down by around 20-40 points. This is highly desirable to an alarm clock app as it encourages the user to keep the app in the foreground so that the app can easily be entered when waking up (instead of relying on the 30 second sound window allowed by local notifications)
Does anyone have any ideas on how to implement this functionality. I assume that it must go somewhere in the:
- (void)applicationDidEnterBackground:(UIApplication *)application
tag within the AppDelegate, but I'm not sure what exactly I need to be reading up on. So if anyone has a link to some relevant Developer Docs that would also be extremely helpful.
Many thanks for your help,
Ryan
There are a handful of built in 'background modes' that change the status bar's appearance depending on what functionality an app provides whilst it's in the background. The one you've identified (a red status bar) is triggered when an app records audio whilst in the background. I presume Sleep Cycle must be acting as though it records audio just for this purpose. Other background modes include VoIP (which I think uses a blue status bar). Check out Apple's documentation on supporting these various background modes
In your case, you'd want to add audio to the UIBackgroundModes property in your Info.plist file.
But note that it wouldn't be unreasonable for Apple to reject an app during review if it pretends to perform one of these background tasks but doesn't. For example, there have been apps in the past that tried playing a silent audio clip continuously in order to stay awake in the background - needless to say Apple got wise to this and the app in question had to change its behaviour.