Common Entry Points for Android Applications

Nowadays most successful mobile applications are published on multiple platforms. There is a strong tendency to try to design application workflows that work, regardless of the platform. But this can be a mistake.

Many applications might find themselves elevated from "just some app I downloaded" to "an essential app I have to have on my device!" simply by making some tweaks to the way users access the application.

By providing different, cleverly conceived entry points to your application, your application might very well be used a lot more and become invaluable to your users.

The basic application entry points are pretty standardized across the different mobile platforms and developers often focus on these. However, there are also platform-specific mechanisms for getting your user to use your application more often, which are, for the most part, fairly straightforward to implement, and often well worth the effort.

In this tutorial, we will provide an overview of common entry points for Android applications. These entry points will focus on ensuring that your application maximizes its utility to the user.

1. What Are Application Entry Points?

In this discussion, we are using the terminology application entry point to mean "a way that your user gets to your application and uses it." Most of these methods result in your application launching and running, but there are also some subtle ways you might encourage the user to use and appreciate your application without even having to launch it.

Why are Entry Points Important?

I don't think it's unreasonable to say that the more a user uses your application, the more successful your application is likely to become. How you benefit from that usage, whether by charging a fee, through in-app purchases, or by showing ads, is beside the point.

What we’re talking about here is making your application so helpful or essential to the user, that they cannot live without it. If they buy a new device, the first thing they do is download your app.

The Android operating system is well designed for applications to integrate deeply with the user’s working environment, while remaining flexible enough so as not to assume the existence of specific applications or services.

The "Share" feature is a good example of this clever design. An application that creates content does not need to write specific code to share that content on Facebook, Twitter, or SnapChat. The application simply tells the operating system "Hey, I've got this to share!" and the operating system checks which applications can handle that request.

Do I Need More Than One Entry Point?

Most applications benefit from having more than one entry point. If your application isn't shown to the user at the right times, you’re missing key opportunities to improve user experience. This is especially important for applications in the utility and lifestyle categories.

Another reason to consider multiple entry points has to do with user sophistication. If you’ve ever spent time watching someone use a mobile device–especially someone who is at least one generation older or younger than you are—then you’ve probably already realized that people use devices differently.

They navigate differently and they have different levels of understanding about the operating system their device is running. Therefore, it makes sense that you’d want to accommodate these different types of users.

The other argument is that the more ways you provide to the user, the more they will use your application, which is a good thing, right?

Of course, different applications have different needs. Not every strategy makes sense for every application, but, generally speaking, when you only rely on the launch method for your application, you’re selling yourself—and your users—short.

Can I Have Too Many Entry Points?

Applications cannot have too many entry points, but you should see to it that all entry points your application uses make sense for your product. You shouldn't show your application as an option for launch if it doesn't do anything useful for the user.

What you don’t want is for your application to be a nuisance. So it makes no sense, for example, for most music apps to support displaying text documents, or for a game to enable video playback.

You want to get your application launched and used by your user as much as possible. An indispensable application is a successful one. Don’t concern yourself about confusing the user by providing too many entry points. Because of the way the Android operating system is designed, your application will simply be available at the user’s fingertips exactly when they need it, and remain silently in the background when it isn't needed.

2. Examples

In this section, we present a list of some of the most common ways to get your user to be interacting with your Android application. This list is by no means comprehensive and new methods are invented on an almost daily basis. But, in broad strokes, here are some of the most effective methods to lure users in and get them addicted to your application.

Method 1: Your App's Default Launch Sequence

Just about every mobile user understands the default app launch scenario: the user navigates to the app list, taps your app's icon, and launches it. Done!

It doesn’t matter what platform we're talking about. Tapping an app's icon and having the app launch is well understood by most users. Because it's a way your application will most certainly be used, make sure you spend time getting this right. Focus on streamlining the launch process, making it as fast and responsive as possible, while minimizing the taps necessary for the user to get down to business.

