Thursday, March 29, 2012

SQL Lite Performance on Android

 

For those who are unaware, Android has some build-in classes to support the use of SQL Lite databases. It provides a great way to structure a small amount of data within Android. However, there are a few pitfalls of using these classes that you should watch out for though.

Depending on which version you are using, a given query could run in milliseconds or minutes. For example, a query that runs in less than a second on a Galaxy S2 (and even quicker on a iPhone 4) takes a full minute to complete on an Atrix 2 and the  HTC Desire. All of these phones are relatively similar in terms of hardware, so what is the difference?

After studying and analyzing the code in question for a few days, it has come down to how the queries are designed. The problem arises when any large joins or unions are used. On many phones, it’s difficult to see much of a slow down. Combining a large table with one or more medium size tables needs to be optimized very carefully to ensure good performance across all devices. It’s very important to limit the size of any large tables before any unions or joins are computed.

Think about the following example database with three tables.

  • A Person table, with details like a person’s name, height, age, etc
  • A Family table, which contains details about a family
  • A City table, which contains a handful of cities where all of the families are located

Joining all three tables together in Android (assuming the Persons table has at least 2000 entries) would work just fine on most devices. If your user is the unlucky one with a older SQL Lite version, your app becomes unusable. Making sure any major join between several large tables is as small as possible ensures acceptable performance across all devices. For example, if it’s possible to pull a subset from the Persons table (by removing an order of magnitude), you will see a huge increase in performance.

The tricky part is figuring what SQL Lite version a given device is actually using. Although Android does have a version baked into a given OS version, manufactures seem to have different SQL Lite versions on different devices. This can cause a major headache when trying to figure out the SQL Lite version of a given device.

Here is a bit of info on StackOverFlow. Figuring out what version of SQL Lite is installed on a given phone can be painful. You’re better off spending some extra time on your queries up front to ensure good performance across Android now rather than later.

One other interesting fact regarding the Android SQL Lite classes involves when a query is actually executed on a given database. You would think the query would actually be executed when you receive a Cursor object. But as it turns out, the query isn’t executed until the cursor is actually used (like when the first moveToNext or moveToFirst). Therefore it’s important to make sure the cursor isn’t being used anywhere near the UI Thread.

Monday, March 19, 2012

Write Android apps on Android

 

Xzibit-on-Android-IDE

Now a desktop computer isn’t the only way to write Android apps anymore. AIDE is a full feature IDE built right into an Android app. AIDE allows you to write your Java code, compile, and test your new app all on the device.

It even has some fairly advance IDE features like syntax highlighting and code completion. The projects AIDE creates are fully compatible with any Android projects made in Eclipse, too. So it would be simple to transition between all of the standard development machines to a tablet with a keyboard.

AIDE is certainly the most interesting app I’ve run across in a long time. If you do any Android development at all, it’s definitely worth a quick download. It’s free to download, too.

The app is currently in beta, but it’s very usable now. Check out the main developer page here.

Tuesday, March 6, 2012

Buttery Smooth List Scrolling in Android

If I had to compare iOS to Android and only list one major benefit iOS has over Android, it would be the scrolling list performance, hands down (and I’m not the only one, or two, or three to say this...).

Seeing as scrolling lists are essential to just about every major mobile app, it affects the end user the most. Android's list view performance leads people to believe that Android is an inferior OS to iOS.

But as it turns out, with a handful of optimizations and some dedicated time, Android's scrolling performance can be just as good as iOS's performance.

You see, even though iOS does have a leg up in this department, iOS Developers still have to spent a good amount of time optimizing their scrolling lists to make them scroll smoothly. On Android, it just takes a bit more time.

When trying to improve Android's scrolling performance with a list of times, it’s important to realize the following few points:

  1. Creating objects is very expensive
  2. Calling findViewById too much can be painful
  3. Drawing on the screen should be done only when necessary

Here’s a few quick optimizations you can make to get the most performance gains for the time spent.

The first optimization is the most common one: The View Holder. It reduces the amount of objects you have to create while scrolling and dramatically cuts down  on some expensive UI calls. This optimization alone will net about 100 % increase in performance. A good example of the pattern in action can be found here.

One other less-used optimization is to only draw views when the user isn't actually scrolling the list. Here’s the idea: If your list view item consists of a few images, some text, and a checkbox, does your user really need to see all of these views generated as they are scrolling by?

When the user is scrolling by, all of the work going into calculating detailed views goes to waste, and it kills the scrolling animation.

The user also doesn’t need to have such a detailed view of scrolling data, either, only the ability to determine where the user is currently in the list. For example, in a list sorted alphabetically, you know where you are by checking the text in the list.

So instead of drawing all of these useless views while scrolling, why not only draw the text on the view? By only drawing the most important views, your list view should see a huge bump in scrolling speed, making it look much, much smoother.

For the code below to work properly, you need to add a boolean value (isScrolling) to your adapter. Any time the scrollState isn’t zero (or scrolling), you set this value to true. Once the scrolling stops, you can tell the adapter to redraw the views with the details necessary.

   1: listView.setOnScrollListener(new OnScrollListener() {
   2:  
   3: public void onScroll(AbsListView view, int firstVisibleItem,
   4: int visibleItemCount, int totalItemCoun) {
   5:     public void onScrollStateChanged(AbsListView view, int scrollState) {
   6:         if (scrollState != 0)
   7:             listView.getAdapter()).isScrolling = true;
   8:         else {
   9:             listView.getAdapter()).isScrolling = false;
  10:             listView.getAdapter()).notifyDataSetChanged();
  11:         }
  12:     }
  13: });
  14:  


After you add the above code in your listView.getView() method, you can use the newly added boolean value to determine if any performance-intensive views need to be drawn or not, like images or complex buttons.

The above two optimizations will give you a good jump in performance for a minimal amount of invested time.

Do you know of some other hidden optimization gems for Android’s List View performance?

Thursday, March 1, 2012

Think you can program Java?

Ever wonder how you really rank up versus other programmers? betterprogrammer.com is a great site to see how you really rank up versus other programmers. Currently, the site only offers a programming test for Java programmers.

The questions you'll find in the test are very similar to ones that high profile companies would ask during an interview. The questions range from determining if a string is an anagram to implementing a Queue with only using two Stacks.

The test itself involves a handful of questions that scale up in difficulty. For each question, they give you a short prompt and some subbed out methods. You're expected to copy the stubs into your IDE, code up your solution as fast as possible (while taking into account all corner cases you can think of), and paste it back into the site. Each question has a recommended duration that you should be able to meet and a maximum amount of time allowed for the question.
When I took the test, the questions ranged from 15 minutes (the easiest one), to an hour for the more challenging questions. At the end, you're sent your results via email. The site itself is used by several companies to gage programming skills, and the site is also used by programmers just trying to sharpen their skills a bit.

The only downfall of the site is its lack of info about how you did. You're only given a ranking of how well you scored versus everyone else that has taken the test (i.e., you scored better than 90 % of all the people who took the test). No info is given about what parts of the test you excelled on, what corner cases you didn't catch, or even if you got a question correct.

The beauty of the site is that you can take the test as many times as you want, with different questions each time. From what I have seen, the questions are great practice for anyone looking to improve his or her coding skills, regardless of the programming language.