# Activity vs UIViewController Lifecycle

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](https://charlesmuchene.hashnode.dev/hooking-into-apps-lifecycle-events-ios-ef433cefdbce). That led me to this discussion between Activity and ViewController lifecycle callbacks.

## Tl;dr

> 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. 😎

* * *

# Assumptions

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.

# Activity/UIViewController Lifecycle

## Activity

From the [Android documentation](https://developer.android.com/reference/android/app/Activity.html) 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](https://developer.android.com/guide/components/fundamentals) 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.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1587882685892/cGyy4lsla.png)

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.

## UIViewController

From [Apple’s documentation](https://developer.apple.com/documentation/uikit/uiviewcontroller), 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](https://developer.apple.com/documentation/uikit/uiviewcontroller). These callbacks are in relation to the **view** that the UIViewController is _managing_ and **not** the UIViewController itself.


![viewcontroller_lifecycle.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1587883305037/RbdaXpGL0.png)

UIViewController's View lifecycle (source https://developer.apple.com/documentation/uikit/uiviewcontroller)

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](https://developer.apple.com/documentation/watchkit/wkinterfacecontroller) 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!

# Conclusion

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.

# Resources
- 
[View Controller](https://developer.apple.com/documentation/uikit/uiviewcontroller)
- 
[Activity](https://developer.android.com/guide/components/activities/activity-lifecycle)