Wednesday, December 31, 2014

MyNotes: Migrating to Android Studio

Converting to Android Studio is pretty easy.

The first step is in the migration is open the Android Studio and import the project:

Once the import completes, you will notice that the structure is a little different than eclipse.  Android Studio uses modules instead of projects.  In the case my import, the top-level module is named "app".  I changed this to MyNotes because I like to use library projects and it easier to manage the modules with more descriptive names.

Underneath that the MyNotes module, you will notice that things are organized a bit differently.

The first big difference is that the project consists of modules.  I only have one at this point, MyNotes.  Under that module, the directory structure isn't flat.  By default, the import only creates the main folder.  The normal android project structure all exists under this folder.

Eventually, main will get a sibling folder that will contain the unit tests, but that is another step.

The other big difference is that build tool here is Gradle.  There is definitely a learning curve with Gradle.  Once I got use to it, I learned to appreciate it.  You will notice that there are three gradle files in the project by default: settings.gradle, the project build.gradle, MyNotes module build.gradle.
The settings.gradle and project build.gradle will not change much.  Most changes occur in the modules gradle file.

Which brings us to the first modification to MyNotes gradle file.  Since the oldest build I plan to support is Ice Cream Sandwich, I updated the gradle file to support that as the minimum SDK and to use Lollipop as the target.

Anytime you modify any gradle file be sure to do a gradle sync or a tools->android->sync project with gradle to ensure the changes propagate. The tools->android->sync project with gradle is actually handy to run anytime you get weird build issues.  It doesn't happen very often anymore, but it is a handy trick to know.

Now that everything is compiling again, we can call the migration good.

You can find the commit for these changes here.

Wednesday, December 24, 2014

MyNotes: Choosing an IDE

This app was originally developed using Eclipse, but Google is no longer releasing Android updates for that platform.  Now that Android Studio is officially released, it is my preference.

Honestly, this wasn't a hard choice.  I have been using Android Studio professionally for over a year. Back then I would have hesitated but it has definitely come a long way since then. I now prefer it just because it doesn't crash or hang on me frequently.  Besides, if I am going to go through all the rework anyway, now is the time to the migration.

New features that you might find useful are :
  • The ability to cross reference the XML resources.  You can show all usages of a resource or go to the resource definition from the code very easily.
  • It shows a little swatch with the color or image for a drawable in the xml.  It doesn't seem like much but it comes in really handy.
  • The Layout Preview actually works and it is the first IDE that I actually preview my layouts before I put them on a device.
  • It has a built-in nine patch editor.  I can take or leave this one.
  • The auto-completion for methods is much nicer than eclipse.
  • The files auto-save.
  • The local history is incredibly helpful when experimenting with files.
Some things you have to get use to:
  • The project structure is a little different.  We will get to this later in the next blog entry.
  • It doesn't do incremental builds (yet).
  • Gradle
  • The hot keys are very different, but can be configured to use the Eclipse hot keys.
  • The debugger and DDMS are mutually exclusive
  • You still need part of Eclipse for the Memory Analysis Tool
  • The tool windows can be annoying.
  • The documentation doesn't automatically appear when hovering over a method.
  • The auto-completion for documentation is irritating.

Wednesday, December 17, 2014

First Up to the Chopping Block: MyNotes

So the first of the apps I am going to deal with is MyNotes.

If you haven't heard of it, your in good company because nobody else has either.

It is one of the many obscure android apps with a very small user base.  It was also the second app I wrote and I haven't even looked at the code in a couple of years.  I am not looking forward to it because I really didn't know what I was doing back then.  Seriously, I orginally wrote it in two days.  It is going to be cringe worthy.

Basically, it is a very small simple application.  It just consists of a database with a single table, an activity for viewing the notes, and an activity for editing the notes.  It was originally written for FroYo and it is still basically written for FroYo.  I did an incomplete and half-baked attempt to update it about 6 months after I wrote it, but lost interest and never finished it.

So to recap, it was written quickly by someone new to android, untested, half-heartedly updated and experimented on, and is 13 API levels out-of-fate.

In other words, it needs a lot of work...

Wednesday, December 10, 2014

The First Step is Admitting You Have a Problem

I can be a sloppy developer.   There I admitted it.

Okay, that's a bit of an overstatement and it only applies to the apps I develop in my spare time.

I do have to admit that I am embarrassed by the code I developed for my earlier apps.  I didn't have the experience that have now and I was trying to cram in the development between my day job and trying to have a personal life.  I wound up cutting corners to try to make the most of the time I had to work on it.  Therefore, things like unit test, documentation, and making the code maintainable kept getting pushed down the to do list.

The end result wound up being that now I have several apps that I want to continue working on, but the code bases are in bad shape.

After some reflection (and a little swearing about the state of the apps), I came to realize that the reasons I felt okay cutting the corners was that I wasn't being paid for the work and nobody else was every likely to see it.  While I can't really justify paying myself for the free time work, I can make my code more visible.

So I decided to publish my code bases publicly on GitHub.

Then I decided to chronicle the refactoring process for each of the apps I want to modernize and improve.  So my current plan is start with one app and publish the out-dated legacy code as-is.  Then I  plan on going go step-by-step improving the app until I finally publish it again.

Part of me really wants to cringe at publically releasing the code in its current state.  However, I thought it was important to show the refactoring process so that others can avoid some of the newbie android developer mistakes I made early on and how to fix them if they are in the same boat as I am now.

Here goes nothing.  The respositories are at GitHub at