Posts tagged Building Droids
“Sloof Lirpa” Source Code Released
Apr 3rd
On April Fool’s Day we released an app on the Android Market that claimed to be a World War 2 First Person Shooter which ended up actually being a humorous self-destruct button. While it was a dirty mean trick we have released the source code of our April Fool’s Day app after we got questions from aspiring developers asking if they could see the inner workings of such a simple app. It is not a tutorial but rather a chance for new developers to see some important features of Android in action. The source code is available in our Downloads section on the AndroidGuys Projects Website in the form of a zip file. While the app has now been taken off the Android Market now seeing as April Fool’s is now over, it is still available for download as in our Downloads section. The key features that developers can look out for in the well-commented code are as follows:
- Use of SoundFX using the Android SoundPool Class.
- Use of threads to make a timer.
- Simple Animation using XML animation files.
- Use of a device’s Vibrator
- and many other simple things such as intent, OnClickListener interfaces, and runnables.
As I am still a fairly new developer, some of the code you see may not be “best-practice”, but in the end I always come out with an app that works exactly as I had originally imagined. I hope the source code is helpful to many new and aspiring developers as my personal source of education has primarily been from examining other developers code.
Thanks and Happy Coding!
Might We Suggest…
Code Pollution: Background Control
Mar 29th
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.
Might We Suggest…
Kickstart Your Android App Funding
Mar 25th
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.
Might We Suggest…
Reasons for Root: Report
Mar 22nd
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.
Might We Suggest…
Google TV, and Your Android Apps
Mar 18th
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.
Might We Suggest…
Code Pollution: Background Becomes Foreground
Mar 16th
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.
Might We Suggest…
Yet More Android Business Models
Mar 4th
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.
Might We Suggest…
