Experiences with the Android Market

I finally released WakeMe@ on the Android Market on 2nd August. I'm pretty happy with the state of it at the moment: everything works (as far as I can see). At least it does now, after two rapid updates. There are plenty more features that I want to add, but that's pretty much always the case with any software development. So now I get to discuss what it's like actually having an item on the market.
It costs $25 to be a publisher on the market: the reasoning given is to stop the market filling up with crapware. The problem that the market has with crap, though, is of single people releasing hundreds of tiny "soundboard" or similar apps from which they actually make substantial amounts of money, so having to pay $25 won't stop them. I guess, having said that, the fee is in place: maybe the market would be in a considerably worse state if it wasn't.
My ponderings about monetization really come to the fore now. Atm the app is free. Current plan is to do it the same as Gina Trapani does with her Todo.txt app: charge a small amount on the market, but have it downloadable for free on github. But only when / if it takes off at all: with less than 50 downloads atm, it's not worth it. I believe that anyone who downloads it now, free, will be able to update free forever.

The Google Developer Console is quite good. It doesn't update as often as some people would like, maybe twice daily, but that's fine for me. Indeed, it stops me checking it way more often than I should. It gives quite a lot of statistical analysis, and makes uploading and managing the apps reasonably straightforward.
There is something that is a bit of a pain, but it requires a little background. Every app on the Android Market must be signed by a key unique to the author, to avoid forgeries. This is fine, but the Google Maps API also requires a key that is generated from the same key as the app's key. The shuffling of keys at release time is a little tiresome.
But all in all, the process was fairly painless. Interestingly, only a few days after I released the app on the market, someone has forked my source repository on github: I'm presuming this isn't a coincidence, and that they got the url from the Market page. But that's what social coding and open-source is all about! If someone else can get the information they need from my source, then I'm glad I decided to go the open-source route.

Published

Done

https://market.android.com/details?id=uk.co.spookypeanut.wake_me_at

I'll write a proper blog post later. Now I just want to relax.

So nearly there...

I just need to write a description. I hate things like this.

The Pain of Prettification

"Two months just to make it a bit prettier?" I hear you shout. Yes, and then some. I've made huge leaps, and most of the app is now themed, but I still haven't decided on the colour scheme. That said, I've not had as much time to play with it as I'd like either. As I'm using it more and more, I'm also realizing that there are some usability issues that need addressing, but I think I'd sooner go for an alpha release, and iterate as quickly as I can.
What I'm proudest of atm is the icon. I made it surprisingly quickly, and I still like it. I've shown here the progress from initial idea to final image: the final colour is not set in stone, but I do like it. I flirted originally with doing it in Google Docs, but when I actually tried the drawing thing there I realized it was nowhere near up to the task. I switched to Inkscape, and I would heartily recommend it. If anyone is interested I'm how any bits were done, just drop me a line. Nothing mind-blowing really though.

My current plan is to get WakeMe@ on the market by the end of July: that may not happen, but it should be close.

Style counts

The list of issues that need addressing before I put WakeMe@ on the market is now short. Just one. I need to make it pretty. I've already tidied up the location editing screen (left), but it's very plain: I would like a pretty colour scheme. The screen to track the location (right) has all the features I want (I think), but it's very much thrown together with no real thought.
The problem is that I'm no designer... I'll just have to see how it comes out, and iterate repeatedly until it looks good. Fingers crossed.

Backing up the internet

Eclim is fabulous.

This post is purely to back up some information, because the original site seems to have disappeared. I found it from a Google cache, but that won't last forever. Here it is (apologies for the shoddy formatting):

Besides .vimrc setting, the complete flow to develop Android app using vim + command line is as follows:

1. Start eclim by starting its server first. 
   
   eclimd&
2. Navigate to project folder. (ex. ~/workspace), and start vim. Use :ProjectCreate to create new project
3. Alternatively, navigate to existing project (ex. ~/workspace/your_android_app), use
   
   :ProjectTree <project name>
   
   to open existing one.
   
   But with the above .vimrc, vim/eclim should be able to automatically open the project tree view for you by just entering vim.  There is no need to follow this step, indeed.
