2011-01-22

As the previous post this will also cover TableLayout. As with borders, there are no attribute for defining a TableRow as a header row. With header row I mean a row that will not scroll with the rest of the data in the TableLayout (providing you have declared the table to be inside a ScrollView).

Well, there is actually a way to work around this using a separate TableLayout for the header row. If you know that the header columns will be wider than the rest of the data in the table it's pretty easy. Some key notes to make this work:

Set all Views in the table to android:layout_weight="1"

You must NOT set android:stretchColumns="*" as this will override the weight attribute.

You must know which row is widest, and use a copy of this as a "dummy" row.

Note that this will only work if you know that the header columns is wider than the rest of the data. If any of the rows in the "main" table is wider than the header row the columns will no longer be aligned. However, there is a way to solve this as well. If you can identify the widest row in the "main" table, then just do the same procedure as above, but this time add this as a dummy row to the header table.

2011-01-02

Have you ever tried to place two buttons next to each other with each button taking up half the screen? Are you using RelativeLayout as well? Finding it hard? There is actually a pretty neat trick for this, using a View layout as a helper object. This will not be visible since the size is 0 pixels, and after centering the View horizontally, the buttons can be aligned to the left/right:

2010-12-18

If you are using a database in your android application you are probably going to delete data at some point. When dealing with one to many relationships, the children should also be deleted when the master is deleted.

For example, a table Album contains many songs stored in another table Songs. The table Songs has a foreign key album_id referencing the primary key id in table Album.

Sqlite3 doesn't support cascade delete until version 3.6.19 (available on Android 2.2), so if you want this to work on a device running android prior to version 2.2 it can be solved using Triggers:

2010-12-15

Since mobile devices are pretty limited when it comes to hardware specs, there are a few things you should think of as a developer to optimize the code. This will make the app run faster and smoother, and the user will more likely keep using your app.

1. One thing I noticed when debugging my app, was a lot of lines in Logcat that looked like: "Gc freed x objects / y bytes in z ms". This is the garbage collector doing it's work and it's of course impossible to write an app that has no GC at some point. But if you start seeing these lines frequently and when the app is idle, you should be able to optimize the code.

The most probable cause for this is that you create too many objects. Look for code like:

Change this by declaring the variables as class member variables instead, then you will create only one object instead of one object/onclick action. Note that you shouldn't use this as a general rule though. A member (global) variable's life cycle is longer compared to local variables, so it will allocate memory for a longer time.

In a GPS listener method executing once every second you should use member variables.

In a method that will be executed a few times only, local variables are preferred.

2. Analyze the layout. If you start nesting several LinearLayout you should consider switching to RelativeLayout instead. The deeper the layout tree becomes, the more expensive it is. One way to analyze this is to use the tool Hierarchy Viewer (included in the SDK). Run your application and click on <Focused Window> and then hit Ctrl + L to load the current activity. You should aim for a wide layout instead of deep layout with many levels.

This will create many objects. Use the primitives (i.e. float, int) instead of their wrapper classes (i.e. Float, Integer) when possible.

4. Access the member variables directly instead of using a getter method. It will always be faster.

5. Reuse views. For example, instead of creating a new TextView object for each TextView in a layout, you should consider reusing only one TextView.

6. This is more of a power consumption optimization, but a good one. If you are using GPS listener for example, you should consider turning it off when the phone is idle or when the user exits the activity where GPS is used, by implementing the onResume and onPause methods: