The latest Android and Google Play news for app and game developers.
When constructing the UnreadConversation builder, you are required to pass in a name. This is the name of the conversation that is displayed to the user when messages arrive.
UnreadConversation.Builder unreadConvBuilder = new UnreadConversation.Builder(conversationName) .setReadPendingIntent(msgHeardPendingIntent) .setReplyAction(msgReplyPendingIntent, remoteInput);
For one-on-one conversations, this is simply the name of the other participant. For group conversations, it is best to choose one of two options for the name:
Getting text to sound natural using a TTS system is a challenging problem. There are teams working hard to improve this, but there are steps you can take to create a better user experience with the current capabilities. The Android Auto messaging API does not yet have an option for pairing participants with individual messages in a group conversation. This is problematic for drivers when there are multiple unread messages from multiple participants in a group conversation, as the drivers cannot see which group member sent which message. One solution is to prepend the sender's name to the message whenever the sender changes so that the names are read aloud to the driver.
CharSequence currentSender = null; for (Message message : myMessages) { StringBuilder messageText = new StringBuilder(); CharSequence sender = message.getSender(); // Maybe append sender to indicate who is speaking. if (!TextUtils.isEmpty(sender) && !sender.equals(currentSender)) { if (currentSender != null) { // Punctuation will briefly pause TTS readout between senders. messageText.append(". "); } currentSender = sender; messageText.append(sender.toString().toLowerCase(Locale.getDefault())); // Punctuation will separate sender from message in TTS readout. messageText.append(": "); } messageText.append(message.getText()); unreadConvBuilder.addMessage(messageText.toString()); }
Some things to note about the above sample code:
In searching for how to handle group messaging, you may have noticed UnreadConversation#getParticipants. This can be confusing as there is no mechanism to add multiple participants in the builder. The builder implementation populates the array with the conversation name passed to its constructor. Internally, Android Auto uses the singular UnreadConversation#getParticipant, which returns the first element of the participants array, to populate the title in the notification view.
The Android Auto team is working on ways to make messaging with drivers simpler and more intuitive for app developers. Stay tuned for future updates so that you can continue to deliver a great user experience!
The subscription business model is one of the best ways to make more regular, reliable, and recurring revenue on Android and Google Play. In fact, both developers and users love subscription apps so much that we’ve seen a 10X growth in consumer spend over the past three years and double the number of active subscribers in the past year. Thousands of developers are offering subscriptions through Google Play and are already seeing success with our billing platform. That’s why we’ve been working hard to help you take advantage of this opportunity and give you greater insights into your business and Android users.
You've got a high-performing product with fantastic features and compelling content, but your business can't succeed without acquiring new users. In addition to free trials, intro pricing, flexible billing periods, and more, we recently launched the ability to pay for subscriptions with Google Play balance. Although people have already been using gift cards to pay for Play content in over 20 countries, the use of gift cards to pay for subscriptions in regions where cash is a popular form of payment, such as Latin America, has resulted in as high as a 15% increase in subscription spend.
But it's not just about acquiring new customers, it's about retaining the ones you have. That's why we are introducing account hold, where we work with you to block access to your content or service if a user's form of payment fails. This directly links a payment failure to the user losing access to your content and/or premium features, which is enough to get them to go and choose a new form of payment. When Keepsafe–the developer of Keepsafe Photo Vault, a photo locker for private pictures and videos with over 50M downloads–integrated account hold, their renewal rate on Android increased by 25%. We have over a dozen developers in early access today, and we will be announcing public availability at the end of June.
We know data is vital to running your business, so we're excited to announce a new subscriptions dashboard in the Play Console, and a new report on Android app subscribers.
The dashboard brings together subscription data like new subscribers, cancellations, and total subscribers. It also displays daily and 30-day rolling revenue data, and highlights your top-performing products. This will give visibility into your subscription products and users and will help guide your business decisions.
In addition to products and features, understanding people's needs is core to building a successful subscription business. We talked to 2,000 Android app subscribers in the US and UK and asked them how and why they use the apps they do. The results shared in 'Subscription apps on Google Play: User insights to help developers win' report highlight some of the opportunities for you to grow your subscriptions user base, set pricing strategies and learn to keep your users engaged, including:
Complications are bite-sized pieces of information displayed directly on the watch face. They can also be great shortcuts into your favorite apps. We introduced the Complications API last year to enable watch faces to receive data from any app that the user selects, and display the data to the user in a way that is stylistically coherent. Today, we are introducing four new tools to make it easier for watch face developers to integrate with the Complications API:
It's never been easier to integrate complications into your watch faces.
We have provided Android view components for building watch friendly user interfaces since the launch of Android Wear 1.0. Developers have told us that they would like to see these components open sourced. So, starting at Google I/O, we are open sourcing some components and providing some Android Wear UI components in the Android Support Library. This brings a number of advantages, including more consistent APIs with the rest of the Support Library, more frequent releases, and better responsiveness to developer feedback. We will:
In the first wave of these changes, we migrated the WearableRecyclerView, BoxInsetLayout and SwipeDismissFrameLayout classes to the new Android Wear UI Library. We expect the migration process to continue during 2017, and developers will have until mid-2018 to migrate to the new UI components. For additional information, see Using the Wear UI Library.
To get started with these new tools, simply update the Android Support Library in Android Studio and update your gradle build files to import the new support libraries. In addition to the documentation links above, check out the Google I/O session - Android Wear UI development best practice - where lead engineers for these tools will be on-hand to explain the technical details.
We will continue to update these tools over the next few months, based on your feedback. The sooner we hear from you, the more we can include, so don't be shy! Let us do some of the heavy lifting for your Android Wear apps and watch faces.
Thousands of apps and millions of stores accept Android Pay, a simpler and more secure mobile payment experience. Android Pay is now available in 10 markets, with more coming soon, including Brazil, Canada, Russia, Spain and Taiwan. And in addition to our already announced Visa and Mastercard partnerships, we'll soon enable a streamlined mobile checkout experience for PayPal users.
Yesterday, we announced the Google Payment API, which lets people pay in app or online with any verified credit or debit card saved to their Google Account, via products like Google Play, Chrome and YouTube.
For users, the option to pay with Google means breezing through checkout without needing to remember and type multiple lines of payment details. You simply choose your preferred card, enter a security code or authenticate with your Android device, and check out.
Developers who adopt this API can enable an easy-to-use checkout experience for their customers. Sign up for early access to the new Google Payment API.
In the upcoming months, we'll also enable people in the U.S. to send or receive payments via the Google Assistant. On your Google Home or Android device, it's as simple as saying "Ok Google, send $10 to Jane for pizza." All you need is a debit card linked to your Google account.
We're also announcing new ways for merchants to engage and reward customers before they walk into the store and after they've left.
The Card Linked Offers API drives customer loyalty by providing a new channel to deliver targeted offers, and Panera Bread is one of the first merchants who will roll out this new capability nationally. MyPanera members who save their loyalty card to Android Pay can discover offers and learn about new menu items, surfaced by Android Pay when they are at the store. The offer is redeemed when you use your MyPanera account at checkout.
We're also making it easier for Android Pay users to add loyalty programs. For example, Walgreens Balance Rewards® members who manually apply their loyalty account with a phone number and use Android Pay will receive a notification on their phone that easily enables them to link that loyalty card to Android Pay for future visits. This experience is powered by our smart tap technology, which Walgreens has fully deployed across their 8,000+ U.S. stores.
There's more—we're collaborating with Clover, a First Data company, to expand our smart tap technology beyond national retailers to businesses of all sizes. With the upcoming integration of smart tap in Clover's developer APIs, you'll be able to build Android apps for loyalty, coupon and gift card redemption and new features, such as order ahead and tap for pick up.
Visit developers.google.com/payments for the latest on all of our Google Payment, Loyalty and Offers APIs.
The Android operating system provides a strong foundation for building apps that run well on a wide range of devices and form factors. That being said, we've listened to developer feedback; Issues like complex lifecycles and the lack of a recommended app architecture make it challenging to write robust apps.
We need to make it easier — and more fun — to write robust apps, empowering developers to focus on areas where they can innovate. Today we're announcing a guide to Android app architecture along with a preview of Architecture Components. Rather than reinventing the wheel, we're also recognizing the work done by popular Android libraries.
We know that there's more than one way to write Android applications. What we're providing is a set of guidelines that can help you architect an Android application to work best with the unique ways that Android interacts. The Android framework has well-defined APIs to handle contact points with the OS, such as Activities, but these are entry points into your application, not building blocks for your application architecture; Framework components don't force you to separate your data model from your UI components, or provide a clear way to persist data independent of the lifecycle.
Android Architecture Components work together to implement a sane app architecture, while they individually address developer pain points. The first set of these components helps you:
Lifecycle Components New lifecycle-aware components provide constructs to tie core components of your applications to lifecycle events, removing explicit dependency paths.
A typical Android observation model would be to start observation in onStart() and stop observation in onStop(). This sounds simple enough, but often times you'll have several asynchronous calls happening at once, all managing the lifecycles of their component. It's easy to miss an edge case. The lifecycle components can help.
Lifecycle, LifecycleOwner, and LifecycleObserver
The core class for all of this is Lifecycle. It uses an enumeration for the current lifecycle state along with an enumeration for lifecycle events to track the lifecycle status for its associated component.
LifecycleOwner is an interface that returns a Lifecycle object from the getLifecycle() method, while LifecycleObserver is a class that can monitor the component's lifecycle events by adding annotations to its methods. Putting this all together, we can create lifecycle-aware components that can both monitor lifecycle events and query the current lifecycle state.
public class MyObserver implements LifecycleObserver { public MyObserver(Lifecycle lifecycle) { // Starts lifecycle observation lifecycle.addObserver(this); ... } public void startFragmentTransaction() { // Queries lifecycle state if (lifecycle.getState.isAtLeast(STARTED)) { // perform transaction } } // Annotated methods called when the associated lifecycle goes through these events @OnLifecycleEvent(Lifecycle.Event.ON_RESUME) public void onResume() { } @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE) public void onPause() { } } MyObserver observer = new MyObserver(aLifecycleOwner.getLifecycle());
LiveData is an observable lifecycle-aware data holder class. Your UI code subscribes to changes in the underlying data, tied into a LifecycleOwner, and LiveData makes sure the observer:
This helps to eliminate many pathways for memory leaks, and reduces crashes by avoiding updates to stopped activities.
LiveData can be observed by many listeners, each tied to a lifecycle owner such as a Fragment or Activity.
ViewModel is a helper class that contains UI data for an Activity or Fragment that serves to separate view data ownership from UI controller logic. A ViewModel is retained as long as the scope of its Activity/Fragment is alive, including when the Activity/Fragmentis destroyed and recreated due to a configuration change; This allows ViewModel to make UI data available to the recreated activity or fragment instance. Wrapping UI data stored within the ViewModel with LiveData provides the data an observable lifecycle-aware home. LiveData handles the notification side of things while the ViewModel makes sure that the data is retained appropriately.
The Android Architecture Components also simplify data persistence with the Room library. Room provides an object-mapping abstraction layer that allows fluent database access while harnessing the full power of SQLite.
The core framework provides built-in support for working with raw SQL content. Although these APIs are powerful, they are fairly low-level and require a great deal of time and effort to use:
Room takes care of these concerns for you while providing an abstraction layer over SQLite.
There are three major components in Room:
To use Room, you annotate the Java data objects you wish to persist as entities, create a database containing these entities, and define a DAO class with the SQL to access and modify the database.
@Entity public class User { @PrimaryKey private int uid; private String name; // Getters and Setters - required for Room public int getUid() { return uid; } public String getName() { return name; } public void setUid(int uid) { this.uid = uid; } public void setName(String name) { this.name = name; } } @Dao public interface UserDao { @Query("SELECT * FROM user") List getAll(); @Insert void insertAll(User... users); } @Database(entities = {User.class}, version = 1) public abstract class AppDatabase extends RoomDatabase { public abstract UserDao userDao(); }
Architecture Components are designed to be standalone, but they're most effective when they're incorporated into an effective app architecture. Today we're launching a Guide to App Architecture that shows how to build a robust, modular, and testable app using Architecture Components. The Guide has three main goals:
We recommend all developers who have had to deal with these problems read the Guide; Even if you're happy with your existing app architecture, the Guide will have useful principles and insights.
We're planning to continue being opinionated, and to continue to introduce new Architecture Components to make it easier for Android developers to make informed choices when architecting their applications. We encourage you to try the preview and provide feedback on what we're doing, because we're all in this together to make robust Android app development easier and more fun.
To learn more about Android Architecture, check out:
Play Console
