# Titanium.UI.iOS.NavigationWindow

On iOS this is a direct analog of the accessibilityElementsHidden property defined in the UIAccessibility Protocol.

On Android, setting accessibilityHidden calls the native View.setImportantForAccessibility method. The native method is only available in Android 4.1 (API level 16/Jelly Bean) and later; if this property is specified on earlier versions of Android, it is ignored.

On iOS this is a direct analog of the accessibilityHint property defined in the UIAccessibility Protocol. On Android, it is concatenated together with accessibilityLabel and accessibilityValue in the order: accessibilityLabel, accessibilityValue, accessibilityHint. The concatenated value is then passed as the argument to the native View.setContentDescription method.

On iOS this is a direct analog of the accessibilityLabel property defined in the UIAccessibility Protocol. On Android, it is concatenated together with accessibilityValue and accessibilityHint in the order: accessibilityLabel, accessibilityValue, accessibilityHint. The concatenated value is then passed as the argument to the native View.setContentDescription method. Defaults to Title or label of the control.

On iOS this is a direct analog of the accessibilityValue property defined in the UIAccessibility Protocol. On Android, it is concatenated together with accessibilityLabel and accessibilityHint in the order: accessibilityLabel, accessibilityValue, accessibilityHint. The concatenated value is then passed as the argument to the native View.setContentDescription method. Defaults to State or value of the control.

Used on iOS only. For Android, use anchorPoint.

Anchor point is specified as a fraction of the view's size. For example, {0, 0} is at the view's top-left corner, {0.5, 0.5} at its center and {1, 1} at its bottom-right corner.

See the "Using an anchorPoint" example in Titanium.UI.Animation for a demonstration. The default is center of this view.

The value of this property is the fully qualified name of the API. For example, Titanium.UI.Button returns Ti.UI.Button.

When the value is true, it allows the view controller to adjust its scroll view insets in response to the screen areas consumed by the status bar, navigation bar, toolbar and tab bar.

The default behavior assumes that this is false. Must be specified before opening the window.

On Android, to specify a semi-transparent background, set the alpha value using the opacity property before opening the window.

For information about color values, see the "Colors" section of Titanium.UI.

A gradient can be defined as either linear or radial. A linear gradient varies continuously along a line between the startPoint and endPoint.

A radial gradient is interpolated between two circles, defined by startPoint and startRadius and endPoint and endRadius respectively.

The start points, end points and radius values can be defined in device units, in the view's coordinates, or as percentages of the view's size. Thus, if a view is 60 x 60, the center point of the view can be specified as:

{ x: 30, y: 30 }

Or:

{ x: '50%', y: '50%' }

When specifying multiple colors, you can specify an offset value for each color, defining how far into the gradient it takes effect. For example, the following color array specifies a gradient that goes from red to blue back to red:

colors: [ { color: 'red', offset: 0.0}, { color: 'blue', offset: 0.25 }, { color: 'red', offset: 1.0 } ]

Android's linear gradients ignores backfillStart and backfillEnd, treating them as if they are true. Android's radial gradients ignore the endPoint property. Defaults to no gradient.

Default behavior when backgroundImage is unspecified depends on the type of view and the platform. For generic views, no image is used. For most controls (buttons, textfields, and so on), platform-specific default images are used.

See the section on backgroundLeftCap and backgroundTopCap behavior on iOS in Titanium.UI.View.

Setting this to true makes the set backgroundImage repeat across the view as a series of tiles. The tiling begins in the upper-left corner, where the upper-left corner of the background image is rendered. The image is then tiled to fill the available space of the view.

Note that setting this to true may incur performance penalties for large views or background images, as the tiling must be redone whenever a view is resized.

On iOS, the following views do not currently support tiled backgrounds:

• Titanium.UI.Button
• Titanium.UI.TextField
• Titanium.UI.Label

See the section on backgroundLeftCap and backgroundTopCap behavior on iOS in Titanium.UI.View.

For information about color values, see the "Colors" section of Titanium.UI.

Defaults to the normal background color of this view (Android), black (iOS).

Each corner is rounded using an arc of a circle. Values for each corner can be specified. For example, '20px 20px' will set both left and right corners to 20px. Specifying '20px 20px 20px 20px' will set top-left, top-right, bottom-right and bottom-left corners in that order.

If you have issues with dark artifacts on Android you can try to disable Hardware acceleration by setting a backgroundColor with a small amount of transparency: backgroundColor:"rgba(255,255,255,254)".

