From 33a1ea297d926ed58c79375dc9f1df782236aaa8 Mon Sep 17 00:00:00 2001
From: Bert McMeen You'll notice that calls to the Data Layer API sometimes return a
- If your code is running on the main UI thread, do not make blocking calls
to the Data Layer API. You can run the calls asynchronously by adding a callback method
-to the If your code is running on a separate handler thread in a background service (which is the case
-in a Wait for the Status of Data Layer Calls
PendingResult,
+PendingResult,
such as
-putDataItem().
-As soon as the PendingResult is created,
+putDataItem().
+As soon as the PendingResult is created,
the operation is queued in the background. If you do nothing else after this, the operation
eventually completes silently. However, you'll usually want to do something with the result
after the operation completes, so the
-PendingResult
+PendingResult
lets you wait for the result status, either synchronously or asynchronously.
Asynchronous calls
PendingResult object,
+to the PendingResult object,
which fires when the operation is completed:
pendingResult.setResultCallback(new ResultCallback<DataItemResult>() {
@@ -51,12 +51,12 @@ pendingResult.setResultCallback(new ResultCallback<DataItemResult>() {
Synchronous calls
WearableListenerService),
+in a WearableListenerService),
it's fine for the calls to block. In this case, you can call
-await()
-on the PendingResult
+await()
+on the PendingResult
object, which blocks until the request completes and returns a
-Result
+Result
object:
An intent filter for the - + {@code WearableListenerService} example shown in the previous section might look like this:
@@ -250,14 +250,14 @@ You can also match a literal path or path prefix. If you are matching by path or path prefix, you must specify a wildcard or specific host. If you do not do so, the system ignores the path you specified. +For more information on the filter types that Wear supports, see the API reference documentation for {@code WearableListenerService}. - -
+For more information on data filters and matching rules, see the API reference documentation for the {@code data} manifest element.
-When matching intent filters, there are two important rules to remember:
+
DataApi.DataListener
- -
+
-
MessageApi.MessageListener
- {@code CapabilityApi.CapabilityListener}
@@ -295,21 +294,21 @@ implementing one or more of the following interfaces:
- Implement the desired interfaces.
- In {@link android.app.Activity#onCreate onCreate()}, create an instance of
-
GoogleApiClient
+GoogleApiClient
to work with the Data Layer API.
-
-In {@link android.app.Activity#onStart onStart()}, call
+In {@link android.app.Activity#onStart onStart()}, call
connect() to connect the client to Google Play services.
- When the connection to Google Play services is established, the system calls
-
onConnected(). This is where you call
+onConnected(). This is where you call
-
+
DataApi.addListener(),
-
+
MessageApi.addListener(), or
@@ -317,14 +316,16 @@ In {@link android.app.Activity#onStart onStart()}, call DataApi.removeListener(),
-MessageApi.removeListener(), or
-
+DataApi.removeListener(),
+
+MessageApi.removeListener(), or
+
+
{@code CapabilityApi.removeListener()}.
An alternative to adding listeners in
-onConnected()
+onConnected()
and removing them in
{@link android.app.Activity#onStop onStop()} is to add a filtered listener in an activity’s {@link android.app.Activity#onResume onResume()} and
remove it in {@link android.app.Activity#onPause onPause()}, so as to only receive data that is relevant to the
@@ -332,18 +333,18 @@ current application state.
- Implement
-
+
onDataChanged(),
onMessageReceived(),
{@code onCapabilityChanged()},
-or methods from
+or methods from
Channel API listener methods, depending on the interfaces that you implemented.
Here's an example that implements
-DataApi.DataListener:
+DataApi.DataListener:
public class MainActivity extends Activity implements
@@ -403,7 +404,7 @@ public class MainActivity extends Activity implements
Using Filters with Listener Activities
Just as you can specify intent filters for manifest-based
-
+
WearableListenerService objects, you can also use intent filters when registering a
listener through the Wearable API. The same rules are applicable to both
API-based listeners manifest-based listeners.
@@ -411,7 +412,7 @@ API-based listeners manifest-based listeners.
A common pattern is to register a listener with a specific path or path prefix
-in an activity’s{@link android.app.Activity#onResume onResume()} method, and to
+in an activity’s {@link android.app.Activity#onResume onResume()} method, and to
remove the listener in the activity’s {@link android.app.Activity#onPause onPause()} method.
Implementing listeners in this fashion allows your application to more selectively receive events,
improving its design and efficiency.
--
cgit v1.2.3-59-g8ed1b