Author: Mark Murphy

Enabling the Ecosystem is a series of interviews with those people and firms that are helping to build the overall Android ecosystem.

This week’s interview is with Andreas Schobel, CTO of Snaptic, makers of the 3banana note-taking application. 3banana, unlike an ordinary note-taker, offers integration hooks to allow third-party apps to add and manipulate notes.

AG: The API seems one-way. Is there any sort of reverse integration (e.g., a note has an Intent attached that allows the user to go back to the app that created the note)?

AS: Developers can get a list of their notes and filter on #tag. We are looking at ways to allow more hooks back into the source app.

AG: Similarly, is there any way for an app to delete its own notes, query its notes, update its notes, etc.? Or is it that once a note is in 3banana Notes’ (virtual) hands, it is up to 3banana Notes and the user to maintain the note?

AS: The great thing about Intents is that it blurs the line between where your app ends and the other app starts. For example, when a user gets a list of notes from Tip Calculator, they also get an in-app list of all their tips, which allows the user to edit, update, and delete their notes.

In general, the notes functionality is the same in an integrated app and 3banana. Intents allow full functionality of 3banana in an integrated app without having to leave the integrated app. The apps are speaking to each other. You don’t have to use 3banana to edit notes you saved in, let’s say, Tip Calculator. You can just use Tip Calculator to view and edit and Tip Calculator will tell 3banana about any changes. It also works if you make changes in 3banana to any Tip Calculator notes, 3banana will talk to Tip Calculator.

AG: Are there any fees for developers to integrate with 3banana Notes?

AS: There are no fees, and we have zero plans to have any. This is really a case where open is good for everyone. Developers win, apps are cooler, and customers benefit by having more use of their content.

AG: What sorts of cross-promotional opportunities are there for developers who integrate with 3banana Notes (e.g., you promote them, they promote you)?

We love to show off the neat ways people are integrating with our platform. We have a gallery of integrations and highlighted our partners at our South By Southwest panel we spoke at a few weeks ago. We are also doing some videos showing off the features, and are actually hosting a developer conference on May 27 in San Francisco.

We are really interested in seeing Android continue to thrive and to keep creating new and more interesting feature combos that users love. We are planning on hosting a couple of these a year to create live opportunities to share ideas and work together. We are loading up on a really cool contingent of speakers and a hackackton for this event. We even have Marten Mickos, the former CEO of My SQL on deck at the conference to talk about running a startup that really leveraged open development. If anyone wants to check it out they can sign up for more info at snaptic.com/events, it is going to be fantastic!

Enabling the Ecosystem is a series of interviews with those people and firms that are helping to build the overall Android ecosystem.

This week’s interview is with Andreas Schobel, CTO of Snaptic, makers of the 3banana note-taking application. 3banana, unlike an ordinary note-taker, offers integration hooks to allow third-party apps to add and manipulate notes.

AG: So, what is 3banana Notes, and why is it important to Android developers?

AS: 3banana helps users capture information in a note-taking application wherever they are, and helps them make the most of that content. Users can save text, photos, location and keep notes organized by easily adding a #tag. Notes are securely backed-up to https://snaptic.com.

What is really nice for developers is that they can add the ability to capture notes in their apps with only a few lines of code. You can find out about more integrations at: https://snaptic.com/gallery/.

AG: How does an Android developer tie their app into 3banana Notes?

AS: The easiest way is to use our Intents. With a few lines of code a developer can quickly save text, photos, and location and then be able to get back a list of their notes. You can find out more at http://github.com/snaptic.

AG: What restrictions does this integration place on the developer’s own application? For example, does 3banana Notes require an Internet connection and will cause problems if the developer’s app tries to create a note when no Internet connection is available?

AS: Being able to access your notes offline with 3banana is something we are really proud of. Offline access means your notes are always available, and if the user decides to turn on sync, everything gets securely backed up when you are online again.

More generally, besides needing 3banana installed on the phone, the only restriction would be the scenario of needing 3banana online to save and edit notes. However, because we offer offline usage, this restriction doesn’t exist. The next time the phone is online, everything will sync and resolve.

AG: What sorts of notes can a developer create? Plain text? HTML? Images? Sounds? Other file formats?

AS: We support text with some HTML, photos, and locations.

Part two of this interview comes tomorrow!

In the Code Pollution series, I’ll be writing about topics where a coding anti-pattern may work tactically for an individual application, but strategically will be bad for Android as a whole, just as pollution may benefit one firm while harming many others.

In the previous post in the Code Pollution series, I pointed out how it is possible for background processes, such as those driven by AlarmManager, can wind up with foreground priority and impact real-time games. Poor frame rates is not the only reason that a user might be concerned about your application’s use of background operations, though.

A popular application category on the Android Market is the so-called “task killer” app. These apps exploit some Android API loopholes to kill off everything associated with an application: services, activities, AlarmManager alarms, etc. Many developers decry these tools, complaining that users then gripe that the developers’ apps do not work, when it was the users themselves (with the task killer’s help) that broke the apps in the first place.

While I agree that the task killers are probably overused, there is also little question that some Android apps are not “good citizens” when it comes to their use of background operations. Perhaps they try to have everlasting services, or perhaps they poll too frequently, or try to do too much in the foreground windows, or something.

In the end, user satisfaction is dependent upon Android apps being responsible in their use of background operations. Here are some tips on how to stay in your users’ good graces.

First, avoid those everlasting services. Users get nervous if they see your service hanging around in memory all the time, particularly if they think they are experiencing performance issues. Users might use a task killer to shut down your service, or they might use the Settings application in newer versions of Android. To the greatest extent possible, architect your application to run on a scheduled basis using the AlarmManager, rather than assuming you will be successful in keeping your service in RAM indefinitely.

Therefore, you might decide that you want the AlarmManager to invoke your service frequently, such as every minute. That may make sense to you. It might not make sense to your users. Make your alarm periods configurable. Even if you elect to choose an aggressive default, let the user choose something that is less frequent. You can cancel and re-establish your alarm when the user changes the setting.

One special case of configurable alarm periods is infinity — in other words, allow the user to disable your background operations altogether. Yes, background work is sexy. On the other hand, as of the time of this writing, iPhone does not support background operations for third-party applications. The fact that iPhone apps can be successful without background operations means you can be successful as well by letting the user choose to forgo such background work. You might want to pop up a dialog or something to warn the user of lost functionality if they disable it, but still let them disable it.