If borderColor is set without borderWidth, this value will be changed to 1 of the unit declared as 'ti.ui.defaultunit' in tiapp.xml descriptor.

On Android, this property has no effect.

Some proxies (most commonly views) have a relationship to other proxies, often established by the add() method. For example, for a button added to a window, a click event on the button would bubble up to the window. Other common parents are table sections to their rows, table views to their sections, and scrollable views to their views. Set this property to false to disable the bubbling to the proxy's parent.

This is an input property for specifying where the view should be positioned, and does not represent the view's calculated position.

Defaults to undefined.

Setting this to CLIP_MODE_ENABLED enforces all child views to be clipped to this views bounds. Setting this to CLIP_MODE_DISABLED allows child views to be drawn outside the bounds of this view. When set to CLIP_MODE_DEFAULT or when this property is not set, clipping behavior is inferred. See section on iOS Clipping Behavior in Titanium.UI.View.

Defaults to undefined. Behaves as if set to CLIP_MODE_DEFAULT.

This is only valid for windows hosted by navigation controllers or tab bar controllers. This property is used to determine the layout of the window within its parent view controller. For example if the window is specified to extend its top edge and it is hosted in a navigation controller, then the top edge of the window is extended underneath the navigation bar so that part of the window is obscured. If the navigation bar is opaque (translucent property on window is false), then the top edge of the window will only extend if includeOpaqueBars is set to true.

The default behavior is to assume that no edges are to be extended. Must be specified before opening the window.

If set true, then the contents of the window will be extended to fill the whole screen and allow the system's UI elements (such as a translucent status-bar) and physical obstructions (such as the iPhone X rounded corners and top sensor housing) to overlap the window's content. In this case, it is the app developer's responsibility to position views so that they're unobstructed. On Android, you can use the safeAreaPadding property after the window has been opened to layout your content within the insets.

If set false, then the window's content will be laid out within the safe-area and its child views will be unobstructed. For example, you will not need to position a view below the top status-bar.

Read more about the safe-area layout-guide in the Human Interface Guidelines.

A fullscreen window occupies all of the screen space, hiding the status bar. Must be specified at creation time or in the options dictionary passed to the open method.

On iOS the behavior of this property has changed. Starting from 3.1.3, if this property is undefined then the property is set to the value for UIStatusBarHidden defined in tiapp.xml. If that is not defined it is treated as explicit false. On earlier versions, opening a window with this property undefined would not effect the status bar appearance.

Defaults to: If undefined, defaults to either FILL or SIZE depending on the view. See "View Types and Default Layout Behavior" in Transitioning to the New UI Layout System.

Can be either a float value or a dimension string (for example, '50%' or '40dp'). Can also be one of the following special values:

• SIZE. The view should size itself to fit its contents.
• FILL. The view should size itself to fill its parent.
• 'auto'. Represents the default sizing behavior for a given type of view. The use of 'auto' is deprecated, and should be replaced with the SIZE or FILL constants if it is necessary to set the view's behavior explicitly.

This is an input property for specifying the view's height dimension. To determine the view's size once rendered, use the rect or size properties.

When this property is set to true, the navigation window hides its back button.

When this property is set to true, an upward swipe hides the navigation bar and toolbar. A downward swipe shows both bars again. If the toolbar does not have any items, it remains visible even after a swipe.

When the value of this property is true, the navigation controller toggles the hiding and showing of its navigation bar and toolbar in response to an otherwise unhandled tap in the content area.

When this property is set to true, the appearance of the keyboard causes the navigation controller to hide its navigation bar and toolbar.

When the value of this property is true, the search bar is visible only when the scroll position equals the top of your content view. When the user scrolls down, the search bar collapses into the navigation bar. Scrolling back to the top reveals the search bar again. When the value of this property is false, the search bar remains regardless of the current scroll position. You must set showSearchBarInNavBar or showSearchBarInNavBar property for this property to have any effect.

Set this value true, if you want the system to determine when to hide the indicator. Set this value false, if you want the indicator shown at all times. The system takes your preference into account, but setting true is no guarantee that the indicator will be hidden.

Note that the parallax effect only happens by tilting the device so results can not be seen on Simulator. To clear all motion effects, use the <Titanium.UI.clearMotionEffects> method.

For more information, see the discussion of horizontal layout mode in the description of the layout property.

