π WWDC2019 | Session : 258 | Category : iPad
π https://developer.apple.com/videos/play/wwdc2019/258
π Dive into the details about what it means to support multitasking in iOS 13. Understand how previous best practices fit together with new ideas. Learn the nuances of structuring your application to support multiple windows, and how to instantiate your UI, handle windows coming and going, and manage your app's underlying window resources.
iOS 12 and earlier
AppDelegate μν (iOS 12 and eariler)
- notify application of process level events
- letting application know the state of its UI
Application has one process and also just one user interface instance to match it.
iOS 13
Application now still just share one process but may have multiple user interface instances or scene sessions.
It's still reponsible for process events and life cycle,
but it's no longer reponsible for anything related to your UI lifecycle.
Instead, that'll all be handled by UISceneDelegate.
β Any UI setup or teardown work needs to migrate to to corresponding methods in your Scene Delegate.
If your application adopts the new scene lifecycle, UIKit will stop calling the old AppDelegate methods that relate to UI state.
If you want to adopt multiple windows support on iOS 13, that doesn't mean you need to drop support for 12 and before.
If you're back deploying, you can simply keep both sets of these methods and UIKit will call the correct set at runtime.
One more additional reponsibility
β the system will now notify your AppDelegate when a new Scene Session is being created, or an existing Scnene Session is being discarded
μ±μ ν°μΉνλ©΄
Before it creates the actual UI Scene, it's going to ask our application for UIScene configuration.
This configuartion specifies what scene delegate, what story board, and if you specifed, what scene subclass you want to create the scene with.
Now our app is launched. We have a scene session.
But we don't see any UI, and that's where our scene delgates did connect to scene session comes in.
Now we see our app.
User swipes up to go back home
At some point in time after, your scene may be disconnected.
In order to reclaim resources, the system may at some point after your scene enters the background, release that scene from memory.
That also means your scene delegate will be released from memory and any window hierarchies or view hierarchies held by your scene delegate will be released as well.
But it's important to not use this to actually delete any user data or state permanently, as the scene may reconnect and return later.
User swipes up on a scene session on switch and explicitly wants to destory it
This finally gives us an opportunity to actually permanently delegate any user state or data associated with the scene such as an unsaved draft in a text editing app.
At some point, these other two background road trip and attendee scenes, have been disconnected and release by the system.
If you don't implement state restoration here, when you go back to the read trip, you're not going to return to the state that previously in.
Instead, start over like it's a brand-new window, and that's now a great user experience.
It works by not any more encoding view hierarchies, but instead just encoding the state which will allow you to recreate your window.
How to best keep application scene in sync.
Only one of scenes updated.
So why is that?
- View controllers recieve an event, may be via button tap, pressing the send button.
- View controllers itself updates its own UI.
- View controllers notifies our model or model controller.
- Architecturally, now if our view controllers, upon receiving an event, immediately and only notify our model controller,
- then we can have our model controller actually notify any relevant subscribers or view controllers, telling them that they should update with this new data
β delegate, notification, Combine