Category: Android

I have been getting more into Android testing lately, especially for a core library that we use within our team that may be shared across projects and may have different developers modifying it to suit there own needs. Not making sure that every commit doesn’t break the code for someone is a recipe for trouble (and I have been there). To avoid that as much as we can, last week I set up an continuous build environment that can run tests against the core library on every commit.

The parts:

• AWS: There are a bunch of advantages of using AWS, but the biggest advantage is the availability of preconfigured stacks called AMIs that can be deployed immediately on an EC2 instance.
• Jenkins: Jenkins is a pretty popular continuous integration server. Jenkins is deployed as a Java War Its used at other parts of the company too so I can seek help if I get into trouble.
• Github: Github is a very popular code hosting service. We have been using it for a bit and its been very convenient for code that needs to be shared or open sourced.

Steps:

• Select the Bitnami AMI from the AWS marketplace and deploy it on a new EC2 instance
  • The AMI creates a couple of users on the server: A default “bitnami” user and another “tomcat” user thats actually starts up a Tomcat server thats has the Jenkins app deployed.
  • The Bitnami AMI has also created a user named “user” with password “bitnami” that you can use to log in to Jenkins. You can at this point decide how you want new users to be added to the system and who has access permissions.
  • If the deploy works, you should be able to go to the root of your server and see a link to the running instance.
• On the left nav, click on Configure link to set up global configuration for your install
  • Click on plugins and make sure to install / update the Git plugin and the Android plugin
• Under Manage Jenkins  >  Configure System
  • Make sure Ant is set up to download if needed
  • For Android make sure “Automatically install Android if needed” is checked
• Create a new Job and choose “Build a free-style software project” 
• In the configure tab, under the Source Code Management section, choose Git and paste the Github URL for the project.
  • Note this part is a little buggy. The problem that took me way too long to realize is that the Tomcat user doesn’t have Github.com in its list of known hosts. Follow the steps here to fix that.
• On the server, as the Tomcat user, create your ssh keys that you will use to authenticate your pull requests with Github. See Github’s guide for doing that here
• Add the public key in the account for an authorized Github user (May not be a bad idea to create a new Github user just for build purposes)
• Log in to your Jenkins account on the web again and in add your private key against the user account in the user settings section. Conveniently, Jenkins can read ssh keys from the running server but you may need to enable that.
• At this point the system is pretty set up. Now make sure your Android project is set up for testing by following the guide on the Android Developers site. At the end you should have 2 projects: Your main application and a test application. Both will have Ant based build.xml files that you will have Ant on Jenkins run. Commit your projects to Github.
• You can point to the build.xml
  file you want to execute. If there is a build.xml
  at the root of the project that’ll be executed by default.
• You should now be able to build your project explicitly at least. Go to your “Job” and click build now.
• You can then set up automatic builds by going into your project settings on Github and go to > Service Hooks > Jenkins (Git Plugin) and pointing it to your server url.
  

Thats it. Now every time a developer pushes to Github, Github will notify Jenkins, which will pull your repo and run the appropriate build file.

Continue reading “Setting up a continuous build environment for Android with AWS, Jenkins and Github”

One of the most commonly overlooked parts of building Android applications is touch feedback. While some views like Buttons have touch feedback built into them, thats not the case when using custom views.

The Android Design Guidelines explicitly talk about the UX part of touch feedback and it was also discussed a while back on the Android Design In Action YouTube series:

The problem is that there are no clean standard hooks in the Android framework to implement these. The only implementations I have found have been:

• FrameLayouts have a foreground property that can be used
• ViewGroups like the ListView that extend the AbsListView class have a property called “drawSelectorOnTop” that can be used to draw the background selector on top of your custom item renderer.

Given the lack of default apis in most of the common layouts, one approach that you jump to (like I did) was to listen to touch events and change background on touch down  and up. This is hard to implement perfectly because a touch event can be canceled in a bunch of ways. For example, a user may be swiping across your view and you may still end up showing touch feedback which would be wrong. In our app, we often ended up with views stuck in an incorrect state.

