Some common pitfalls you might want to avoid when you're managing an Android app. Currently, there are more than 850,000 apps on Google Play and developers add a new app every 2 minutes. Some of them will skyrocket their downloads and be the next superstar, but most of them will fail. I will not tell you how to make the next killer app (even if I knew) but you will increase your chance by avoiding some common pitfalls.
Apps are like Ice-creamApps are more like ice-cream and less like a sledgehammer. While you can try to lick both, an ice-cream is something you buy on the go while you purchase a sledgehammer for a specific purpose. Users will most probably not install your app because they already know what to do with it, take it home and read the manual first. They will find and install it on the go, and I mean this literally. Imagine the user is walking down the road while opening your app for the first time. Don't run the user through setup screens or a registration process, you can do all this later. Don't even present a welcome message or a disclaimer, ice-cream doesn't do either.Talk to ThemBe responsive when users speak to you. You published a support email address with your app on Google Play. I try to respond to support emails immediately and frequently users are impressed. This is not a job you should shift to your nonproductive time. If you feel no motivation for good support, assume it adds half a star to your ranking. Imagine all the time you'll have to spend otherwise to increase your ranking like this.
Email support is just the beginning, though. Create a wiki, a discussion group or a Facebook page. Anything that you believe can help your users will also increase the visibility of your app.
Everything you learned about quality in software engineering has never been more important. Mobile users can quickly tell the good apps from the bad ones. And they are relentless. Once you dropped below the magic 3.5 star ranking, most users will entirely ignore your app. It's hard to gain ground when you are there, so do your best to prevent being in the underworld right from the start.
On the other hand, it's not too hard to make a high quality app. The great news about mobile apps is that a single-handed developer has the chance to compete with even the top-notch companies out there in some fields.
Android has some very useful testing tools and features. There is a test monkey that runs random user interface tests. Manual user interface testing tends to do the same tasks using the same parameters over and over again. The monkey fills this gap and does things that are entirely unexpected. Expect crashes and ANRs. The monkey is also good to check for memory leaks: You run the monkey for a while, then you dump an HPROF file of your app and check it with the Memory Analyzer. Here is a good video about how to find memory leaks with this tool.
In system settings on Android devices you'll find some very useful testing features. When you check "Don't keep activities", Android will destroy all your activities right when they go out of scope. This is something that usually only happens when a device is under heavy memory load. Be sure to test your device with both this option checked and unchecked.
You don't need a phalanx of test devices, but try to cover a certain range. If you're supporting both tablets and phones, have at least one of each. Also, have a least one device at both ends of the supported Android versions. Testing on the emulators is not enough, they have a different timing and a real device pays off quickly when you consider all the time you spend to run a test case through an emulator.
Check the error reports from users in your developer console. Always try to address all crash reports where "reports this week" is substantially greater than 1. These bugs slipped through your testing, think why.
Being an AndroidTry to make an Android app, not an app that runs on Android. Use intents, activities, fragments, services and content providers accordingly. If you don't, your app will look like an alien on the device and the user experience will be broken. If you don't think Android at the very beginning, you will have a lot of redesign work later (most probably a few days in front of your planned release date). For example, both threads and services can run in the background. A service adds overhead but it is the only way to make sure the job is guaranteed to run.
Make sure you understand activities and their concepts, like intents, the back stack and saved instance states. If you think an activity is like a window or dialog, think again. You risk design flaws that are hard to fix later.
Being mobile also means that you should try to avoid transient data as much as you can. On a desktop computer, you open a document, work on it, and then save it when you want to. This concept requires that the application you are using keeps running until you save. On Android, this is not the case: Imagine the device powers down because the battery is low. Android devices also have less memory and when the user is staring an app Android may decide to shut down your app to gather free space. Beware that your activities (and sometimes also your services) might shut down and you have no chance to ask the user if and where to save his work. To solve this dilemma, you can support draft documents or simply keep saving changes all the time.
I'm sure you find a lot more things that are important to your specific app and that I didn't cover here. These issues are on the top of my personal list, feel free to adapt it to your scenario.
|
Articles >
