Archive for category Coding

LWUIT on Android

padersyncPader-Sync have created an Android version of LWUIT. LWUIT comes from the Java ME world and solves two things. The first is being able to create rich controls on a Java ME canvas (i.e. the blank screen) as an alternative to using the less-attractive Form and Form controls. The second is to abstract away differences in screen sizes and phone capabilities.

I can see LWUIT for Android being useful for…

  • Allowing a common UI framework across Java ME and Android
  • Abstracting away differences in Android phone capability
  • Providing UI construct that aren’t provided by the Android UI

One of the original authors of LWUIT has taken Pader_Sync’s implementation, tweeked it a bit and has run it on the Nexus One. There’s a video at Shai’s Java & LWUIT Blog.

How to do Logging

I have been looking into the options available for remote logging. However, before I continue, I should mention local logging is done using log.

e.g. log.v(TAG, "This is a log message");

The TAG is a unique string for your app so you can differentiate it from all the other log messages. You view the log messages in the Eclipse LogCat screen. If it’s not already showing in your workspace then use Window… Show View… Other… Android … LogCat.

A problem with the Eclipse LogCat window is that once it receives too many log messages, they all scroll within a single line overwriting old ones. Also, the LogCat window is unreliable and sometimes shows nothing. Instead you can invoke

adb logcat

from the command line, while in the Android tools directory, that always works as expected.

Back to remote logging. This is logging by your testers when you don’t have direct access to the emulator or device and need logging sent to a  server.

Droddrop seems  the most capable remote logging currently available. There’s also remote stacktrace which does what it says… allows you to view exception information at a server. It can also be configured so that the server can also be your own if you don’t want to share your exceptions with the World.

There’s also an Android version of microlog that has been used available for years under Java ME. The Android version seems to be less capable and currently doesn’t do that much. However, there’s also a slightly more developer version at microlog4android.

Finally, if you need analytics as opposed to logging, you might like to take a look at Flurry.

NDK r3

androidrobotGoogle have just released the latest NDK. The biggest change is support for OpenGL ES 2.0…

“Android 2.0 (API level 5) or higher can now directly access OpenGL ES 2.0 features. This brings the ability to control graphics rendering through vertex and fragment shader programs, using the GLSL shading language.”

As mentioned on Forbes, ‘Mobile Games On Android Haven’t Caught On Yet’. This is partly because there aren’t that many great games. Part of the reason is that Java isn’t great for creating real-time games and you really need native coding to achieve high frame rates. Access to (native) OpenGL ES 2.0 should encourage creation of some great games and might even eventually help some games get ported from iPhone.

As it happens, I have recently been doing some development with the previous NDK and have two tips to help you get set up a bit quicker if you are developing under Windows.

  • When you install Cygwin ensure you include (tick) ‘make’ in the install
  • Cygwin maps your hard drives under /cygdrive/c/, for example /cygdrive/c/ for c:\. However, if you cd to cygdrive you won’t see c listed. If you include it in a path it works.

Android Training Videos

androidselftrainingJérôme Arnaud has emailed me about his Android training videos. Chapter 12, on Intents, is available free while the others are available for $9.95.

SQLite Performance

sqliteI have been doing some Android work involving medium size databases and have come across some barriers to using SQLite. With tens of thousands of records, performance degrades such that the use of the Android CursorAdapter together with a ListActivity are no longer viable.

More specifically, with just tens of thousands of records, opening the database cursor takes several seconds. Also, moving backwards using a cursor is far too slow. Digging deeper, other developers have commented on problems with Listview.setAdapter() and more specifically its call to cursor.getCount().

Anything more than 12,000 records and Android’s SQLite can’t provide the required performance for the UI performance to remain acceptable. In these cases you have to either limit the number of rows returned (via SQL) or resort to more custom ways to store your data. This goes some way to explaining why there aren’t any generic database applications on the Android Market.