Layout deep dive

Prism’s ethos is all about enabling you to build high quality native applications without having to learn the intricacies of each platform’s native frameworks.

There are a few techniques you can make use of to take this further, alongside some utilities you can use to make your life easier when maintaining your applications. We’ll run through these in this guide.

Includes

Often in mobile applications you strive for consistency whenever possible, so that your end-users can learn your user interface intuitively and understand how it works based on a handful of interactions with your app.

Include elements help a lot here, by allowing you to define common structures within your layout in separate files and reuse them. Let’s see how this works in practice:

<!-- component-error-bar.xml -->
<include>
  <image src="icon--error" top="10" left="10" bottom="10" width="28" height="28" />
  <label id="errorTitle" left="48" top="10" bottom="10" right="10" />
</include>

<!-- modal-error.xml -->
<layout>
  <relative-panel>
    <include src="component-error-bar" />
  </relative-panel>
</layout>

<!-- screen-error.xml -->
<layout>
  <relative-panel>
    <include src="component-error-bar" />
  </relative-panel>
</layout>

As you can see, we can declare common elements that are present across multiple layouts and include them. This helps a lot in modularising your layout files and ensuring consistency of the UI in your applications.

Platform-specific layouts

Whilst Prism takes great strides in ensuring your applications fit in by using native UI views and applying the best-practices of each platform, this may only get you so far.

If you want to tweak things per-platform, like for example changing what font you use, or switching between system button styles and custom styles, you can do that easily with platform-specific layouts.

Let’s see how this works:

<!-- index.xml -->
<layout>
  <label>I'm a generic layout!</label>
</layout>

<!-- index-ios.xml -->
<layout>
  <label>I'm an iOS layout!</label>
</layout>

Prism’s rule for loading layouts is to choose the most specific layout for your device. If the application was running on iOS for example, the index-ios.xml file would be looked for first before attempting to load the default index.xml file.

This goes for includes too:

<!-- component-error-bar.xml -->
<include>
  <image src="icon--error" top="10" left="10" bottom="10" width="28" height="28" />
  <label id="errorTitle" left="48" top="10" bottom="10" right="10" />
</include>

<!-- component-error-bar-ios.xml -->
<include>
  <label id="errorTitle" left="10" top="10" bottom="10" right="10" />
</include>

<!-- modal-error.xml -->
<layout>
  <relative-panel>
    <include src="component-error-bar" />
  </relative-panel>
</layout>

In the above example, on iOS, the component-error-bar-ios.xml layout file would be loaded as it’s the most specific layout available.

This can be incredibly powerful, and allow you to make those finishing touches that set apart your app from the crowd.

State

One of the main development chores when building user interfaces is managing UI state. You’ll often have various error states, loading states, blank states and happy/unhappy states. Prism caters for this with State elements. Let’s see how this works in practice:

<layout>
  <state id="currentState" initial-state="loading">
    <layout state="loading">
      <label top="20" left="20" right="20">Loading...</label>
    </layout>
    <layout state="error">
      <label top="20" left="20" right="20">Something went wrong</label>
      <button id="retryButton" bottom="20" left="20" right="20">Retry</button>
    </layout>
    <layout state="loaded">
      <label id="content" top="20" left="20" right="20" bottom="20" />
    </layout>
  </state>
</layout>

In the above example we have three states we can swap between. We can set the initial state that’s displayed on-screen when the layout loads with initial-state.

We swap between states with JavaScript, like so:

window.currentState.state = 'loaded'

As you can see, we can access the State layout via its id. It exposes a state property which can be used to query and update the current state.

State layouts expose every state’s identified elements (elements with an id) rather than just the ones on-screen at the moment. This is due to the fact that you would often want to bind any necessary data to your views and get things ready for display before switching to your intended state.

Switching states is a synchronous and instantaneous operation, so you’ll want to make sure things are ready so that users don’t see stale content.

States are a great tool for managing the display of a group of UI elements, and can enable your JavaScript to be much more concise than in alternative frameworks.

Summing up

In this guide we’ve learnt some of the more advanced layout concepts in Prism. In the next guide, we’ll run through how to apply custom styles to your applications.