Understand that, even with this configurability, the user might still nuke your app via a task killer. Do not fight the user. The user knows what the user wants. It is up to you to deliver. If the user wants your background operations disabled and chooses to do that via a task killer than your preference activity, so be it. In fact, if you have a good way to check to see that you were killed (e.g., the time gap between your last background run and now is well over the alarm period), you might even pop up a dialog saying something to the effect of “I see you used a task killer to get rid of me. Would you like my background operations to be disabled?”. That way, you turn a negative (user feeling a task killer is appropriate for your app) into a positive (you demonstrate that you are aware of their interest and can be configured the way they want).

That is one facet of a bigger issue: do not assume you know best. Yes, you like your app. Yes, you think all users will like your app and want to use it the same way you do. That rarely works out in reality. Even some things you might consider essential may not be. For example, one argument for using an everlasting service is a VOIP app — after all, there is no other way to receive an incoming call if there is no service with a socket watching for calls from the SIP server. However, that assumes the user wants incoming calls. Perhaps they do not, wanting VOIP just for outbound calls. If you do not let this be configurable, they will be inclined to smack your app around via a task killer to get rid of the service.

Some mobile operating systems preclude background operations. Android does not, but that does not mean background operations are always a good thing. Let the user decide. The more developers do this, the less of a problem task killers will pose for everyone.

So far, I have documented 49 Android business models, only one of which involves selling individual apps to individual users via the Android Market.

Model #50 is to get paid up front.

Once you have established some credibility, perhaps through a free app or two, you might consider trying to fund your app development before you actually build the app, or at least before you complete the app. While this may cap how much you make, it also limits your downside risk.

This may sound bizarre. After all, if you are having difficulty getting people to pay 99 cents for an app on the Market, how can you get people to pay money before there is even an app?

Yet some developers and other folk have managed to pull it off.

Take, for example, Zombie Defense for the iPhone. This project was initiated via Kickstarter, a site for enabling this sort of project funding. He requested $700 up front to complete the app, based on a short project description. He collected $701 from a total of 14 people.

Why did they contribute?

Some probably did because they thought the game might be interesting. Others, though, were in it for the rewards.

What Kickstarter promotes is selling things that are scarce — such as being mentioned on a credits page in the app — to help fund the development of things that are not necessarily scarce (in this case, copies of an app). In this case, while the rewards were…well…not earth-shattering, they were apparently sufficient to get the seed money the developer wanted to complete the project.

The app itself is not free (after a trial period), so the developer still gets money from the iPhone App Store for sales.

Will this work for everyone? Probably not. After all, there are other iPhone projects on Kickstarter that haven’t received much funding at all. However:

• If you have established a dialogue with existing users of your apps (via a newsletter, blog, Twitter, whatever), you will have an easier time than if you are just trying to beg for money from the public at large. After all, your current users have already demonstrated interest in your work.
• If you can come up with creative rewards, you will have an easier time enticing people to fund you. Can the user be a character in your game? Can the user get votes on features to include in your app? Can the user get this new app, or past ones, for free by helping to fund up front? Will you be willing to release the app for free for everyone if you get enough funding?
• In the end, a weak app proposal will have as much difficulty getting funded up front as it would getting sales later on. In fact, this is one of the advantages of a Kickstarter model — it can help you gauge potential interest in the app.

Kickstarter will not work for everyone and will not be right for every app. But, it is certainly something you could consider, in your quest to make money at mobile.

Not quite three weeks ago, I made a request in this column for “reasons for root” — business arguments why a device manufacturer should be willing, perhaps even interested, to allow replacement firmware and/or root access on their devices. That post received a number of comments, as did a tweet and a thread on the [android-discuss] Google Group.

I then culled those ideas, along with my own, into a report. I passed a draft by a few people, got more feedback, and incorporated those changes as well. You can view the full seven-page report here.

I divided up the arguments into two groups: reasons that benefit Android as a whole against competing platforms, and reasons that benefit one Android device manufacturer in competition with other such manufacturers. Helping Android overall is a “rising tides lifts all boats” approach to helping any given manufacturer. However, given that firms like HTC and Motorola are competing on Android devices as much as collaborating on the OS itself, we needed some arguments there as well.

Three reasons came to light for how replaceable firmware helps Android as a whole:

• It should increase the number of developers skilled in Android firmware, and those developers are key for everything from implementing features to customizing Android for specific enterprises or other bulk customers
• It should reduce concerns about upgrade paths that put Android at a disadvantage compared to iPhone
• It helps Android stay ahead of, or at least on par with, platforms competing on openness, such as Symbian and Meego

For helping a specific Android device manufacturer, the report outlines:

• Just because a device manufacturer came up with one use for a product does not mean there are no other uses that might drive sales, as is seen in “hackable” products like the Linksys WRT64GL router
• Many technology leaders like Android for its openness and will tend to like open devices more than closed ones — getting them to back your device can help with promotion
• Getting more firmware developers working on Android — per the first bullet point in this post — gives you a bigger pool of potential hires or contractors, and having some with specific knowledge of your own devices makes them that much more useful
• If Android and other open platforms represent another step on a trend line from completely closed to the current semi-open state, one way to exploit that trend is to get in front of it

Obviously, this report does not include every possible argument, specifically trying to stay away from emotional or ethical points and sticking to business and financial ones. I am sure there are more ideas and arguments to be made, so I expect this report to be a “living document”, republished periodically, gaining strength each time.

Feel free to read and distribute the report, and send me your additional ideas, as comments here, or via posts on the [cw-android] Google Group.

Let’s assume, for the moment, that the New York Times article is correct: Google TV is coming, and it runs on Android. Let’s further assume that some, if not all, Google TV devices (or other TV set-top boxes) will allow third-party Android applications, versus routing everything through a Chrome-style browser. And, let’s further assume that the article is correct and developers will get tools “within the next couple of months” and that products “could appear as soon as this summer”.

What should you, the intrepid Android application developer, be thinking about?

First, think big…as in screens. Suffice it to say, one should expect Google TV to run on something bigger than a 3.5″ LCD. A 35″ LCD is probably closer. 720p (1280×720) and 1080p (1920×1080) seem likely supported screen resolutions. Android will probably handle these like they handled previous resolution changes, with some automatic scaling plus the option for you to specify your own appropriately-formatted resources (e.g., res/layout-reallyfrakkinhuge). You still wind up with more screen real estate than you might ever have thought possible, and it is up to you to figure out what to do with it.

