Released June 4th, Killboard Buddy is my first published Android application. It’s far from being perfect, but it has no doubt been a good learning experience when it comes to developing for Android and allowing others to use something I’ve made from scratch.
This accomplishment feels good, but at the same time it revealed several issues I either glossed over or didn’t even think of. This post will attempt to summarize some of these things.
Total User Installs: 188 (total number of installs of the app)
Active User Installs: 105 (number of devices that currently have the app installed)
I released an initial same-day update to fix some UI strings to make things a little more clear. The Killboard Feed screen was still using some strings from the API List, making it unclear of what screen the user was actually in.
The second update fixed two reported crashes, animated refresh icons during updates, and included several other changes to help improve user experience.
Low and behold, you release your app on Google Play, ask others to check it out, and begin to receive reports that no developer wants to hear:
I can’t start up your app without having it crash on me…
My heart started racing the moment I heard this. I had gone through and tested my app thoroughly. Tried it against various Android versions and was baffled when the first person posted about it.
I checked the Developer Console in Google Play but there was no crash. The user had a Galaxy S i9000 running Android 2.3. I asked them to report it, but the Developer Console still showed no reported crashes. Others started to chime in on the crash too, and it was apparent there was something wrong…
While I was working on my first update, I actually stumbled on the crash by complete accident. I was checking something out in a 2.1 emulator and noticed the app crashed when checking for new killmails (within a service).
After a little digging I came across the culprit. The TimeUnit class only recently added declarations for MINUTES, HOURS, etc which doesn’t exist in all versions of Android. I had run across this previously, but in my fury of adding bits and features in the leadup to a release, I had added it again without thinking.
By converting the values to seconds and using TimeUnit.SECONDS instead, I stopped the most common crash in my app. I later stumbled on the second crash (for which I had *one* crash report for) involving the tabs on the killboard screen after performing a search.
To help obtain information about crashes more quickly in the future, I implemented Application Crash Report for Android (ACRA) which sends crash reports to BugSense. Since the latest update, I’ve yet to receive a crash report (I double checked crashes were working just to ease my fears that I had misconfigured something).
Poor New User Experience:
The second problem in the feedback thread and communication channels was a lack of understanding on just how to get started with the app.
Where do I go?
How do I add my API key?
I added a killboard feed but the Killboard still shows no results.
Somewhere between a 1-star review, and a conversation with a friend, I came to the realization of just how crappy setting up the app can be. I had previously acknowledged the initial user experienced sucked. But this time I realized it’s at best a programmer mockup.
The entry fields assume the user has knowledge of what needs to be supplied. This is fine in closed development or at best closed testing, where things are constantly changing and you’re busy stress testing other areas of the app.
But it’s a bit too green when it comes to a public release. It frustrates users, they uninstall and move on. I’ve essentially upped the difficulty of users actually finding my app useful, by setting such a high barrier so early on when using the app.
To help ease user pain in the short term. I went over each UI screen in my app and checked the strings for accuracy and clarity and made changes where necessary.
I moved the most time consuming database operation into it’s own thread. The act of inserting killmails into the internal database is slow at best. Ideally all database calls should take place off of the UI thread but this makes for a good short term fix. Threads open a whole new can of worms, so I’d like to take my time to carefully implement threading throughout my app in the future.
By moving the updates off of the UI thread I could now animate the refresh icon. Animation wasn’t nearly as complex as I’d imagined, and I quickly feature creeped on my original plan by checking to see if an update is underway and animating the refresh cursor each time a new screen is loaded. It’s a nice touch, and helps prevent multiple updates from taking place concurrently.
In a future update, I’m going to improve the way users add kill feed information to the app. I feel as though the API method is relatively easy to use, but it appears as though the Eve API is not very useful when it comes to tracking kills for a character or corporation. As a result Killfeeds will be getting much more love.
That covers the major issues since release. As mentioned previously I have since started working on a new app, taking this knowledge into consideration and taking more time to focus on developing a more pleasant UI for the user.
Have I stopped working on Killboard Buddy? No, but my attempts to make Android development my full time job means I need to explore monitization and find a way to generate income. I see myself working on an update in my free time or when I need to take a break from the new app.
Anyways, I hope this was helpful to someone out there. At the very least, it’s been helpful for me to go over this and think things through a bit more.