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)?

Screenshot time

I've got the app to a certain point. The basics all work: it now handles a database of saved locations. I thought this would be a good time to blog with some very early screenshots. I should point out that the gui is only at "functional" level: it needs to be made pretty at some point.

Lack of provision

or
What To Do When getProviders Returns An Empty List

I rearranged some stuff recently, and afterwards, the app broke. After some digging, I discovered that it was because getProviders, which is supposed to give me a list of the types of location providers present on the device (gps, network, and so on), was returning an empty list. I ran to Google, which has very much been my friend throughout this, and discovered pretty much everyone saying it was because the permissions were not set.
But that can't be the case for me! It worked a couple of days ago!
So I faffed, looking into what other things it could be, but it pretty much all came back to that. So I checked my AndroidManifest.xml, and sure enough, there were the lines:

<uses-permission android:name="android.permission.INTERNET">
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION">
</uses-permission></uses-permission>

So it can't be that. So I faffed a bit more. Eventually, I looked back at the commits since it worked. Oooh. There was one on the AndroidManifest.xml. That's suspicious. "Whitespace cleanup" you say? Well, nearly. Actually, I'd moved the permissions from outside to inside the <application>, where they're useless. So I moved them back, and all is well.
I'm blogging about it mostly because I swore I would, having dug so deep into the internet, and not found the solution to my particular problem, I wanted to post it for others to benefit from. So if you're reading this and you think the obvious problem doesn't apply to you, it probably does.
One beneficial side-effect was my discovery and first usage of Log.wtf, which, naturally, stands for "What a Terrible Failure".

Next stop, DB/UI

Just a blog post to keep me thinking about things.
So I've got the basic functionality working, and I've actually used it "in anger" (i.e. I've got it to alert me when I'm approaching my destination). Naturally, once I've set it, I remember to get off the train anyway, but that's not the point. Interestingly, and surprisingly for me, I find getting it to find the location from the network the best. It uses very little battery (compared to GPS), and is reliable enough to detected location to within 1.5km or so (which is usually all that the app needs).
But now I've got to the stage where there is one thing missing: usability. This separates off into three things.

1. It needs a database of previously saved locations, so you don't have to find the location every time (which can take 10-15 minutes, if the data connection is bad).
2. It needs a UI which works the way people expect it to, rather than the way I threw things together to begin with.
3. The alarm needs to be more configurable. At the moment it just sets off the default alert whenever the location changes to something within the specified radius.

I'm starting at the top and working down. Thanks to Another Android Blog, I've got a database installed in my app and working, but at the moment not actually storing any useful information. I think the next point of call will be the UI: I can't start storing / using multiple database entries without a complete change to the UI, so that's what's coming next. When I get round to it.

Incidentally, I don't know if this is the way these things are generally done, but I find that actually using my app on a semi-regular basis for what it's intended has kept me looking for the most important things to improve about it. I don't think the app would ever come about if it wasn't something I actually used.