The Android framework’s selector system (or rather the StateListDrawable class) handles a bunch of these situations appropriately already. The best approach therefore is to create a selector and the apply that to your view. Setting that selector as your view’s background though will draw that under all the views on top which doesn’t work either. To fix that, the best approach is overriding the dispatchDraw method and then after calling super, calling your new drawable’s draw method within the bounds of the View, something like:

@Override
protected void dispatchDraw(Canvas canvas){
super.dispatchDraw(canvas);
touchFeedbackDrawable.setBounds(0,0,getWidth(), getHeight());
touchFeedbackDrawable.draw(canvas);
}


The one gotcha here is that the base ViewGroup does not invalidate custom drawable invalidated automatically, so this is something you have to do by overriding a different method:

@Override
protected void drawableStateChanged() {
if (touchFeedbackDrawable != null) {
touchFeedbackDrawable.setState(getDrawableState());
invalidate();
}
super.drawableStateChanged();
}

Props to Rich Ratmansky for solving this quirk.

The final result looks something like this:

I have created a sample project to show the experience. You can find the project on Github. This works well, but as you can see it does require a custom ViewGroup class. If anyone from the Android framework team is reading this, having a “touchFeedbackDrawable” property would probably be really useful extension to the framework.

[Update] Had an interesting discussion on this on Google+, whether touch feedback should be shown in a view’s background or foreground. The consensus seems to be background as long as the background is fairly prominent/visible. For opaque content like say images, foreground feedback is pretty much required.

Most developers know about the different ways to specify dimensions of visual elements in Android. While setting dimensions for visual elements is usually done in “device independent pixels”, it is recommended to use “scale independent pixels” (sp) for type. The Android OS provides a setting (under the Display category on stock Android) where users can set the default minimun font size of all applications to small, normal, large or huge, an important accessibility feature for users with poor eyesight. Any text fontSize set in sp’s will scale up or down to respect this setting.

That said, you may want your textView to not scale up or down with the settings. Setting the TextView value to some sp value in the layout.xml file will do that. However if you are setting the text size in code, remember that even if you do read the dimensions from a dimen.xml file with values set in dp, the value returned cannot be used in textView.setTextSize (value) since it will interpret those values as sp’s regardless. To set dp values, use the other setTextSize method that takes an additional parameter: how to interpret the numbers being read.

TL;DR: Use setTextSize(TypedValue.COMPLEX_UNIT_DIP, xx) to set dp values to textviews

I installed the first installable image of Ubuntu Touch for Android devices today, and it was a little tricky since the install instructions seem to assume an audience already running Ubuntu. Either way, I wanted to do a quick review of it but figured a video might do a better job explaining what I was talking about than trying to write em out. The video is embedded below:

The performance of the build isn’t very good but thats expected. I feel the UX is relying a little too heavily on gestures, way too many of them and a lot of “half-gestures” (swipe halfway for action-1 and all the way for action-2). Also the home screen feels too much like an app store and less like a launch board. Pixels wise the UI looks nice and has some nice animations at times (like clicking on a thumbnail of a movie to see the larger image). Will definitely be interesting to see how this evolves.

 

In the last couple of months, a few of my friends have moved to Android from iPhones. Some of them reached out to me on advice on devices and apps they should install on their new phones. The Android app ecosystem is pretty rich and while there are a bunch of apps that can replicate the functionality of iOS apps, there are a lot more that I find interesting because of how they leverage the unique strengths of the Android platform. I won’t mention the basic apps that I use like Foursquare, Flipboard, GroupMe or the Google apps like Maps and GMail that you can pretty much get on either platform. This post lists some of the apps that I use that make me a big fan of the Android platform.

An integrated music experience with Google Music, Last.fm, Gigbeat and LyricsPlayer
One of my favorite parts of Android is how applications interplay with each other. The music experience is a great example of this.

