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?

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.

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.

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.