This post is to basically explain how the Devchix to do list android app that Nola and I have been working on works. Currently, we are working on Iteration 1 of our plan. Here’s how I understand what we have working so far: In our app, users can switch between 2 activities using the menu option, “Add Task”.

When our app is first opened the first activity that is rendered is the ViewTasks activity. We first start with some setup steps…. we inflate our layout, create our task database and open a connection to that database. We create a cursor that will just represent all tasks that we have put in our database and we call the startManagingCursor method, so that we do not have to do that ourselves.

We get a ListView from our ListActivity; this ListView will be our list of tasks. In our ViewTask activity, we have a subclass class called TaskAdapter, that will help us get data out of our cursor and into our list view. Lastly, we set our TaskAdapter as an adapter on the ListView we just created.

When the user clicks on the menu button, we will see the two menu options whose names we grabbed out of our strings.xml. And because we have implemented the onMenuItemSelected to detect which option the user selects, we the user selects the Add Task option, our second activity will be started where users can enter the name of the task and save the task to the tasks database.

If there are already Tasks in the task database, then TaskAdapter will inflate a new row from the records we get back from our query and then have the TaskWrapper place the contents of the cursor into a Task object. The task object represents has getters and setters for setting the various task fields, which may be overkill right now because we don’t have many fields but as our application grows and expands to do more complex things with task information this may make our code more modular.

Other than creating the table, I don’t believe the methods we have in the TasksDbAdapter class are currently being used. Depending on how we want to clean the code up, we may be able to refactor this class—either move the db creation into the ViewTask activity or move the other queries out into the TasksDbAdapter.

Here’s the link to the Devchix Task List Android App on Google Code.

I attended the Atlanta Linux Fest last Saturday. I only got to stay for two talks, but what I saw was great!

From the Ubuntu Kernel talk given by Pete Graner of Canonical, I learned a couple of interesting things about Ubuntu…

Canonical has teams that work on things other than the ubuntu kernel, including integration for OEMs like Dell and HP, maintaining LaunchPad, and distributing install cds. They are able to maintain a 6 month release cycle for Ubuntu by deciding to only fix those bugs that are truly critical and focusing on the goals decided at the Ubuntu Developer Summit.

Ubuntu One allows you to back up any number of systems into the cloud.

The folks at Canonical have created a version of android that runs on Ubuntu Notebook Remix. It sounded like android uses some of its own version of libraries so a unique version of android had to be compiled to use those libs.

I also saw Kirrily Robert give her Standing Out in the Crowd talk. If you missed OSCon 2009 or the Atlanta Linux Fest, you can check out her talk here.

Write scripts for Android on the fly with bean shell, python or lua using Android Scripting Environment (ASE).

Install ASE on android.

Install TTS on android.

Write 3 lines of lua for an “app” that can speak whatever crazy explicatives you desire.

 require android
 name = android.getInput("Enter text to speak","")
 android.speak(name.result)

ASE is well suited for playing with Lua or Python on your commute home.

Any functionality native to the phone that isn’t already exposed in the API can be exposed by recompiling the app, which requires that you compile the android os too.

Last week I attended Big Nerd Ranch’s Android bootcamp. Wow! What an awesome week! So, I was only marginally familiar with the Andoird SDK before I attended the bootcamp. These are the kinds of things I knew before going to class…

1. Adb logcat is a command that opens the log of what’s really going on under the hood. Adb stands for android debug bridge. Typing adb logcat at a terminal/command prompt while the emulator is running provides you with a very useful console log.
2. Screen layouts are controlled by xml, an android specific xml format.
3. Resources classes are compiled from the layout, strings and other xml files in res folder and can be referenced in code by R.layout.name_of_layout_xml. These resources can make little red x’s in Eclipse show up even when there isn’t a real problem with your code because you just need to clean/build.
4. Apps aren’t deployed as wars or jars. They are deployed in an apk.
5. The activity lifecycle includes a number of methods that you can override, including onCreate and onPause.
6. I had done some tutorials, bought some books, and looked over several of sites I had also asked for help, but nothing really got the concepts in my head like the training at the Big Nerd Ranch.

