Posted by Ian Lake, Developer Advocate
Today, we’re excited to give you new tools to build better apps with the rollout of Google Play services 7.3. With new Android Wear APIs, the addition of nutrition data to Google Fit, improvements to retrieving the user’s activity and location, and better support for optional APIs, there’s a lot to explore in this release.
Google Play services 7.3 extends the Android Wear network by enabling you to connect multiple Wear devices to a single mobile device.
DataApi will automatically sync
DataItems across all nodes in the Wear network, the directed nature of the
MessageApi is faced with new challenges. What node do you send a message to when the
NodeApi starts showing multiple nodes from
getConnectedNodes()? This is exactly the use case for the new CapabilityApi, which allows different nodes to advertise that they provide a specific functionality (say, the phone node being able to download images from the internet). This allows you to replace a generic
NodeListener with a more specific
CapabilityListener, getting only connection results and a list of nodes that have the specific functionality you need. We’ve updated the Sending and Receiving Messages training to explore this new functionality.
Another new addition for Android Wear is the
ChannelApi, which provides a bidirectional data connection between two nodes. While assets are the best way to efficiently add binary data to the data layer for synchronization to all devices, this API focuses on sending larger binary data directly between specific nodes. This comes in two forms: sending full files via the
sendFile() method (perfect for later offline access) or opening an
OutputStream to stream real time binary data. We hope this offers a flexible, low level API to complement the
We’ve updated our samples with these changes in mind so go check them out here!
Google Fit makes building fitness apps easier with fitness specific APIs on retrieving sensor data like current location and speed, collecting and storing activity data in Google Fit’s open platform, and automatically aggregating that data into a single view of the user’s fitness data.
To make it even easier to retrieve up-to-date information, Google Play Services 7.3 adds a new method to the
readDailyTotal(). This automatically aggregates data for a given
DataType from midnight on the current day through now, giving you a single
TYPE_STEP_COUNT_DELTA, this method does not require any authentication, making it possible to retrieve the current number of steps for today from any application whether on mobile devices or on Android Wear – great for watch faces!
Google Fit is also augmenting its existing data types with granular nutrition information, including protein, fat, cholesterol, and more. By leveraging these details about the user’s diet, developers can help users stay more informed about their health and fitness.
LocationRequest is the heart of the
FusedLocationProviderApi, encapsulating the type and frequency of location information you’d like to receive. An important, but small change to
LocationRequest is the addition of a maximum wait time for location updates via
setMaxWaitTime(). By using a value at least two times larger than the requested interval, the system can batch location updates together, reducing battery usage and, on some devices, actually improving location accuracy.
For any ongoing location requests, it is important to know that you will continue to get good location data back. The
SettingsApi is still incredibly useful for confirming that user settings are optimal before you put in a
LocationRequest, however, it isn’t the best approach for continual monitoring. For that, you can use the new
LocationCallback class in place of your existing
LocationListener to receive
LocationAvailability updates in addition to location updates, giving you a simple callback whenever settings might have changed which will affect the current set of
LocationRequests. You can also use
getLocationAvailability() to retrieve the current state on demand.
Connecting to Google Play services
One of the biggest benefits of
GoogleApiClient is that it provides a single connection state, whether you are connecting to a single API or multiple APIs. However, this made it hard to work with APIs that might not be available on all devices, such as the Wearable API. This release makes it much easier to work with APIs that may not always be available with the addition of an
addApiIfAvailable() method ensuring that unavailable APIs do not hold up the connection process. The current state for each API can then be retrieved via
getConnectionResult(), giving you a way to check at runtime whether an API is available and connected.
GoogleApiClient’s connection process already takes care of checking for Google Play services availability, if you are not using GoogleApiClient, you’ll find many of the static utility methods in
GooglePlayServicesUtil such as
isGooglePlayServicesAvailable() have now been moved to the singleton
GoogleApiAvailability class. We hope the move away from static methods helps you when writing tests, ensuring your application can properly handle any error cases.
SDK is now available!
Google Play services 7.3 is now available: get started with updated SDK now!
To learn more about Google Play services and the APIs available to you through it, visit the Google Play services section on the Android Developer site.
Join the discussion on