My Android Sqlite3 helper batch file for DOS

Back in the day I used to use Windows as my main dev OS (now I like Kubuntu a lot more), and wrote this batch file to help me when I had to investigate a database on a device. I found it today when I was helping Seren out with one of her apps, and thought I would post it up as it may be useful to someone.

@echo off
echo. %1
echo. copy this string to open your db in sqlite3
echo. sqlite3 /data/data/<YOUR PACKAGE NAME HERE>/databases/<YOUR DB NAME>.db
echo. --
echo. within sqlite3 paste these three lines, they will:
echo. 1. turn column mode on so that your data is presented nicely
echo. 2. turn the headers on so you can tell which columns are which
echo. 3. tell you the tables within the database
echo. .mode column
echo. .headers on
echo. .tables
echo. --
echo. These next 4 lines are just reminders of how to do basic database manipulation in SQL
echo. select * from event where parent_id="4610";
echo. delete from event where event_id="5462";
echo. insert into event (id, something) values (4, sdfv);
echo. update event set id=43, something=[23]
if "%1" == "-e" goto :startemulator
if "%1" == "-d" goto :startdevice
if "%1" == "" goto :startdevice
goto :end

echo. starting emulator shell
adb -e shell
goto :end

echo. starting device shell
adb -d shell
goto :end


Read More

3rd Party Andriod Libraries

A few weeks ago I went to DroidCon 11 in London – there were some really great presentations although I felt that I picked up less than I did last year. I don’t know if this is because the lack of the US Google guys, or that I’ve another year of Android development under my belt so know a lot more about the platform or something else.

Something that I did take away from the conference, and I’ve noticed that languages/platforms do this as they hit the big time (in my previous life I was a front end web dev, and I noticed the same with JavaScript), was that the Android ecosystem is maturing and with it a lot of libraries are emerging.

Today I stumbled upon this StackOverflow link detailing a lot of libraries – What Android 3rd-party libraries are there?.

Handy – no?

Read More

Book review : Android Wireless Application Development

Original review posted on the Barnes & Noble site.

As a seasoned Android developer it’s easy to forget the steps necessary in getting up and going with the platform – Conder and Darcey do a very good job of explaining the basics, with a small taster of the more complex stuff, with plenty of code examples to help along the way and just enough levity to keep the experience engaging (I also want to call my pet Null!) For someone new to the platform this is definitely a book you can read the first third of without skipping any, and then refer back to as a reference guide as and when needed.

The middle parts of the book, where the more complex ideas come in, aren’t full enough to be of any real use – the OpenGL and NDK sections could have multiple books written about each. I’m stuck between wondering if they are a nice, but brief, introduction which people will find useful to whet the palate, or short enough, and not detailed enough, to be of no real use and to warrant not being included in the first place. The latter parts of the book include some useful guides for testing and selling you Android app, as well as some short but useful sections on Eclipse; the emulator; SQLite and ADB. I found there were a few items I would have liked to have seen some more info about (i.e. broadcast receivers receive very little attention), and there were a few small coding mistakes throughout the book. The order of the sections in the latter half of the book also looked like they could have had a little more thought applied to them.

Overall this is a solid book for getting up to speed with Android development and the negative points are small enough so as to not distract from the overall learning experience. It’s not a book you are going to keep forever as once you learn the basics you’ll want to move on to other fuller, and more detailed, sources.

Read More

Code first, fail early (or why I throw away code)

I’ve been thinking a lot recently about how I go about writing new applications. I’ve worked in a lot of places and have seen first hand all styles from a waterfall style plan-everything-upfront, to a more agile approach of detailed short term plans with less detailed plans longer term. However, when I write my own applications I don’t take any of these approaches – I write code first, then throw it away. This completely goes against my gut instinct of how code should be written, it feels hacky, but it works much better than any other approach I’ve tried.

The benefits I get from jumping in to code early are:

  • I can flesh out an idea to see if there’re any issues with the approach (fail early)
  • I understand the problem domain much better after I’ve written some prototype code
  • I get an ideal if the code works from a end user point of view, much better than reading a spec will ever do
  • I can normally port some of the code from my prototype in to the final code
  • Coding is way more fun than writing specs
  • It saves me time and helps me write better applications

Let me restate that last point – by writing code and throwing it away, I’m saving myself time AND I end up writing a better application. There are many reasons why this happens – spending time in the problem domain means more time for my brain to subconsciously process what’s going on; better visibility of the issues; more likely that I’ll notice an article in my RSS reader which is in some way relevant and usable; more likely I’ll talk about any issues with friends who may have ideas about it – the list goes one. The main thing is that by getting in to the code early I give myself more opportunity to succeed.

I’m aware that writing code by yourself is way different to when you write code within an organisation; I know what I’m doing and I don’t have to prove to anyone that work is underway. This means I can spend time concentrating on core architecture, rather than rushing through it to get to concrete implementation details which in turn results in a more extendable, more maintainable, more functional codebase with less bugs.

From my experience I can understand why some companies may be cautious of adopting this process, to non techies this kind of loss leader may not make sense or seem a good use of time on a project with a deadline, but it’s in this exact situation that this approach works best. In the immortal words of The Doors “The time to hesitate is through” – write some code, throw it away; see how much you learn, and how much time you save.

Read More