Debugging Web Requests with Fiddler for Android

May 4, 2012 08:18 by wjchristenson2

Fiddler is a popular web traffic debugging tool which lets you inspect web requests.  This ability is very helpful when developing applications which consume web services.  I’ve been working with a team on an Android application and I needed to use Fiddler with Android.  In this post, I’m going to show you how to setup Fiddler to inspect web traffic from an Android device running Ice Cream Sandwich.

 

1) First, if you don’t have Fiddler yet, you can download it here.

2) Second, you need to set and take note of some Fiddler options.  Check the “Allow remote computers to connect”.  This option will allow your Android device to connect to Fiddler via your computer’s local IP address and proxy port.  You can see and/or configure what port Fiddler listens on as shown below.  The default proxy port is 8888.

3) Restart Fiddler so that it loads your new configuration options.

4) Next, you’ll need to setup your Android device to run it’s connectivity through Fiddler.  Navigate to Settings >> Wireless & Networks >> WiFi.  Select the network you are using.  If you are debugging your Android application, you’ll probably be using your local wireless connection.

5) Enter the basic settings and check “Show Advanced Options”.

6)  Under Proxy Settings, select “Manual” so we can manually enter the IP address & proxy port which Fiddler is running on.

7) Enter the IP Address and Proxy Port information where Fiddler is running.  Most likely Fiddler will be running on your local development machine.  If using Windows, you can find your IP address by going to the command prompt and using ipconfig (Start >> Run >> “cmd” >> “ipconfig”).

 

That’s all there is to it.  After you have this setup, make sure that Fiddler is running and web traffic from your Android device should be routed through Fiddler.  Happy web traffic inspecting!

 

Bookmark and Share

Breakpoints not hit while Debugging an AsyncTask in Eclipse for Android

May 1, 2012 03:10 by wjchristenson2

I ran into an issue yesterday where my breakpoints in an AsyncTask doInBackground method were not being hit.  After an hour of troubleshooting, I found two situations that can cause this issue.

1.  The doInBackground method is running before the Android debugger can attach to the process. Add the following to the beginning of your doInBackground method to see if this is the case.  If not, see cause 2 below.

 

@Override
protected Void doInBackground(Void... params) {
	android.os.Debug.waitForDebugger();
	
	// TODO Auto-generated method stub
	return null;
}

 

2.  An AsyncTask cannot execute another AsyncTask within the doInBackground method.  This was my problem.  An AsyncTask must be executed from the main (UI) thread.  So AsyncTask “A” cannot execute AsyncTask “B” in its doInBackground method as this is running on a background thread.

 

Bookmark and Share

Performance Tips for Loading Objects with a SQLiteCursor

April 22, 2012 07:02 by wjchristenson2

This last week, I ran into poor performance loading Java objects on Android using SQLiteCursors.  I needed to load a hierarchy of objects.  This hierarchy was 4 levels deep and contained around 1,000 objects.  I tried a few approaches to see what method could load these objects the fastest.

In my first approach, I decided to de-normalize my results to limit the number of database hits.  Instead of 100’s of database hits (queries), I returned 3 large result sets.  Then, I thought I’d loop the cursors to fill the hierarchy starting with the top levels and working to the detail levels.  Loading the objects took 50.9 seconds…  Ouch.

I knew that all 3 queries took < 1 second.  So I looked at the loading of each object.  I thought part of my problem was the SQLiteCursor.getColumnIndex() method.  I’ve read that this method can be very taxing.  So I thought I’d create a HashMap of the column indexes and then pass that to the loading of each object so I didn’t have to call the getColumnIndex() method for each property for each object.  A coworker of mine made me a bet that the SQLiteCursor already lazy loaded the column indexes so subsequent calls wouldn’t have to loop the column names each call.  He was right.  So creating a HashMap of column names to indexes would not help.

My next thought was that looping SQLiteCursors over and over was not a good idea.  So I had a better idea.  Load the objects from the cursor with one loop into a generic ArrayList, then assemble the hierarchy/relationships. 

I’m used to .NET and disconnected Datasets and DataTables.  I’d usually load a DataTable then run DataTable.Select() filters on it to get my data subsets to build object hierarchies… but Android doesn’t have such mechanisms.  So I decided to add helper properties to my objects so that I could load a generic ArrayList of my objects from cursors and then assemble them after the database querying was done.  This proved to be a very good idea.  3 queries with loading of 3 generic ArrayLists of my objects ran in just over 1 second.  That proved that the SQLiteCursor.getColumnIndex() is not as taxing as I thought.

