Android Multimedia Development – My talk at SG-GTUG

Twitter has made me so lazy that I rarely post on my blog these days. Also had been traveling over the last 2 months so had been a bit busy. Anyway, SG-GTUG had been kind enough to invite me to give a talk on Android at Google, Singapore on September 18, 2010. Bharathi Subramanian from SQLSTAR was the program chair for this event.

I spoke at length about the Media framework of Android. While I clearly appreciated some features such as ease of writing OpenGL-ES applications on Android (as the platform does the EGL config stuff by itself and all the developer has to do is to put together a few GL calls), I reserved my choisiest of abuses for MediaPlayer and MediaRecorder classes in android.media. This was also a result of the frustrations I had been through over the last 9 months dealing with these 2 monolithic classes.

One can argue that they simplify the playing and recording of audio/video content and a developer has to code precious little to get playing and recording of content done. Agreed, BUT there are no other classes to process video and audio content at the SDK level. As I had mentioned in the talk, the MediaPlayer.getFrame() method had been discontinued after API level 1 and MediaPlayer.snoop(), used in some live wallpapers bundled with the SDK, is annotated @hide. I had put up a feature request to expose OMXCodec.h to the NDK so that developers could build powerful media applications.

I thoroughly enjoyed speaking to a lively audience, who bombarded me with questions, some of which I couldn’t provide a clear answer to But all in all it was time well spent. Special thanks to SPT Krishnan who runs the group and Louis Shue for organizing the event flawlessly. I am attaching my slides to this post. Feel free to use them if you find anything useful. It would always be better if you could cross-check their accuracy quotient

Apple’s iOS4 vs Android Froyo

My new post on SG-GTUG.

It’s a tricky proposition to compare these software platforms without discussing the real devices but let us give it a try! Both platforms carry major improvements in their latest releases and are rapidly emerging as 2 poles in the Smart Phone OS battle.

Lest the fanboys flame me, lets start with what iOS4 is good at. User experience and improved power management come to mind. The camera app has received great reviews, specially the digital zoom and tap-to-focus features of the video capture. The unified e-mail inbox is a very good idea and Android lacks it. Since iPads also would be getting an iOS4 update later this year, the iBooks app is a good one too. Stacking up apps into folders is a neat idea. But the user has to now remember where a certain app has been stored.

The iOS4 has at long last added multitasking support. But hang on, that’s just a headline. It allows 3rd party apps to push certain kind of (mostly Audio, GPS and VoIP related) apps into background. That’s about it. So you can listen to music and send text or e-mail but you cannot do either of those if you are buffering a Youtube video. This pales in comparison to what Android has to offer. All in all, I think iOS4 is a decent improvement over its predecessor, but doesn’t quite get the multi-tasking part going still (and covers it up saying that “full” multitasking drains battery power).

Coming to Froyo, the first impression I got running it on my Nexus one was – Froyo is fast, thanks to JIT compilation. Even the browser has quickened up. Also the soft “call key” is a good addition, however I still believe hard keys do the job better. It is good that Froyo is Flash 10.1 enabled, something which iOS4 discarded outright citing security and speed concerns. There is a new media framework, called StageFright, used for streaming and it may eventually replace the existing OpenCore. Froyo also allows us to install apps on the SD card and thereby save space on the phone memory.

The USB and Wifi tethering are both great (and geeky) ideas but penalize the battery. Froyo’s Media Player is still disappointing as is the power management and hence battery performance. FM radio is still not enabled. There aren’t many compelling multimedia applications (video editor for example) on Froyo and with devices with large screen sizes, multimedia should be an area to address. In terms of user experience, Froyo still has some work to do and it is good that Gingerbread – the next version- is focusing on user experience.

Given that both platforms have specific concerns to address, I think it is a tie! I hope Gingerbread would give Android a definitive edge and it is about time Google improved Android’s Market place experience as well.

P.S.: It seems that Froyo would be “the” Android distro for slightly lower end Android devices and Gingerbread would find a place in higher end ones. We need to watch how this pans out in terms of App development, App portability across devices and device software upgrades. Watch this for more info.

Multitasking on Mobile devices – Android style

My new post on SG-GTUG blog. It is about Multitasking in Android OS. Would be writing more often from now on the GTUG blog. The link to the original post can be found here.

Enabling multitasking for third party mobile applications can be a tricky proposition in the best of times. Rogue applications hogging memory and draining the battery are most cited concerns – this is common knowledge. It is in this context that Android’s philosophy on multitasking is a refreshing change. Tim Bray has a great overview on Android’s multitasking functionality in his Android Developers blog post. “All applications are created equal” and “All applications run all the time” are the tenets on which the system has been designed and designed elegantly at that. Contrast this with once popular co-operative multitasking systems that depend on user applications explicitly ceding control failing which the device may become unresponsive and you will be able to appreciate the philosophy of Android better.

But the real deal on Android is not multitasking on its own, it is the overall way in which UI components, applications and background components gel together to create a fabulous user experience. Consider an example: Go to the gallery, select a picture to be uploaded to facebook. What the user sees is a Toast prompt saying something on the lines that the picture would be uploaded, further suggesting the user to look at the notification bar for the progress of the upload operation. The user can, in the meantime, select another image for upload and Android obliges. What the user doesn’t see is a upload progress bar blocking further uploads. Instead the nifty notification bar/window takes over that mantle. A background service performs the upload operation and updates the notification window leaving the main application window open for further user interaction.

What if the user chooses to switch the application after choosing to upload the picture? I know that app developers want users to stay on their application longer and may not be comfortable with the user “exiting” their application even though the operation is not fully completed. Worst still what if the operation fails? The notification window solves this problem as well. Whether the user gets an intimation that the operation has failed (say via a Toast) or the user voluntarily checks back in the notification window, clicking on the appropriate notification will lead the user back to the application. Developers even have the freedom to create a custom layout for the notification space. For example, the notification window can contain the application’s icon, action buttons or progress bars. A good starting point for exploring this functionality is RemoteService.java present in ApiDemos.

As explained above, Android spins an excellent mobile experience built around a unique philosophy on multitasking. It is not multitasking itself that makes a difference, it is how applications use the power of multitasking, not just for providing the user with advanced functionality, but offering him a hassle free experience that counts.

Until next time, cheers!