4. For editing, :FirstExplorerWindow to the tree view or Ctrl+w Ctrl+w, use :Tlist to open taglist
   
   Open new tab by <Enter> or open split window by <S>, when navigating in the project file tree view. 
5. When :w, eclim will do :Validate for you, pointing out live syntax check and display suggestions like what you’ve got in Eclipse. 
   
   For auto-complete, Ctrl+x Ctrl+u as you’re used to. 
6. To build project,
   
   :Ant
   
   Notes: if there is no build.xml, excute
   
   :!android update project -p .
7. To start an AVD, use 
   
   android list avd
   
   emulator -avd <avd_name>
   
   
8. To upload project to default emulator or device, 
   
   :Ant install
9. To see LogCat debugging log, open another terminal, check available devices by 
   
   adb devices
   
   once you got what devices to look at, 
   
   adb -s <device_name> logcat
10. To turn off eclimd, in vim, type :ShutdownEclim, or in command line, eclim -command shutdown

Fun with vim, fun with alpha, no fun with apks

I've been distracting myself for the last couple of days by installing eclim: it really is pretty amazing. I have yet to use it in anger, but I'm a vim user at heart: the last few months using Eclipse have felt like I was cheating (in a particularly inefficient way: a touchpad is even less efficient than a mouse).

The alpha testing so far has taught me a lot. There was one major bug that I had never seen, and a strongly desired enhancement (that I had planned, but much longer term), both of which are now sorted. It's also given me a good idea of how others will actually use the app: not necessarily the same way that I do.

But the biggest thing it has taught me is that it's not easy enough to install an apk file. When I tried to help my friend install it on her HTC Desire, it took much longer than it should, and we ended up having to install a file manager app from the market. So my next stage will be beta, and it will be on the market: it's so much easier to just send people a url that they can install from.

Alpha

Since I now a small legion of people (well, about 5) that I've coerced into helping me test my app, I figure I may as well make the apk public. So I've added it to the github downloads page. Feel free to check it out, so long as you leave comments telling me how well it worked!

Revisiting monetization of open source on a pre-alpha high

I'm nearly ready to send my app out friends to test it. I should start compiling a list of people that have different phones...

Once this stage is done, and people are out there testing the functionality, then I need to prettify it. The previous prettification was pretty basic, so I need to go all out, re-skin buttons, etc.

After my discussion of how to money from open source a while back, another option came to my attention. In short, charge for the app on the Android market, but provide the app as an apk for free on the web. The way Gina describes it, the money that you pay for the market version buys you two things:

1. Automatic updates via the market
2. The warm fuzzy feeling that you're helping the project

This option sounds very appealing to me. It's making everything as hard as possible for pirates: what are they gonna do, give out the apk? I do that already! Apart from people who want to help the project, who will always pay, it relies on people's laziness: it's much easier if they spend a pound or two on the market, then the app automatically gets better over time.

My current plan is to start out with it for free, while I'm getting my friends to test it. Also so that any early adopters (who are bound to have a rough time, there will be bugs!) don't have to pay for it. When do I switch to charging? That will depend on how much take-up there is, I guess.

References in Source Code

I've made quite a bit of progress: I've made my app more and more usable. Hopefully in a month or two I'll be ready for alpha testing.

But this post is about something completely different, about something that I haven't talked about yet here (or anywhere actually). Maybe it's the academic in me, maybe the obsessive-compulsive, but I'm planning to publish alongside my app references to all the open-source code / other resources that helped me to code it. In fact, I've already started, but it's a bit slap-dash atm. I had been planning some sort of awk or similar based system so that I can put a particular keyword in my code, then a script goes through and pulls them all out later. But now I've started doing that, it's making my code look a little unsightly (there are some long urls out there).

What do people think? Is it necessary to reference at the point where the code was used? Or should I just keep my simple list (but maybe add a description for each of what I got from there)?