From iOS to Android – Part III
Exploring the differences between iOS Interface Builder and Android Layout Editor13th July 2018
Android and iOS both provide ways to create a user interface using a GUI editor, rather than defining the entire interface from code. iOS has Interface Builder and Android has Layout Editor. Both tools use XML to store the created interface, although there is an important difference between the file formats: Android XML layout files are intended to be easily readable and editable, while storyboard files should purely be manipulated graphically using Interface Builder.
Storyboards can contain multiple view controllers, linked together with segues to represent transitions between screens in an app. This allows a developer to easily get an overall impression of particular UI flows and use cases within an app, or even the navigation flow of an entire app during a smaller project.
Storyboards can become problematic when working on larger projects with multiple screens and/or multiple developers. If using Git, storyboards can be a major source of git conflicts when two developers simultaneously edit parts of the same storyboard. Because the backing xml file is not designed to be edited by humans, it can be very difficult to merge changes using a text based merge tool. Keeping storyboards small and using references to other storyboards is a way to reduce issues, which also helps to reduce the loading time for storyboards in Xcode.
Android Layout Editor
Android XML layout files each contain a single element such as an activity, fragment or table cell. There is no equivalent to iOS segues, instead all transitions between activities require programmatic creation of an Intent object. Consequently it can be harder to get an idea of the overall flow of an Android app, although there are other benefits that mean this isn’t a huge issue.
Readable XML files ensure that merge conflicts for Android layout files are incredibly easy to resolve, and once familiar with the structure of XML files it can often be faster to create or modify UIs using only the XML, without needing the graphical layout editor at all.
iOS provides a layout system called Auto Layout which is supported natively by Interface Builder. The idea behind Auto Layout is that a layout is defined by a system of mathematical equations known as constraints. An essential concept behind the system is that constraints are separate objects, rather than being part of any one view. The constraints can then reference one or two views depending on the type of constraint. The constraints are mathematically solved as a system of linear equations to give the positions and sizes of all views in the hierarchy. Constraints can also have priorities, allowing the developer to specify which constraints should get broken if the system of equations cannot be solved directly. This system allows positioning to be responsive and dynamic, hence the name “Auto Layout”.
Android provides a selection of different ViewGroups which allow subviews to be positioned in different ways, such as horizontally, vertically or on top of one another. It is quite common to have many ViewGroups nested inside one another to create complex layouts if using simple ViewGroups such as LinearLayout. One of the newer additions to the platform is the ConstraintLayout, which allows the developer to keep the layout hierarchy flat by specifying view positioning using constraints in a similar way to AutoLayout. These constraints are different to the ones on iOS, because they are unidirectional, positioning one view in relation to another, whereas iOS constraints are independent objects that positions two views in relation to each other.
There are some significant differences between iOS and Android layout tools, although the broad idea of positioning views using constraints is similar. Android has easily editable XML files, multiple types of ViewGroup and the choice to use simple one directional constraints. iOS on the other hand uses XML files to store storyboards but discourages direct editing and has two directional constraints that are solved as equations.