I've had the opportunity to work on Android for a while now building a career on it. In 2017, I got the privilege to dive head on into the iOS waters when I built an MVP app for my previous company. Back then, I learnt by trying to map the concepts one-to-one: AppCompatActivity to UIViewController, XML layouts to StoryBoard/Nib Files etc. Luckily, the company hired a full-time iOS dev who shaped the app in accordance to iOS platform guidelines and industry standards. I retreated to do minor bug fixes and code reviews as I watched and learnt iOS development from the pros.
Sometime back, I came across a view controller lifecycle-related challenge which I cover in another article. That led me to this discussion between Activity and ViewController lifecycle callbacks.
The Android and iOS teams have taken different approaches in application platform designs. Blindly borrowing concepts from either platform will only result to chaos in your app development. Invest time learning each. 😎
In my opinion, taking a one-to-one possible mapping in concepts can be a shortcut to dive into the other platform but I think understanding the basics of how each works will be most helpful in the long run.
One of the biggest assumptions I made was that Activity lifecycle callbacks map to ViewController callbacks. Let’s look why this isn’t necessarily the case as we look beyond the basics.
From the Android documentation we get the following:
An activity is a single, focused thing that the user can do. Almost all activities interact with the user, so the Activity class takes care of creating a window …
But let us go with a clearer explanation presented elsewhere in the documentation:
An activity is the entry point for interacting with the user. It represents a single screen with a user interface.
You use an instance of the activity to place your UI but we are more interested in its lifecycle (and related callbacks).
Activity lifecycle (source developer.android.com)
From the image above, we can count 7 lifecycle callbacks methods exposed by the activity to hook up your logic. There are other supporting callbacks, for instance, methods to save the activity state in a bundle. All these are in response to the activity’s lifecycle itself. For an instance, when the activity is going away (e.g the app is backgrounded), a series of callbacks in the activity, starting with onPause(), are invoked in response. One may expect a corresponding behavior in the ViewController but let’s have a look at it.
From Apple’s documentation, a UIViewController is:
An object that manages a view hierarchy for your UIKit app.
From the documentation, we can see that one of the main responsibilities of the view controller is to manage a view (for which it maintains a reference using the view property). In the view controller, you can override view callbacks e.g. viewDidAppear(), viewWillDisappear() etc. Check out the state transition diagram and corresponding literature here. These callbacks are in relation to the view that the UIViewController is managing and not the UIViewController itself.
UIViewController's View lifecycle (source developer.apple.com/documentation/uikit/uiv..)
Nevertheless, in regards to detecting when the UIViewController is going away, the best bet is to still rely on the view*() callbacks e.g. viewDidDisappear() is invoked after a view controller has been dismissed by the presenting controller. NB: child view controllers have lifecycle methods e.g. willMove(), didMove() etc in which you can use in your app. Also, WatchKit has methods awake(), *Activate() and *Appear() that hook up well with the WKInterfaceController’s lifecycle events.
viewDidLoad(), therefore, is technically not the corresponding equal for onCreate() even though both are called in the initial stages of their parents’ lifecycles. The former is called after the controller’s view is loaded into memory and the latter is invoked when the activity is starting. Clearly, these two can’t just be mapped one-to-one!
Hope this article has debunked any ideas of blindly comparing Activity’s and UIViewController view’s lifecycle callbacks. I can learn a thing or two on how you approach either platform using the knowledge you know about the other.