I use Google Music to store my music in the cloud. However I have a bunch of applications that listen to song events and provide different functionality when a song is playing. For example take a look at my notification shade when I have a song playing:
I can control song playback right from the notification shade (Rich Notifications ftw). Additionally, as I play a song, Last.fm scrobbles the song to my Last.fm account. Additionally the LyricsPlayer app offers me a one click link to the lyrics of the song currently playing while Gigbeat searches for upcoming tour dates for the artist.

The photo experience with Panoramas, Photospheres and Instant Uploads
I really love the Android camera app, it was fine before but the recent addition of PhotoSpheres has me completely hooked. I feel it captures the essence of an event or a location so much more. Take a look at my PhotoSphere of the Venetian hotel in Las Vegas when I was there recently for CES (click on the image for the PhotoSphere).
Again, like music playback, taking photos sends a system level event in Android. This enables apps like Dropbox and Google+ to allow instant photo upload services that are pretty useful. I haven’t manually uploaded pictures from my device in ages. Whenever I am ready to share my pictures or view them on a different device, they are just there.
The official Flickr app for Android is pretty mediocre but if you use Flickr, Glimmr for Flickr is an excellent replacement.

AddressBook extensions with LinkedIn, Last.fm and HaxSync
The Android address book (recently renamed to the People App) is really remarkable. It allows applications to annotate user data on the address book with additional information. For example, the LinkedIn application automatically sets a contact’s most recent job title right in the Contact details view. Similarly Last.fm synchronizes your contacts with their Last.fm profiles.

The people app also allows applications to publish recent status updates right to the app that is available in the contact details as well. This feature is kinda nice, though its a little buried so I don’t use it as much. There are a couple of apps on the Play Store like Current Caller Id that show contact social updates when they call, but they don’t tap into the contact app data. Hopefully the native dialer app will use this data in a future version of the OS. Android doesn’t come with native Facebook or Twitter integration, but you can get Facebook updates in your People app using HaxSync.

Managing files with Astro FileManager, AirDroid and DropSync
A big difference between Android and iOS is that Android devices do let you browse the local file system as well as create folders and files there like a regular computer. You can browse the folders on your PC when the device is connected, but you can also use apps like Astro File Manager to browse the local file system. Another pretty useful app to browse your phone’s content is AirDroid that lets you connect to your device wirelessly as well. The biggest thing I use local file systems for is for auto syncing certain folders among my different devices via Dropbox using DropSync. For example, I have one “Wallpaper” folder that syncs across my Mac, tablet and phone. A different app, the Wallpaper changer, then automatically swaps out my wallpapers once every few hours (again, unlike iOS, Android has a wallpaper api). I also have a dropbox folder called currently-reading that has a bunch of pdfs that sync with a folder my pdf-reader app uses as a source for readable files.

Other notable mentions:

Location based information with FieldTrip: Love this app, it indexes a bunch of news and information against location points and shows them when you are around. I use it more when I am traveling to find random interesting trivia.

Twitter with Tweetdeck or Falcon: Falcon is the new kid on the block for Android Twitter clients, and its pretty nicely done, but I am still stuck on Tweetdeck for Android even though it hasn’t been updated in ages. The fact that it polls for Twitter data in the background means I never have to hit “load” on the app. Its pretty nice and minimal.

Managing Podcasts with DoggCatcher: Lots of features and no need to sync to a device. Never had any trouble with it.

Browser: Chrome / Firefox: I like Chrome on my phone but lately have been trying Firefox and it almost seems faster than Chrome at times. I feel the Firefox UI has a little bigger tappable buttons so it seems a little easier to use, it also has a sync across devices feature and allows for plugins!

Keyboard: I am currently running Swiftkey Beta for Android. Its really well done and I do enjoy using it. Additionally I have been using Google voice a lot for dictation and it works surprisingly well. Bonus points for it working offline.

Google Now is neat

The DoubleTwist Alarm app is my default alarm app. It has some nice features like power nap alarms, etc but I like it mostly for the UI.

Thats most of my suggestions. Let me know if there are any other apps that you use that you find really interesting.

