Thursday, May 29, 2008

Google IO 2008 Day Two

HTML 5 - Gears

From a vendor's perspective: You don't win users by being super standards compliant. At best, you don't lose users. Gears targets developers, not users. So, Gears considers standards to be a profit center rather than a cost center. Gears is a playground for new web APIs. One such example is SQL in Gears, which once proven successful in Gears, was included in HTML5.

Dalvik VM Internals:
Dalvik is designed to run on a slow CPU, with relatively low RAM, and on an OS without swap space while powered by a battery. The system library takes around 10MB. Thats a fairly large library at the application developer's disposal. Memory is saved via minimal repetition, per-type pools, and implicit labeling. Zygote is a pre-initialized process + pre-warmed Dalvik VM. This ensures responsiveness. When requested, it forks and returns the new process. The advantage is that the application shares the API classes in memory so that the memory foot print is less. Android manages multiple processes which have separate heaps, and separate GCs. When an application is installed, it is verified so that it does not violate the constriants of the system. The application is also optimized( static linking, inlining some native methods etc) so that when the application is run, it runs faster. Oh btw: the Dalvik is not a stack based machine but it is a register based machine. Theoretically, it is defined to be an infinite register machine. This results in fewer instructions to perform operations.

Inside the Android Application Framework:

Android provides a lot of hooks for application developers to plug-in custom code during the lifecycle. In my APIs, I try to give my developers a powerful yet simple looking APIs. Granted it is a tricky decision to make, but it is all about drawing a line and finalizing on the API. The Android lifecycle hooks are pretty complex and remind you of EJB lifecycle. Hopefully, a lot of developers will not get confused with differences between methods like onCreate(), onStart() and onStop(), onDestroy()

Each process has a thread. Each thread has a Looper which handles a message queue. Any events are posted to this message queue. And, are processed by the thread through the Looper. Loopers cannot accommodate multi-threaded access. Loopers support a message handler to handle multi-threaded access. Looper also handles calling local service calls. Local services are ones defined in the same process.

Each process is given it's own user ID. The only processes that run as root as Zygot, runtime, and init. A process has Intents, Services, and ContentProviders among other things. A Service is used to expose some functionality to other applications. To expose data, a ContentProvider is used.

Google IO 2008 Day One

Keynote by Vic Gundotra
3 areas that Google is concentrating on are Client, Connectivity, Cloud.

The client from Google's perspective is the browser. Google Gears is spearheading to improve the browser capabilities. The Gears team is a major contributor in HTML 5.

Alan, Vice President of engineering from myspace showed an interesting usage of Gears by utilizing the local computing power of the PC. When a user with Gears performs a search on myspace, the results are served in realtime by the gears server on the local machine and using it's power and not having to make a trip to myspace's servers. Better experience for the user, lesser load for myspace. This is an interesting usage as Gears was initially designed to solved the disconnected client problem.

Nice to findout that Webkit browser built into android. And, yes it is embeddable into Android applications. When cell applications and bandwidth of the mobile phone industry mature enough, browser will play a major part in how we deploy and run applications on the mobile. Nice to note that google is working on Gears support for Android. Next was an Android demo. Browser, Maps, Notification, Games, built in Compass et al. Can't wait to get my hands on an Android powered phone !!!

Kevin Gibbs the Tech Lead of App Engine gave a talk about the current capabilities of the App Engine platform (checkout my previous blog about App Engine) and the future direction for the project. One of the features that google is working on is offline processing for AppEngine. The ability to import and export data and to perform batch processing. Oh yes, App Engine now supports memcache. Google released a pricing for AppEngine and oh yes, AppEngine is public now. So, go and sign up if you already haven't. But, no Java/Groovy support yet. I spoke to a few Googlers about Java support for AppEngine. As we all know it is in the works. But, they were pretty tight lipped about it.

GWT: Bruce Johnson - Engineering Manager GWT
For me, being able to use GWT on mobile phones is the ultimate. Development in GWT is quite nice but, some things are not as productive as they could be. For example, having to define an interface for each component, using an custom Interface to access resource bundles. After looking at the buttoned down approach that Rails and Grails take for web development, I think GWT will really fly if it supports a scripting language(jvm based obviously) to develop.

Introduction to Android - Jason Chen
Looks like there are 1.1 billion PC based internet users and over 3 billion mobile users. And, most of the mobile market is fragmented with more than a dozen platforms to develop applications on. Jason discussed the android application stack which you can find here.

Anatomy & Physiology of an Android Application
Linux Kernel: Android built on linux kernel but it is not linux. All android specific functionality is built as drivers that run on top of the kernel. Thanks to the power of microkernel architecture. Android has custom linux drivers like Alarm, Ashmem (shared memory), Binder (IPC), low memory killer, power management, kernel debugger and logger modules.

Binder: Reduces IPC(Inter Process Communication) overhead and manages security issues. Uses shared memory (data between applications is shared). Manages per process thread pool. Performs Reference counting and mapping of object references so that shared objects are tracked and cleaned up. It also supports synchronous calling between applications to enable IPC. When process A calls method foo on service stub, binder driver proxies the object and sends it to the service. Since there is no serialization, there is no overhead that is encountered by a typical IPC.

Power Management:
Mobile devices run on battery power which have limited capacity. So, Android builds on linux's power management to manage power better. It does not replace linux power management. Android uses wake locks (partial, full) which expose the platform' power management to the developer. An Application requests a wake lock, PowerManager makes sure that the device is powered on until the application releases the wakelock. Alternative way of implementing wakeness is userActivity which takes a time period and keeps the application processing part of android alive.

Sitting on the linux kernel are libraries written in C++. Like Bionic (the custom libc implementation) Function libraries like Webkit browser, SQLlite and Native libraries like the SurfaceManager. Applications write to surfaces and the surface manager coalesces the different surfaces and outputs it to the frame buffer (display). Audio Manager works similarly. Audio Flinger routes different audios to different audio devices like speaker, headset, ear piece etc.

Hardware Abstraction Library: These are native libraries that sit above the linux kernel. This layer defines APIs for developers to port android to different hardwares.

Android Physiology:
When the Android platform starts, it starts the linux daemons like USB, Debug Bridge etc. It them starts the Zygote process which is basically a template for future processes. Next, it starts the service manager as the default binder. Overall, this talk rocked.

Under the covers of App Engine Datastore - Ryan Barrett

The AppEngine datastore is powered by BigTable. BigTable is basically a sharded sorted array. Supports sort of test and set operations. They call it single row transactions (read-update)

All entities are stored in a single table called Entities table. Entity keys have a field name:value format(hierarchial). The entities table is ordered by key. So, accessing an entity with a key or iterating on adjacent keys is easy. Although, the only way to re-parent an entity is to delete it and re-create it.

Composite Index:
You define the index yourself in index.yaml Or, when the app runs in the dev area, app engine looks at it's queries and creates indices by default. The flip side of auto-index is if a query has not been hit in dev mode, the prod refuses to handle it, and throws an exception. So, run all ur code paths in dev mode.

Transactions: AppEngine datastore supports atleast read-committed using a last committed timestamp embedded into the data.

Oh yes, there was a 4 hour party at the end of the day. Good music, good food and got to network with Geeks and Higher-ups alike.