I have a simple "timer" watchOS app that uses hierarchical navigation. I can press the digital crown to return to the watch Springboard, then tap the app icon and be returned to the same interface controller I was using.
If I return to the watch face and tap my app's complication, the app is launched, but appears to have restarted: I lose my current state. Is there any way to prevent this?
It sounds like you're asking how to stop your app being swapped out of memory?
If so, just like on iOS this isn't possible - and obviously the watch has less memory than a phone so is more likely to be swapped out.
What you need to do is store your state in some persistence layer - e.g. NSUserDefaults - so when the app restarts it can reload its state
If you open your watch app by tap complication, the app will automatically back to root interface controller(s). This is a system forced behavior.
If you want to preserve previous state, you need to change your app's hierarchic to page-based interfaces.
User interaction in page-based interfaces can be just like navigation-based interfaces. You can replace pushController(withName:context:), pop() and popToRootController() methods to becomeCurrentPage(). I also found switch from one page interface to another is also faster than navigation (push/pop) to another.
Related
Should my app be updated to Scene Delegate from App Delegate. My app supports ios 13.0 and up
first you have to understand what is difference
You could think of them as the global and private versions. One is shared and the other is limited to the individual owner. In a way, they are exactly what you would expect by the names.
Multi-window support is happening
Next time you create a new Xcode project you’ll see your AppDelegate has split in two: AppDelegate.swift and SceneDelegate.swift. This is a result of the new multi-window support that landed with iPadOS, and effectively splits the work of the app delegate in two.
From iOS 13 onwards, your app delegate should:
Set up any data that you need for the duration of the app.
Respond to any events that focus on the app, such as a file being shared with you.
Register for external services, such as push notifications.
Configure your initial scenes.
In contrast, scene delegates are there to handle one instance of your app’s user interface. So, if the user has created two windows showing your app, you have two scenes, both backed by the same app delegate.
Keep in mind that these scenes are designed to work independently from each other. So, your application no longer moves to the background, but instead individual scenes do – the user might move one to the background while keeping another open.
at last I will say that you can go with Scene Delegate
Courtesy of https://www.hackingwithswift.com/articles/193/whats-new-in-ios-13
I have a doubt:
I have an app with 10 views. I want that, if the user is on View1 and sends the app to the background, it terminates the application (exit (0)). But I wanted this to happen only on View1, on the other screens, if the app goes to the background and then returns, it will continue where it left off.
What can I do?
Apple's guidelines seem to be strictly against terminating your app programmatically (for example, with exit()); it would go against what iOS users expect of how apps work.
Instead, I recommend the following approach:
When the app is sent to the background (applicationWillResignActive(_:) is called), check which view controller is currently being displayed.
If it's such that you wish to start over next time the app is brought to the foreground, just reset the app window's root view controller to whatever the initial view controller of your app is (typically, it involves reloading the inital view controller from Main.stroyboard, but your setup could be different).
You can not choose at runtime whether your app goes to the background or is terminated when the user presses the home button ("multitasking"); that is set in stone in your Info.plist file at build time.
Also, remember that even if you are in the screen that you wish to preserve when the user resumes, your app might be terminated by the system while it is in the background (to reclaim scarce system resources), so in that case it will still start from the initial screen. To prevent this, you might want to check out the APIs for state preservation and restoration.
Here is another SO question asking how to find the identity of the current view controller. Why not query the current view when you receive applicationWillResignActive indicating that your app is going to move to the background and then choose the action you want?
As far as I understand your description Preserving and Restoring State is what you are looking for.
Excerpt from Documentation:
The preservation and restoration process is mostly automatic, but you need to tell iOS which parts of your app to preserve. The steps for preserving your app’s view controllers are as follows:
Required
Assign restoration identifiers to the view controllers whose
configuration you want to preserve; see Tagging View Controllers for
Preservation.
Tell iOS how to create or locate new view controller objects at
launch time; see Restoring View Controllers at Launch Time.
Optional
For each view controller, store any specific configuration data needed to return that view controller to its original configuration; see Encoding and Decoding Your View Controller’s State.
Here is a link to Preserving Your App’s Visual Appearance Across Launches
I have an app (iOS, Swift) which is usually started in the morning by the user. The user will press a couple of buttons, enter some text, move to other views (using a navigation controller) and so on. When everything is filled out the right way, the user will put the iPhone into standby mode. As far as the app life cycle is concerned, it will enter the background state. When the user opens the app again, he will still be on the same page, with the same parameter, ... Everything is fine.
In case of a suspended app (due to a lack of resources or other stuff), the app will start again from the beginning and not from the view where the user has navigated to before. In such a case, what's the best way to navigate to the specific view the user was when bringing the phone into the standby mode and keep respectively build up the whole navigation stack as it was before the suspension?
You can use Apple state restoration and preservation technique for this purpose. Here you can find an example provided by Apple.
Hope this will help.
In xcode you need to specify the initial interface controller for the watch app, which is the entry point of the watch app, shown first when you open it.
But is it shown every time you open the watch app? For example you open a watch app, navigate to a page, close it, and open it again. Does it open on the page you were last time (like on iOS), or again on the first interface controller?
According to apple documentation:
Normally, WatchKit displays the first interface controller in the sequence initially.
Well, normally is not every time. I looked through watch app videos from the watch presentation event, but there wasn't a case when they opened an app twice.
That's a great question!
Main Entry Point
First off, you can certainly avoid showing that MainInterfaceController each time. See this thread for more information where I detail exactly how to use that entry point to launch the appropriate set of InterfaceController objects.
Watch Extension Lifecycle
It is VERY important to understand what the expected lifecycle of a Watch Extension actually is. It will only run while the user has the Watch up and is running your app. This will generally be 1-5 seconds (opinionated value). As soon as the user lowers their wrist, your Watch Extension will be terminated completely. Therefore, it is going to be restarted every time at the same entry point. This means that you need to track your app state if you want to launch a different page set in the MainInterfaceController.
Hopefully that helps shed some light.
If your WatchKit extension is still running, it will pick up where you left off. If not, and everything has been dumped out of memory, it should start again with your initial interface controller.
I'd like to add some code to the app delegate that resets the view hierarchy back to the beginning.
My app is basically a demonstration mockup, and I'd like EVERYTIME the app opens that it resets to the first view in the storyboard, and doesn't remember what page the user was on when they closed or 'minimized' the app.
I'm using iOS sdk 8.1, and Xcode 6.
Putting aside that it's actually quite bad user experience - it's very easy to do. You just need to specify that your app doesn't run in the background, and each time user closes app, next time - brand new copy will be launched.
Here is what you need to set in your project properties in Xcode:
If your'r info.plist Show raw keys/values option are enabled, the property is named UIApplicationExitsOnSuspend which you can get by right clicking on the empty space of info.plist properties table and selecting Add Row option as follows
and right after that you will be presented with following option,
where you can select second options which is Application does not run in the background.
Selecting the mentioned property and setting it to YES, the app opt out of background mode and it cycles between the not-running, inactive, and active states and never enters the background or suspended states and moved back to the not-running state. In other words, iOS will not preserved any states which allows the app to run as fresh on next launch.