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!