Monthly Archives: February 2014

Hell Is Other People’s Code

Some say “Hell is other people.” As software engineers, we say “Hell is other people’s code.” Seriously, we love to hate code we didn’t write. Other people’s code is hard to understand. It doesn’t follow what we think are best practices. It’s full of warts and hacks scattered all over the place.

It’s core to our product and business critical for our customers.

Wait… what?

At this point I’d encourage you to go read this excellent blog post about why the most important part of your software has the ugliest code. If the software you work on has been around long enough to become a useful product for a lot of customers, chances are it was around before you started working on it and it is “other people’s code” to you.

We should keep this in mind next time we want to hate the “other people’s” code we are looking at. Legacy code is usually the way it is for a reason. As software professionals, everybody is much better off if we spend our energy making our inherited code the best that we possibly can instead of spending energy harboring negative feelings.

Advertisements

Leave a comment

Filed under Software Engineering

SQLite Database From Tutorial To Actual Use

The standard Android training site has a useful guide on getting started with the built-in SQLite database. It gives us as new developers the idea of where to start, and allows us to start writing code with it almost immediately.

However, this guide has a critical gap: it does not mention how much more there is more to using the database than those few sample lines. It does not mention where to go next to find out more. We can easily read the guide and come away with the false impression that this way to access the database is the end of the story… until everything breaks and we need to start googling or looking through the sample applications and find out how much more there is to using the database *correctly*.

Here are the missing steps between the guide and functioning code.

Missing Step #1: Manual Transaction Management

To anybody used to using @Transactional annotations, manual transaction management is not the first thing that comes to mind when coming to Android for the first time. Yet, transaction management is critical in this environment. Here is the code that you actually need to use. Think of this as a standard structure that you’ll need for all of your interactions with the database.

// we can begin the transaction outside of the try block
database.beginTransaction();
try {
  // database insert / update  / etc goes here
  database.setTransactionSuccessful();
}
catch(Exception ex) {
  // log or rethrow as you like
  // this dummy code is here to provide a convenient breakpoint
  String cause = ex.getMessage();
  throw ex;
}
finally {
  // always end the transaction in a finally block!
  // don't leave transactions hanging around!
  database.endTransaction();
}

Missing Step #2: Managing The Database Throughout Activity Lifecycle

In the Activity, the database is opened in the onCreate() method. Note that we must have an implementation of SQLiteOpenHelper per the SQLite guide, and that the Context it takes can actually be the Activity since Activity extends Context.

@Override
protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  SQLiteOpenHelper helper = new MyDatabaseOpenHelper(this);
  database = helper.getWritableDatabase();
}

Correspondingly, in the Activity, the SQLiteDatabase that we obtained from SQLiteOpenHelper.getWritableDatabase() is an open resource that must be closed when the activity is destroyed.

@Override
public void onDestroy() {
  super.onDestroy();
  database.close();
}

Conclusion

That’s it! With these extra steps to supplement the official guide, we can write fully functioning code against the SQLite database.

For more information: the official sample apps do include some sample applications that use a database. Presumably BasicSyncAdapter is the best option at this point (the others being in a “legacy” area).

SDK/samples/android-19/legacy/NotePad
SDK/samples/android-19/legacy/SearchableDictionary
SDK/samples/android-19/legacy/ApiDemos
SDK/samples/android-19/connectivity/BasicSyncAdapter/BasicSyncAdapterSample

Even with functioning code, there is more to learn about how to use it *better*, such as how to open databases in a background thread to improve performance, and a full analysis of using an Android ORM library. For now: enjoy using the database on your Android device!

Leave a comment

Filed under Android, Software Engineering

How to set up unit tests for Android / Gradle

In a recent post we found that maven and gradle are designed for unit testing but not for integration testing (although gradle makes it fairly easy to write separate integration tests).

In Android, it turns out that there is an extensive testing system in place, but that it is not for unit testing, it is for integration testing (actually running your complete application on connected devices). Hilariously, Android seems to have the inverse problem of what we saw in maven and gradle: integration tests are baked in to the system, and unit testing requires special work.

To this end, after having read the android guide on testing with the android gradle plugin, I wanted to set up JUnit tests for my POJO’s that don’t run with the instrumented tests. The idea was that tests for code that doesn’t depend on Android should be very fast (and facilitate TDD).

Unfortunately, after much googling and experimentation, I was forced to the conclusion that simple unit testing is just not supported out of the box with android and gradle. Indeed I was not able to make it work the way I’d like. The best solution I can come up with for the time being is that any code that is completely independent of android is best placed in its own project (say, a sibling to the android application in the gradle main project) and run unit tests there.

If anybody reads this and has ideas, feel free to drop an answer on StackOverflow.

Leave a comment

Filed under Android, Software Engineering

Choosing an IDE for the New Android Developer

When a developer wants to learn android development and visits the android developer website for the first time, they will quickly find that there are two options for how to develop for android. There is Android Studio which is an early access preview, and the ADT Plugin for Eclipse (also distributed as the SDK ADT Bundle).

This raises the question: if a developeris starting out learning Android, should they start with the stable tool (Eclipse) and save time migrating/relearning later when everybody switches to Android Studio? Or start with Android Studio which might have bugs but which is the tool probably everybody will be using at some point in the future (and which might have hot new features)?

As an android novice, I did some research and here’s what I found: If you start out by using Android Studio, all the tutorials are for ADT so differences between what you see in the tutorial and what you see in Android Studio could slow you down. And if things aren’t working, it might be hard to say whether it’s a bug in Android Studio (because it’s still in beta) or because you did something wrong. For these two reasons: if you’re just starting out learning android, I would recommend to start learning on Eclipse/ADT.

Leave a comment

Filed under Software Engineering