Assembling the objects into the hierarchy then boiled down to nested loops and setting the appropriate object relationship properties.  Total cost: < 3 seconds after a 50.9 second first try.  Much better… I want it in ~1 second.  We’ll see where I go from here.

Lesson: Don’t use SQLiteCursors in nested loops to build object hierarchies.  Get the data in the least number of database hits that you can, load your objects from a cursor in a single loop, close your cursor, and then assemble the object hierarchies after.  Also, remember if you are running multiple select statements to run them under one transaction.  Multiple transactions for multiple queries is more taxing than one transaction for multiple queries.  Remember that SQLite implicitly creates a transaction for each query ran unless you explicitly create one and run all queries under it.

 

Bookmark and Share

SQLite Bulk Insert

February 19, 2012 06:13 by wjchristenson2

“Bulk Insert” for SQLite does not exist.  However, there are some tricks to speed up bulk loading of SQLite data.  In this post, I am going to show you some techniques that I’ve learned to load data as fast as possible into a SQLite database.

First, every SQL statement ran on SQLite is ran under a transaction even if you don’t specify one.  When loading thousands of records, this can be very taxing and slow things down very fast.  As a result, you’ll want to load all records under one transaction so that the SQLite DBMS will not start/commit a transaction for every row.

Second, use prepared statements and/or reuse your SQLiteCommand objects.  What you do is dependent on what technology you are using SQLite with (e.g. Java for Android or ADO.NET).  Rebuilding objects for every record inserted is very taxing.  So you’ll want to build the object once, then pass values to it for each row.

In summary, do the following for quick “bulk inserts”:
1)  Use 1 transaction to load all records.
2)  Reuse command/prepared statements to insert each row.

Here’s a snippet on how to bulk insert in Java for Android:

db.beginTransaction();
try {
	SQLiteStatement insert = null;
	insert = db.compileStatement("INSERT OR REPLACE INTO \"MyTable\" ("
			+ "\"MyColumnName\") VALUES (?)");
	
	for (i = 0; i++; i < 10000)
	{
		insert.bindLong(1, i);
        insert.execute();
		insert.clearBindings();
	}
	
	db.setTransactionSuccessful();
}
catch (Exception e) {
	String errMsg = (e.getMessage() == null) ? "bulkInsert failed" : e.getMessage();
	Log.e("bulkInsert:", errMsg);
}
finally {
	db.endTransaction();
}

 

Here’s an example of how to bulk insert in VB .NET:

        Using sqliteConn As SQLiteConnection = New SQLiteConnection("Data Source=c:\test.s3db")

            Dim sqliteTran As SQLiteTransaction = Nothing

            Try
                Dim sql As StringBuilder = New StringBuilder()
                sql.Append("INSERT INTO ""MyTable""(""MyColumnName"") VALUES (:MyColumnName);")

                Dim cmdSQLite As SQLiteCommand = sqliteConn.CreateCommand()
                With cmdSQLite
                    .CommandType = CommandType.Text
                    .CommandText = sql.ToString()
                    cmdSQLite.Parameters.Add(":MyColumnName", DbType.Int64)
                End With

                Dim i As Integer = 0
                While i < 10000
                    cmdSQLite.Parameters(":MyColumnName").Value = i
                    cmdSQLite.ExecuteNonQuery()

                    i += 1
                End While

                sqliteTran.Commit()
            Catch ex As Exception
                'attempt to rollback the transaction
                Try
                    sqliteTran.Rollback()
                Catch ex2 As Exception
                    'do nothing
                End Try

                'rethrow the exception
                Throw (ex)
            End Try
        End Using

 

Both examples insert 10,000 records.  Notice that we explicitly kick off one transaction for all inserts and commit it after we are finished inserting.  Also notice that in both examples, one command/prepared statement is built and reused for all 10,000 inserts.  There are some other SQLite tweaks you can do to slightly speed up performance, but the 2 mentioned will give you the most gains without having to get too technical with the SQLite DBMS engine.


Bookmark and Share

Android Version History

November 5, 2011 12:18 by wjchristenson2

If you are like me, you may be confused with all of the Android release code names.  Something I learned today is that the code names are in alphabetical order.  So if 5.0 is Jelly Bean, my wild guess is 6.0 will be Kiwi…

 

Distribution API Level
5.0 Jelly Bean 15-16
4.0 Ice Cream Sandwich 14-15
3.x.x Honeycomb 11-13
2.3.x Gingerbread 9-10
2.2 Froyo 8
2.1 Eclair 7
1.6 Donut 4
1.5 Cupcake 3


Something else I learned today… don’t set your SD card size to 16gb for your AVD.  It literally takes up 16gb of HD space and takes forever to allocate.  :(

Bookmark and Share