- Understanding the UI Layout System Changes
- Summary of Layout Properties
- View Types and Default Layout Behavior
- Layout Precedence
- Batch Layout Updates
- Control Size and Position and Post-Layout Event
- Universal Unit Support
- Horizontal and Vertical Layouts
- Special Cases for Parent and Child Sizing
- Behavior Changes in Release 2.0
- Migrating Applications to Release 2.0
Release 2.0 includes a set of changes to the layout system designed to provide more control over layout and improve the parity between platforms by having all platforms implement a single, well-defined set of behaviors.
These changes affect existing layout behavior on all platforms, so you may see UI changes in your application. This document details:
- How the new layout system works
- Behavior changes from 1.8.2 to 2.0
- How to update your application to work with the new layout system
Understanding the UI Layout System Changes
This section explains the new layout system implemented in Release 2.0. While many of the details are familiar from previous releases, there are a number of changes designed to unify layout behavior on the different platforms.
Summary of Layout Properties
The following table summarizes the layout properties that affect the layout of views.
Defines the width of a UI component.
Defines the height of a UI component.
Pins the left side of a UI component relative to its parent. Measured from the parent's left bound.
Pins the right side of a UI component relative to its parent. Measured from the parent's right bound.
Pins the top of a UI component relative to its parent. Measured from the parent's top bound.
Pins the bottom of a UI component relative to its parent. Measured from the parent's bottom bound.
Dictionary with properties
Defines how the component lays out its children. One of "vertical", "horizontal" or "composite".
Stack order of UI component in its parent. Higher values are rendered towards the top, in front of components with lower values.
Could be used as a layout parameter prior to Release 2.0. In Release 2.0,
New in Release 2.0,
View Types and Default Layout Behavior
In previous releases, using the value 'auto' for a control's width or height resulted in platform-dependent behavior. Depending on the platform and the type of view involved, 'auto' either caused the view to fill its parent, or to conform to the size of its contents.
This release introduces two new constants,
Titanium.UI.SIZE, designed to replace the 'auto' keyword. With these values you can explicitly specify either type of 'auto' behavior.
It is recommended that you remove use of the 'auto' keyword, which will be deprecated in a future release.
In this release, the behavior of the 'auto' keyword has been defined on a per-control basis, so each control has a logical default behavior if you are using the 'auto' keyword.
Views are logically grouped into three categories:
- Views that should fill the parent view by default
- Views that should size themselves to their content by default
- Views that should fill in the horizontal direction only (for example, toolbars)
Windows fill the screen by default.
Auto Size Views
For the following views, specifying 'auto' for either
the same as specifying
Auto Fill Views
For the following views, specifying 'auto' for either `height` or `width` is
the same as specifying
Auto Fill Width Views
The following views fill the available width by default, and scale vertically to fit
For these views, 'auto' specifies
FILL behavior when it is used as a
width value, and
SIZE behavior when it is used as a
This section describes the precedence rules that determine which settings take precedence if conflicting layout parameters are specified.
Used to position the view horizontally if
Used to position the view horizontally when neither
If specified, always takes precedence for positioning the view horizontally.
Used to position the view vertically if
Used to position the view vertically if neither
Batch Layout Updates
Another change in this release involves batch layout updates. In previous releases, each update to a layout parameter (such as
height, and so on) could trigger a layout cycle. This results in a lot of repeated work.
To avoid this, you can batch layout updates, so multiple layout changes only result in a single layout cycle. The applyProperties method allows you to update a set of layout parameters in a single operation. For example:
Control Size and Position and Post-Layout Event
In previous releases, there was no reliable means to determine the size and position of a control after it was laid out. In this release, the rect and size properties can be used to determine the size and position of the view.
Because layout can occur asynchronously, it is sometimes difficult to determine the actual size of a control after it has been laid out. To address this issue, a new
postlayout event has been added that is fired when a layout cycle completes. For example:
Note that updating a view's layout in the
postlayout event can cause an infinite loop of layout events. Furthermore, endless
postlayout cycles can be avoided by careful coding. For instance, only listen to the
postlayout event for specific views, not for the entire window. If you are laying out some elements based on the position or size of another element, you can cache the last known size of the element you are interested in, and only make layout changes if the size actually changes.
Bear in mind that even non-layout parameters may affect the layout; for example, changing a label's text may make its size change.
In previous releases, it was possible to change a view's size on iOS by updating the
size dictionary. As this is now a read-only property on all platforms, doing so is no longer supported.
Universal Unit Support
All platforms now support specifying units for size and position values. The following table lists the supported units:
dip or dp
Equivalent to Apple "points."
Android, iOS only
Android, iOS only
1/72 of an inch. Android only. Not to be confused with Apple "points."
On Android, a density-independent pixel (DIP) corresponds to one pixel on a 160DPI display.
On iOS, a DIP corresponds to one pixel on a non-Retina display, which is 163DPI for iPhone/iPod touch and 132DPI for the iPad. A DIP corresponds to 2 pixels of width or height on a Retina display.
On Mobile Web, both a DIP and a pixel are equal to one browser pixel, which may not correspond to a pixel on the display. From testing, most browsers seem to report a DPI value of 96DPI, regardless of the actual display density.
Absolute measures, such as inches, are dependent on the device correctly reporting its density. On Mobile Web, these values are unlikely to be exact.
If no units are specified, a system-default unit is assumed. The system default unit is:
- pixels on Android
- DIP on iOS
- DIP on Mobile Web
Horizontal and Vertical Layouts
There are no significant changes to the function of the relative layout modes, horizontal and vertical, but the same precedence rules apply.
UI components with the layout parameter defined as either 'vertical' or 'horizontal' follow the same layout principles as the composite layout, but the view adds extra layout logic. Each child is laid out inside its own pre-calculated "sandbox", such that no two sandboxes overlap. Due to this two-step nature horizontal and vertical layouts are inherently slower than the composite layout, which simply uses the parent bounds as its sandbox.
A UI component with its layout parameter defined as 'vertical' stacks all its children one below the other. All child sandboxes have the same width (set to the parent's width). The
bottom properties are used to define vertical padding between the children. The
center.x properties are used to determine the child's horizontal positioning. Defining a child with FILL width behavior fills the parent width. Defining a child with FILL height behavior in a vertical layout will fill all the remaining vertical space in the layout, causing all children added after this child to be outside the bounds of the parent and hence invisible.
A UI component with its layout parameter defined as 'horizontal' will layout its children next to each other left to right. Starting in Release 2.1, UI components support a
horizontalWrap flag which determines whether the children should be wrapped to fit on multiple rows (default) or remain in a single row (more like the behavior of a 'vertical' layout).
In both cases, the
right elements are used as padding between the children, and the
bottom properties are used to position the children vertically.
horizontalWrap set to
true, if a child cannot fit in the width remaining the child element is moved to the next row. The height of the row is defined as the height of the tallest element in a row. All children in a row have the same sandbox height.
horizontalWrap set to
false, all children are placed in a single row.
Special Cases for Parent and Child Sizing
In some cases, the size values for a parent and child may conflict:
- When a UI component follows SIZE behavior but the calculated dimensions are larger than the bound of the parent, the child bounds are restricted by parent bounds.
- When a child follows FILL behavior and the parent follows SIZE behavior, the parent effectively follows FILL behavior (the child will try and push the parent bounds until a constraining bound can be determined).
- When a child has its dimensions defined as a percentage (child dimension based on parent bounds) and the parent follows SIZE behavior (parent dimensions based on child bounds) the result is undefined.
Behavior Changes in Release 2.0
This section summarizes how the new UI layout behavior differs from the previous behavior on each platform.
iOS Behavior Changes
The behavior changes in IOS for composite layout are listed below with sample code illustrating the changes. Screen shots are attached showing the difference in behavior between Release 1.8.2 and Release 2.0.
iOS now follows the same behavior as Android, and clips child views to the bounds of their parents.
Auto Sizes in iOS
When width or height parameters are specified as "auto", components will follow the specification as defined in the UI Composite Layout Behavior Spec. In previous versions of the Titanium SDK "auto" enforced SIZE behavior on iOS.
To restore 1.8 behavior on iOS, you can simply replace any "auto" sizes with
Undefined Sizes in OS
When width or height parameters are undefined, an attempt will be made to calculate these parameters implicitly. If they cannot be calculated implicitly, they will follow "auto" behavior. In previous versions of the Titanium SDK undefined width or height enforced FILL behavior.
For any views that don't have sizes defined and can't be sized implicitly, set an explicit size of
Ti.UI.FILL to restore the 1.8 behavior.
The following excerpt shows a label with undefined size and no position pins. In 1.8, this uses the FILL behavior, but in 2.0, it uses the SIZE behavior.
The following excerpt shows a label with undefined size and position pins. In 1.8, this uses the FILL behavior, but in 2.0, the size is calculated implicitly from the position pins.
To restore a view's 1.8 behavior on iOS, explicitly specify sizes as
Positioning Pins in iOS
In previous versions of the Titanium SDK, the precedence of positioning pins was
right for horizontal positioning and
bottom for vertical positioning. It now follows the precedence defined above: that is,
left take precedence over the
When no positioning pins are defined the child is placed at the center of the parent.
The following excerpt creates a view that has conflicting position pins. In Release 1.8, the
center values take precedence, but in 2.0, the
top values take precedence.
Note that in this example, an animation that moved the child view by changing its
center value would not work, because the
center value is overridden by the
Horizontal Layout in iOS
In previous versions of the Titanium SDK, the sandbox height of a child was independent of its sibling's dimensions. Now all children in a row have the same sandbox height. (See section on #Horizontal and Vertical Layouts below).
The following code sample creates a view with horizontal layout that contains two children. In Release 1.8, the green child is laid out flush to the top of the parent view. In Release 2.0, the green child is centered relative to its larger neighbor.
Note that there are still inconsistencies between Android, iOS and Mobile Web in the handling of horizontal layouts. This is a known issue.
Android Behavior Changes
The behavior changes in Android for composite layout are listed below with sample code illustrating the changes. Screen shots are attached for both Release 1.8 and Release 2.0.
Layout Precedence in Android
In previous releases, the positioning properties would determine the width or height of a view even when width or height was specified explicitly. With the new layout rules, the specified width/height take precedence, and then positioning properties afterwards. If one positioning property conflicts with another, properties lower in the precedence chain are ignored.
Undefined Sizes in Android
When width or height parameters are undefined, an attempt will be made to calculate these parameters implicitly. If they cannot be calculated implicitly, they will follow "auto" behavior. In previous releases, undefined width or height would result in looking at the center values first.
The following excerpt shows a child view with positioning pins but no defined width or height. In 1.8, this resulted
Positioning Pins in Android
In previous versions of the Titanium SDK, the precedence of positioning pins was (center.x, left, right, center.y, top, bottom). It now follows the precedence defined above. When no positioning pins are defined the child is placed at the center of the parent.
Mobile Web Layout Behavior
On the Mobile Web platform, if you do not specify a height or width for a view (or define the size implicitly using
center or other layout properties), they use the default behavior defined above - either fill, size, or fill width.
If a value of 'auto' is specified for
width, it is interpreted as
Ti.UI.SIZE. This differs from the 'auto' behavior on Android and iOS. However, using either
FILL explicitly should result in the same layout on all three
Migrating Applications to Release 2.0
When migrating applications to Release 2.0, you should focus on reducing or eliminating the use of 'auto' sizes in favor of explicitly selecting SIZE or FILL behavior.
In most cases, simply leaving the width and height undefined should give reasonable default behavior for all view types, which was not always true in previous releases.
On iOS, the following changes apply:
- Any UI component with the
widthproperty defined as "auto" can safely define its
Ti.UI.SIZEto return to 1.8 behavior.
- Any UI component with the
widthproperty undefined and with less than 2 positioning pins defined can safely define its
Ti.UI.FILLto return to 1.8 behavior.
The same principles apply to the
On Android, the 'auto' behavior remains the same for most components. However, it is recommended to remove any 'auto' sizes in favor of explicitly specifying the desired behavior.
After replacing 'auto' values, if you are still seeing layout changes, they are likely due to the changes in the precedence order of layout properties.
If you are using
size as a read/write property, you must rewrite these references to set the
height properties directly.
If your code specifies size and position values with units and relies on the units being ignored on iOS, it will break in 2.0. This should only cause problems if you specify a unit other than DIPs, which is the default unit on iOS.