Android code generation

I started looking more seriously into Android development, especially after a great training session with Mark Murphy organized by Chicago Android. Right now I am experimenting with simple user interfaces (buttons, lists, etc) and learning how to utilize various phone’s sensors.

What’s caught my attention is the way Android’s build tools generate code. The layout for activities, templates, styles and controls is defined in XML files. These are then parsed at build time to extract the IDs, which then become available off the generated “R” class. The layout is “inflated” at runtime given a numeric ID. That’s also how one can get a reference to UI elements.

The use of XML files for UI layout is not unique to Android. In the past I used Glade, Mozilla’s XUL and Microsoft’s XAML. Lately especially I’ve been playing XAML. It was a surprise to me that pretty much every single Java sample contains code like this:

Seems very repetitive and a lot of silly code to write. Tooling for other frameworks take slightly different approaches. In XAML there is a special namespace used by the XAML parser that allows the user to specify a name for the class member referencing the layout element. For example:

results in creation of member variable “ClearButton” in the class “MyCoolWindow” of “MySample” namespace. No need for getting view elements by id and for casting. I’m wondering why can’t something like this be done for Android?

I obviously am not even pretending to know anything Android, so I am asking you the experts =)
Is there any technical reason against it?

C# has a concept of partial classes (one class spanning multiple source files), so it’s easy to just stick the generated code into its own file. Java’s philosophy is different: why span multiple files? Just create multiple classes. Seems like it shouldn’t be that difficult.

One could come up with an XML schema for specifying the name (like in XAML). XML allows decorating elements with multiple attributes, so it would work. Or, alternatively, the name specified in android:id could be used, but I think it needs to be unique for all IDs. Specifying a name per class could be more desirable.
Please see a mockup file below:

A custom pre-processor tool could be written that would parse the XML files and create a new class for each of them – say “LayoutXyzHelper”. These helpers would perform all the findViewById() during construction and expose all desired controls as member variables. A generated helper class for the XML layout above could look like this:

The usage would be to construct the layout helper and save it as a “ui” member variable.

Well, what do you think? Does this sound like a good open-source project idea? Or am I missing something obvious due to my lack of Android experience? Maybe this has already been done?
Either case, please let me know.

Async Patterns with C# – Handling Requests

This is a continuation of my earlier blog post regarding asynchronous operations in .NET. We are now going to discuss the various ways of issuing and receiving results from asynchronous requests.

There are three main ways of issuing an asynchronous request and later receiving the result. They are described in the sections below.

Callback methods

The pattern of specifying a callback method goes way, way back. And it is still being widely used today. The idea is simple:

  • Call a method that starts an asynchronous operation
    • Pass in a delegate to the function you want called when the operation completes
    • Optionally specify user data
  • The specified callback methods gets called asynchronously. The arguments passed to it usually contain:
    • The result of async operation
    • Error indication (Exception object or error code)
    • User data

Depending on the needs the callback method could be a simple delegate or an interface.


The approach of passing delegates is convenient, because one could easily take advantage of closures/lambdas. That way objects in scope become available to the “callback” method.

A main disadvantage would be that it is difficult to “cancel” the asynchronous operation. There also is no “identity” to the operation (unless we consider the pair <delegate, user data>).

Although there are no technical reasons, in practice only 1 delegate gets passed as a callback.


When viewed simply as “collections of methods,” interfaces could be considered a special case of “callbacks” or, as Java folks like to call them, listeners. In Java it is convenient to pass interfaces to receive callbacks, because Java allows for creation of inline anonymous classes. This is unfortunately not the case for C#, which is why the “request object” is a more interesting pattern for the .NET crowd. More on that in the next section.

Since interfaces represent concrete objects, they do have identities. This could allow for “cancelling” async requests by passing the same observer instance that was used when making the request.

Request objects

This is a very common pattern that most coders are familiar with. The premise is simple:

  • Create an object representing the asynchronous operation
  • Optionally set properties on the request object, for instance store some user data.
  • Hookup the event handler (or handlers).
  • Call a method starting the asynchronous action.
  • Receive the event with results. Extract the information from event arguments.

The main advantage of using the request object is that the object itself is responsible for emitting the events signaling the completion/failure of the async operation. In other words, the “sender” passed to the event handling function is the request. Users can store custom data with the request and easily get to it from the handler. This could be accomplished via composition (for example by having a Tag property), or by inheritance (by allowing the users to extend the request object).
Depending on the needs, the request object can have multiple events. For instance, one for signaling completion, and one errors.
The request object could also optionally provide a “Cancel” method that would stop the asynchronous action, or at least prevent the events from being fired.

Once can classify the request objects depending on how they are created, and who actually starts the asynchronous operation. Several main categories are briefly described below.

Self-created, self-submitting

The user can create the request object by calling its constructor directly. The method starting the async action is off the request object itself.
This variation of the pattern is convenient as it could allow for extending the request object through inheritance.

Factory-created, self-submitting

The user creates the request object by calling a factory method. Typically the factory is some kind of main “API” object that contains multiple operations. Once created, the request object is self-sufficient and can be “submitted” using its own method.
Since the request is constructed by a factory, it usually means that extending the request object is not allowed.

Self-created, factory-submitted

The user is able to create the request object by calling its constructor. This could potentially allow for inheritance scenarios.
Asynchronous action is started by calling a method on another object, which usually ends up being the main “API” object.

Hybrid – BeginInvoke/EndInvoke

The pattern of BeginInvoke/EndInvoke that is build into the .NET framework can be seen as a hybrid of callback method and request object. The usage is a follows:

  • Call a “BeginInvoke” method to start an async operation
    • The method accepts a callback delegate and user data.
    • The return of the method is an IAsyncResult instance that the caller needs to hold on to
  • IAsyncResult could be used to wait until async operation completes and to cancel it.
  • When the callback function gets called
    • Call “EndInvoke” and pass it the IAsyncResult instance acquired from the “BeginInvoke”
    • The “EndResult” will return the “outcome” of the async operation.

Async patterns with C#

Lately I have been doing a lot of asynchronous development. At work I’m designing a trading API that is very asynchronous in nature, and in my spare time I have been messing around with Silverlight.

I would like to share a few different patterns for retrieving data asynchronously that I have encountered. Hopefully my blog posts will be a good resource for you.