We covered a ton of stuff over the course of the week: Layouts—lists, spinners, radio buttons, Activities (multiple activities), Menus, Saving to Database, Notifications, Toasts, Video, Webkit, Location, Intents, Content Providers, AIDLs, Services, Dailing a number, Maps… (there were more topics, but these are the ones that really stood out).

There were modules on each of these topics complete with code examples and exercises, which has really been helping out now that I am back at home writing Android apps as fast as my little fingers can type.

The time our class spent together eating meals was incredibly instructive—as folks drilled our instructor with Android-related questions. :) Here are some of my notes from class. After the course, I am re-writing the Android Sheep app and am working on my own “to do” list app—original, huh.

Here’s how I activated my SIM/hardware-unlocked Android Dev Phone.

1. I popped the SIM card out of my AT&T Go phone (cost approximately $20 at Target).
2. I made sure that there was some $$ on my Go phone account.*
3. I followed these instructions to activate the phone.

Why did I activate my Android Dev phone with a pay-as-you-go account?

My initial desire was to have a device that I could put apps on and test the apps as a user; however, now that I have the phone unlocked, I am thinking that I will want the phone as my primary phone. We will see; I am so indecisive about this phone. One reason that I can’t decide what to do is that I am on Verizon (CDMA); the G1 runs on 3G on GSM, but not at the same frequency as AT&T 3G network. So, in order to run the G1 on AT&T, I would have to run it on EDGE, which is slower than the 3G. So, I may end up switching to T-Mobile anyways… they have a nice flex plan that doesn’t require a 2yr commitment or your SSN.

*I believe I had $25 on the phone when I activated the phone. After about an hour of web surfing and email checking on the phone, all of my minutes/KBs were used up. :(

The Goal

Using the Android development kit, create an Android application that allows users to scroll through images of electric sheep and vote on which images they like.

First impression of Android: rich, open API with quick-n-easy dev set up

Holy shit! The documentation is like drinking from a water hose, definitely worse than a JavaDoc. The pay off is that there is a ton of features that “come with” this open source SDK. As mentioned on android linux,

usually you have major companies forming an oligarchy of mobile handset programming, but not so much with Android, anyone, even the girl next door, could be the person making the next great Android based mobile application.

And if you are familiar with Eclipse and HttpClient and jaxp and a slew of other things int the java world, then developing an Android app should be a snap. :-)

First lesson learned: keep your performance tuning cap on

Go ahead and resize all images to fit the phone screen. One issue that Gloria and I encountered was that switching between images in the image switcher was slow. I am not sure what the best way to do this is if you do not know the screen size; i mean i guess you would simply detect the screen size and choose the corresponding image size, but this assumes that the appropriately sized image would be available to you.

I did change the scaletype to CENTER, but I didn’t really notice a big performance difference… I mean I couldn’t even tell which one was faster. Per the moderator’s comments… the thumbnail isn’t stretched. The thumbnail and the png are two different files. But the ‘stretching’ that could be giving us problems is the shrinking of the png to fit it inside the small screen—I can see this because when the scaletype is set to CENTER or not set at all, the image appears much larger and not all of it fits on the screen. But so, unless we resize the images, there will always be some stretching/shrinking… it seems reasonable to close the ticket; we can optimize by resizing if there continues to be a performance issue. Anyways… interesting stuff. I am beginning to see what some of the challenges would be in writing a mobile app.

Second lesson learned: be mindful of your focus

Either do not set the focus on the ImageView or pass in the gallery so you can set the focus back to the gallery. I received some great help from the Android Beginners Google Group.

Setup Tips

1. Another issue that tripped me up was logging. Sysouts won’t work… or at least Android provides its own logging. This logging how to helped me out. The short of it is use “adb logcat” command to view logging done by android.util.Log.
2. Don’t waste time decompiling; get the source. Although it never fails, I end up decompiling stuff anyways. <^_^>