The id property of the Ti.UI.View represents the view's identifier. The identifier string does not have to be unique. You can use this property with getViewById method.

By default edges are only extended to include translucent bars. However if this is set to true, then edges are extended beyond opaque bars as well.

The default behavior assumes that this is false. Must be specified before opening the window.

Automatically use the large out-of-line title based on the state of the previous item in the navigation bar. An item with largeTitleDisplayMode = Ti.UI.iOS.LARGE_TITLE_DISPLAY_MODE_AUTOMATIC will show or hide the large title based on the request of the previous navigation item. If the first item pushed is set to Automatic, then it will show the large title if the navigation bar has largeTitleEnabled = true.

When set to true, the navigation bar will use a larger out-of-line title view when requested by the current navigation item. To specify when the large out-of-line title view appears, see largeTitleDisplayMode.

There are three layout options:

• composite (or absolute). Default layout. A child view is positioned based on its positioning properties or "pins" (top, bottom, left, right and center). If no positioning properties are specified, the child is centered.

  The child is always sized based on its width and height properties, if these are specified. If the child's height or width is not specified explicitly, it may be calculated implicitly from the positioning properties. For example, if both left and center.x are specified, they can be used to calculate the width of the child control.

  Because the size and position properties can conflict, there is a specific precedence order for the layout properties. For vertical positioning, the precedence order is: height, top, center.y, bottom.

  The following table summarizes the various combinations of properties that can be used for vertical positioning, in order from highest precedence to lowest. (For example, if height, center.y and bottom are all specified, the height and center.y values take precedence.)

  Scenario	Behavior
  height & top specified	Child positioned top unit from parent's top, using specified height; any center.y and bottom values are ignored.
  height & center.y specified	Child positioned with center at center.y, using specified height; any bottom value is ignored.
  height & bottom specified	Child positioned bottom units from parent's bottom, using specified height.
  top & center.y specified	Child positioned with top edge top units from parent's top and center at center.y. Height is determined implicitly; any bottom value is ignored.
  top & bottom specified	Child positioned with top edge top units from parent's top and bottom edge bottom units from parent's bottom. Height is determined implicitly.
  Only top specified	Child positioned top units from parent's top, and uses the default height calculation for the view type.
  center.y and bottom specified	Child positioned with center at center.y and bottom edge bottom units from parent's bottom. Height is determined implicitly.
  Only center.y specified	Child positioned with center at center.y, and uses the default height calculation for the view type.
  Only bottom specified	Child positioned with bottom edge bottom units from parent's bottom, and uses the default height calculation for the view type.
  height, top, center.y, and bottom unspecified	Child entered vertically in the parent and uses the default height calculation for the child view type.

  Horizontal positioning works like vertical positioning, except that the precedence is width, left, center.x, right.

  For complete details on composite layout rules, see Transitioning to the New UI Layout System in the Titanium Mobile Guides.

• vertical. Children are laid out vertically from top to bottom. The first child is laid out top units from its parent's bounding box. Each subsequent child is laid out below the previous child. The space between children is equal to the upper child's bottom value plus the lower child's top value.

  Each child is positioned horizontally as in the composite layout mode.

• horizontal. Horizontal layouts have different behavior depending on whether wrapping is enabled. Wrapping is enabled by default (the horizontalWrap property is true).

  With wrapping behavior, the children are laid out horizontally from left to right, in rows. If a child requires more horizontal space than exists in the current row, it is wrapped to a new row. The height of each row is equal to the maximum height of the children in that row.

  Wrapping behavior is available on iOS and Android. When the horizontalWrap property is set to true, the first row is placed at the top of the parent view, and successive rows are placed below the first row. Each child is positioned vertically within its row somewhat like composite layout mode. In particular:

  • If neither top or bottom is specified, the child is centered in the row.
  • If either top or bottom is specified, the child is aligned to either the top or bottom of the row, with the specified amount of padding.
  • If both top and bottom is specified for a given child, the properties are both treated as padding.

  If the horizontalWrap property is false, the behavior is more equivalent to a vertical layout. Children are laid or horizontally from left to right in a single row. The left and right properties are used as padding between the children, and the top and bottom properties are used to position the children vertically.

  Defaults to Composite layout.

On Android, this property has no effect.

Set to true to create a modal window.

Must be specified at creation time or in the dictionary passed to the open method.

