Pushing Onward With App #2

Just a quick update to keep everyone in the loop on my plans.

I’ve been continuing to work on my second Android app and am hoping to release it sometime this week. The app is a scheduling app for students to help track classes/lectures and assignments on a daily basis.

The core features are in and now I’m adding some additional functionality. This will be my first attempt of doing a lite/full version of an app and I’ve also been looking into putting it on the Amazon app store in addition to Google Play.

Hopefully this works out, I’m looking forward to seeing the result.

Lessons Learned from Killboard Buddy

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.

General Statistics:

Updates: 3
Total User Installs: 188 (total number of installs of the app)
Active User Installs: 105 (number of devices that currently have the app installed)
Donations: $0

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.

New App

I’ve started prototyping a new app for Android today. This will hopefully give me a chance to learn a bit about monitizing apps and gaining some experience there.

I’d consider the complexity of the app to be much less difficult than the challenges I faced creating Killboard Buddy. There were are a lot of variables to account for and quite a bit of data had to be imported from outside of the app (API data, killboard feeds, etc).

Things are starting off rather well on the new one, so I’ll post an update when I have something a bit more visual to share. 

New version available

KillboardBuddy v0.2 is now available on Google Play. Click here to go to the download page.

General Features:
– Refresh icons are animated.
– API Keys and Killboard Feeds now have independent update times (set via Debug)
– Added Help/FAQ
– UI refreshes after updates
– Added crash reporting

– Fixed a crash which would occur inside of the update service on some devices
– Fixed a crash on the killboard screen when selecting a tab after searching for a character
– Removed unnecessary notifications.
– Fixed “Add Feed” text on the Killboard Feed management screen.

Post Release Analysis

Killboard Buddy has been out on the market for a couple of days and now I have a better idea of what to work on from here.

The biggest issue when hearing users initial feedback was a lack of direction on where to go. It’d be more helpful to guide users into creating their first account, which I think makes it easier to know where to go afterward.

A FAQ or some way to explain some limitations of the app (API limitations and also how the app is only able to collect so many kills per update cycle).

There were a few reported crashes but so far the developer console hasn’t revealed any to me. I’ll look into adding a third party solution for bug reporting/app crashes.

I did push out an update to fix some activity titles and change the icon colours. The icons weren’t as apparent on some devices as they were too dark, now they are more white than grey which should make this less of an issue.

A summary of things I’ll be looking at for my next update:

– Improved “First-Time” experience. Directing the user to setup a killboard feed or add an API key
– Adding API key from a text file stored on the SDCard. This is how some other Eve apps handle the addition of API keys
– An in-app FAQ to clear the error about some limitations of the app
– Look into moving API updates off of the main UI thread
– More responsive UI. Show the user that something is happening during an update.
– Tweak notifications. Pop up a notification only when updates are actually added to the database

On the bright side, the database side of things is holding up for the time being, so that should make it easier to push out the next update. I have 36 installs on 19 devices, so I’ll advertise my app a little more post-update.