iOS <> Android Vocab Cheat Sheet
A couple months ago while at Venmo, @chrismaddern and I discussed the lack of a bidirectional dictionary/vocab list of parallel terms in Android and iOS. It's important to know what your teammates are refering when they talk about code, even if you're not engaged with it every day. This is a beginning attempt to finally break down that knowledge gap. The goal is to allow developers of one framework to understand the basics of the other and should someone want to make the switch, this can be a resource in helping learn the new framework.
If there's a topic that you think would be interesting to discuss, tweet at me and we'll get include it in this list. I'll be updating this post with links to all future posts.
Disclaimer: I'm an Android developer and have done minimal iOS/Objective-C programming. If there is anything incorrect, reach out and I'll fix it as soon as possible. I'm assuming iOS developer are not, on the whole using Swift yet, so all references will be to Objective-C.
UIViewController vs. {Activity, Fragment}
Both frameworks have concepts for a View Controller - a central place for code that bridges the gap between Views and Models. iOS leads the way here in that UIViewControllers are composable (a parent VC can contain 1 or more child VCs). Fragments are a closer resemblance to UIViewControllers, though they cannot live on their own, they must be contained within an Activity. Before Android 4.2 (API 17), you could not nest Fragments (though Fragments in the support library provide backward compatibility). Activitys encompass one single screen, but otherwise have a very similar API to Fragments. Often, developers might have an activity that only has one Fragment as a forward-thinking API design, should they ever want to include the fragment in a tablet layout alongside another fragment.
[self loadView] [self viewDidLoad]
onCreate() // Activities and Fragments onCreateView() // just fragments
These methods are where the the view is created and configured, respectively. In iOS, if you have a NIB associated to your view controller, loadView isn't necessary; if you don't, then you must call
self.view = /* your root view */;
To set the root view in Android, call setContentView for activites, or return the view in onCreateView on Android.
- viewDidAppear vs. onResume()
Callback for when the controller's view is presented or when the user returns to the view from within the app. On Android, this could be called multiple times in the controller's lifecycle if the user leaves and returns to the app, but not on iOS.
- viewWillDisappear vs. onPause()
The inverse of - viewDidAppear / onPause(). These are called when the controller is hidden.
In iOS, for a UIViewController to receive callbacks for when the app is foregrounded/backgrounded, it can listen to the UIApplicationDidEnterBackgroundNotification and UIApplicationWillEnterForegroundNotification notifications like so:
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(yourCallbackMethodName:) name:UIApplicationDidEnterBackgroundNotification object:nil];
Don't forget to unregister when you're done!
- (void)dealloc { [[NSNotificationCenter defaultCenter] removeObserver:self]; }
Thanks to @dasmersingh and @chrismaddern for some polish on the iOS side of things. Let me know if you liked this and I'll continue writing it!