The big benefit of the default launch method is that just about every user knows how it works. The drawback, of course, is that the user has to remember to do this on their own.

Try this little exercise: grab your device and go look through all the apps you’ve installed. How many did you download, maybe ran once or twice, and then forget about entirely? Do you feel like launching them now or are they just wasting space on your device?

Most applications work this way. Games especially tend to use this method—launch, start or resume game, play game, save and close game.

Method 2: The Notify & Launch Sequence

A simple way to get users to "remember" to come back to your app is to use notifications. The Android notification system allows for rich notifications to be delivered to the user. The user can read the notification and, if inclined, launch the application.

A good rule of thumb is to provide the richest, most relevant content in notifications. Notification frequency is also very important. You’ve got to strike a balance between reminding users enough to keep them from forgetting about your application, but also not so much that you're spamming or misusing the notification system.

There are a number of best practices for notifications and certain no-nos like badgering your users with marketing notifications, for example.

An email client, for example, may notify the user every time a new mail arrives, but stack and collapse those notifications as needed. For example, if I leave my phone unattended for the day, I may receive 55 new emails, but by the time I look at my notifications, there should only be one notification indicating I have 55 new emails instead of 55 notifications I need to go through one by one.

Note that these notifications are rich: they often contain information about the sender and the subject line and even the first few sentences of the message. They do not just say "You have a new email."

If your application is less a utility and more the stand-alone type, like a game, then you can still use notifications to cajole the user back to your application. I have a game I play sometimes, and if I go a few days without playing, they offer me some free in-game stuff. A strategy like this should be used with caution. You need to avoid bothering your user, perhaps by allowing them to turn off these notifications.

Method 3: Launching By Widgets

Android users customize their devices with widgets on their home and lock screens. Creating a widget that complements your application is an excellent way to keep user eyeballs trained on your application.

Different applications will have different widget requirements. Widgets can do more than display data. You can enable them such that your user can interact with them to shortcut frequent tasks, such as updating their social media status or keep apprised of any changes within the application. Widgets can even launch into the full application, if more features are needed.

A weather application, for example, might use a widget to provide up-to-date forecast data for your current location. Be creative about how to use widgets. For example, a photo gallery application might display cute photographs. A game might have a leaderboard widget, which could entice users back when their friends beat their high score. A travel application might include a widget listing the current TSA threat level or approximate security line wait time at the nearest airport.

Method 4: Launching with Seeded Data by Explicit Intent

The default launch sequence is one where the application just launches without any real knowledge of the user's intent within the application. However, you can also configure your application to launch straight into specific features by providing some metadata with the launch.

Such launches can be implicit or explicit. That is to say, you can create requests to launch a specific application and pass it the data, or you can tell the operating system "Hey, I have this piece of data I want to do something with, what apps can handle it?"

Let’s talk first about the explicit method. In this case, you would likely be the owner of the data to start with. For example, a music player application might have an app widget that allows the user to play music from a playlist. However, the user could click on that widget and the full music player could launch and display all playlists—or the content of that playlist. In this case, your widget would want to cause an explicit launch, because you don’t want to leave it up to the operating system as it may offer the user other music players in addition to yours. It’s not a default launch, instead you'd pass in the playlist data for the current playlist showing in the widget and bring the user straight to the playlist editing screen to do their thing.

Similarly, the widget could display the current song being played of that playlist, and if she taps the album icon for the song, your application could explicitly launch into the album listing screen.

Method 5: Launching with Seeded Data by Implicit Intent

Android's real power really starts to show when we start talking implicit intents. In this case, the requesting application does not specify which application should handle a request. Instead, it just describes the request to the operating system, which uses the intent filtering rules to determine which applications are capable of handling the request. This is also how the operating system figures out which applications can handle an attachment from an email or text message.

For example, a user might receive a music file from a friend and wants to play it. It’s unlikely the email application is capable of playing the audio file. Instead, it’s more likely the client uses an implicit intent to get the operating system to show a list of the applications that can play audio files. So it’s pretty obvious that if your application is capable of playing music, you want the operating system to know it so the user can choose your application over other competing apps.

