G4 has just been released!
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.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.
Be 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.
Try 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.
I just started the Facebook Page for GPS Essentials. If you are a frequent user of GPS Essentials, come and join us! I'll keep on posting latest info there plus some extra stuff you will not find anywhere else.
Some people asked about the Sticky Broadcast permission that GPS Essentials requests when you install. I believe that the name of this permission has not been chosen wisely because it is a very technical one.
I'll try to explain it as less technical as I can: A broadcast is a message that some piece of an app sends to a different piece. Since GPS Essentials is a rather big app it lives in different processes and uses broadcasts to communicate. For example, when you choose a different unit in settings a broadcast will tell both the dashboard and the map to update its widgets.
Sticky broadcasts add the capability to remain there once it has been fired up by someone. For example, when you start tracking a sticky broadcast will fire up to tell everybody. Even if you open the map after you started tracking the map can still see the broadcast message to see if you are currently tracking.
Since a broadcast message can also be sent from one app to another, Android thinks it is of some security concern and better ask the user for permission.
With the lastest dev version (2.7.0) I moved some of the functionality into services and when this migration is complete, I can hopefully take the sticky broadcast permission down again.
I spent some time looking for a good example on how to wrap a CellTable so that it can be used in the Editor Framework. Since there was none, I wrote one by myself:
Edit: Fixed for GWT 2.5.1, attached original source.
I have recently came across this article that contains some interesting numbers about the different versions of Android that people currently use. There has been a long debate about the "device fragmentation" in the Android world and how it affects security.
From the perspective of somebody who maintains an app this means that a lot of time goes into maintaining compatibility that I would prefer to spend making new features. GPS Essentials is still compatible to Android 1.5 and at the time of this writing 14,336 users are running GPS Essentials on the very first public version of Android.
From the perspective of somebody using one of the Android 1.5 and 1.6 devices, the new apps that lack backward compatibility just don't appear on Android Market and more and more apps just don't update any more.
Not the best environment to build a solid relationship between a software company and its customers.
The first version of the Getting Started guilde is ready for download. I promised this for a while and here it is finally.
Ars Technica had a closer look onto the Maylong M-150. This is a specimen of a class of tablets currently flooding the market. I get many requests from users of GPS Essentials asking if and how GPS Essentials will perform on these devices. Well, read the test yourself .
The new release features a toolbar for map view so that you can access common functions much easier. Get it now from the download site.
1-10 of 28