android wear的其他特性

Wear Input Method Framework

In this document

1. Creating an Input Method for Wear
2. Invoking IME
3. General IME Considerations

Wear 2.0 supports input methods beyond voice by extending the Android Input Method Framework (IMF) to Android Wear. IMF allows for virtual, on-screen keyboards and other input methods to be used for text entry. The IMF APIs used for Wear devices are the same as other form factors, though usage is slightly different due to limited screen real estate.

Wear 2.0 comes with the system default Input Method Editor (IME) and opens up the IMF APIs for third-party developers to create custom input methods for Wear.

Figure 1. Sample input methods

Creating an Input Method for Wear

---

The Android platform provides a standard framework for creating IMEs. To create a Wear-specific IME, you need to optimize your IME for limited screen size.

This document provides guidance that can help you create a Wear-specific IME. Before you continue with this guide, it's important that you read the documentation for Creating an Input Method on handsets.

Invoking an Input Method

---

If you are developing an IME for Wear, remember that the feature is supported only on Android 6.0 (API level 23) and higher versions of the platform. To ensure that your IME can only be installed on Wearables that support input methods beyond voice, add the following to your app's manifest:

 android:minSdkVersion="23" />

This indicates that your app requires Android 6.0 or higher. For more information, see  API Levels and the documentation for the   element.

To control how your app is filtered from devices that do not support Wear IMEs (for example, on Phone), add the following to your app's manifest:

 android:required="true" android:name="android.hardware.type.watch" />

Wear provides user settings on the watch that lets the user to enable multiple IMEs from the list of installed IMEs. Once the users enable your IME, they can invoke your IME from:

• A notification or an app using the RemoteInput API.
• Wear apps with an EditText field. Touching a text field places the cursor in the field and automatically displays the IME on focus.

General IME Considerations

---

Here are some things to consider when implementing IME for Wear:

• Set Default Action

  RemoteInput and Wear apps expect only single-line text entry. The ENTER key should always trigger a call to sendDefaultEditorAction, which causes the app to dismiss the keyboard and continue on to the next step or action.

• Use full-screen-mode IME

  Input methods on Wear consume most of the screen, leaving very little of the app visible; using full-screen mode ensures an optimal user experience regardless of the app UI. In full-screen mode, an ExtractEditText provides a mirrored view of the text field being edited and can be styled to blend with the rest of the input method UI. For more details on full-screen mode, see InputMethodService.

• Handle InputType flags

  For privacy reasons, at a minimum you should handle the InputType flag TYPE_TEXT_VARIATION_PASSWORD in your IME. When your IME is in password mode, make sure that your keyboard is optimized for single key press (auto spelling correction, auto completion and gesture input are disabled). Most importantly, keyboard in password mode should support ASCII symbols regardless of the input language. For more details, see Specifying The Input Method Type.

• Provide a key for switching to the next input method

  Android allows users to easily switch between all IMEs supported by the platform. In your IME implementation, set the booleansupportsSwitchingToNextInputMethod = true to enable your IME to support the switching mechanism (so that apps can switch to the next platform-supported IME).