Then, think low…as in density. A 37″ 1080p screen will have lower density than a 27″ 1080p screen, which probably has lower density than the monitor you’re looking at now, which certainly has lower density than any Android phone. So, while you have lots more pixels, each pixel also will take up more physical space than before.

Next, think far…as in the user’s distance from the screen. Most people using a smartphone will use it at arm’s length at most, frequently closer. Most people watching TV will watch it at arm’s length at least, frequently farther. The net of these first three points is that it will take some time for us to work out the heuristics for what will look good on a TV compared to looking good on a phone.

Later, think remote…as in remote controls. You may have been spoiled by Android devices generally sporting touchscreens, even if they were a mix of resistive (stylus) and capacitive (finger) styles. Most TVs aren’t touchscreens, except around small children. It is rather likely that a Google TV will offer some sort of remote control, perhaps like those available for the Neuros Link or upcoming Boxee Box. Figure that users will be using trackballs or arrow keys to navigate the app, just like they might use a D-pad or trackball on a phone. The good news is that you can get all of this working on your app today, if it’s not working automatically.

Then, think poor…in terms of features you might be used to in Android devices. I doubt a TV set-top box will have GPS, for example, so any code of yours that assumes GPS for location will need to be made more flexible. Similarly, many Google TV setups probably will lack traditional GSM/CDMA telephony, SMS capability, and the like. The home screen will probably be vastly different, there may not be a camera on some models, etc. Now, an Android set-top box might have other positive features (e.g., more space for apps), but some things that make sense for a device in your pocket will not make sense for a device sitting underneath a TV.

Finally, think rich…in terms of the possibilities. Whether it is formal Google TV or devices from other firms, an Android set-top box offers new avenues for distribution of your applications, through the Android Market, through OEM bundling deals, etc. If and when this stuff becomes available, are there opportunities related to your existing apps, or other ideas you have been kicking around, that might work great on a TV? It might even be worthwhile for you to pick up a Link, or play with Boxee on your PC, to see how they approach the set-top box arena, to give you other ideas.

In the meantime, the (Android) world waits to see whether or not, in this case, the New York Times’ news was, indeed, fit to print.

In the Code Pollution series, I’ll be writing about topics where a coding anti-pattern may work tactically for an individual application, but strategically will be bad for Android as a whole, just as pollution may benefit one firm while harming many others.

In previous posts, I complained loudly about trying to write services that remain in memory all of the time, and extolled the virtues of using AlarmManager to convert those services into scheduled tasks (a la Linux cron jobs). That advice is still very valid, but there is one scenario that the previous posts do not take into account.

But, first, a word (or, perhaps, several words) about games.

Real-time games, like the ever-popular first-person shooter (FPS) genre, aim to push a high “frame rate”. The faster the frame rate, the smoother the animations will appear. Game developers go to great lengths to make sure their application does not stall unexpectedly due to its own code — for example, developers will avoid generating garbage and will try to run the garbage collector only at safe times.

That is all fine and well, but a persistent concern for game developers on Android is the impacts that external forces have on their frame rates. For example, a year ago, the big concern was garbage collection going on in other processes — garbage collection takes CPU time, even if that work is being done in a totally separate Linux process from the game itself.

To counteract this, the core Android team made some improvements in Android 1.6, relegating all background processing to a class that is capped in terms of CPU utilization, leveraging some Linux process and thread control frameworks. Garbage collection in those background processes will no longer hog the CPU. Hence, games can run with minimal interference…so long as background processing stays in the background.

What has come to light recently is that there are still circumstances when code that was in the background class will be promoted to the foreground, at least briefly, to prevent operating system stalls. The two documented scenarios are:

• BroadcastReceiver objects will be brought to the foreground for the onReceive() call
• Services will be brought to the foreground for onCreate(), onStart(), and onDestroy()

Hence, while normal background processing is CPU-capped, any processing done in the two areas shown above will be in the foreground class and could steal more significant CPU time from the game.

And this is where the AlarmManager pattern comes in.

AlarmManager triggers a BroadcastReceiver to get control, in onReceive(), at the time an alarm goes off…which could be in the middle of a game. If that receiver attempts to do significant work in onReceive() itself, it will impact the frame rates of games being played at that time. You have long been encouraged to keep onReceive() calls short — this is just another reason to keep these to the millisecond range, not several seconds.

The best pattern, overall, for using AlarmManager is to use the BroadcastReceiver as a bridge to an IntentService. The IntentService will do whatever significant work there is in a background thread, one that should remain part of the background class and therefore will not harm game play. The downside is that the IntentService may wind up being created, started, and destroyed, and those specific operations will run in foreground priority. So long as you do not add any logic of your own to those three callbacks — relying instead on IntentService’s stock implementation — the effect should be minimal…but there will still be an effect.

The ideal solution would be for your background code to realize that a time-sensitive foreground operation is underway, so you can perhaps disable your alarms outright, or at least dial back their frequency. This could be accomplished in the operating system, but it could also be done as a community standard. We could come up with a pair of broadcast actions (e.g., GAME_ON, GAME_OFF) that everyone aims to honor. A game would broadcast GAME_ON before the game begins; those implementing alarms would respond by disabling those alarms. Similarly, the game would broadcast GAME_OFF to notify background work to resume normal operation. We would need to work out the mechanics of handling the case where GAME_OFF was not broadcast, due to crashes or evil developers.

Regardless, for those of you who use AlarmManager, please do what you can to make sure that you do as little work as possible in the foreground windows of background processes. Our ability to frag rests in your hands.

Back in September, I ran a series of five blog posts on different Android business models, where selling individual apps to individual users through the Android Market (and kin) was just one of the models.

On Saturday (March 6th), I will be speaking at Chicago’s Day of Mobile conference on this topic. I figured it was time to toss out another 9 business models for you to consider.

Again, the goal is to demonstrate that there are many, many ways to try to build a business in mobile, particularly with Android — engineers who focus exclusively on the Android Market are missing out!

Most of these models are focused consulting specialties — not just claiming to be an Android developer, but places where you might become world-renowned in a specific niche.

Model #41: Porting Specialist

