Google rolls out Honeycomb SDK for Android tablets

Google has released the full software development kit for Honeycomb, the tablet-friendly version 3.0 of its Android operating system.

In a blog post on Tuesday, Android SDK tech lead Xavier Ducrohet wrote that the release made it possible for developers to create applications for the new platform and publish them to the Android Market.

Honeycomb looks quite different to other versions of Android, as it is designed for use on larger screens than those present on smartphones. The new SDK makes it easier to manage screen space usage and the kinds of gestures that people will use on tablets such as the Motorola Xoom, which will be the first Honeycomb-bearing tablet to hit the market.

Read more of "Google rolls out Honeycomb SDK for Android tablets" at ZDNet UK.

Why .NET developers should check out the await system

Jason Rainwater, a C# and WPF expert, spoke at the Columbia Enterprise Developer Guild meeting in early February about asynchronous programming in .NET. He gave a good history of asynchronous programming in .NET, and showed off a class called WorkerQueue that makes it pretty easy to asynchronously run code that interacts with the UI thread (historically, this has been an annoyance). He finished his presentation with something that I've been paying attention to lately: the new await keyword in the Async CTP and scheduled for C# 5.

The new await system is interesting because it allows you to run code that does not block the main UI thread, but at the same time can update the main UI thread. For anyone who has messed around with systems like BackgroundWorker, you know this is a real headache. And because the structure is built on Tasks (from .NET 4's Parallel Extensions Library), you get access to built-in functionality such as cancellation.

It's pretty easy to use the await system. If you want a method to run asynchronously, you mark it with the async keyword after its scope declaration, and you make at least one call within it using the await keyword. When you use await, it must be to a method that supports it. Out of the box, you get a couple of simple methods (such as WebClient.DownloadStringAsync) that support await. The method that is asynchronous can return void, Task, or Task<TResult>. If you choose to return a result using Task<TResult>, the compiler will do it automatically for you.

Here's a code sample:

private async void AsyncMethod() {
mainWindow.Control.Property = await GetDataAsync();
}

This code assumes you've made a GetDataAsync() method that supports await. When the awaitcall is run, it checks to see if the GetDataAsync method has a result yet (remember, it uses Task under the hood). If the GetDataAsync method has a result, it returns it and keeps moving. If the GetDataAsync method doesn't have a result, it essentially allows control to return to the UI thread, keeping the application responsive, while the work is performed in a separate thread. There is a lot more to the details than what I've summarized, but it's enough to know that your application can keep running.

Something very important to keep in mind is that all of the code you have written runs in the UI thread, but it gets called via a "continuation" by the Task when it completes. Essentially, this is a good replacement for BackgroundWorker for certain scenarios.

The pattern's value The pattern makes it easier to write asynchronous code, so processes that can take up time no longer jam up the application's UI. In the past, you needed to either home brew something with delegates or Thread, use BackgroundWorker (which was not a pretty pattern), or work with Tasks or lambdas. None of those options addressed the issue of UI updates, which required the BeginInvoke system because you can't modify data in one thread from another. In this pattern, all of your code is running in the UI thread, so you don't have the issues with UI updates. In addition, none of your code is running concurrently, which eliminates the data integrity issues (deadlocks, race conditions) typically associated with concurrency.

Caution:
Because all of your code is running on the UI thread, if your async method takes up a lot of time outside of the await-ed call, you lose your benefits pretty quickly. Keep your work in the async method as minimal as possible, and the UI will show no slowdowns.

Summary 
If you are doing things that are CPU bound, you should use proper parallel processing; this is not a replacement for that approach. But if you have something that is I/O bound, await is a great way to handle it.

I look forward to getting to work with await in a final form, and I think that it will be a great benefit to .NET developers.

Sencha Touch 1.1 Release with BlackBerry Support

Today we’re excited to announce the release of Sencha Touch 1.1, which includes BlackBerry 6 support, new list features, new demos, and other enhancements.

BlackBerry 6+ Support

With Sencha Touch 1.1, you can now develop apps for Blackberry 6, the OS of the Blackberry Torch, as well as the new Blackberry TabletOS on the upcoming Playbook tablet. We’ve also made special enhancements to improve animation performance for Blackberry devices that do not have a Graphics Processing Units (GPUs), e.g. BlackBerry Torch. In addition, we’ve included a theme tailored specifically to BlackBerry which uses a “flat” style to minimize CSS3 overhead and again improve performance.

Reseach In Motion (RIM), the makers of BlackBerry devices, was so thrilled by our efforts to help developers create web apps on Blackberry devices, that they are offering a free BlackBerry Torchto the first ten developers to submit an application to BlackBerry App World using our framework!

Read more about the promotion

New features: Pull to Refresh and Pagination

We are also excited to introduce our first official plugins for the framework, which also serve as great examples for when you start to create your own class additions. The first feature is a popular user experience paradigm from many iOS apps (including Twitter and Facebook), called “pull to refresh.” By enabling this in your List component, you can now offer users an easy, natural feeling way to refresh list contents by pulling the top of the list down to a predefined point. Data is automatically fetched from your pre-defined data store, so setting up this new enhancement is just a few lines of code.

Additionally, we have introduced pagination, to help improve the data use of List components. You can now simply add in the listpaging plugin, and Sencha Touch will automatically add a link to the bottom of your list which, when tapped, loads the next set of records. You can also set the optional ‘autoPaging’ plugin attribute, so the next set of records is loaded automatically as the user hits the bottom of the list.

New Demo: O’Reilly Conferences

We are also including a brand new demo app in this release: A conference app we made in coordination with O’Reilly Conferences. The app features the conference schedule (which automatically defaults to the current day during the conference), speaker information, tweets related to the conference, a map for the venue, a list of YouTube videos relating to the conference, and several plain pages for things like credits and overview — all in under 800 lines of code. One of the most note-worthy pieces of the demo is its use of relationships, which allow us to easily show a list of speaker’s sessions when viewing their bio, and likewise a list of speaker bios when viewing a session.

The custom theme created for the app which provides a unique look and feel and is accomplished with under 90 lines of custom SASS. Great care was taken in optimizing the theme as well, so the entire CSS output (including embedded icons) comes in under 60kb. Lastly, we made the entire app configureable from a single file, so it can be easily modified to accommodate future events.

Performance tweaks and style updates

In addition to the improvements we have made for BlackBerry, we have also made several optimizations specific to Android and are offer almost 3x better scrolling performance. Likewise, we have made several tweaks to resolve minor flickering situations on iOS.

We’ve also included prominent links to some of our most helpful examples, like building apps that take advantage of HTML5 localStorage or wrapping your web app in a native wrapper by using PhoneGap. Lastly, we’ve also included a variety of style updates to Sencha Touch 1.1, including refined toolbar form fields, added an magnifying glass icon to search fields, better list styling, improved selects in overlays, and size optimizations.

We hope you’ll enjoy the many enhancements and fixes in the new release and use them to develop some awesome cross-platform mobile apps.

Sencha Touch: Optimizing Memory Usage

Although most modern mobile devices have good hardware specs, almost all of them are still lacking in areas like memory — especially compared to their desktop counterparts. Others either have weak graphics processing units (GPUs), or the browser doesn’t properly leverage the GPU for animations and drawing. In a previous article, we looked at event delegation as a way of improving the performance of your mobile web application. Event delegation speeds up your app because it reduces the amount of memory your application uses at a given time. Of course, this is not the only thing you can do. In this article, we will look at one more technique that improves your application’s memory usage.

The Size of Your DOM

The number of elements on your page has a large effect on the amount of memory your application uses, so it’s a good idea to keep your DOM as small as possible at all times. “Heavy weight” elements like images should especially be kept to a minimum.

We do have one major advantage: due to the size of screens for mobile devices, the applications on them typically show only a small part of the interface at any given time. This means we can remove the elements related to parts of the app that are not visible anymore. In Sencha Touch, this particularly applies to things like popups, modal windows, and cards in Panels and Carousels. So how can we leverage this knowledge when writing our apps?

In Sencha Touch, there are events that fire when the visual state of a component changes. For example, when you switch cards in a Container with a CardLayout, the Container will fire a cardswitch event once it’s done. We can hook into these events and destroy Components that are not visible anymore because of these transitions.

Let’s look at a simple example. Our goal is to have a List that slides to a details panel whenever you tap on an item. Once we get to the details panel, we want to destroy the List. Then when we go back to the List, we want to destroy the details panel. This way, we ensure the minimum required markup in the DOM at any given time.

Example

Here is an example of the code for the List:

var list = {
       xtype: 'list',
       title: 'Contacts',
       listeners: {
           itemtap: function(item) {
                   details.html = item.details;
                   panel.setCard(details);
           }
       }
       // list & store configuration ...
    };

Note the use of xtype. Here, we are not creating an instance of our list, simply a JSON object representing the object. This way we can destroy and recreate our list easily.

We do the same for the details panel, except in this case, we will put a Back button inside the panels top toolbar which will cause the container to show the list again when pressed.

var details = {
       xtype: 'panel',
       dockedItems: {
           title: 'Details',
           dock: 'top',
           items: {
                   text: 'Back',
                   ui: 'back',
                   handler: function() {
                         panel.setCard(list);
                 }
           }
       }
       // component configuration ...
    };

Now, we get to the interesting part. Let’s create the following Panel which will contain our child components.

var panel = new Ext.Panel({
       fullscreen: true,
       layout: 'card',
       items: [list]
    });

As you can see, we have created a fullscreen Panel with a layout of card that contains our list by default. We haven’t put in the details panel yet. Instead, we will only insert the details panel when you tap an item.

Now, it’s time to set up a listener to the cardswitch event. This is where we actually ensure that the card we just came from is being destroyed.

panel.on('cardswitch', function(newCard, oldCard) {
       if (oldCard) {
           this.remove(oldCard, true);                    
       }
    }, panel);

As you can see, we are removing the old card from the container. By passing true to the second argument of the remove function, the container will call the destroy method on the card—also removing all of the events bound within that object as well as the actual DOM created.

This same concept applies to hiding a modal window or popup. In fact, you can apply this concept to almost any visual state change of your app. Of course, you want to find a balance between reducing your app’s memory usage and rendering heavy components again and again. In some cases, the benefit of not having a long rendered List in memory is offset by having to render a very long list again when you switch back to it.

So far, we have looked at event delegation and DOM cleaning as ways to reduce your applications memory usage. In a future article, we will look at things you can do to improve the performance of your animations. Till then, delegate and keep your DOM clean!