Judul : Android Wear 2.0 Developer Preview 4: Authentication, In-App Billing, and more
link : Android Wear 2.0 Developer Preview 4: Authentication, In-App Billing, and more
Android Wear 2.0 Developer Preview 4: Authentication, In-App Billing, and more
Posted by Hoi Lam, DeveloperAdvocate
A key part of Android Wear 2.0 is letting
watch apps work as standalone apps, so users can respond to messages, track
their fitness, and use their favorite apps, even when their phone isn't around.
Developer Preview 4 includes a number of new APIs that will help you build more
powerful standalone apps.
Seamless authentication
To make authentication a seamless experience for both Android phone and iPhone
users, we have created new APIs for
and added support for one-click Google Sign-in. With the OAuth API for
Android Wear, users can tap a button on the watch that opens an authentication
screen on the phone. Your watch app can then authenticate with your server side
APIs directly. With Google Sign-In, it's even easier. All the user needs to do
is select which account they want to authenticate with and they are done.
In-app billing
In addition to paid apps, we have added
billing support, to give you another way to monetize your Android Wear app
or watch face. Users can authorize purchases quickly and easily on the watch
through a 4-digit Google Account PIN. Whether it's new levels in a game or new
styles on a watch face, if you can build it, users can buy it.
Cross-device promotion
What if your watch app doesn't work standalone? Or what if it offers a better
user experience when both the watch and phone apps are installed? We've been
listening carefully to your feedback, and we've added
new APIs (PlayStoreAvailability and RemoteIntent)
to help you navigate users to the Play Store on a paired device so they can
more easily install your app. Developers can also open custom URLs on the phone
from the watch via the new RemoteIntent API; no phone app or data
layer is required.
int playStoreAvailabilityOnPhone =
PlayStoreAvailability.getPlayStoreAvailabilityOnPhone(getApplicationContext());
if (playStoreAvailabilityOnPhone == PlayStoreAvailability.PLAY_STORE_ON_PHONE_AVAILABLE) {
// To launch a web URL, setData to Uri.parse("https://g.co/wearpreview")
Intent intent =
new Intent(Intent.ACTION_VIEW)
.addCategory(Intent.CATEGORY_BROWSABLE)
.setData(Uri.parse("market://details?id=com.google.android.wearable.app"));
// mResultReceiver is optional; it can be null.
RemoteIntent.startRemoteActivity(this, intent, mResultReceiver);
}
Swipe-to-dismiss is back
Many of you have given us the feedback that the swipe-to-dismiss gesture from
Android Wear 1.0 is an intuitive time-saver. We agree, and have reverted back to
the previous behavior with this developer preview release. To support
swipe-to-dismiss in this release, we've made the following platform and API
changes:
- Activities now automatically support swipe-to-dismiss.
Swiping an activity from left to right will result in it being dismissed and the
app will navigate down the back stack. - New Fragment and View support. Developers can wrap the
containing views of a Fragment or Views in general in the newSwipeDismissFrameLayoutto implement custom actions such as going
down the back stack when the user swipes rather than exiting the activity. - Hardware button now maps to "power" instead of "back" which
means it can no longer be intercepted by apps.
Additional details are available under the
changes section of the Android Wear Preview site.
Compatibility with Android Wear 1.0 apps
Android Wear apps packaged using the legacy embedded app mechanism can now be
delivered to Android Wear 2.0 watches. When a user installs a phone app that
also contains an embedded Android Wear app, the user will be prompted to install
the embedded app via a notification. If they choose not to install the embedded
app at that moment, they can find it in the Play Store on Android Wear under a
special section called "Apps you've used".
Despite support for the existing mechanism, there are significant benefits for
apps that transition to the
delivery mechanism. Multi-APK allows the app to be searchable in the Play
Store on Android Wear, to be eligible for merchandising on the homepage, and to
be remotely installed from the web to the watch. As a result, we strongly
recommend that developers move to multi-APK.
More additions in Developer Preview 4
and Navigation Drawers: An enhancement to peeking behavior
allows the user to take action without scrolling all the way to the top or
bottom of a list. Developers can further fine-tune drawer peeking behavior
through new APIs, such assetShouldPeekOnScrollDownfor the action
drawer.
The curved layout is now opt-in, and with this, the WearableRecyclerView is now
a drop-in replacement for RecyclerView.
protection icon for complications: Complication data providers can now
provide icons for use on screens susceptible to burn-in. These burn-in-safe
icons are normally the outline of the icon in interactive mode. Previously,
watch faces may have chosen not to display the icon at all in ambient mode to
prevent screen burn-in.
Feedback welcome!
Thanks for all your terrific feedback on Android Wear 2.0. Check out
documentation, keep the feedback coming by
Developers community, and stay tuned for Android Wear Developer Preview 5!
Demikianlah Artikel Android Wear 2.0 Developer Preview 4: Authentication, In-App Billing, and more
Anda sekarang membaca artikel Android Wear 2.0 Developer Preview 4: Authentication, In-App Billing, and more dengan alamat link https://androidthenews.blogspot.com/2016/12/android-wear-20-developer-preview-4.html
0 Response to "Android Wear 2.0 Developer Preview 4: Authentication, In-App Billing, and more"
Posting Komentar