Rather than just advertise yourself as a generic Android consultant, become expert in helping firms port existing mobile applications to Android. You might specialize in iPhone->Android, to help firms who jumped on the iPhone bandwagon catch up on Android faster. You might specialize in Windows Mobile->Android, to help firms worried that their legacy WinMo code will not work on the new Windows Phone platform. And so on.

Model #42: Native-izer

Android’s Native Development Kit (NDK) provides a gateway to native code, written in C/C++, implemented as extension libraries for traditional Android Java-based apps. Many applications could take advantage of the NDK to speed up algorithms: signal processing, game physics, encryption, and so on. However, many Android developers are comfortable in Java and less comfortable in C/C++, particularly for mobile. Develop the expertise, then promote your ability to help firms accelerate their Android apps by converting key portions of Java code to native code.

Model #43: Mobile Web Guru

Let’s face it: despite more and more platforms standardizing on WebKit, there are still plenty of idiosyncrasies when developing Web content for mobile. These range from WebKit version differences to trying to adapt desktop browser libraries to work better on the small screen and over mobile broadband connections. You could aim to become an expert in this process, helping firms tweak their Web sites’ mobile editions to work well on Android and other mobile platforms. This could easily extend to helping them create applications using tools like PhoneGap, that allow you to write cross-platform mobile apps using traditional WebKit-hosted HTML, CSS, and Javascript. Or, you might work on the techniques to create offline-capable Web apps using HTML5 and help clients implement those for Android and other HTML5-capable platforms.

Model #44: Accessibility Maven

Android offers text-to-speech and speech-to-text (a.k.a., voice recognition), haptic response, and other technologies designed to help with accessibility. However, it is easy for developers to skip over these features — after all, some of us are still climbing the hill towards internationalization and localization. Top-notch Android apps, though, will make themselves accessible, providing access to new markets begging for this sort of support. You could become an expert in accessibility on Android, helping developers (through code, training, or consulting) make their applications more accessible.

Model #45: Talent Agent

A lot of focus has been placed on firms using various techniques, like off-shoring, to reduce the salaries of their programming staff. However, some firms are realizing that, for the right talent, paying top dollar (or euro or yuan or whatever) makes some sense. Some developers are simply more productive than others, particularly when it comes to new technologies that existing staff lacks experience in. We are not far from a world where “rock star” developers might actually want to retain agents to help negotiate contracts. Such agents will need to know enough about the technology to “speak the language” while also being able to strike deals, while earning an agent’s commission along the way.

Model #46: Enterprise Customizer

Over time, more and more enterprises will be interested in Android. Some of them will want handsets tailored to their specifications, not so much in terms of hardware, but in terms of firmware and software. Some may want phones without the ability for users to install software, or phones that have “call home” capabilities if they are reported lost (that cannot be readily disabled), or phones that store all modifiable data in encrypted partitions.

Android, out of the box, is a consumer operating system today. However, it is open source, and in partnership with the right device manufacturers, Android could be tailored for enterprise use. However, device manufacturers may not have the staff or expertise to do that customizing themselves, turning to outside consultants who can spend the time to learn enterprises’ needs and adapt handsets to match.

Model #47: Sync Specialist

Android 2.0 introduced the notion of syncing contacts with third-party contact registries, ranging from Exchange to Facebook. Creating such synchronization code is no picnic, either on the handset or on the server. You might aim to become expert in helping firms needing such synchronization — whether to public social networks or proprietary enterprise systems — enable such synchronization for Android devices.

Model #48: App Generator

A lot of noise is created about the gap in catalog sizes between the iPhone App Store and the Android Market. A substantial portion of that gap comes from “generated apps”, ebooks being the most prominent. There are some 20,000 books available for iPhone on the App Store and far fewer than that for Android on the Market. These are not custom-written applications, but rather generated from existing content (e.g., EPUB).

You could create app generators designed to allow non-technical people to get their ebooks, audiobooks, RSS feeds, or other off-the-shelf content into the Android Market. Create a site that accepts the content as input and spits out a signed APK as output for the customer to upload from their Market account. You would be selling access to the app generators, or perhaps for specific generation capabilities (e.g., different prices for simple ebooks or ebook+audiobook combination apps).

Model #49: Augmented Reality Layer-er

As augmented reality (AR) apps continue to grow in popularity and power, different firms or groups may want to have their data represented in AR layers, but lack the time and expertise to do so. This is especially true so long as there are no standards for what such layers should look like, requiring custom work for different AR engines. You could become expert in these AR engines and in layer creation, to help cities or activists or whoever get their data out in this new visualization technology.

When new Android devices show up, one of the first questions raised is: “can we run our own firmware?” And, if that’s not first overall, then the first question is probably “how do I get root access?”. After all, those two are somewhat related — you sometimes need root to flash alternative firmware, and alternative firmware may well give you root access.

There is little question what benefit this provides to some users: full control over their devices.

What is not clear, though, is why a device manufacturer should want to do this in the first place.

Case in point: Motorola. They have been raked over the coals recently by a vocal set of Milestone owners who are peeved that the DROID can have replacement firmware and the Milestone cannot. In reality, “normal practice” for Motorola is to prevent “a non-Motorola ROM image from being loaded” — the Milestone will not be alone.

If we, the community, want hardware manufacturers to more routinely allow users the ability to gain root or flash their phones with replacement firmware, we need to speak to them in business terms. How will offering these abilities help hardware manufacturers sell more devices, reduce technical support costs, or otherwise make more money than they are today?

I have a few ideas, but this post really is to solicit input from you. How do you think device manufacturers can benefit from granting root/firmware capabilities? Add comments on this post, and I will organize the ideas (and add my own) in a later follow-up post.

The ground rules:

• I want business and economic arguments. While there are moral and ethical reasons for offering users full control over their devices, that is unlikely to sway most manufacturers. Remember: we need to speak their language.
• Act like professionals. In business, it helps to do unto others as you would have them do unto you.
• That being said, both carrots and sticks are valid suggestions. If you can make a plausible argument that, say, failure to allow replacement firmware violates some license somewhere, that’s worth noting. I’m hoping we come up with many more carrots than sticks, of course.
• Do not overestimate the size of the current modding community. Yes, tens of thousands of people are using Cyanogen and related ROMs. However, that is on a base of millions of Android devices and tens (maybe hundreds?) of millions of smartphones. Even if all current modders were to race out and switch to some specific manufacturer’s devices en masse, that may not “move the needle” very much. So, arguments of how much the modding community will value a more open policy need to indicate how that policy — and the community — will grow that base to be a more significant number.

