iOS <> Android Vocab Cheat Sheet

iOS_Android_Vocab_Cheat_Sheet.md

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.

Part 1: View Controllers

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.

- loadView and - viewDidLoad (UIViewController) vs. onCreate() for Activity, and onCreate() + onCreateView() for Fragment

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.

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];
}

- viewWillDisappear vs. onPause()

The inverse of - viewDidAppear / onPause() - called when the controller is hidden.

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!

- (void)viewDidAppear: and - (void)viewWillDisappear: are called when the user leaves and returns to the particular view controller (either by presenting and dismissing a modal view controller or pushing and popping to view controller on the navigation stack, but they are not called when the user leaves and returns to the app.
In this scenario, the UIApplicationDelegate's - (void)applicationDidEnterBackground: - (void)applicationWillEnterForeground: methods are called instead. A view controller can listen for the user leaving and returning to the app by observing the UIApplicationDidEnterBackgroundNotification and UIApplicationWillEnterForegroundNotification notifications.

@dasmer, is this how you would do that? Taken from here

[[NSNotificationCenter defaultCenter] addObserver: self
                                         selector: @selector(yourCallbackMethodName:) 
                                             name: UIApplicationDidEnterBackgroundNotification
                                           object: nil];

yup! We don't usually have spaces between the colon and argument.

Also, whenever NSNotificationCenter adds an observer, its important to make sure to remove that observer before it becomes deallocated to avoid invoking a method on a deallocated object.

so in the dealloc method of the view controller (assuming self is the view controller) you need to add:

- (void)dealloc
{
    [[NSNotificationCenter defaultCenter] removeObserver:self];
}

@dasmer we don't usually have a new line after a method identity :p

- (void)dealloc {
    [[NSNotificationCenter defaultCenter] removeObserver:self];
}