Android Wear-app Structure for Android Wear (application structure)

Original address: http://developer.android.com/design/wear/structure.html

The user is accustomed to clicking on the icon to launch the app, but Android Wear is not the same. A typical wear application inserts a card into the stream at the right moment in a situation. This card may contain a button for quick interaction to open a full screen view (in some cases, the card may not provide interactive buttons):

The following is a simple sort of building block. You can use one or more of these modules, but we strongly recommend that you do not build such an application: users must carefully consider how to respond to a given location, activity, a specific time of day, or something happening on the cloud before starting or exiting the app.

* Contextual cards in the information flow

1. Bridged notifications (bridging notification) is a notification that is pushed from a handheld device to a wearable device, such as a new SMS notification, and they use the standard Android notification. This kind of notification on the wearable device requires little or no code at all.

2. Contextual notifications (contextual notification) is generated locally on the wearable device and appears only at the relevant contextual point in time, such as when you run a card that appears to exercise your body. You can do more on this type of card than with notifications from a handheld device.

* Full Screen application

1, 2D picker (two-dimensional selector) is designed to allow users to choose from a range of options, such as selecting artists and genres, and so on. Whenever there is an association, we recommend using prebuilt components in the SDK.

2. Custom layouts are also allowed when the basic card is the latter that the stream component cannot meet the application. such as displaying an image or a map.

1, bridged notifications (bridge notification)

On Android Wear, this can be obtained in a simple way. In fact, your app has completed this section if you use notifications. You can use the new notification APIs like add extra pages to add specific wearable features or support voice replies.

DEVELOPER DOCS Creating a Notification

2. Contextual notifications (contextual notification, contextual notification)

Android wear is good at dealing with things like this: displaying the information and features users need when they need it.

Here's how it works: Your app knows when to associate with a user. When the corresponding event occurs, the application will trigger a notification. Maybe you're designing a running app to use when the user is running. or a museum navigation program used when a user visits your museum. See the Design Guide for more information on how to associate your app with contextual contexts.

It is important to correctly trigger the event in the appropriate context, and it is what you need to do to design a good user experience.

The simplest way to implement this kind of notification is to use the standard Android notifications template. Of course, you can also integrate an activity in the card to achieve your own interface layout. If you really decide to do this, we strongly recommend that you take a look at the style guide to make sure you use the same style as your device.

Don't forget to test all the trigger points of your application. Too many triggers can seriously harass the user so that the user may turn off all your notifications.

Develiper DOCS Creating Custom Layouts

3, 2D picker (two-dimensional selector)

The two-bit selector design model (available as a Gridviewpager component) is ideal for displaying options in a list. Search results from Google search are a good example of using this model:

This model can be used to display a single vertical list, or a one-dimensional selector.

It can also be used as a two-dimensional option matrix as a way to display classification options.

Actions

For action responses for each card, use the Action cards pattern (model)

Making it fast (let it run smoother)

Here are some tips on how to make a two-dimensional selector faster:

* Reduce the number of cards

* Show the most commonly used cards at the top

* Keep your cards as simple as possible

* Optimized speed to exceed custom

The navigation should be vertical and horizontal, not first horizontal and vertical, and limit the cards in the vertical direction to no more than 5 sheets.

Exiting (Exit)

When the user makes a selection, you should turn off the two-D selector. The user may also exit by sliding the first card down or swiping the leftmost card to the right.

4. Breaking out of the "card" (with custom layouts) (using the customized layout to break the card limit)

There's something you can't show on the card. For example, slide some routes on the map or use the joystick to control the game. In these cases, a quick jump to full screen may be a good solution.

A typical full-screen app experience on Android Wear is as follows:

1. Your context card is inserted into the stream

2, the user clicks the action button of the card.

3. Open a mini-interactive full name activity.

4. Exit the activity and the user returns to the information stream.

When to go full screen (time to enter fullscreen)

We strongly recommend that you jump to the full-screen interface only if you are unable to process your transaction on a single card, and quickly exit the full screen to return to the stream after the user has completed a simple interaction. This will make your application feel more like part of the system. The Android wear itself goes into full screen when the voice is restored or the visualization is stopped.

Making it distinct (make it unique)

Your full screen interface should not be similar to the card stream to avoid misleading users. If you really need a card-style UI, consider using a two-dimensional selector.

Automatically exiting (Auto exit)

Many devices do not provide a return and main interface button, so how to exit is something you should consider. Here are some examples of natural exits:

* If the map requires users to mark a location, they should exit when the user labels.

* When a small game is finished, exit naturally.

* An animation app can exit after 5 seconds of activation.

Manually exiting (manual exit)

There are some logical exits, such as in some situations where the user wants to exit immediately. This is often a long-running application. In this case, using Dismissoverlayview, you should handle long press events to send out the intent.