With that, it’s over to you. What business reasons does a manufacturer have to switch to an open root/firmware poilcy?

This is the first part of a several part series on handling multiple screen sizes in your Android projects. This material is adapted from a chapter in The Busy Coder’s Guide to Android Development, Version 3.0.

So far, in the previous posts of this series, we have focused on how you can ensure your layouts look decent on other screen sizes. And, for smaller screens than the norm (e.g., QVGA), that is perhaps all you can ask for.

Once we get into larger screens, though, another possibility emerges: using different layouts designed to take advantage of the extra screen space. This is particularly useful when the physical screen size is larger (e.g., a 5″ LCD like on the ARCHOS 5 Android tablet), rather than simply having more pixels in the same physical space.

Here are some ways you might take advantage of additional space:

Replace Menus with Buttons

An option menu selection requires two physical actions: press the MENU button, then tap on the appropriate menu choice. A context menu selection requires two physical actions as well: long-tap on the widget, then tap on the menu choice. Context menus have the additional problem of being effectively invisible – users may not realize that your ListView, for example, has a context menu.

You might consider augmenting your user interface to provide direct on-screen ways of accomplishing things that might otherwise be hidden away on a menu. Not only does this reduce the number of steps a user needs to take to do things, but it makes those options more obvious.

For example, let us suppose you are creating a media player application, and you want to offer manual playlist management. You have an activity that displays the songs in a playlist in a ListView. On an option menu, you have an “add” choice, to add a new song from the ones on the device to the playlist. On a context menu on the ListView, you have a “remove” choice, plus “move up” and “move down” choices to reorder the songs in the list. On a large screen, though, you might consider adding four ImageButton widgets to your UI for these four options, with the three from the context menu enabled only when a row is selected by the D-pad or trackball. On regular or small screens, you would stick with just using the menus.

Replace Tabs with a Simple Activity

You may have introduced a TabHost into your UI to allow you to display more widgets in the available screen space. So long as the widget space you “save” by moving them to a separate tab is more than the space taken up by the tabs themselves, you win. However, having multiple tabs means more user steps to navigate your UI, particularly if they need to flip back and forth between tabs frequently.

If you only have two tabs, consider changing your UI to offer a large-screen layout that removes the tabs and puts all the widgets on one screen. This puts everything in front of the user, without having to switch tabs all the time.

If you have three or more tabs, you probably will lack screen space to put all those tabs’ contents on one activity. However, you might consider going half-and-half: have popular widgets be on the activity all of the time, leaving your TabHost to handle the rest on (roughly) half of the screen.

Consolidate Multiple Activities

The most powerful technique is to use a larger screen to get rid of activity transitions outright. For example, if you have a ListActivity where clicking on an item brings up that item’s details in a separate activity, consider supporting a large-screen layout where the details are on the same activity as the ListView (e.g., ListView on the left, details on the right, in a landscape layout). This eliminates the user having to constantly press the BACK button to leave one set of details before viewing another.

---

You can see some of these techniques utilized in the EU4You sample applications, covered in The Busy Coder’s Guide to Android Development, Version 3.0.

This is the first part of a several part series on handling multiple screen sizes in your Android projects. This material is adapted from a chapter in The Busy Coder’s Guide to Android Development, Version 3.0.

The Android emulators will help you test your application on different screen sizes, to exercise the support you added based on the previous blog posts in this series. However, that will only get you so far, because mobile device LCDs have different characteristics than your desktop or notebook, such as:

• Mobile device LCDs may have a much higher density than does your development machine
• A mouse allows for much more precise “touchscreen” input than does an actual fingertip

Where possible, you are going to need to either use the emulator in new and exciting ways, or try to get your hands on actual devices with alternative screen resolutions.

Density Differs

The Motorola DROID has a 240dpi, 3.7-inch, 480×854 pixel screen.

To emulate a DROID screen, based on pixel count, takes up one third of a 19″ 1280×1024 LCD monitor, because the LCD monitor’s density is much lower than that of the DROID – around 96dpi. So, when you fire up your Android emulator for an FWVGA display like that of the DROID, you will get a massive emulator window.

This is still perfectly fine for determining the overall look of your application in an FWVGA environment. Regardless of density, widgets will still align the same, sizes will have the same relationships (e.g., Widget A might be twice as tall as Widget B, and that will be true regardless of density), and so on.

However:

• Things that might appear to be a suitable size when viewed on a 19″ LCD may be entirely too small on a mobile device screen of the same resolution
• Things that you can easily click upon in the emulator with a mouse may be much too small to pick out on a physically smaller and denser screen when used with a finger

Adjusting the Density

By default, the emulator will keep the pixel count accurate at the expense of density, which is why you get the really big emulator window. You do have an option, though, of having the emulator keep the density accurate at the expense of pixel count.

The easiest way to do this is to use the new Android AVD Manager, introduced in Android 1.6. The Android 2.0 edition of this tool has a “Launch Options” dialog that pops up when you go to start an emulator instance via the Start… button:

By default, the “Scale display to real size” checkbox is unchecked, and Android will open the emulator window normally. You can, however, check that checkbox and then provide two bits of scaling information:

1. The screen size of the device you wish to emulate, in inches (e.g., 3.7 inches for the Motorola DROID)
2. The dpi of your monitor – click the ? button to bring up a calculator to help you determine what your dpi value is

This will give you an emulator window that more accurately depicts what your user interface will look like on a physical device, at least in terms of sizes. However, since the emulator is using far fewer pixels than will a device, fonts may be difficult to read, images may be blocky, etc.

Accessing Actual Devices

Of course, the best possible way to see what your application looks like on different devices is to actually test it on different devices. You do not necessarily have to get every Android device ever made, but you may want to have access to ones with distinctive hardware that impacts your application…and screen size impacts just about everyone.

You can virtually test devices using services like DeviceAnywhere. This is an improvement over the emulator, but it is not free and certainly cannot test everything (e.g., changes in location).

You can purchase devices, perhaps through back channels like eBay. Unlocked GSM phones can readily share a SIM when you need to test telephony operations or go SIM-less otherwise.

If you live in or near a city, it may be you can set up some form of user group and use that group for testing applications on your collective set of hardware.

You can also always take the user-testing route, releasing your application as a free beta or something, then letting user feedback guide adjustments. You may wish to distribute this outside of the Android Market, lest beta test feedback harm your application’s market rating.