Your application can listen for specific events sent by the operating system and create intent filters to specify what types of activities and what types of data it can work with.

A media application, for example, might specify that it is capable of playing specific music formats like mp3 or wav files. Similarly, a word processing application might be capable of viewing or editing documents, such as doc and txt files.

However, it wouldn’t make a lot of sense for a word processing application to offer to launch when the user is trying to play music, so you would want to configure your application to filter out requests that don't match it’s run criteria.

The intent filtering mechanism on Android is very powerful and flexible. It's one of the more distinctive and unique features of the Android platform and well worth leveraging, even if the application is also available on platforms that don't support implicit intents. This is especially true if your application can handle common types of content, such as text or audio. A music player consumes music. A social media application might consume text, pictures, and videos. You get the idea.

As we mentioned earlier, this is how Android's "Share" feature works. Let's say you're creating a social media application allowing its users to post text messages, photos, video clips, and sound files. The simplest version of this application might support the default launch scenario:

• The user launches the application or uses the application's widget.
• The user types a message, captures a photo, shoots a video, or records an audio clip.
• The user posts the content to the service.
• The user closes the application.

This is a reasonable user scenario, and it’s certainly one that any social media app should support, but it’s not terribly exciting. It doesn’t take into consideration all the other apps that the user has running on their device, generating exciting and pertinent content the user might want to share.

With a few simple modifications, you can let the operating system show your application to any application generating content that matters to your service.

Method 6: Enabling Your App as a "Share" Source

We've talked about how to prepare your application to accept data from other applications, but it's also important to consider the inverse situation—enabling the "Share" feature within your own application.

You may initially feel a little wary of allowing users to basically export data from your application to other apps. There may even be applications that try to prevent this. But most applications thrive when they play nicely with the rest of the operating system.

Here’s an example. A graphics application might have features that let you create amazing art. If this application doesn't offer the option to share the user's creations, the user's content is stuck in the application.

When users demand some way to export their artwork, developers not terribly familiar with Android might be tempted to develop their own export functionality. This is rarely necessary. By using implicit intents to share the user's content, that graphics application does not need to know a thing about which applications can handle the share request or if they're installed on the user's device. That's the operating system's responsibility. The graphics application creates a request saying "Hey, I’ve got this bitmap file. Can anyone do something with it?"

Let's say I have a zombie game I love to play and the game let's me make short video clips. So I decide to take a little clip of my zombie beheading spree for my friends and try to share it. In this situation, your social media application can be set up as the volunteer to help the user when they choose to share the content. Your application basically says "Hey, I can share video clips, give it here!"

Configuring your application as a share target can be straightforward or you can get sophisticated by trying to have your application adapt to new media types as they come along. Consider if you can provide helpful new ways to get users to use your application this way. You can get quite clever and innovative with this kind of stuff. For example, if your application is a music store and player, it could accept text data and try to match it with song titles or albums, creating a sort of hyperlink mechanism.

Different applications are going to find that different launch methods are most effective. However, some of these methods require significant development and can complicate your application's code base, so you'll want to weigh the benefits against the drawbacks in terms of code complexity and maintenance.

Another helpful way to determine which ways are working best is to collect usage data in your application. It's easy to add hooks to all your launch mechanisms. It will enable you to see how your application's users use and don't use your application.

Just remember that not using a method doesn’t necessarily mean it’s not a good idea, it just might require some education to get users to realize they can perform certain tasks. This is easily managed with a help screen or user tips and suggestions at the right time.

Conclusion

Use these opportunities to integrate your application more tightly with the Android operating system. The more your users use your application in their daily tasks, the more valuable your application becomes to them. But as applications become more socially aware and content is generated by applications—be it text, images, audio, video clips, or what have you—many app developers are learning to find interesting ways to create and share, or consume this content with their own applications.