How to do Logging
Posted on March 10th, 2010
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
Posted on March 9th, 2010
Google 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.
Google Android Seeding
Posted on March 8th, 2010
I have just received confirmation that I’ll be receiving a Nexus One. All developers with a rating of 3.5 stars or higher and more than 5,000 unique downloads will be receiving either a Droid or a Nexus One.
In my opinion, 5,000 downloads is actually quite low. I have three apps at the moment totalling over 120,000 downloads. I think Google is giving phones out to developers to encourage earlier developers to test their older apps on newer devices as well as encourage more apps to be written.
Purchasing the latest phones is an issue for developers. It can be costly ensuring an app runs on all phone variants. In my 14 year mobile career I can only remember having received (as a developer) an iPAQ from Redmond and very recently a Satio from Sony Ericsson.
Conversely, as a blogger I have received many more phones. Phone OEMs and network operators have been far more interested in getting the word out on new phones than ensuring that applications continue to work/continue to be developed. As usual, Google is taking an engineering rather than marketing driven approach. Seed developers with phones and see what happens.
Thoughts on Apple vs HTC Suit
Posted on March 4th, 2010
I have been thinking through the implications and reasons for the Apple vs HTC patent chaos. Engadget gives a great breakdown of the patents.
Many of the patents are so generic and involve ‘prior art’ that I am surprised Apple has patents for them. Take Patent #6,424,354 from 2002: Object-Oriented Event Notification System With Listener Registration Of Both Interests And Methods. Isn’t this the observer pattern from the classic 1994 Design Patterns book ?
Nevertheless, it’s likely that Apple has a least one, maybe more, valid patents. The problem is which ones? Why have Apple even included the ridiculous ones? It can only slow down the resolution process.
PC mag might have the answer.
“Just slowing down the rapid growth of Android would be a win. Just getting manufactures to think twice before rolling out Android phones would be a boon. Even a few months of legal wrangling would help Apple pad its lead.”
This equally applies to Windows Phone Series 7 (and HTC’s other Windows Mobile v6.x devices), Symbian or any other platform.
I tend to believe this is the real reason. If Apple were serious about this they would have concentrated on one or two winnable patents. As it is, there’s chaos and this can only lengthen the time over which OEMs might think twice about Android (and Windows Mobile etc). I think Apple are more interested in disrupting things than stopping competitors’ phone shipments, the latter of which they might have done much sooner has they had a more focussed legal suit.
Fragmentation in the Web Space
Posted on March 3rd, 2010
It’s interesting to see people complaining that they can’t get Google’s Buzz on pre-Android v2 devices. This demonstrates a point I wrote about a while ago. The deeper web browsers get into phone APIs, the more fragmentation there will be. The web is not a ‘golden bullet’ and doesn’t solve fragmentation problems. What it does do is concentrate them at one place that might be said to be an advantage in terms of development effort, cost and maintainablity.