In tomorrow’s final post in the series, we will look at ways you might take proactive advantage of larger screens, rather than merely reacting by drawing the same UI bigger.

This is the first part of a several part series on handling multiple screen sizes in your Android projects. This material is adapted from a chapter in The Busy Coder’s Guide to Android Development, Version 3.0.

When designing your app, there will be times when you want to have different looks or behaviors based upon screen size or density. Android has ways for you to switch out resources or code blocks based on the environment in which your application runs. When properly used in combination with the techniques described in the preceding post, achieving screen size- and density-independence is eminently possible, at least for devices running Android 1.6 and newer.

<supports-screens>

The first step to proactively supporting screen sizes is to add the <supports-screens> element to your AndroidManifest.xml file. This specifies which screen sizes you explicitly support and which you do not. Those that you do not will be handled by the automatic “compatibility mode”.

Here is a manifest containing a <supports-screens> element:

Three of these attributes are almost self-explanatory: android:smallScreens, android:normalScreens, and android:largeScreens each take a boolean value indicating if your application explicitly supports those screens (true) or requires “compatibility mode” assistance (false).

The android:anyDensity attribute indicates whether you are taking density into account in your calculations (true) or not (false). If false, Android will pretend as though all of your dimensions (e.g., 4px) are for a normal-density (160dpi) screen. If your application is running on a screen with lower or higher density, Android will scale your dimensions accordingly. If you indicate that android:anyDensity = “true”, you are telling Android not to do that, putting the onus on you to use density-independent units, such as dip, mm, or in.

Resources and Resource Sets

The primary way to “toggle” different things based on screen size or density is to create resource sets. By creating resource sets that are specific to different device characteristics, you teach Android how to render each, with Android switching among those sets automatically.

Default Scaling

By default, Android will scale all drawable resources. Those that are intrinsically scalable, as described in the previous section, will scale nicely. Ordinary bitmaps will be scaled just using a normal scaling algorithm, which may or may not give you great results. It also may slow things down a bit. If you wish to avoid this, you will need to set up separate resource sets containing your non-scalable bitmaps.

Density-Based Sets

If you wish to have different layouts, dimensions, or the like based upon different screen densities, you can use the -ldpi, -mdpi, and -hdpi resource set labels. For example, res/values-hdpi/dimens.xml would contain dimensions used in high-density devices.

Size-Based Sets

Similarly, if you wish to have different resource sets based upon screen size, Android offers -small, -normal, and -large resource set labels. Creating res/layout-large-land/ would indicate layouts to use on large screens (e.g., WVGA) in landscape orientation.

Version-Based Sets

There may be times when earlier versions of Android get confused by newer resource set labels. To help with that, you can include a version label to your resource set, of the form -vN, where N is an API level. Hence, res/drawable-large-v4/ indicates these drawables should be used on large screens at API level 4 (Android 1.6) and newer.

Apparently, Android has had the ability to filter on version from early on, and so this technique will work going back to Android 1.5 (and, perhaps, earlier).

So, if you find that Android 1.5 emulators or devices are grabbing the wrong resource sets, consider adding -v4 to their resource set names to filter them out.

Finding Your Size

If you need to take different actions in your Java code based on screen size or density, you have a few options.

If there is something distinctive in your resource sets, you can “sniff” on that and branch accordingly in your code. For example, as will be seen in the code sample at the end of this chapter, you can have extra widgets in some layouts (e.g., res/layout-large/main.xml) — simply seeing if an extra widget exists will tell you if you are running a “large” screen or not.

You can also find out your screen size class via a Configuration object, typically obtained by an Activity via getResources().getConfiguration(). A Configuration object has a public field named screenLayout that is a bitmask indicating the type of screen the application is running on. You can test to see if your screen is small, normal, or large, or if it is “long” or not (where “long” indicates a 16:9 or similar aspect ratio, compared to 4:3). For example, here we test to see if we are running on a large screen:

There does not appear to be an easy way to find out your screen density in a similar fashion. If you absolutely need to know that, a “hack” would be to create res/values-ldpi/, res/values-mdpi/, and res/values-hdpi/ directories in your project, and add a strings.xml file to each. Put a string resource in strings.xml that is has a common name across all three resource sets and has a distinctive value (e.g., name it density, with values of ldpi, mdpi, and hdpi, respectively). Then, test the value of the string resource at runtime. This is inelegant but should work.

The next post in the series will look at ways to help you better use the emulator, and real devices, for testing these different screen sizes and densities.

This is the first part of a several part series on handling multiple screen sizes in your Android projects. This material is adapted from a chapter in The Busy Coder’s Guide to Android Development, Version 3.0.

The simplest approach to handling multiple screen sizes in Android is to design your user interfaces such that they automatically scale for the screen size, without any size-specific code or resources. In other words, “it just works”.

This implies, though, that everything you use in your user interface can be gracefully scaled by Android and that everything will fit, even on a QVGA screen.

Here are some tips for achieving this “all in one” solution:

Don’t Think About Positions, Think About Rules

Some developers, perhaps those coming from the “drag-and-drop” school of UI development, think first and foremost about the positions of widgets. They think that they want certain widgets to be certain fixed sizes at certain fixed locations. They get frustrated with Android layout manager (containers) and may gravitate to the deprecated AbsoluteLayout as a way to design UIs they way they used to.

That rarely works well even on desktops, as can be seen by applications that do not handle window resizing very well. Similarly, it will not work on mobile devices, particularly Android, with its range of screen sizes and resolutions.

Instead of thinking about positions, think about rules. You need to teach Android the “business rules” about where widgets should be sized and placed, with Android then interpreting those rules based upon what the device’s screen actually supports in terms of resolution.

The simplest rules are the fill_parent and wrap_content values for android:layout_width and android:layout_height. Those do not specify specific sizes, but rather adapt to the space available.

The richest environment for easily specifying rules is to use RelativeLayout. While complicated on the surface, RelativeLayout does an excellent job of letting you control your layout while still adapting it to other screen sizes. For example, you can:

• Explicitly anchor widgets to the bottom or right side of the screen, rather than hoping they will wind up there courtesy of some other layout
• Control the distances between widgets that are “connected” (e.g., a label for a field should be to the left of the field) without having to rely on padding or margins