In the user interface, a modal window is a window that blocks the main application UI until the modal window is dismissed. A modal window requires the user to interact with it to resume the normal flow of the application.

See the "Modal Windows" section for platform-specific information.

Returns the navigation window that hosts this window. Returns null if the window is not hosted by a navigation window.

iOS notes: For modal windows that cover the previous window, the previous window is removed from the render stack after the modal window finishes opening. If the modal window is semi-transparent, the underlying window will be visible during the transition animation, but disappear as soon as the animation is completed. (In general all modal windows cover the previous window, except for iPad modal windows using the Page sheet or Form sheet style.)

Android notes: If you set any of windowSoftInputMode, fullscreen, or navBarHidden, and you wish to use the opacity property at any time during the window's lifetime, be sure to set an opacity value before opening the window. You can later change that value -- and you can set it to 1 for full opacity if you wish -- but the important thing is that you set it to a value before opening the window if you will want to set it at any time during the window's lifetime.

The technical reason for this is that if the opacity property is present (i.e., has been set to something) and a new Android Activity is created for the window, then a translucent theme will be used for the Activity. Window transparency (opacity values below 1) will only work in Android if the Activity's theme is translucent, and Titanium only uses a translucent theme for an Activity if you set an opacity property before opening the window. Additionally, do not use opacity and fullscreen: true together, because translucent themes in Android cannot hide the status bar. Finally, if you do set the opacity property, be sure to also set a backgroundImage or backgroundColor property as well, unless you want the window to be completely transparent.

To determine the current orientation of the device, see orientation, instead.

See the discussion of the orientationModes property for more information on how the screen orientation is determined.

Note: Using the orientationModes property to force the orientation of non-modal windows is considered a bad practice and will not be supported, including forcing the orientation of windows inside a NavigationWindow or TabGroup.

To restrict this window to a certain set of orientations, specify one or more of the orientation constants LANDSCAPE_LEFT, LANDSCAPE_RIGHT, PORTRAIT, UPSIDE_PORTRAIT.

orientationModes must be set before opening the window.

To determine the current orientation of the window, see orientation. To determine the current orientation of the device, see orientation. To be notified when the device's current orientation changes, add a listener for the orientationchange event.

# Android Orientation Modes

On Android, orientation behavior is dependent on the Android SDK level of the device itself. Devices running Android 2.3 and above support "sensor portait mode" and "sensor landscape mode," in these modes, the device is locked into either a portrait or landscape orientation, but can switch between the normal and reverse orientations (for example, between PORTRAIT and UPSIDE_PORTRAIT).

In addition, the definition of portrait or landscape mode can vary based on the physical design of the device. For example, on some devices LANDSCAPE_LEFT represents the top of the device being at the 270 degree position but other devices may (based on camera position for example) treat this position as LANDSCAPE_RIGHT. In general, applications for Android that need to be aware of orientation should try and limit their orientation logic to handling either portrait or landscape rather than worrying about the reverse modes. This approach will allow the orientation modes to adopt a more natural feel for the specific device.

The following list breaks down the orientation behavior on Android based on the contents of the orientationModes array:

1. Empty array. Enables orientation to be fully controlled by the device sensor.

2. Array includes one or both portrait modes and one or both landscape modes. Enables full sensor control (identical to an empty array).

3. Array contains PORTRAIT and UPSIDE_PORTRAIT. On Android 2.3 and above, enables sensor portrait mode. This means the screen will shift between both portrait modes according to the sensor inside the device.

   On Android versions below 2.3, locks screen orientation in normal portrait mode.

4. Array contains LANDSCAPE_LEFT and LANDSCAPE_RIGHT. On Android 2.3 and above, enables sensor landscape mode. This means the screen will shift between both landscape modes according to the sensor inside the device.

   On Android versions below 2.3, locks screen orientation in normal landscape mode.

5. Array contains only PORTRAIT. Locks screen orientation to normal portrait mode.

6. Array contains only LANDSCAPE_LEFT. Locks screen orientation to normal landscape mode.

7. Array contains only UPSIDE_PORTRAIT. On Android 2.3 and above, locks screen in reverse portrait mode.

   On Android versions below 2.3, results are undefined.

8. Array contains only LANDSCAPE_RIGHT. On Android 2.3 and above, locks screen in reverse landscape mode.

   On Android versions below 2.3, results are undefined.

Preview context to present the "Peek and Pop" of a view. Use an configured instance of Titanium.UI.iOS.PreviewContext here.