• Wear Navigation and Actions

  In this document

  1. Create a Drawer Layout
  2. Initialize the Drawer List
  3. Create a Custom View Drawer
  4. Listen for Drawer Events

  This lesson describes how to implement action and navigation drawers in your app using the WearableDrawerLayout APIs.

  Create a Drawer Layout

  ---

  To add an action or a navigation drawer, declare your user interface with a  WearableDrawerLayout object as the root view of your layout. Inside the WearableDrawerLayout, add one view that contains the main content for the screen (your primary layout when the drawer is hidden) and additional child views that contain the contents of the drawer.

  For example, the following layout uses a WearableDrawerLayout with three child views: a FrameLayout to contain the main content, a navigation drawer, and an action drawer.

  
      android:id="@+id/drawer_layout"
      xmlns:android="http://schemas.android.com/apk/res/android"
      xmlns:tools="http://schemas.android.com/tools"
      android:layout_width="match_parent"
      android:layout_height="match_parent"
      tools:deviceIds="wear">
  
      
          android:layout_width="match_parent"
          android:layout_height="match_parent"
          android:id="@+id/content_frame"/>
  
      
          android:id="@+id/top_navigation_drawer"
          android:layout_width="match_parent"
          android:layout_height="match_parent"/>
  
      
          android:id="@+id/bottom_action_drawer"
          android:layout_width="match_parent"
          android:layout_height="match_parent"/>
  
  
  

  Initialize the Drawer List

  ---

  One of the first things you need to do in your activity is to initialize the drawers list of items. You should implement WearableNavigationDrawerAdapter to populate the navigation drawer contents. To populate the action drawer with a list of actions, inflate an XML file into the Menu (via MenuInflater).

  The following code snippet shows how to initialize the contents of your drawers:

  public class MainActivity extends  WearableActivity implements
  WearableActionDrawer.OnMenuItemClickListener{
      private WearableDrawerLayout mwearableDrawerLayout;
      private WearableNavigationDrawer mWearableNavigationDrawer;
      private WearableActionDrawer mWearableActionDrawer;
      
      ...
      
      @Override
      public void onCreate(Bundle savedInstanceState) {
          super.onCreate(savedInstanceState);
          setContentView(R.layout.activity_main);
          
          ......
          
          
          // Main Wearable Drawer Layout that wraps all content
          mWearableDrawerLayout = (WearableDrawerLayout) findViewById(R.id.drawer_layout);
          
          // Top Navigation Drawer
          mWearableNavigationDrawer = (WearableNavigationDrawer) findViewById(R.id.top_navigation_drawer);
          mWearableNavigationDrawer.setAdapter(new YourImplementationNavigationAdapter(this));
  
          // Peeks Navigation drawer on the top.
          mWearableDrawerLayout.peekDrawer(Gravity.TOP);
          
          // Bottom Action Drawer
          mWearableActionDrawer = (WearableActionDrawer) findViewById(R.id.bottom_action_drawer);
  
          // Populate Action Drawer Menu
          Menu menu = mWearableActionDrawer.getMenu();
          MenuInflater inflater = getMenuInflater();
          inflater.inflate(R.menu.action_drawer_menu, menu);
          mWearableActionDrawer.setOnMenuItemClickListener(this);
  
          // Peeks action drawer on the bottom.
          mWearableDrawerLayout.peekDrawer(Gravity.BOTTOM);
      }
  }
  

  Create a Custom View Drawer

  ---

  To use custom views in drawers, add WearableDrawerView to the WearableDrawerLayout. To set the contents of the drawer, call setDrawerContent(View)instead of manually adding the view to the hierarchy. You must also specify the drawer position with the android:layout_gravity attribute.

  The following example specifies a top drawer:

  
       
      android:id=”@+id/content” />
  
      
          android:layout_width=”match_parent”
          andndroid:layout_height=”match_parent”
          android:layout_gravity=”top”>
           
              android:id=”@+id/top_drawer_content” />
      
  
  

  Listen for Drawer Events

  ---

  To listen for drawer events, call setDrawerStateCallback()on your WearableDrawerLayout and pass it an implementation ofWearableDrawerLayout.DrawerStateCallback. This interface provides callbacks for drawer events such as onDrawerOpened(), onDrawerClosed(), andonDrawerStatechanged().

  Peeking Drawers

  ---

  To set the drawers to temporarily appear, call peekDrawer() on your WearableDrawerLayout and pass it the Gravity of the drawer. This feature is especially useful because it allows immediate access to the alternate drawer views or actions associated with it.

  mWearableDrawerLayout.peekDrawer(Gravity.BOTTOM);

  You can also call setPeekContent() on your drawer to display a custom view when the drawer is peeking.

  
  

• Bridging Mode for Notifications

  1. Preventing Bridging with the Bridging Mode Feature
  2. Using a Dismissal ID to Sync Notification Dismissals

  By default, notifications are bridged (shared) from an app on a companion phone to the watch. If you build a standalone watch app and have a companion phone app, they may duplicate notifications. The Android Wear 2.0 Preview includes a Bridging mode feature to handle this problem of repeated notifications.

  With the Android Wear 2.0 Preview, developers can change the behavior of notifications with the following:

  • Specifying in the standalone app's Android manifest file that notifications from the corresponding phone app should not be bridged to the watch
  • Setting a dismissal ID so notification dismissals are synced across devices

  Preventing Bridging with the Bridging Mode Feature

  ---

  To prevent bridging of notifications from a phone app, you can use an entry in the manifest file of the watch app (e.g. the standalone watch app), as follows:

  com.google.android.wearable.notificationBridgeMode
      

  Setting that entry to NO_BRIDGING will prevent bridging:

   android:name="com.google.android.wearable.notificationBridgeMode"
                     android:value="NO_BRIDGING" />

  The default bridging behavior occurs if you do not include the entry or if you specify a value of BRIDGING instead of NO_BRIDGING.

  Existing method of preventing bridging

  An existing way to prevent bridging is with the Notification.Builder class; specify true in the setLocalOnly method.

  However, this way to prevent bridging may not be preferable. For example, if a user installs a phone app but not the corresponding watch app, thesetLocalOnly method could prevent the bridging of helpful notifications. Additionally, users may have multiple paired watches and the watch app may not be installed on all of them.

  Thus, if bridging should be prevented when the watch app is installed, use the Bridging mode feature.

  Using a Dismissal ID to Sync Notification Dismissals

  ---

  If you prevent bridging with the Bridging mode feature, dismissals (cancellations) of notifications are not synced across a user's devices. However, the following methods of the NotificationCompat.WearableExtender class enable you to use dismissal IDs:

  public WearableExtender setDismissalId(String dismissalId)
  public String getDismissalId()
      

  To enable a dismissal to be synced, use the setDismissalId() method. For each notification, pass a globally unique ID, as a string, when you call thesetDismissalId() method. When the notification is dismissed, all other notifications with the same dismissal ID are dismissed on the watch(es) and on the companion phone. To retrieve a dismissal ID, use getDismissalId().

  In the following example, syncing of dismissals is enabled because a globally unique ID is specified for a new notification:

  NotificationCompat.WearableExtender wearableExtender =
  new NotificationCompat.WearableExtender().setDismissalId(“abc123”);
  Notification notification = new NotificationCompat.Builder(context)
  <set other fields>
  .extend(wearableExtender)
  .build();
      

  Dismissal IDs work if a watch is paired to an Android phone, but not if a watch is paired to an iPhone.