Sunday, 13 March 2011

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

Tuesday, 1 March 2011

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.

Wednesday, 23 February 2011

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!

Thursday, 17 February 2011

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.

Saturday, 22 January 2011

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

Saturday, 18 December 2010

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.


Tuesday, 14 December 2010

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".