Note: This property can only be used on devices running iOS9 or later and supporting 3D-Touch. It is ignored on older devices and can manually be checked using forceTouchSupported.

The view's bounding box is defined by its size and position.

The view's size is rect.width x rect.height. The view's top-left position relative to its parent is (rect.x , rect.y).

On Android it will also return rect.absoluteX and 'rect.absoluteY' which are relative to the main window.

The correct values will only be available when layout is complete. To determine when layout is complete, add a listener for the postlayout event.

On Android, this property has no effect.

Translation values are applied to the static post layout value.

When setting extendSafeArea to true, the system's insets such as a translucent status bar, translucent navigation bar, and/or camera notches will be allowed to overlay on top of the window's content. In this case, it is the app developer's responsibility to prevent these insets from overlapping key content such as buttons. This property provides the amount of space needed to be added to the left, top, right, and bottom edges of the window root view to do this.

This property won't return values greater than zero until the window has been opened. It is recommended that you read this property via a postlayout event listener since the padding values can change when when the app's orientation changes or when showing/hiding the action bar.

If the extendSafeArea property is set false, then the returned padding will be all zeros since the root content will be positioned between all insets.

Below is an example on how to set up a safe-area view container using this property.

// Set up a window with a translucent top status bar and translucent nav bar.
// This will only work on Android 4.4 and newer OS versions.
var win = Ti.UI.createWindow({
    extendSafeArea: true,
    theme: 'Theme.Titanium.NoTitleBar',
    windowFlags: Ti.UI.Android.FLAG_TRANSLUCENT_NAVIGATION | Ti.UI.Android.FLAG_TRANSLUCENT_STATUS
});

// Set up a safe-area view to be layed out between the system insets.
// You should use this as a container for child views.
var safeAreaView = Ti.UI.createView({
    backgroundColor: 'green'
});
win.add(safeAreaView);
win.addEventListener('postlayout', function() {
    // Update the safe-area view's dimensions after every 'postlayout' event.
    safeAreaView.applyProperties(win.safeAreaPadding);
});

// Open the window.
win.open();

Although property returns a Dimension dictionary, only the width and height properties are valid. The position properties--x and y--are always 0.

To find the position and size of the view, use the rect property instead.

The correct values will only be available when layout is complete. To determine when layout is complete, add a listener for the postlayout event.

Sets the status bar style when this window has focus. This is now the recommended way to control the status bar style on the application.

If this value is undefined, the value is set to UIStatusBarStyle defined in tiapp.xml. If that is not defined it defaults to DEFAULT.

This property is a direct correspondant of the tintColor property of UIView on iOS. If no value is specified, the tintColor of the View is inherited from its superview.

Use this property to specify the color, font and shadow attributes of the title.

Assigning a value to this property causes the tool tip to be displayed for the view. Setting the property to null cancels the display of the tool tip for the view. Note: This property is only used for apps targeting macOS Catalyst.

On Android, this property has no effect.

If false, will forward the events to peers.

Android only supports Matrix2D transforms.

Note that the parallax effect only happens by tilting the device so results can not be seen on Simulator. To clear all motion effects, use the <Titanium.UI.clearMotionEffects> method.

iOS Defaults to undefined. Behaves as if transparent. Android default is black. On Android you can set <item name="android:ambientShadowAlpha">0.5</item> and <item name="android:spotShadowAlpha">0.5</item> in your theme to change the opacity.

Defaults to undefined. Behaves as if set to (0,-3)

Defaults to undefined. Behaves as if set to 3. Accepts density units as of 10.0.1.

Defaults to: If undefined, defaults to either FILL or SIZE depending on the view. See "View Types and Default Layout Behavior" in Transitioning to the New UI Layout System.

Can be either a float value or a dimension string (for example, '50%' or '40dp'). Can also be one of the following special values:

• SIZE. The view should size itself to fit its contents.
• FILL. The view should size itself to fill its parent.
• 'auto'. Represents the default sizing behavior for a given type of view. The use of 'auto' is deprecated, and should be replaced with the SIZE or FILL constants if it is necessary to set the view's behavior explicitly.

This is an input property for specifying the view's width dimension. To determine the view's size once rendered, use the rect or size properties.

A view does not have a default z-index value, meaning that it is undefined by default. When this property is explicitly set, regardless of its value, it causes the view to be positioned in front of any sibling that has an undefined z-index.

Defaults to undefined.