In my previous post, I had written a bit about creating custom Layouts for Android. However to make a truly reusable layout there are a few more things we’d probably need:

1. Some unique properties that you may want to assign to it via XML (Like LinearLayout has an orientation property unique to it)
2. Custom LayoutParams object that you can assign to the children of the Layout to assign them properties that the layout can inspect when its laying the children out.
3. For bonus points, package this container in an external library project so you can reuse the class in a bunch of projects (this will also force you to write truly decoupled code)

Creating custom properties:

Since most often we use XML to define our layouts, it makes sense that we would like to assign configuration properties in the XML file as well. The way you do this is by creating a bunch of declare-styleable nodes in your /res/values/attr.xml file. For example:

<resources>
    <declare-styleablename="MyCustomLayout">
        <attrname="mynewproperty"format="string"/>
        <attr name="mynewproperty2" format="string"/>
    </declare-styleable>
</resources>

The name property of the declare-stylable node should reflect the class-name of your custom View/ViewGroup. The attr node inside references the actual property you are trying to create, You can create a bunch of these properties here. The format of the property can be of the following types:

• reference
• string
• color
• dimension
• boolean
• integer
• float
• fraction
• enum
• flag

Once you have created the declare-stylable, you have to ensure that those values are visible from the XML document. This is done by adding a new namespace to your application. For example

<com.arpitonline.flint.containers.MyCustomLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:arpitonline="http://schemas.android.com/apk/res/com.arpitonline.mycoolapp"
... >

The new namespace is just your application package appended to the end of “http://schemas.android.com/apk/res/”. Now any property specified there will be retrievable in the constructor of your custom Layout which you can retrieve like so:

public MyCustomLayout(Context context, AttributeSet attrs) {
     super(context, attrs);

     TypedArray arr = context.obtainStyledAttributes(attrs, R.styleable.MyCustomLayout);
     CharSequence o = arr.getString(R.styleable.MyCustomLayout_mynewproperty);

          // do something here with your custom property     

     arr.recycle();
}

Note that its good practice to have getters and setters for the property that you are assigning via XML so that the layout can be instantiated just as completely via code. The method described above can be used as is for custom Views as well. For a more detailed explanation see this link.

Creating Custom LayoutParams

As you create custom layouts, you may want to assign properties to the children that the layout may contain. For example, RelativeLayout has properties like layout_centerHorizontally etc that aren’t relevant for children of LinearLayout ViewGroups.

First, you need to create the attributes in the declare-stylable nodes just as mentioned in step 1 usually with the convention MyCustomLayout_LayoutParams. These will be read by your custom LayoutParams object and kept as properties.

The next step is to create a public inner class named (by convention) LayoutParams that extends ViewGroup.LayoutParams. Additionally in the main ViewGroup class, you have to override 3 methods:

1. public ViewGroup.LayoutParams generateLayoutParams(AttributeSet attrs)
2. protected boolean checkLayoutParams(ViewGroup.LayoutParams p);
3. protected ViewGroup.LayoutParams generateDefaultLayoutParams ()

The way this works is if there are custom layout attributes in the children, you get the attributes when the framework calls generateLayoutParams method and its up to you to generate the LayoutParams object based on the values coming in and return it.

Once that is done, there is a call made to checkLayoutParams which seems to give you one last chance to see if the object you created is something you still want to use to determine layout information. This can be done by looking at the class of the LayoutParams object for example. If you return false here, your generateDefaultLayoutParams method will get called which should return a default layout object that you can use anyway.

The layoutparams object will now be magically available during your onLayout pass and can be looked up by calling the view.getLayoutParams() method which you can then use to size and position that particular view.

External Library Projects

Its convenient to package all your custom code in an external Library Project that your app can reference. Doing so is easy, just create a new Android application and check the isLibrary checkbox in the wizard. Then add the library project to your project by right clicking on your application project and going to Preferences > Android screen and clicking the Add… button.

Note that for a long time it wasn’t possible to add custom attrs in Library Projects, this was fixed in SDK 11