The greatest control for specifying rules is to create your own layout class. For example, suppose you are creating a series of applications that implement card games. You may want to have a layout class that knows about playing cards: how they overlap, which are face up versus face down, how big to be to handle varying number of cards, etc. While you could achieve the desired look with, say, a RelativeLayout, you may be better served implementing a PlayingCardLayout or a HandOfCardsLayout or something that is more explicitly tailored for your application. Unfortunately, creating custom layout classes is under-documented at this point in time.

Consider Physical Dimensions

Android offers a wide range of available units of measure for dimensions. The most popular has been the pixel (px), because it is easy to “wrap your head around” the concept. After all, all Android devices will have screens with such-and-so number of pixels in each direction.

However, pixels start to become troublesome as screen density changes. As the number of pixels in a given screen size increases, the pixels effectively shrink. A 32px icon on a traditional Android device might be finger-friendly, but on a high-density device (say, WVGA in a mobile phone form factor), 32px may be a bit small for use with a finger.

If you have something intrinsically scalable (e.g., a Button) where you had been specifying a size in pixels, you might consider switching to using millimeters (mm) or inches (in) as the unit of measure. 10mm is 10mm regardless of the screen resolution or the screen size. This way, you can ensure that your widget is sized to be finger-friendly, regardless of the number of pixels that might take.

Avoid “Real” Pixels

In some circumstance using millimeters for dimensions will not make sense. Then, you may wish to consider using other units of measure while still avoiding “real” pixels.

Android offers dimensions measured in density-independent pixels (dip). These map 1:1 to pixels for a 160dpi screen (e.g., a classic HVGA Android device) and scale from there. For example, on a 240dpi device (e.g., a phone-sized WVGA device), the ratio is 2:3, so 50dip = at 160dpi = 75px at 240dpi. The advantage to the user of going with dip is that the actual size of the dimension stays the same, so visibly there is no difference between 50dip at 160dpi and 50dip at 240dpi.

Android also offers dimensions measured in scaled pixels (sp). Scaled pixels, in theory, are scaled based on the user’s choice of font size (FONT_SCALE value in System.Settings).

Choose Scalable Drawables

Classic bitmaps — PNG, JPG, GIF — are not intrinsically scalable. If you are not running in “compatibility mode”, Android will not even try to scale them for you based on screen resolution and size. Whatever size of bitmap you supply is the size it will be, even if that makes the image too large or too small on some screens.

One way to address this is to try to avoid static bitmaps, using nine-patch bitmaps and XML-defined drawables (e.g., GradientDrawable) as alternatives. A nine-patch bitmap is a PNG file specially encoded to have rules indicating how that image can be stretched to take up more space. XML-defined drawables use a quasi-SVG XML language to define shapes, their strokes and fills, and so on.

The next post in the series will look at techniques for when the above techniques fail and you need to provide specific support for specific screen sizes and densities.

This is the first part of a several part series on handling multiple screen sizes in your Android projects. This material is adapted from a chapter in The Busy Coder’s Guide to Android Development, Version 3.0.

For the first year or so since Android 1.0 was released, all production Android devices had the same screen resolution (HVGA, 320×480) and size (around 3.5″ / 9cm). Starting in the fall of 2009, though, devices have been arriving with widely disparate screen sizes and resolutions, from tiny QVGA (240×320) screens to much larger WVGA (480×800) screens.

Of course, users will be expecting your application to be functional on all of these, and perhaps take advantage of larger screen sizes to add greater value. To that end, Android 1.6 added new capabilities to help better support these differing screen sizes and resolutions.

The Android documentation has extensive coverage of the mechanics of handling multiple screen sizes. These blog posts are designed to complement that coverage.

Let’s suppose, though, that you start off by totally ignoring the issue of screen sizes and resolutions. What happens?

If your application is compiled for Android 1.5 or lower, Android will assume your application was designed to look good on the classic screen size and resolution. Android will then automatically do the following:

• If your application is installed on a device with a larger screen, Android will run your application in “compatibility mode”, scaling everything based on the actual screen size. So, suppose you have a 24px square PNG file, and Android install and runs your application on a device with the standard physical size but a WVGA resolution (a so-called “high-density” screen). Android might scale your PNG file to be 36px when it displays it, so it will take up the same visible space on the screen. On the plus side, Android handles this automatically; on the minus side, bitmap scaling algorithms tend to make the images a bit fuzzy.
• Android will block your application from running on a device with a smaller screen. Hence, QVGA devices, like the HTC Tattoo, will be unable to get your application, even if it is available on the Android Market.

If your application is compiled for Android 1.6 or higher, Android assumes that you are properly handling all screen sizes, and therefore will not run your application in “compatibility mode”.

The next post in the series will begin providing tips for how to design layouts that will work independent of resolution.

There’s this little bookstore, up around Seattle, called Amazon.com. You might have heard of them. They sell an ebook reader called the Kindle, now in its second generation. Now, the Kindle is turning into a mobile platform, with the introduction of “active content”, complete with an SDK and “app store”. Here’s my take on what they are offering. Note that this is based solely on materials presently available at public URLs, as I have not yet elected to agree to the beta terms and conditions.

From a programming standpoint, the Kindle embeds JavaME, specifically the Personal Basis Profile. Hence, instead of Android widgets, you’re using AWT for containers and drawing and some Kindle-specific widgets, like KButton and KTextField. However, it is still Java from a programming language standpoint, a plus for Android developers looking to dip their toes in the Kindly waters.

The equivalent of an Android activity is the “kindlet”. It is unclear if the Kindle will support any sort of multiprocessing (e.g., playing music while the user reads), but preliminary indications suggest it will not. Notably, you cannot keep your “kindlet” running while the device is idle (screensaver mode) or when the Kindle is mounted as a USB device.

Also, bear in mind that the Kindle is not a touch-screen device. Instead, you use what amounts to a D-pad to navigate. It also has a fairly slow screen refresh rate, courtesy of e-ink technology. The combination of these means fast-twitch games (e.g., first-person shooters) seem unlikely apps for Kindle. Displays are also monochrome, with only a few shades of gray. However, the Kindle does sport a QWERTY keyboard.

The SDK comes with simulators for both sizes of Kindle, supported on Linux, OS X, and Windows. You can also associate up to three real Kindles as test devices — apparently, these are then also eligible for you to use for testing applications.

---

Once we get out of the realm of programming and into the realm of the “app store”, though, things start to radically depart from the Android model.

