Last Saturday marked the one-year anniversary of release 2.3 of Android Market client, aka "The Green Goblin". It brought a number of UI restylings, with swooshes, carousels, curved tabs and more. After a gap of more than half a year, we released a completely redesigned (and reimplemented pretty much from scratch) client in mid summer, quickly followed by a number of improvements in features, device support, styling and performance - with many more to come in 2012.

I mentioned a useless bit of trivia related to the internal codenames of 2.* branches, starting with Frootloop, going back to Elephant and forward to Granola. We never got to an H, and the strongest candidate at that point was HoHo. I also had a chance to give a nickname to the implementation of the new swooshy green restyling. I always wanted to use Velvet for one of my side projects, but the right opportunity never presented itself. And so Granola, aka The Green Goblin aka Velvet aka Market 2.3.6 was the end of the line for app-only Market client.

A few people asked me about providing some of the pieces of the Market client (2.3 and 3.*) as reusable components. I won't shy away from talking about the what, the why and the how - and you can go to to see detailed explanations of most of the UI pieces of both versions. However, that is quite different from providing, maintaining and enhancing an officially supported component library.

Defining an API surface of a modern UI toolkit is a delicate exercise, which is left to people who actually know what they're doing. As an application developer, my job is much easier if I can just point my finger at an existing core component, wire it to the data source, set a few styling properties and be done. However, as we're moving into a world of richer layouts, skinning and interactions, the expectations from UI toolkits are growing at an alarming rate. This has a number of unwieldy side effects, as every new API and property are expected to interact smoothly and seamlessly with all the existing ones, placing ever more burden on design, implementation, testing and maintenance.

If you're an application developer, the capabilities of core widgets should not necessarily restrain your designs (but rather provide a general best practices route). Extending a core layout, or even writing your own one that addresses a very narrow requirement from your UX designers is not the end of the world. Furthermore, there is no need to start thinking about making that layout into an omnipotent beast. Start small, and progressively iterate, enhance and combine only if you see that there is a real similarity or overlap between multiple pieces of your application.

Expecting the core widget set to address every single design is unrealistic, unproductive and, at times, even counter-productive if it will reinforce the usage of patterns that will have proven to be inadequate in the long run. Once a UI toolkit is pixel-complete - allowing you to have control over every single pixel if you wish to - it has to be flexible enough so that once you know its best practices and limitations, you can bend it at will.

This, of course, does not mean that the core widget set is not evolving. The excellent ViewPager class available in the compatibility library is a veritable treasure trove for applications that wish to take advantage of one of the strongest design patterns that has emerged in Android UX in 2011, and it continues its evolution as more internal and external applications switch to use it for tabbed navigations. Some of you will be quite happy to see its new capabilities, indirectly influenced by switching Market client to use ViewPager in our latest release.
Shared publiclyView activity