The only gotcha here is that everything you have done in your library project may be in the namespace of your library project but when referencing it in your main application, they are referenced with the namespace of the main application project.

I have started a new project on Github where I’ll post some custom layouts/classes that may be helpful. Its pretty early right now but you can see the above code in action at least at the repository.

One of the most common techniques for animations (regardless of UI technology, Flash, iOS or Android) is to animate a Bitmap of the view being manipulated rather than the actual view itself since animating the view requires moving all subviews and for animations that distort the view dimensions, may cause expensive reflow of the internal components, not to mention the weird glitches as the internal components resize or reflow.

The core animation engines in both iOS and Android do this work for you themselves. When an object is animated, its only its drawing layer that gets moved. Thats why in Android, if you dont call setFillAfter(true) for an animation, the position of the View as Android understands it and its display on the screen diverge and buttons etc become unclickable. In the new Android animation framework introduced in HoneyComb, the animation framework even includes a withLayer() option that is advisable to use that draws the bitmap to a hardware accelerated layer and moves that which would perform better than the software option.

But grabbing the Bitmap of a View has other uses as well (like modifying photographs, taking screenshots of interesting points in a game etc). Here are 2 ways of doing that.

Method 1:

A View can actually draw itself on any instance of a Canvas class (usually at the end of the measurement and layout process, it draws itself onto a Canvas instance that is internal to the View class). So you can pass it a fresh instance of a Canvas thats constructed off a Bitmap object that you created like so:

	Bitmap b = Bitmap.createBitmap(targetView.getWidth(),
				       targetView.getHeight(),
				       Bitmap.Config.ARGB_8888);
	Canvas c = new Canvas(b);
	targetView.draw(c);
	BitmapDrawable d = new BitmapDrawable(getResources(), b);
	canvasView.setBackgroundDrawable(d);

Method 2:

This way was mentioned in a couple of posts I read, but there is a gotcha. This involves getting a Views drawingCache which is a Views own reference to its bitmap. Note that drawingCaches aren’t always available and so you may need to actually have the View generate it. You can do this by either setting setDrawingCacheEnabled(true) on the View or manually calling View.buildDrawingCache() and then using the Bitmap generated in the same way as previously mentioned. The gotcha I found was that the generated bitmap can be disposed without your knowledge. Since its recommended that calling the buildDrawingCache should be matched with a destroyDrawingCache(), you have to copy that bitmap data into a bitmap you own.

    targetView.buildDrawingCache();
   	Bitmap b1 = targetView.getDrawingCache();
   	// copy this bitmap otherwise distroying the cache will destroy
   	// the bitmap for the referencing drawable and you'll not
   	// get the captured view
   	Bitmap b = b1.copy(Bitmap.Config.ARGB_8888, false);
   	BitmapDrawable d = new BitmapDrawable(b);
   	canvasView.setBackgroundDrawable(d);
   	targetView.destroyDrawingCache();

The code for this project is on Github as well. Since I am only getting into this aspect of Android, let me know if I there is a better way to do this.

There are a lot of great articles on Android development on the web but one field that doesn’t feel explored enough is creating custom Layouts. For one thing, the Android framework does spoil you with a bunch of layouts that usually fit most of the usually designed interfaces. The problem comes when faced with slightly unconventional UIs. A basic knowledge of how layouts work may help you avoid creating a mess of nested layouts when a quick custom one may have sufficed. The design below for example was accomplished with one custom layout object.

I have to admit I am not a fan of some fundamental choices made on the UI architecture side. For one thing Layouts are Views (or more specifically ViewGroups) themselves and not only position and size the elements they are supposed to but also add them as children to themselves. This means that if you wanted to create an experience where you maybe started with a grid of photos and when the user clicks on one of them, lay the photos out in a row, you can’t really do that well since the photos have to be unparented from one View (the GridLayout) and then added as children to another. And don’t hope for any animations in between. In the coming months I hope to create an open source project for some custom layouts that separated a views parent from its layout (Adobe Flex went the same route between Flex 3 and Flex 4. Flex 3 had HBoxes, VBoxes etc but were deprecated in Flex 4 with Spark Layouts that could be attached dynamically. If you are a Flex software engineer, the Android architecture will look very familiar).

