From iOS to Android – Part II
Exploring Android concepts as an iOS developer1st May 2018
UIViewControllers, Activities & Fragments
Mobile operating systems such as Android and iOS provide classes to manage screens within an app that a developer must subclass, however the two main operating systems approach things in slightly different ways. This article will explore some of the concepts behind UIViewControllers on iOS, as well as Activities and Fragments on Android, before examining some of the differences between the two platforms.
Apple define a UIViewController as “An object that manages a view hierarchy for your UIKit app”. This concise description summarises the intended functionality very well; the core purpose of a view controller is to control a view and the hierarchy of subviews within it. All classes that inherit from UIViewController have a single UIView at their root, although in some cases the UIView is replaced with a subclass such as a UITableView or a UICollectionView.
Managing a view hierarchy
The main responsibilities of managing a view hierarchy include updating subviews to ensure that the backing content is displayed accurately, responding to user interaction such as button presses or typing, as well as handling layout changes including rotation and resizing. View controllers are also responsible for coordination with other parts of an app, although this responsibility is often misinterpreted by developers, causing view controllers to become responsible for large amounts of functionality, leading to bloated files and unnecessary complication. If an interface consists of several logically separate parts then a view controller can contain child view controllers, such as two panels in a master/detail app.
On Android, an activity is defined as “a single, focused thing that the user can do”, which is a much broader definition than on iOS, although the concept of managing what’s displayed on a single screen is the same.
An activity takes care of creating a window and then allows the developer to take responsibility for creating the specific user interface.
On Android, activities are managed within a stack, meaning that the last activity added to the stack is the first to be removed. This also means that only one activity is on screen at a time; the Android equivalent of iOS nested view controllers requires the use of fragments.
Android fragments are defined as representing a behaviour or portion of a user interface. Fragments must be contained within an Activity, although multiple fragments are allowed within a single activity to build UIs with multiple panels. The lifecycle of a fragment is directly linked to it’s parent activity, although fragments can be added or removed while an activity is active using fragment transactions. One of the primary reasons for the addition of fragments in 2011 was to increase flexibility in apps designed for large screens such as tablets. Fragments are intended to be built in a reusable and modular style, to allow them to be used in multiple places within an app.
There are various similarities and differences in how the two operating systems handle a single screen/view within an app. Android activities feel more deeply integrated into the operating system, possibly due to the built in navigation stack as opposed to the separate navigation controller on iOS. Activities and fragments also have a more complicated lifecycle with more operating system callback functions when compared to iOS, again making them feel more closely integrated.
The XML manifest file
Android relies on an xml manifest file to define the overall structure and basics of the app, including the names of all activities, various required permissions and any device features required so that certain devices without necessary features can be prevented from installing an app. iOS has a similar plist file, although iOS does not require as many things to be added to it.
iOS includes various subclasses of the UIViewController class to improve developer efficiency in certain situations. Some of the useful subclasses include UITableViewController, UITabBarController & UINavigationController; all of which have built in support for a specific feature to make day to day life easier for developers. Android doesn’t provide any similar subclasses to the activity class, although various templates can be inserted using Android Studio for things such as tabbed activities, scrollable actives or master-detail navigation flows.
In conclusion, there are some considerable difference between activities and view controllers, although this article has barely scratched the surface. The concept of the classes on both platforms are similar: managing a specific view hierarchy, however the implementation and design style are both considerably different for a developer to work with.
Missed part one? read it here