0.7 Released: Support for system alerts

January 13, 2019

Adam Stepinski

Today we released Hyperview v0.7.0. This version includes one new feature: the ability to trigger native system alerts on iOS and Android.

Here's the HXML to render the alert above:

<behavior
  xmlns:alert="https://hyperview.org/hyperview-alert"
  trigger="longPress"
  action="alert"
  alert:title="This is the title"
  alert:message="This is the message"
>
  <alert:option
    alert:label="Screen 1"
    href="/screen1"
    action="push"
  />
  <alert:option
    alert:label="Screen 2"
    href="/screen2"
    action="new"
  />
</behavior>

Alerts are triggered using the standard behavior syntax. This means any Hyperview trigger can cause an alert to appear: press, longpress, load, refresh, etc. You could even trigger an alert on visible, but I wouldn't recommend it as a good user experience.

To prevent name clashes, the new attributes and elements use a namespace: https://hyperview.org/hyperview-alert. I find it's nice to define the namespace on the <behavior> that will show the alert (see the example above), rather than at the root of the doc. This will likely be a common pattern for new elements added to Hyperview.

The child <alert:option> elements define the available options on the alert. The options contain standard Hyperview behaviors that trigger on press. This means alert options can do things like navigate screens, update parts of the page, or execute custome behaviors.

Use cases

System alerts open up many new use cases in Hyperview, some common ones are explained below.

Confirmation before performing an action

Before performing a destructive action, like a DELETE request to the server, it can be a good idea to get confirmation from the user. To do the confirmation with a system alert, wrap the destructive behavior in an alert with a "Confirm" and "Cancel" option. The destructive behavior should be triggered when the user presses "Confirm". No behaviors need to be associated with the "Cancel" option, which will dismiss the alert.

<view style="Button">
  <behavior
    xmlns:alert="https://hyperview.org/hyperview-alert"
    action="alert"
    alert:title="Delete business?"
    alert:message="All job posts at this location will be permanently deleted."
  >
    <alert:option
      alert:label="Delete"
    >
      <behavior
        verb="DELETE"
        href="/businesses/123"
        action="replace"
        target="Main"
      />
    </alert:option>
    <alert:option
      alert:label="Cancel"
    />
  </behavior>

  <text style="Button__Text">
    Delete
  </text>
</view>

Status after performing an action

After performing a server-side action, alerts can be used to convey the status of the result. For example, if there's a problem validating the data or other server-side error, the response can include a behavior triggered on load that displays an alert with the error message. No alert options need to be provided, the system will have a default dismiss button.

It's best not to overuse alerts for statuses, since they require user interaction to dismiss. For less important status updates, such as positive confirmation, consider using a non-blocking toast or inline feedback.

<view style="Main">
  <behavior
    xmlns:alert="https://hyperview.org/hyperview-alert"
    trigger="load"
    action="alert"
    alert:title="Something went wrong"
    alert:message="The business could not be deleted. Please try again later."
  />
</view>

Show extra options for user actions

Sometimes a user action may have unclear intent. For example, when deleting a recurring event in a calendar app, it's unclear if the user means to delete just the event on one day, or all future events as well. In situations like this, an alert with the two options can disambiguate the user's intent. When using an alert for disambiguation, providing a "Cancel" option is a good ideas as well.

<view style="Button">
  <behavior
    xmlns:alert="https://hyperview.org/hyperview-alert"
    action="alert"
    alert:title="Delete future events?"
    alert:message="Do you want to delete all future events as well?"
  >
    <alert:option
      alert:label="Delete single event"
    >
      <behavior
        verb="DELETE"
        href="/events/123"
        action="replace"
        target="Main"
      />
    </alert:option>
    <alert:option
      alert:label="Delete all future event"
    >
      <behavior
        verb="DELETE"
        href="/events/123?delete_future=true"
        action="replace"
        target="Main"
      />
    </alert:option>
    <alert:option
      alert:label="Cancel"
    />
  </behavior>

  <text style="Button__Text">
    Delete
  </text>
</view>

Next steps

Check out the full documentation of alerts on the reference page. You can also play around with examples in the demo app or see the HXML samples in the Github repo.

The implementation of alerts demonstrates how behaviors can do more than navigations or screen updates, and how chaining behaviors together opens up new interaction possibilities. The pattern used for alerts will be used for other upcoming features, such as:

  • system permission dialogs
  • action sheets
  • prompts

Look for support for these behaviors in an upcoming release! Follow @hyperview_org on Twitter to hear about the latest news.

Recent Posts