But this post explains the layout architecture as is. So lets begin. The attached code blocks are from a custom Layout example I wrote and is available on Github. Its a very simplistic LinearLayout that sizes its children equally. You can grab the github project here.

The base class for a Layout is a ViewGroup that basically extends a View and has hooks for things like addView etc. To create a custom ViewGroup, the only method you need to override is onLayout. The onLayout is triggered after the ViewGroup itself has finished laying itself out inside its own container ViewGroup and is now responsible for laying out its children. It should call the layout method on all of its children to now position and size them (the left and top parameters will determine the child view’s x and y and the right and bottom will determine its width (right – left) and height (top-bottom).

@Override
protected void onLayout(boolean changed, int l, int t, int r, int b) {
     int itemWidth = (r-l)/getChildCount();
     for(int i=0; i< this.getChildCount(); i++){
         View v = getChildAt(i);
	 v.layout(itemWidth*i, t, (i+1)*itemWidth, b);
         v.layout(itemWidth*i, 0, (i+1)*itemWidth, b-t); (Fixed bug mentioned by Nathaniel Wolf in the comments below)
     }
}

One thing to note is that at this point you are playing at the pixel level and not with the pixel abstraction units like dips. But besides that you should be fine.

The problem here is that while this will layout any simple views (i.e. Views that aren’t layouts themselves), any child layout objects aren’t visible at all. This is because the child layouts have no idea till that time how they should lay out their own children since they haven’t been measured at all and return a measured width and height of 0. To do a layout correctly, you need to make sure that you also override the onMeasure method in your layout and call the measure method on each of your children appropriately.

During measure, you need to first calculate your own measuredWidth and measuredHeight and then based on that tell your children how they need to size themselves. For example a horizontal LinearLayout might say “My measuredWidth is 100 plxels and I have two children so each must measure exactly 50 pixels. This it would do my passing a MeasureSpec object which defines how the child should interpret the measurement its receiving: either EXACTLY, AT MOST or UNSPECIFIED. The child view then uses those cues to create its own measuredWidth and measuredHeight (by usually calling setMeasuredDimension at some point in the onMeasure).

@Override

protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec){

     //At this time we need to call setMeasuredDimensions(). Lets just 
     //call the parent View's method 
     //(see https://github.com/android/platform_frameworks_base/blob/master/core/java/android/view/View.java) 
     //that does:
     //setMeasuredDimension(getDefaultSize(
     //                       getSuggestedMinimumWidth(), widthMeasureSpec),
     //                    getDefaultSize(
     //                       getSuggestedMinimumHeight(), heightMeasureSpec));
     //		

      super.onMeasure(widthMeasureSpec, heightMeasureSpec);
      int wspec = MeasureSpec.makeMeasureSpec(
                  getMeasuredWidth()/getChildCount(), MeasureSpec.EXACTLY);
      int hspec = MeasureSpec.makeMeasureSpec(
                  getMeasuredHeight(), MeasureSpec.EXACTLY);
      for(int i=0; i<getChildCount(); i++){
         View v = getChildAt(i);
         v.measure(wspec, hspec);
      }
}

Note that the measuredWidth and measuredHeight are cues for the parent layout when its laying out the children. It might still decide to ignore the measured width and height and lay them out as it feels since its up to it to define the left, right, top, bottom values during onLayout but a good citizen of the layout world will probably not ignore them.

Also I am just getting into this so I may have missed something so please drop me a comment or let me know on Google+ and we can have a discussion.

[Update 1] I have written an extension to this post that includes adding custom attibutes and layoutparams to your layout class

[Update 2] Great talk on this topic from Google I/O 2013

