Shared publicly  - 
 
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 http://www.pushing-pixels.org/category/android 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.
39
19
Qoyum Nasri's profile photoMykola Kondratenko's profile photoPittaya Sroilong's profile photopawan kumar's profile photo
13 comments
 
A comment on the new market, I faced issues downloading one of the games that I had bought, flight Control. The download was 27MB in size, it would seemingly complete downloading but error out with a "There is insufficient space on your device" error. This didn't make sense as I had over 1.5 GB of space left on my Galaxy S. I later found that this was due to low space in the cache volume. I followed the recommendation to uninstall the update to Market and used the original market that came with my ROM to complete the download successfully.
 
++LONG POST AHEAD++ (summary at the end)

I understand "officially supported" UI libs are not easy to mantain, but why won't you (the Market team) just open source selected UI widgets, code snippets and such? Even a no-warranties, dump-as-is can do the trick if you're trying to replicate some of the Market UI/UX in your app. It's then of course up to the dev himself (or the community, if someone adopts the code) to make sure it works on its target devices just the way he wants/needs to.
Also, and here I'm asking something more abstract, why don't you guys at Google try to stick to the same UI guidelines? Each and every new app (or even app version!) Google releases for Android has different UI/UX conventions, sometimes even going against what are the (vague) public Android UI/UX guidelines.
My idea is that you guys and your designers should work in a more coordinated fashion. Once you've made up your mind, you should tell us, Android devs, what we should do, provide clear and strict guidelines, and most importantly, provide us all the widgets/samples we need to correctly implement them. This should not be an overly difficult task, anyway, since you at that point should already have written them to adhere to those guidelines yourself.

++ tl;dr ++
Create strict guidelines, use them yourself, provide us code to do the same.
 
I agree 100% with +Sebastiano Poggi. Applications do not need to look identical, but some consistency would be nice.
The Market version that is currently being distributed is an example of such. I'm not exactly sure if it's a bug or a 'feature', but the indicator for the ViewPager has changed. There is no longer a line between the indicator and the View with a thicker line for the current View. If this was done on purpose, does that mean the line will also disappear in the Google+ application? If this was done on purpose, was this done because of speed considerations, or because the indicator widget isn't available as core widget?
 
+Dirk Hollweg well, yes and no. I mean, it's a huge step forward, and I love it (can't wait for my Galaxy Nexus to be shipped!). But, and that's a huge but, it doesn't solve all the UI consistency issues in third-party apps (heck, you can even get the old 2.x look in it if you explicitly use Theme or Theme.Light instead of Theme.Holo.*), nor the ones in Google's own "aftermarket" apps. On this matter, see: http://minming.posterous.com/google-currents-yet-another-contribution-to-t (I know some of those claims are wrong or solved in ICS, but most still are there).
After Google has merged all of its UI/UX patterns in a consistent one in its own apps, it needs to enhance Android documentation (while not dropping the previous versions like it's constantly doing with each update). And then, ease developers work, by providing the code for all and each of the widgets/techniques cited in guidelines - or nobody will bother following them, since it'd be too much of an hassle.
 
I really dont understand the new Market Layout. In Maps there is this menu for Places, Nav, etc. Why dont you use this type of menu for my apps in Market.
 
The implementation of the pager view in the Honeycomb version of the market is broken. At the top of the Market home area, is a scrolling banner of highlighted apps. If you swipe your finger left/right to view the next item, you will skip two full items. Landing on a desired banner is quite challenging.

Also, you still can't buy music from the Honeycomb Market. "What's up with that?"
~ Jerry Seinfeld
 
Developing endless list view (one that loads and appends the next portion of items when scrolling to its end) is one of the most challenging tasks during the development of Android REST client applications. I have found two libraries simplifying the development of such a component but both have their drawbacks.

1) https://github.com/commonsguy/cwac-endless
One of the problems with this approach is that loading of new items is called from the method Adapter#getView(int, View, ViewGroup) that can be called by Android OS when you don't expect it to be called.
Another problem is that AppendTask loading new items in the background is an inner class and after orientation change it indirectly references the destroyed activity instance thus it is not able to update the UI of the new activity instance. The new Loader API introduced in Android 3.0 Honeycomb have been designed to solve this problem. And the next library makes use of it.

2) http://code.google.com/p/libs-for-android/wiki/FeedFramework
The problem with this library is that changing orientation during the loading of next portion of items leads to disappearing of old items and displaying of ProgressBar in the center of the screen.

But the endless list view functionality is the piece of such Google applications as Gmail client, Market client and Google+ client. It will be very good if you provide the endless list view as reusable component. It will speed up the development of Android REST client applications dramatically.
 
I agree. Currently implementing endless lists is a pain in the ass, because you have to write your Adapter that can dynamically request new items to the underlying service, etc. This is the classic example of where having one of Google's already tested implementations would do miracles.

EDIT: you know what else could do miracles? A working implementation of a two levels ram/file cache, and an ImageView that can rely on it (kinda like GreenDroid's AsyncImageView)
 
Sure, having an image loader component that can asynchronously load remote images and set them to ImageViews making use of thread pooling and two-level caching would be a big plus. Although there are some implementations such as already mentioned GreenDroid's AsyncImageView and http://code.google.com/p/libs-for-android/wiki/ImageLoader it is desired to have this functionality in the standard Android SDK. Hoping to see it in the next release of the Android platform.
 
I'd actually hope to see them coming in the compatibility library or some other library, and have them compatible with Android 2.2+, so that we don't need to get crazy implementing them...
 
On an older phone, the new market is still unpleasantly slow compared to the old one, even after the noticeable performance improvements after it launched.
 
+Jagannath Moorthy I had the same problem while downloading 'Cordy' from the Android Market and I proceeded to do the same thing that you did, by rolling back to the older version that came pre-installed on the device and then it magically worked. Strangely, it only gave me that error for that one app while other big apps were downloaded just fine.
Add a comment...