It would appear the only way to deliver “active content” to the Kindle is through Amazon.com. This is not surprising, considering it follows the iPhone App Store model and fits with Amazon’s strong preference for you to get your Kindle books through Amazon.com. Also, like the iPhone App Store, Amazon must approve all applications (“We recommend that you test your application on a Kindle before submitting it to us for approval.”). Their current terms notably prevent one from creating a VOIP app, an alternative reader (e.g., for EPUB), or display advertising.

Applications will be protected by Amazon’s DRM system. Since this was broken some time ago for ebooks, it will be interesting to see how long this lasts, and whether people are able to “root” or “jailbreak” their Kindles for use with apps distributed outside Amazon with removed DRM.

Their “active content” pricing rules are…interesting. Developers get a 70/30 split (less a 15-cent delivery fee), much like the Android Market and iPhone App Store. However, your choice of pricing model depends on how much bandwidth you consume. Kindle users get free 3G service (Whispernet), and Amazon clearly does not want to bankroll ridiculous bandwidth charges. Hence, you can only distribute an app for free if it is smaller than 1MB to begin with and uses less than 100KB/user/month. If you want to offer a one-time charge (a la Android Market and iPhone App Store), you can, and you can then have a larger app (10MB for Whispernet, 100MB for USB-based installation), but you still are subject to the 100KB/user/month bandwidth budget. If you want more bandwidth, it appears you have to charge a monthly fee, and it is unclear what bandwidth limits you are subject to under that model.

---

Perhaps the biggest thing that the Kindle has going for it is the possibility of a “land rush”. Many Kindles have sold, though Amazon has been mum on actual figures. Some estimates peg it at around 1.5 million as of the end of 2009, though many of those were first-generation Kindles that will not support active content. The iPhone app land rush was caused by many more iPhones, and it is unclear how popular “active content” will be among Kindle users. However, the Kindle is popular enough that there may be first-mover opportunities to make some money, if you have an app that is small, has modest bandwidth requirements, fits the display and user input constraints of the device, and might prove popular among Kindle users.

Android already dwarfs Kindle’s market size, and Android would appear to have a far better growth curve. Hence, Android is a better bet overall, if you are not in position to support too many platforms. But, Kindle will still have its share of winners, and since it is Java-based, Android developers may want to check it out.

The One From the Stack series will highlight some interesting questions and answers from StackOverflow’s #android tag, a fine place to get your Android application development questions answered.

Today’s one from the Stack is from a developer trying to figure out how to attain a look and feel similar to one that is already in Android. In this case, the poster is looking for the gray box behind the Done and Revert buttons in the Edit Contact activity in the built-in “Dialtacts” application.

If you poke through the source code, you would eventually stumble upon this layout file, showing that the button bar has a style=”@android:style/ButtonBar”. Tugging on that thread via Google Code Search will give you this styles.xml snippet, indicating that the background for that style is @android:drawable/bottom_bar.

At this point, you can turn to your local SDK. All resources are stored in $SDK/platforms/$PLATFORM/data/res, where $SDK is wherever you installed your SDK and $PLATFORM is the specific Android version you are interested in (e.g., android-2.1). If you go in there, you will see that bottom_bar refers to a pair of PNG files, one in data/res/drawable-hdpi and one in data/res/drawable-mdpi.

You might be tempted to just plop the same style or background image reference in your own code. While simple, this leads to somewhat fragile code, as you are now dependent upon things that are not truly part of the SDK. Part of the reason for making all these resources available to you in your SDK installation is so you can copy them into your project, so you are now independent of any changes Android makes to its names or looks of these images.

Note that the answer I provided on the question itself is a bit off. I thought that hierarchyviewer would be another possibility, rather than poking through the source code. Unfortunately, I didn’t think that all of the way through — hierarchyviewer does not report background resource values.

One frequent complaint from some corners of the Android developer community is having to deal with multiple screen sizes. Cries of “Fragmentation!” rebound through discussion groups, blog comments, and the like.

It is as if these developers have never seen this before. That’s odd, since they have relied upon the same concepts for applications they use daily for a couple of decades now.

For example, there’s a very good likelihood that you are viewing this page right now in a Web browser on a desktop or notebook computer. If you are, the odds are very high that the computer in question runs a so-called “windowed” operating system, such as Windows, OS X, or most installations of Linux.

(my apologies in advance to those of you viewing this page via lynx from a shell prompt in Linux)

So, as a test, grab the lower-right corner of  your browser window and drag it to a new position. Assuming your window is not maximized, your window should resize to new dimensions. Perhaps it was 749×403 before and now it is 840×590, or something.

This feature — resizable windows — has been around for quite some time. Application developers for the desktop and the Web have had to deal with the fact that their windows will run at different sizes, based on user preferences, monitor resolutions, and the like. In fact, the number of combinations of possible resolutions is huge.

Some developers simply ignore the problem, by either fixing the window size in code or just not really doing anything with the available space. Generally, these apps seem to have fared worse in the marketplace than have apps that do a nice job of resizing to look decent on all resolutions. The best are the ones that take additional space and become more effective: offering a bigger editing area, showing more toolbar icons, and such.

So, if developers have been successfully handling this on the desktop for a couple of decades and the Web for years, why are there complaints about handling this on Android?

After all, Android greatly simplifies matters. There are only a half-dozen or so official screen sizes, and the size of a given device is unlikely to change while the app is running. Desktop and Web developers have it much worse, with a seemingly infinite number of possible resolutions that can change at any moment.

Android developers can learn from how others have handled resizable windows in other environments. For developers that have done other GUI work before — whether it is .NET or AJAX or whatever — there should be lessons that can be re-learned and transferred over from those past experiences.

Without a doubt, mobile introduces different challenges. For example, changes in screen density is not something desktop or Web developers have had to worry about much, but is a bigger issue on Android devices. But even here, desktop developers have had to have multiple icon sets to handle 15″ 800×600 displays and 19″ 1280×1024 displays, so their toolbar buttons and the like do not wind up being too small on newer screens.

Android is not fragmented by multiple screen sizes any more than Windows has fragmented because of resizable windows or OS X has fragmented because Apple came out with many different size screens on their iMac line. It is something developers have had to address in their applications since the dawn of the GUI. Savvy developers will learn from the past and apply it using Android’s tools of the day (e.g., RelativeLayout). Other developers…well, in the words of Edmund Burke, “Those who don’t know history are destined to repeat it.”