For the last few months I have been doing quite a bit of work on the Android platform. Its no secret that I am a big fan of the Android OS both technically and philosophically. Needless to say, I was really excited to be able to attend AnDevCon III conference earlier this month for both the opportunity to learn some new things about the framework as well as interacting with some of the stars of the developer community. The event, held in Burlingame (SF), did not disappoint. It was amazing to meet folks like Chet Haase, Romain Guy, Jake Wharton, Mark Murphy, etc and hear them speak as well as meet some awesome local devs doing amazing work (and thanks to Twitter, I can stalk them forever 😉 ).

I took a bunch of notes which are available in their very raw form on my shared Evernote Notebook here. While most of the sessions were pretty good, some of the more memorable ones are listed below:

• Romain Guy and Chet Haase‘s talk on best practices for Android UI was probably the most educational giving me a bunch of tips on improving some of my apps’ behavior.
• Chiu-Ki Chan‘s talk on Android Custom Components was probably the one that I was most desperately looking for. The talk was fantastic and we hit it off pretty well. She is a coding machine and already has another app out there on the Sony Smartwatch she won there.
• Kirill Grouchnikov‘s talk on Responsive Mobile Design for Android was great and laid out some great tips on how to create screen-size aware interfaces for Android applications.
• Mark Murphy‘s talk on App Integration was very eye opening. I was already pretty aware of the Android Intent system that allowed data to flow between applications seamlessly, but he laid out a bunch of other ways apps can be integrated with each other, like sending the complete UI to another app using Remote Views, app plugins etc. Also I didn’t realize Mark was a local guy, so maybe we can coerce him to coming to one of the Android group’s talks in the near future.
• Jake Wharton gave a great talk on his libraries. The guy is a celebrity in Android circles and I already use his ActionBarSherlock library on some projects but I didn’t realize he had ported Android 3.0’s animation system to work on pre-HoneyComb devices as well via his NineOldAndroids library (Very useful for my current project). His other projects like ViewPagerIndicator and HanselAndGretel were pretty cool as well.
• Blake Meike‘s talk on Concurrency in Android was probably the most packed session besides the official Google talks. Listening to his talk I realized how little attention I had been paying to possible concurrency issues in some of my apps. There was great back and forth with the audience in the session on a bunch of details on Android application lifecycle.
• Aleksandar Gargenta‘s talk on Android Services and how IPC works across the Android system at the lowest level was fascinating. While I don’t see myself ever writing or needing to know the details of the lowest level Android services, it gave me a lot better understanding of what Android/Linux is doing when different actions are performed.
• Joshua Jamison gave a great talk on Advanced Design Implementation with some very usable tips on faithfully translating designs to Android applications.

Besides the talks, I really loved the HTC and the Barnes and Noble keynotes. HTC is doing some amazing work with their phones and very carefully navigating the waters of adding functionality to their line of phones and avoiding fragmentation by creating a set of apis only for their phones that differ very slightly in functionality from the core Android OS. The entire HTC keynote was broadcasted to the projector from their phone. They also introduced the new APIs in the latest iteration of Sense including LockScreen, Beats Audio and Video call APIs. B&N gave some rather interesting statistics on the Nook audience, like having over 85% of their audience be women. Android has had a notoriously hard time appealing to women so this statistic was interesting. The Nook marketplace is also apparently very profitable, which I seem to have heard from some other devs there as well (so it wasn’t just PR), though the conspiracy theorists attribute that to their curated market being fairly small. Their talk on thinking of apps as content (like books) was pretty good. Though the best part may have been winning the Sony Smartwatch draw at the end of the conference. The watch actually has a very interesting architecture with most of the user interface generated on the paired mobile phone and the watch itself being just a dumb screen. I hope I get some time to play with the SDK soon.

I missed most of the after event parties since I had a truckload of work to do for a project due the immediate next week (I was sneaking off to write iOS code which is kinda ironic), but did make it a point to attend Square’s dessert bash. In my book they also won the award for best schwag t-shirt ever.

P.S: My friend and fellow Android Alliance organizer Chuck Greb has already posted his notes from the event on his blog.