Download Sencha Touch 2 RC   View Release Notes

Six full-featured example apps

To provide some inspiration, we’re shipping six combination examples written by the Sencha Touch core team. Each uses best practices to help you get started on building your next great application.

In addition to the new examples, we have fixed various bugs and added some more features:

Ext Direct

Combined with your favorite server side stack, you can now invoke remote methods client side using Sencha Touch.

// Calling a method on the server
myRemoteClass.myRemoteMethod();

Enhancements to DataView

We now have a new option on DataViews that give your lists padding and rounded corners.

Ext.create('Ext.List', {
    ui: 'round'   // It's that simple
});

While we’re all accustomed to using carousels when transitioning between cards, we thought it would be helpful if we could add in the ability to horizontally scroll Lists. DataViews can now scroll horizontally giving you all the momentum scrolling goodness you’ve come to love.

Ext.create('Ext.List', {
   inline: { wrap: false }  // Smooth horizontal scrolling
});

Bridging to Native APIs

While we wait for native APIs to be exposed in standard browsers (WebKit just landed Vibration API), you can get access to many commonly requested APIs by packaging your app in a native shell. With the release of our native packager, you now have access to these popular APIs via JavaScript. In addition to a sample app and demo video, we’ve written a guide on Using Native APIs to show how simple using native APIs from JavaScript can be. This release candidate has the following APIs:

• Connection – tells you whether or not the device has a current connection to the internet
• Notification – allows you to use native notification windows (the native version of Ext.Msg)
• Orientation – gives you as much information as the device provides about its current orientation
• Camera – allows your app to take pictures or select from the camera library (with your user’s permission)

Screencast

SDK Tools Update

Back in October of last year, we previewed our native packaging for iOS and Android as part of our SDK Tools. Although we only released the Mac OS version, we talked about being able to build these mobile applications on multiple platforms. Today’s release now supports the ability to package and sign iOS applications on Windows.

Download SDK Tools
Download for Mac   Download for Windows

Getting Started

Once you download and install the SDK tools, you can start packaging your HTML5 app in a native shell by running a simple command.

// Packaging made simple
sencha package ios.json

// Source of your ios.conf
{
        "versionString":"1.0",
        "iconName":"icon.png",
	"applicationName":"MyGreatApp",
	"applicationId":"com.yourcompany.MyGreatApp",
        // Your webapp path
	"inputPath":"C:/projects/MyGreatApp/www/",
       // Native app destination
	"outputPath":"C:/projects/MyGreatApp/ios/",
       // Destination App Store!!!!
	"configuration":"Release",
        "platform":"ios",
	"deviceType":"iPhone",
        // Your Developer Cert
	"certificatePath": "c:/certs/Developer.p12",  
        "certificateAlias":"iPhone Developer",
        "orientations": ["portrait",
		"landscapeLeft",
		"landscapeRight",
		"portraitUpsideDown"
	]
}

The application was successfully packaged
The application was successfully signed

Summary

We are extremely proud of this progress we’ve made in this release candidate. We’ve worked around the clock refining and polishing Sencha Touch 2 for general release! We believe that Sencha Touch 2.0 raises the bar for mobile web experiences. We hope you think so too.

Follow Sencha Touch 2 Development

If you missed all the great progress in our development of Sencha Touch 2, catch up with our release blog posts from the last three weeks:

• Feb 1: Sencha Touch 2 Beta
• Feb 8: Sencha Touch 2 Beta 2 and a tutorial on DataView
• Feb 14: Sencha Touch 2 Beta 2 added support for Kindle Fire, and Chrome for Android
• Feb 22: Sencha Touch 2 Release Candidate

UPDATE: On February 15th, we pushed an update to Sencha Designer 2 beta. This update addresses several critical bugs, as well as adds our new Snow Theme for the UI. Open the app and click accept to automatically get the update.

Building a Sencha Touch Mobile App using Sencha Designer 2

This tutorial is delivered in both video and written form. You may find it easier to follow one or the other, or use both in unison. Continue on to the bottom of this post to see the full video walkthrough.

The application we’ll be building is called CityBars, a Sencha Touch app for mobile devices which makes use of the Yelp API to find nearby watering holes. I’ve tried to add some color to the video and to introduce you to Sencha Designer 2 in much the same way I’d help any developer new to Designer.

Project Assets

To follow along with the project you’ll need a copy of Sencha Designer 2 beta; and a Yelp developer API key. Note: Your API key will be capped at about 150 calls per day. If everything stops working this might be why.

You’ll also need to follow the step-by-step guide along with the CityBars project file — be sure to unzip it. (The CityBars project is also available as Github repository, though this is simply the Sencha Touch mobile app, and not the Sencha Designer project.)

Watch the Video

If you hit any road bumps, head over to the Sencha Designer 2 Help & Discussion forum to ask questions and get some assistance!

Download Sencha Touch 2 Beta   View Release Notes

UPDATE: Sencha Touch 2 RC is now available. Go download that instead!

Android Chrome and Kindle Fire Support

We’re thrilled to be able to add support for 2 new platforms today. The first is Android Chrome, which Google released in beta last week for Android 4.x (Ice Cream Sandwich) devices. While there are still relatively few ICS devices out there (only around 1% of all Android devices carry that version currently), Chrome for Android is already providing a much improved experience compared to the stock browser (see our Chrome HTML5 scorecard).

The second is the Kindle Fire, which we think is one of the best Android tablets out there. While earlier versions of the Fire’s browser had some performance and rendering issues, the recent 6.2.2 update brings much more speed and rendering correctness to the device, which allows us to officially support it. The browser improvements, in addition to some tweaks of our own, have combined to provide a great Kindle Fire experience with Sencha Touch 2.

We were so happy with the performance of both platforms that we recorded a short video on real hardware to show you what you can do with the new support. The first device is an Asus Transformer Prime, running smoothly at a whopping 1280 × 800 resolution, and the second is a Kindle Fire, which displays impressive performance for a device costing under $200:

Amazon hasn’t officially released the sales numbers for the Kindle Fire but they are estimated to have shipped several million in Q4 alone, which means your Sencha Touch 2 applications can now be deployed to millions more devices, most of which will receive the 6.2.2 update automatically.

On the Android side of things, we’ve recently been asking for your help in escalating crippling problems with ICS’s default browser. We’ll continue seeking improvement there but Chrome for Android is providing a great alternative for ICS device owners in the meantime.

Performance Improvements

As well as adding support for more devices, we’ve also spent time further refining the experience on all supported platforms. This release contains several performance tweaks, mostly centered around optimizing CSS selectors and styles.

Some of the more apparent improvements include faster button tap feedback and smoother card transitions, especially to and from forms. Previously these actions might have felt a little slow but as of B3 it feels much snappier. When we investigated why these things were feeling sluggish we found it was caused by certain innocuous-looking CSS rules and were able to improve performance dramatically by using alternative styling to achieve the same look and feel.

Finally, we’ve polished other parts of the framework to give better perceived performance. For example, carousel indicators now update immediately when you swipe instead of after the animation has finished. It still takes as much time as before, but makes your app feel faster to the user. Performance has been a major objective of Sencha Touch 2 and we’re very pleased with the improvements so far.

The Path to GA

This beta is the seventh public release of Sencha Touch 2. We’re very happy with the performance and stability of beta 3, we think we’re in the home stretch toward GA.

Beta 3 is expected to be the final beta version before we ship a Release Candidate. With its API frozen we have no hesitation in recommending that you start building your apps using B3 if you’re keen to get a head start on your app.

As always, we’d like to thank you for all of your support in getting to this stage, and hope you’ll share your thoughts with us in the comments.

As part of our continuing series on the HTML5 capabilities of new mobile platforms, today we’re taking a look at the new Chrome for Android mobile browser beta. There have been rumors of Chrome for Android for quite some time, and we were encouraged but a little underwhelmed by the stock Android 4 browser. We were hoping that there was more to come.

And we didn’t have to wait long. After testing Chrome for Android, we’re happy to say that it’s a very solid HTML5 browser, and even in its beta form, is a “must-install” for any Android 4 owner. Hopefully Chrome for Android quickly becomes the only browser for Android 4.

“If you own an Android 4, there is no question you should download and use Chrome Mobile beta as your primary browser.”

Our First-Look “Methodology”

Our HTML5 scorecard consists of a series of tests aimed to help mobile web developers understand new devices and new form factors as they come to market. We test in a number of areas, namely JavaScript performance, HTML5/CSS3 features, rendering performance and rendering accuracy. To get there, we use a variety of tests, including Modernizer, Acid3, SunSpider, Sencha Animator demos and our Sencha Touch Kitchen Sink.

Acid3 and Modernizr

Chrome for Android scores a perfect 100/100 on the Acid3 test, just like the Android 4 browser. However, the tell tale rendering artifact (a very faint red/pink box in the upper right corner) that has marred a perfect score on other Android browsers, once again rears its head. (Chrome Desktop doesn’t have this artifact, so perhaps this is an OS/graphics stack issue rather than a browser problem). In practice, this won’t impact web browsing or web development much, but it would be nice to fix this for the final release.

Next up, Modernizr! Once again, we used haz.io which is a clean and mobile friendly Modernizr checker. The verdict? High marks on HTML5 support — as one might expect from the folks who brought you Chrome. Once again, the browser does have @font-face support — Google Fonts display perfectly — but TypeKit does not yet detect Chrome for Android correctly. As with the original Playbook, and Android 4 stock browser support, Typekit has a lag between first ship and support, but I’m sure the Typekit folks are on top of this.

Compared to the stock Android 4 browser, there is a substantial number of additional HTML5 features: Web Workers, Web Sockets, HTML5 Input Types, overflow: scroll, requestAnimationFrame and more. That’s not to say that Chrome for Android has absolutely everything. As detected by the other handy testing site for HTML5, many newer features are absent, notably Shared Workers and WebGL. The video codec cold war also continues: Ogg Theora and Ogg Vorbis support is still not there — which is not a surprise.

Performance

For performance benchmarking, we use SunSpider. In the last 9 months, all the mobile browsers have converged at basically the same SunSpider performance levels. This also holds true for Chrome for Android. Although it’s slightly faster on one or two tests vs. Android 4 browser, it’s in the same general ballpark, which is not too surprising since they’re both using the V8 engine on the same hardware. Since Chrome for Android is visually much faster and smoother than the Android stock browser, this is probably a good time to consider putting SunSpider on the shelf as a good predictor of user-perceived performance.

Real World Tests

As we’ve said many times previously, many mobile browsers do well on the checkbox tests like Modernizr, but fall short when it comes to real world applications and content. (In some cases, mobile browsers have even reported support when none exists.) So for real world testing, we use a collection of our own favorite HTML5 sites and demos.

First up, the new CSS properties for mobile content. On our HTML5 wish list for 2011 we asked for high performance position: fixed. And Chrome for Android delivers. For simple pages, Chrome for Android does a top notch job of glueing fixed position content to the screen. Fixed headers and footers for simple mobile optimized pages are now easily implemented without having to use a framework. However, the browser struggled when trying to maintain fixed positioning on more complex pages, particularly when combined with pinch/zoom. We saw poor frame rates and occasionally content disappeared or was misplaced. Happily, the very new -webkit-overflow-scrolling: touch property, which debuted in iOS 5, is also now available in Chrome for Android. It’s smooth and fast. (Nice job Chrome team!)

On to SVG. On Chrome mobile, basic SVG worked very nicely. Our Raphael vector demos were very smooth, and many other SVG effects like text on a path, and animated gradients worked smoothly at a good frame rate. For more advanced effects (demos at David Dailey’s page), there’s still work to be done: SVG effects like complex filtering were either not supported or ran at low frame rates. Since there is little popular content that relies on these advanced effects yet, this is not such a big deal. However, when CSS Filters start to percolate into general usage, getting these right will become more important.

We next tried Canvas and here Chrome for Android has a good implementation. Basic Canvas drawing is unproblematic, and our favorite Canvas stressor — Canvas Color Cycling was smooth and high performance even under pinch/zoom. The most complex demos we could find (that can cause even desktops to pause), such as the demos at Mr. Doob did cause some problems — with long wait times and occasional complete display failures.

Our testing of embedded HTML5 audio and video went well. Plain inline HTML5 video works, (although don’t try to combine it with other effects or Canvas). This is an area where Chrome Beta has the advantage over iOS 5 which still lacks inline video playback.

Finally, we took a look at CSS3 Animations & Transforms. This is an area that we’ve invested in here at Sencha with Sencha Animator. Poor Android performance on 3D transforms has been a limitation on the complexity of CSS animations that can deploy cross platform. Our most complex animation — our Sencha Animator KickFu game — was playable, but the frame rate was too low for a smooth experience — I’d estimate a 5-10 frames per second performance. More basic CSS3 animations — even 3D ones — worked well, although we did uncover our first official bug for the Chrome team which we will be filing — transformed elements seem to drop border-radius. In addition, there are a few layout quirks that are present in desktop Chrome for transformed elements that also show up in Mobile Chrome.

Sencha Touch 1.0 Kitchen Sink

Although we’re in late beta with Sencha Touch 2, we decided to test Sencha Touch 1.1 instead. Compared to Android 4, the Chrome for Android experience is vastly improved. Full-screen flashes and screen flicker are absent. Other things that we take for granted such as smooth border radii, masking etc. are also well implemented. But it’s also true that some of the browser properties that we rely on for layout in Android are now different in Chrome Beta and these result in minor artifacts in layout and list scrolling that we’ll need to be address.

Chrome for Android beta: tips for the HTML5 developer

Chrome for Android is a big leap forward for web browsing on Android devices — even in its beta form. We suspect that many of the browser limitations are limitations more of the device processors than the browser itself. There is still work to be done before general release, but in all we’re very happy to have a top notch browser for Android. If you own an Android 4, there is no question you should download and use Chrome for Android as your primary browser as soon as you are able.

Beta 2 should be a drop-in replacement for beta 1, and as before, we have prepared a full set of release notes. We hope you’ll continue to let us know what you think of the release in the comments, twitter and your own blogs.

Download Sencha Touch 2 Beta   View Release Notes

UPDATE: Sencha Touch 2 RC is now available. Go download that instead!

Great Progress on ICS Issues

Last week we asked for your help in raising awareness of a critical performance issue with Android 4/Ice Cream Sandwich. Thanks to your participation the bug report has been starred over 250 times and last week yielded a patch from the Android team that addresses the flashing that can happen before animations.

While that’s great news, it’s only half the story so we’d like to ask for your help one more time. While the flashing is gone, we feel that Android 4 is still not performing as well as it should when it comes to animations so if you’re in favor of better animation performance on Android 4, we’d like to ask you to take a moment to click the star on this bug report to let the Android team know how much this matters to everyone building HTML5 applications.

DataView Improvements

DataView is a powerful Component that enables you to render an HTML template for each record in a Store. While that’s very useful, Sencha Touch 2 raises the bar by allowing you to render entire Components for each record. This enables a wealth of new UI options and we’d like to take the rest of this post to walk you through what’s improved.

Component DataView

The Sencha Touch 2 DataView offers two ways to render items from a Store: element based and component based. In 1.x only the element-based approach was available, which made it difficult to do things like add a Button to each item in a List.

Turning your element-based DataView into a component-based one is straightforward. With a template based DataView, you normally specify a store and itemTpl configuration, but with a component based DataView, you do not need to specify an itemTpl. Instead, you set the useComponents configuration to true. This tells DataView that it will be rendering components.

Next we have to tell it which types of components it will be rendering. To do this, we set a defaultType for our DataView. This tells the DataView which type of Component to create for each record.

In the example below, we’re creating a fullscreen component-based DataView that uses the kittenslistitem type to create each item (we’ll create this kittenslistitem Component in a moment). We’re also passing in a Store full of kittens. DataView will render one kittenslistitem for each kitten:

Ext.create('Ext.DataView', {
    fullscreen: true,
    useComponents: true,
    defaultType: 'kittenslistitem',
    store: {
        fields: [
            "name",
            "image",
            { name: "cuteness", type: 'int' }
        ],
        data: [
           { name: 'Yawning kitten', image: 'data/images/kitten1.jpg', cuteness: 70 },
           { name: 'Sitting kitten', image: 'data/images/kitten2.jpg', cuteness: 90 },
           { name: 'Evil kitten', image: 'data/images/kitten3.jpg', cuteness: 70 },
           { name: 'Ginger kitten', image: 'data/images/kitten4.jpg', cuteness: 80 },
           { name: 'Kitten friends', image: 'data/images/kitten5.jpg', cuteness: 20 },
           { name: 'Milk kitten', image: 'data/images/kitten6.jpg', cuteness: 50 }
        ]
    }
});

Custom DataView Item

Now we have a component DataView and we’ve told it to use a component with an xtype of kittenslistitem. That hasn’t been defined yet; so let’s do that now.

It is important to note that this DataView item must extend Ext.dataview.component.DataItem. This is because this object includes important functionality to bind a specified record to the component.

Our custom DataView item will include three items:

• Ext.Img — displays an image of the kitten
• Ext.Component — displays the name of the kitten.
• Ext.slider.Slider — shows a slider component will the cuteness of the kitten.

Each of these components will be defined as a configuration in our KittenListItem class. Once the class is instantiated for each record, the configurations will be added into the item. This looks like the following:

Ext.define('KittensListItem', {
    extend: 'Ext.dataview.component.DataItem',
    xtype: 'kittenslistitem',
 
    config: {
        image: true,
 
        name: {
            cls: 'x-name',
            flex: 1
        },
 
        slider: {
            flex: 2
        },
 
        layout: {
            type: 'hbox',
            align: 'center'
        }
    }
});

Let’s start from the top:

• Define the KittensListItem which we will use in our component DataView
• Extend Ext.dataview.component.DataItem
• Inside the config object, add a new config called image and set it to true (this will be transformed into a Ext.Img component)
• Create another config called name. This is an object containing a cls and a flex property of 1 (this will be transformed into an Ext.Component component)
• Create another config called slider which has a default flex of 2 (this will be transformed into a Ext.slider.Slider)
• And finally give it a HBox layout and vertically align the items in the center.

For each new configuration we create, we need to create the appropriate apply and update methods so they get transformed into the correct component, and inserted into this item. Lets do this for the image configuration:

 applyImage: function(config) {
     return Ext.factory(config, Ext.Img, this.getImage());
 },
 
  updateImage: function(newImage, oldImage) {
     if (newImage) {
         this.add(newImage);
     }
 
     if (oldImage) {
         this.remove(oldImage);
     }
 }

First, we define the applyImage which is called when this component is initialized and each time the image configuration is changed. In the method, we use Ext.factory to transform the configuration into a Ext.Img component. We then define the updateImage method which is called after applyImage. This method gets called with two arguments: the new image, and the old image (if one existed before). In this method we simply check if newImage exists and add it to this component Data Item, and the same for the oldImage, except in this case we’re removing it.

We then repeat this process for the other two configurations: name and slider.

If you want to learn more about how the Class System works, there is a great guide written by Jacky Nguyen in the Sencha Touch 2 Documentation.

Mapping the Record to the DataItem

Now we have the component data item created which will be used in our DataView. The three new configurations we created are automatically transformed into components and added into the item. The next step is configuring the map between the record and the item displayed in the list. Remember we have three fields we need to map:

• name -> html config of the name component
• image -> src config of the image component
• cuteness -> value config of the slider component

To do this, we use the dataMap configuration in our DataItem. This configuration allows us to map a setter of a configuration in our DataItem to a field in the record bound to our DataItem. Lets look at an example:

config: {
    …
 
    dataMap: {
        getImage: {
            setSrc: 'image'
        }
    }
}

Once this DataItem is added into DataView and the record is updated, this will essentially do this:

this.getImage().setSrc(record.get('image'));

As you can see, it is using the getter for our new image config, then calling the src setter on the Ext.Img component with the image field of our record.

We now repeat this process for the name and cuteness fields, so the appropriate components are updated. And the final dataMap is:

config: {
    …
 
    dataMap: {
        getImage: {
            setSrc: 'image'
        },
        getName: {
            setHtml: 'name'
        },
        getSlider: {
            setValue: 'cuteness'
        }
    }
}

Now that the DataItem is mapped to the record, we can load up our example in a browser. And when we add some CSS sparkle, the demo will look a little like this:

Conclusion

You can view a live demo of this example on Sencha Labs and the full source code (with lots of comments!) over on GitHub.

The enhanced DataView in Sencha Touch 2 Beta 2 makes it easy to build complex data bound lists. If you have issues or find bugs with the beta, feel free to drop by our forums and let us know. We’re actively hunting down and fixing bugs, so let us know if there are things you’re expecting to work that just aren’t.

Having worked on Flex at Adobe, I have a deep respect for Flex as a technology and ecosystem. Flex is great technology but the foundational dependency on Flash Player is forcing many projects to re-architect towards HTML5. Within this disruption, I believe there is a great opportunity for Flex developers to learn a new technology, leverage existing knowledge, and deliver great application experiences with Sencha. I also believe that Flex developers have the opportunity to define and lead the movement toward HTML5 applications as they bring years of experience building world class applications with components, classes, MVC, and a futuristic version of ECMAScript.

The developer paradigms of Sencha and Flex are very similar and developers who know Flex will learn Sencha frameworks quickly and find their existing knowledge of component development instantly valuable. While the syntax and architecture are different, I keep finding patterns and concepts that match Flex perfectly but are suited to the interpreted model of web development and deployment. Within Sencha frameworks, Flex developers will find a modern class system with package support, a rich set of UI components, model classes for loading data, declarative component instantiation (xtype), and MVC integrated into the framework.

Today Sencha is launching a fast-track program for Flex Developers looking to develop HTML5 applications. We begin with a Flex to Sencha Webinar on Tuesday, February 14, and will continue with a Flex to Sencha Road Show meeting with Flex user groups and Flex/Flash conferences throughout the year. We are also working on technology additions to Sencha frameworks including AMF and SOAP WebService support direct from JavaScript. For those that prefer visual tools, I also want to highlight the upcoming Sencha Designer 2 which helps you build both desktop and mobile applications visually.

Flex to Sencha Events:

• Webinar Registration

• Roadshow Registration

I look forward to highlighting Sencha’s object-oriented and component based solution to building HTML5 applications to the Flex ecosystem. Having built many applications myself with Flex, I know that you can be successful building HTML5 applications with Sencha.

Thank you to our community for your feedback during our sneak peaks with our Preview Releases. Your contributions in the forums, reporting bugs, adding feature requests, and your inspirational teamwork in the Q&A threads have kept us focused on what’s really important to you—delivering quality. We’ve taken all your feedback and we’re proud to deliver a release that we hope will exceed your expectations.

Download Sencha Touch 2 Beta   View Release Notes

UPDATE: Sencha Touch 2 RC is now available. Go download that instead!

What’s New?

With every major release, we strive to bake in the latest innovate approaches to help you create impressive applications. And learning how to use these techniques is now easier than ever.

API Documentation, Guides, and Examples

We’re investing a great deal of time in creating comprehensive documentation for Sencha Touch 2. Every major class now has a full introduction complete with code samples and how it fits into the wider context of your app. As well as class docs, we’re adding over 20 brand new guides covering everything from getting started through to building and deploying your applications.

On top of this, our documentation center now allows you to experiment with inline code editing.

We’re continuing to lead the way when it comes to innovation in our learning materials. We’re also proud to continue sharing all of the hard work we put into our documentation tools under the open source JSDuck project, a part of Sencha Labs.

New Facebook Integration Example

We’re adding an example showcasing Sencha Touch’s seamless integration with the Facebook Graph API. Jog With Friends combines the Facebook JavaScript SDK on the client side with a 200 line node.js script backed with MongoDB on the server side. For a live demo, check out http://ju.mp/senchajwf on a WebKit browser.

Foundational Improvements

Each major new version of Sencha Touch brings with it an opportunity to advance the state of what can be done with the mobile web. Here are just a few of the improvements we’ve made in Sencha Touch 2.

A New Class System

Sencha Touch 2 benefits from the supercharged class system that powers Ext JS 4. The upgraded system enables powerful new capabilities like dynamic loading, custom builds and new features like mixins. This makes developing your app easier from the first line of code all the way through to creating a minimal custom build that contains only the classes your app actually uses.

As a developer though, the biggest improvement you’ll probably notice is the use of the new config system. Sencha Touch components have always been very configurable, but for version 2 we’ve made a big improvement to the consistency of the API.

Every single configuration can now be set and updated in a very predictable way through the use of generated getter and setter functions. These functions always follow the same format and can be called at any time so once you know the config name you automatically know what function to call to update it:

var panel = Ext.create('Ext.Panel', {
    html: 'Sencha Touch 2 rocks'
});
alert(panel.getHtml()); // alerts the current value of the html config
panel.setHtml('It sure does'); // changes your panel html to a new value

These functions always follow the same format, which makes learning the framework really easy. As well as the getter and setter functions we provide hook functions which makes it easy to create your own configs—check out the new class system guide to find out more.

MVC with History Support

One of the most frequently asked questions about web frameworks is how to structure your apps to make them easy and fun to create and maintain. With Sencha Touch 2, we’re bringing significant improvements in our MVC architecture, providing new functionality and a cleaner, leaner API.

History support is baked right into Controllers in this new release, making it easy to add back button and deep linking support into your application. We have a full guide on history support and you can see it in action on your device by checking out the upgraded Kitchen Sink example.

Setting up routes is easier than ever—just define the urls your app needs to react to inside your controller along with a function to call when that url is detected. For example here’s how we can easily create an ecommerce application that shows product details when the user navigates to urls like http://myapp.com/#products/123:

Ext.define('MyApp.controller.Products', {
    extend: 'Ext.app.Controller',
    config: {
        routes: {
            'products/:id': 'showProduct'  // It’s that easy
        }
    },    
    showProduct: function(id) {
        console.log('showing product ' + id);
    }
});

Check out the full guide on History Support to find out how to add this to your app.

Multi Device Profiles

One of the challenges of a multi-device world is building an application that runs seamlessly across operating systems and screen sizes. With Sencha Touch 2 we provide a simple mechanism that enables you to write your app once then customize it for each device it runs on.

This is achieved by configuring Device Profiles, which usually split your app into Phone and Tablet modes. Define all of the models, views, controllers and store that you want to reuse in your Ext.application and anything profile-specific inside the configuration for each Profile.

For example, let’s say we’re creating a Facebook app and want to show a simple feed view on Phones and a detailed one on Tablets. We can start by telling our Application that it has two profiles:

Ext.application({
    name: 'FB',
    profiles: ['Phone', 'Tablet'],
    controllers: []
});

Now we set up a Tablet Profile that’s activated when we detect that we’re running on a Tablet device:

Ext.define('FB.profile.Tablet', {
    config: {
        controllers: ['Feed'],
        views: ['DetailedFeed', 'Timeline']
    },
    isActive: function() {
        return Ext.os.is.Tablet;
    }
});

And one for Phones:

Ext.define('FB.profile.Phone', {
    config: {
        controllers: ['Feed'],
        views: ['SimpleFeed', 'Timeline']
    },
    isActive: function() {
        return Ext.os.is.Phone;
    }
});

When the app boots up, it will automatically figure out which Profile to activate and use its specialized models, views and controllers. Check out the Device Profiles guide to find out how to use them in your app.

New Components—Component Data View and Navigation View

In addition to using the new XTemplates in your dataviews, we’re adding one of the most asked for features—using components in your data views. You can now add buttons, or any components, to items.

Giving your users the proper visual cues helps your applications flow more naturally. With Sencha Touch 2, wiring up view transitions are now simpler than ever when using a Navigation view. If you choose to use a navigation view, navigational controls such as back buttons will be handled for you. As an added bonus, we’re adding sexy animations when switching between cards.

Dive In

Now that we’re in beta, we encourage you to dive right in. We have a stable API, and we have more guides to help get you going quickly. If you’re looking to port your Sencha Touch 1.0 app we have a backwards-compatibility build that helps you through the migration process. We also have an upgrade guide to help you out.

Note: those of you who have been using the Sencha Touch 2 Preview releases, be aware that we have cleaned up the builds we generate and as a result you may need to change which build of Sencha Touch you use. Most people should now be using sencha-touch-debug.js while developing, but for a complete list of the builds we generate see the builds guide.

Features We’re Still Working On: Android ICS Performance

Sencha Touch 2 has significantly faster performance on Android 2.x browsers – with fast list scrolling being a particular point of pride. We’ve always treated the browser in Android 3.x as fundamentally broken, and do not plan to officially support it in Touch 2. We are currently working on improving performance in Android 4.0 – the Ice Cream Sandwich release. So far, we have found no acceptable mechanism to achieve fast and flicker-free animations. We have filed a bug with a simplified test case showing poor performance on a variety of mechanisms with the Android bug list. If you’d like to help prioritize this bug, please go to the bug page for Android bug number 24833, and “star” the bug by clicking on the star icon just before the headline. Solving this bug will help, not just Sencha Touch 2, but the entire web community developing content for the Android 4 browser. Feel free to add your own test cases as well!

Summary

We hope you enjoy playing around with the examples, and diving in to building your next great app. It’s been a lot of hard work getting to this point, and we thank you for all the feedback. Please keep sharing your ideas.

We’re thrilled to announce that Sencha Designer 2 Beta is available for download! Designer 2 makes it easier than ever to build desktop and mobile applications using Ext JS and Sencha Touch.

We’ve been working hard to bring you the next generation of Designer that will help you quickly build Ext JS and Sencha Touch applications. Experienced users will enjoy the productivity gains of the visual development environment, while folks new to Sencha will have a much easier time learning how to work with our frameworks and quickly build a complete application.

Ext JS and Sencha Touch are incredibly rich: they provide UI components, charting, controllers, models and data stores. In Designer 2, we make all of these features easily accessible and neatly organized to make it easier to discover all their capabilities.

From Ext Designer 1 to Sencha Designer 2

Designer 1.0 was the first step in tooling for Sencha frameworks. Designer 1 was a visual UI builder that made it easy to scaffold and design the UIs for your applications. You used it in conjunction with another code editing tool in order to build Ext JS 3 apps.

In Designer 1.2, we adding the ability to target multiple frameworks and also added support for Ext JS 4. You could continue to build views and stores utilizing all of the new widgets available in the new framework, like charts, enhanced stores, and more.

While you told us that you loved the features of Designer 1.x, we kept hearing that you wanted Designer to do more to help you build fully functional applications in a collaborative way.

Designer 2: Easier, Faster, Stronger

When started planning Designer 2, we wanted to improve every aspect of the tool. To achieve this goal, we adopted the mantra “Easier, Faster, Stronger.”

• Easier because we believed that the learning curve of building Sencha apps could be shortened. In Designer 2, all components come with handy in-line documentation, and there are quick links to go deep into the API reference. More fundamentally, developers can try things quickly and get instant feedback. The Designer canvas is a live view giving you immediate feedback. Learning the dozens of components in Touch or Ext JS is now a breeze.

• Faster because traditionally, web based development proceeded like this: write some code, refresh the browser, check the changes. Over and over again. While better web debugging tools have come a long way, debugging and error checking is still a tedious and sometimes unpredictable process.

  Designer 2 is different: all code generated by the tool is guaranteed to work out of the box. You can’t arrange components in a way that will break the frameworks’ conventions. Every property or event of every component is available in Designer, removing guesswork and eliminating digging through the API docs.

  Moreover, the Project Inspector has been greatly enhanced. It’s the heart of your project, and it shows your views, controllers, models, and stores all in one place, along with information about the project’s structure. All components and their relationships are there where you can see and analyze them.

  If you need to jump into a project somebody else started, the Designer Project Inspector makes it easy. At one glance, you can see the entire project and understand how the application is built without thumbing through pages of code.

• Stronger because Designer 2 helps you create well-structured applications from day one, and ensures that generated code follows best practices. Most (if not all) of the boilerplate code is generated for you, so you can focus on the code that really matters: the controller logic that’s at the core of your unique application.

What’s new in Designer 2?

Designer 2 represents a significant leap ahead in functionality, and here is a brief list of what’s new and what changed since the previous version:

Support for Sencha Touch 2

This feature has consistently been the top request from our community, and now it’s here! Sencha Touch 2 is now a first-class citizen of Designer. Visual development of mobile web applications is now a reality. This beta includes the PR4 release of Sencha Touch 2.

Code editor

Designer now includes a built-in editor so you can add your own code any time you want. You can toggle between the design view, which gives you access to Designer visual controls, and code view, where you write your JavaScript. The files are saved to .js files on the file system, so you can use your editor of choice, or the built-in editor in Designer.

New Toolbox

The component Toolbox has been expanded and improved: it now includes all the components you need to create a fully functional application like Controllers, Models and even a brand new store that connects to Sencha.io. We also worked to make the vast array of components more manageable by adding base categories. This allows you to narrow down the selection quickly, and create your own to fit your personal workflow.

New Project Inspector

The Project Inspector shows the entire application at a glance. The root Application node contains your launch function, while the Controller, View, Store and Model nodes help you keep things organized as you’re building an MVC application.

Event Bindings

There’s a new panel that displays all the Event Bindings available for a component, and you can use this to bring your UI to life. And when your application grows in scope, you can stay organized by moving your event bindings into a controller.

Source control friendly file format

Developers share code using source control, but developers using Designer 1 had a hard time doing that because of the monolithic nature of our project files. Designer 2 projects are better: gone is the single file archive (you still can package them that way for easy sharing via email). Now, each view, model, store is its own file. Designer 2 makes it easier to work in a project team.

In-line documentation

In Designer 2 every component, property and configuration comes with handy in-line documentation, and if you need more there are quick links to go deep in to the API reference.

Caveats for the Beta Release!

We’re excited to share with you our first beta of Designer 2. While we’re excited to see our community give it a whirl, it is still a beta, and there’s still some work left to do. In the following weeks the team will concentrate on two things:

• Further quality improvements of the existing feature set
• Improvements in the user experience and the UI design

Certain features that were not quite ready for the beta have been disabled – don’t worry they’ll be back soon. As of today’s beta, the most notable absence is packaging for mobile devices.

The coming weeks are going to be fundamental to make Designer 2 the application you’ve been waiting for, so we need your feedback. We will be running usability tests to make sure we catch bugs on our own before the official release, but if you find something that doesn’t work as you expected, or think you have an idea that would make the application better, go ahead and let us know. All feedback will be evaluated carefully.

If you’re local to the San Francisco Bay Area, and are interested in participating in the usability testing that we’re doing, we’d love to hear from you. Click here to apply for the usability test.

Since the application is going to improve and change significantly before release, the Designer documentation for beta is very basic. We are releasing an introductory article to get you started, and more material will become available as Designer takes its final shape.

We don’t recommend that you adopt the beta of Designer 2 yet in your production environment. Designer 2 has an auto-update feature, so as we make updates, we’ll be pushing changes directly to the application, and you can choose to accept or decline the updates.

To share your ideas, comments and critiques with us, please use the Sencha Designer 2 forum.

To report bugs, please use the Designer 2 Bug Forum.

Promotions, pricing and availability

We are updating pricing for the product at the launch date: individual copies of Designer will be $399, with discounts for 5 and 20 packs.

Special offer: buy an Ext Designer 1.x License today and take advantage of promotional pricing of $279. Plus, you’ll receive a free upgrade to Designer 2.x License when released. Hurry, this offer ends on March 31, 2012.

Upgrading: if you bought Ext Designer 1.0 after January 1st, 2012, you’re entitled to a free upgrade to Sencha Designer when it ships! In order to get your upgrade license please contact the email address designer.upgrade@sencha.com and we will take care of everything for you.

If you purchased an Ext Designer 1.x license prior to January 1st, 2012, you can upgrade to Designer 2 for $199 from now until March 31, 2012. To take advantage of this offer please email us at designer.upgrade@sencha.com. Note that after March 31, 2012, the upgrade price increases to $279.

Please note that Sencha Complete which will include Designer 2, will remain priced at $999.

So, go ahead, download the Designer 2 beta trial or purchase Ext Designer 1 from the Sencha Store, and share your experiences with us!

Like everybody else on the US west coast, this morning we woke up in a world where Apple is poised to transform the way we consume textbooks. One of the compelling features of this new and exciting medium is the ability to easily publish interactive books through iBook Author.

iBook Author lets you embed interactive content in your books to create more engaging experiences for learners, and our first thought here at the Sencha HQ was to try using Sencha Animator to create that interactive content.

So after a few minutes of fiddling, we found a fairly straightforward way to embed an Animator project in an iBook.

Step 1: Preparation in Animator

Open a Sencha Animator project you’d like to place inside your iBook. Take a screenshot of the stage area to create a “cover” for the animation, and rename it “Default.png”. This cover image will be used to show the animation in the page when inactive. Make sure it’s the same size as the stage.

Export the project as you normally would, then place your Default.png inside the output folder.

Step 2: A Little Hacking…

Now comes the tricky part: you need an “info.plist” descriptor file in your output folder, so we provided one ready for you in our project file available to download at the bottom of this article.

Edit the info.plist file to enter the dimensions of your animation, then the BundleName to match the export folder’s name (e.g. myExportFolder), and finally add the extension “.wdgt” to the folder.

If you’re working in Mac OS X, the icon of the folder will change to that of a Dashboard widget. If you’re on Windows or Linux, you can create a widget but you will need Mac OS X Lion in order to complete the process, since iBook Author only runs on that version of Apple’s operating system.

Finishing Up in iBook Author

Now that you have an animation file ready, you just need to add an HTML widget to your book, and drag the .wdgt file in the widget’s properties as we show in the screenshot.

Now you’re ready to export your book and enjoy the results of your work! Of course, you’ll need the new iBooks Author app and Sencha Animator on your Mac. Download our demo Sencha Animator iBook project below to get started.

• Download Animator->iBooks Project File
• Start your 30-day trial of Sencha Animator 1.1
• Download iBooks Author from Apple (Available for free on the Mac App Store)

Interpreted

The single hardest shift for me is embracing the interpreted nature of JavaScript within the Ext JS framework in general. While not new to interpreted systems, I personally expect compiler emitted errors/warnings/flags, syntax auto-completion, and strong typing for member variables, return types and assignments. Having come most recently from Java, I find that being shown errors and autocompletion as I type is a great productivity enhancement but these benefits are tied to the nature of a strongly typed and compiled language. The general lack of these facilities in working with JavaScript is really the first hurdle in moving to web technology. Truth is, as I got more comfortable with the interpreted nature of the the language, I quickly found myself enjoying the advantages:

• JavaScript’s flexibility is a double edged sword. The language’s freedom is a joy but you must use best practices to avoid common pitfalls.
• Modern browsers offer developers great insight into application behavior at runtime. I have found the Chrome developer Console and Debugger JavaScript tools to be invaluable.
• Ext JS uses JavaScript as a meta-language to provide deeper OOP/MVC/Class Loading/Mixin support is very elegant for larger scale application development. These facilities exist in very few frameworks and really differentiate Ext JS and Touch. The ability to extend components or leverage a clean MVC pattern within an application make it very developer friendly as a framework.
• Leveraging JavaScript object literals and JSON for data/component instantiation is very productive. The ability to load components remotely, define UI as objects at runtime, and leverage client layout templating is very powerful. The syntax of larger object literals using xtype takes some getting used to. I found myself formatting my code more than normal to avoid the dreaded missing comma errors deep within an object literal.
• Using the Eclipse VJET Plugin was a great productivity boost for JavaScript and Ext JS development. The plugin provides auto-completion for JavaScript and there are several open source syntaxes for Ext JS. Being able to see instances, warnings/errors, and in-context return types is a very pleasant addition based on my past experience. VJET VJET+ExtJS

Ext JS “Standard Library”

Ext JS provides a foundational set of helper classes and methods to make building applications easier. I found that the Ext.Array, Ext.Date, Ext.String, Ext.Object, Ext.Loader classes make working with data very easy and generally simplify building applications. Every application will use these common libraries and having them included and integrated into the framework is great.

Ext.require( [ 'widget.*' , 'layout.*' , 'Ext.data.*' ] ); 
Ext.Array.each( [ 1, 2, 3, 4 ], function( name ) { console.log( name ); });
Ext.Object.getSize( { age:23 , height:6, name:"Ted" } );  //3

Containers

Ext JS provides a rich set of containers (Ext.window.Window, Ext.panel.Panel, Ext.container.Container, Ext.grid.Panel, etc.) to allow developers to easily create nested views and more complex application logic. In Ext JS, containers’ layout behavior is programmatic and allows you to set the behavior of a container at runtime to ‘vbox’, ‘hbox’, or any of the Ext.layout.container types. Additionally you can set sizes dynamically by assigning values to the ‘flex’ property on items within a container.

Xtype

Ext JS provides a loosely typed data format called Xtype to allow you to pass trees of containers and controls as a single object. It is a very, very powerful technique and really makes building lots of UI components at all at once easy. In Flex and Android I used declarative XML for component initialization and layout but these are closely tied into compiler workflow. In an interpreted system, you want to leverage a format that is rapidly parsed and supports remote loading. As Xtype is a JavaScript Object Literal, it is parsed at the speed of the JavaScript engine in use. On both mobile and desktop targets, this is very fast. While you can create components independently, using xtype for component generation is much more productive once you get the hang of it. Here are 3 xtypes passed within an Array:

[ { xtype: 'container', html:'First Item', flex:1 } ,
{ xtype: 'splitter' } ,
{ xtype: 'container', html:'Second Item', flex:1, maintainFlex:true } ]

If this were assigned to a container’s ‘item’ property, it would render a split view. I found this very simple and elegant, compared to the complexity in other frameworks.

Styling

I have styled components in several frameworks. In Ext JS, abstracting style properties as runtime loaded CSS for all components is very powerful. Better still, generating CSS from the provided SASS/Compass source formats makes building a global style change quite easy. In both Flex and Android, style is baked in at compile-time and is less flexible than a runtime interpreted model. While I now feel comfortable generating a base color change in Ext JS, it will take me some time to absorb the finer details of CSS styling of the components. This is easily one of the more complex areas of the framework and will take me time to fully understand.

Hello Sencha

Given this is my first real post on Ext JS on Sencha.com, I thought it would be good to post the simplest example possible. The example creates a window with an image inside. Feel free to paste into a local html file and open in a browser.

<!DOCTYPE html>
<html>
  <head>
    <title>Hello Sencha</title>
    <!--styles-->
    <link rel="stylesheet" type="text/css" href="http://cdn.sencha.io/extjs/4.1.0.b1/resources/css/ext-all.css">
    <!--extjs 4.0.2-->
    <script type="text/javascript" src="http://cdn.sencha.io/extjs/4.1.0.b1/ext-all.js"></script>
    <!--app-->
    <script type="text/javascript">
      //define the application
      Ext.application({
        launch: function() {
          //create a window
          var win = Ext.create( 'Ext.window.Window' , {
            title: 'Hello Sencha',
            height: 285,
            width: 250,
            layout: 'fit',
            //add an image to the window by an xtype object
            items: {
              xtype: 'image',
              src: 'http://www.sencha.com/files/blog/old/blog/wp-content/uploads/2010/06/sencha-logo.png'
            },
            listeners:{
              beforehide: function( com, owner, opt ){
                alert('hiding win');
              }
            }
          });
          //show the window
          win.show();
        }
      });
    </script>
  </head>
  <body></body>
</html>

I will continue to document my journey learning Ext JS and Touch frameworks as I go. There is clearly a lot to learn and hopefully sharing my experience will help others new to Sencha. More to follow.

Experimental support for Firefox 7+

Firefox recently introduced support for CSS animations, and we wanted to give our users access to animation on newer Firefox browsers. Animator now exports -moz as well as -webkit animations. If your customers use Firefox 7 and above, they can take advantage of this new Animator capability.

As we continue to work on support for Firefox, you may notice a few issues (e.g., div elements with gradients applied will fail to render). Improving Firefox support will be one of the areas we will focus on in coming updates.

A new color picker

This latest release of Animator makes selecting colors easier and gives users more control. The new color picker features separate hue, saturation, luminosity, and transparency scrollers with integrated preview to fine tune color selections. You can also use RGB values if you prefer to work in the RGB color space. Animator keeps both sets of values up to date seamlessly, so you can switch color spaces as your project demands it.

More workflow improvements

The new color picker is the most visible new feature but it is not the only one. On the basic UX front, new users can now create a Sencha ID without leaving the application; we hope this will make the experience of using Animator for the first time more convenient. To help users who work on smaller screens, we also added the ability to turn off the rulers around the main stage.

We also took a look at how we could improve the editing experience in Animator’s stage. The application positions child objects relative to their parents, according to the rules of CSS positioning. This generates behaviors that at first sight might look strange for designers used to traditional graphic design packages. In the case of nesting objects inside other objects, this can make objects appear to be in the wrong place on the stage.

The new version of Animator compensates for this, maintaining the child object’s position on the stage for ease of editing, while still preserving the correct CSS under the hood. This takes care of the majority of cases when objects are nested, but it won’t always work if extreme transformations have been applied to the objects.

Let’s look at an example involving two objects to see how Animator accomplishes this. Object A is at x=100, y=100 on the stage. Object B is at x=300, y=300. According to the rules of CSS positioning, which position a child object relative to its parent, nesting Object A inside of Object B will make Object A jump to a stage position of x=400, y=400.

Animator compensates for this during nesting by adjusting for the difference between the original positions of the two objects (300-100=200) when determining the new relative position of Object A. When Object A is nested inside Object B, Animator places the Object A child at a relative position of x=-200, y=-200 to place it in the same stage position that it was before nesting.

Export has also been improved, with a new “split export” feature. The new version of Animator lets you split your export up, exporting HTML, Javascript, and CSS separately instead of exporting a single file with all code embedded inline. In addition, Animator exports now also work around some Android 2.x CSS issues with the implementation of fill mode for greater browser compatibility.

Bug fixes

We fixed a number of bugs mostly to address animation editing, automatic updating, a previous incompatibility with Mac OS X Snow Leopard, and export behavior. See the changelog for a complete list. We are serious about providing a trouble free experience in Animator, and we encourage you to report bugs in the Bug Forum.

Press Play to start…

The Animator team hopes you will enjoy this update and that you will keep creating beautiful animations with our tool.

For now, go ahead and update, either by accepting the update prompt you will get inside Animator on startup, or download Sencha Animator 1.1, and show us what you can do with it.

• A richer CSS3 effects toolbox; and lo there was CSS Filters, a port of the sophisticated filters available in SVG to the DOM.
• High performance position: fixed for mobile browsers; and we were granted it in iOS 5’s Mobile Safari. Now we’re waiting for other devices to catch up.
• Pervasive GPU acceleration; and we were pleased to see the BlackBerry PlayBook and Android 4.0 join iOS’s excellent implementation of accelerated graphics.
• Websockets stabilization: and we got a Christmas present of RFC 6455 and the W3C Candidate Recommendation for the web sockets protocol and API respectively.

But our other six wishes didn’t fare so well. There was only minor progress toward deeper device access on mobile browsers and developers continued to use native wrappers to access cameras and microphones. WebSQL stayed dead as a standards track technology (and its performance even decreased in iOS 5). We also saw slow progress on IndexedDB implementations. The rival HTML5 codec camps remained entrenched with little prospect of harmony, even as the mobile patent battles raged across global jurisdictions and institutions, and live debugging on mobile browsers remained a difficult task.

In the “welcome surprise” category, Microsoft impressed us with its support for HTML5 in the IE10 preview, showing a solid commitment to the latest HTML5 and CSS3 standards. Finally, and disappointingly, many of WebKit’s nicest proprietary extensions, like background-clip: text, remained off the standards track and omitted from other browsers.

So, looking forward to 2012, we’ve got a new top ten wish list for HTML5 and for the browser makers. Some of 2011’s top wishes make a comeback, but others are brand new. We don’t claim these are definitive, but a motley collection of what we think would be most interesting for developers creating the rich and responsive applications that HTML5 was built for.

10. HTML Media implementations

Although we got some support for photo uploads in Android, web browser support for media capture and other HTML5 media technologies remains elusive. As a result, mobile web developers, in particular, have to wrap their web apps in a shell to get device API access. Camera access is the #1 feature reason for HTML5 developers to deploy to native rather than web, and given Apple’s leadership in almost every other area of mobile web, it remains a glaring omission for Mobile Safari.

9. HTML5 audio quality

While long-playing HTML5 audio works in most places, short-form audio, particularly for the features that games need, is lacking. Synchronizing audio with video or animations, multi-channel and mixing are all features that developers want. There are a number of early stage drafts to create standards for richer media handling, so that’s encouraging. Perhaps by the end of the year, we’ll be looking at solid desktop support, at the very least, with some standardization in round 2 of working drafts. We wish.

8. Better Offline Caching

HTML5 cache manifests are great for basic offline application support, but they require developers to know in advance what their assets are, declare them in a file and link the file into their pages. Mobile browsers in particular have had idiosyncratic and occasionally buggy interpretations of cache manifests. So, we’re wishing for a more dynamic, easier caching mechanism, ideally one that has some JavaScript APIs.

7. Web Intents: Standardization & support

Web Intents are a great mechanism to allow web applications to hand off tasks to one another, without knowing in advance who and what the offloading web app is. Invented by Paul Kinlan from Chrome, and inspired by Android’s intents system, they’re a neat way to allow web applications to collaborate on tasks. We’re wishing for a speedy standards track draft and good interoperable Firefox and WebKit implementations by the middle of the year.

6. WebGL Everywhere

It’s here, it works, it’s gorgeous. We’re even supporting a framework for WebGL. It looks fantastic on desktop. Our (probably fruitless) wish for 2012 is that IE10 supports WebGL, and we get ubiquitous WebGL on mobile. With iOS planning to support WebGL only within iAds, at least for now, it looks like we might wait a while to get that broadly, but we’re wishing for it anyway.

5. IndexedDB

2011 put a stake through the heart of WebSQL (thanks to Mozilla’s leadership) but IndexedDB is not ubiquitous yet. On desktop, Safari has yet to ship it, and it’s not here on mobile. Until then, developers continue to roll their own shims on top of local storage and WebSQL to get cross-browser offline data storage. We’re wishing for IndexedDB everywhere this year.

4. Right-sizing images

Sencha.io src helps developers deliver the right image size to any mobile device, but in our opinion this is a neat solution for something that should be solved in standards. Karl Dubost from Opera points out that there was a proposal back in the day to enable this at the HTTP layer. However, given today’s cloud environments where developers often dont get to tweak their web servers and vanilla HTTP is the only thing available, this won’t fly. It needs to be added to either HTML or CSS. We’re hoping the CSS4 Images standard now in “pre-draft” form will get some love and attention this year.

3. Contacts API

We’d like contacts access without having to use a shell API. So would lots of our developers. There’s a spec from Nokia and friends but too few implementations.

2. Background Services

We’d also like to see more capabilities for managing multiple resources and handling background tasks. Chrome, once again, is leading on implementing these OS-y type services. Web notifications are in working draft and we wish they get broader implementation this year. We’d also like to see server-sent events get the wake-up behavior that’s spec’d.

1. Better Mobile Browser Debugging

And for the second year in the row, we’re asking for better mobile browser debuggability and profiling. Chrome’s remote debugging feature has been made to run on BlackBerry PlayBook, there is no reason others can’t follow it. Scriptable debugging/profiling would greatly assist mobile application QA, something that’s currently a painful task in mobile web app (and framework ) development.

So that’s it! We know lots of our wishes have to do with mobile, since that’s where new technologies get adopted and reach critical mass the fastest. But it’s also the environment that’s hardest to hack around shortcomings, since the iOS and Windows Phone environments are so tightly controlled. And there’s a much longer list of things that we could add here (better, easier crypto for one, WebCL and more) but we’ll stop here in the interests of brevity. What’s your favorite wish for 2012? Give us your feedback in the comments!

Nanocrowd develops technology that understands why people like things. Our first use of this technology is helping people find movies they’ll enjoy. By knowing why people like things, we can make the process of finding movies faster, easier, and more fun.

These are wild times to be in the movie business, and we have to remain flexible, moving quickly to new platforms. For example, with over 40 million iPads sold (and half of them being used to stream movies and television), the iPad has become a leader in mobile entertainment devices. To support this platform, we recently announced our first movie-search application designed for the iPad, built with Sencha Touch: search.nanocrowd.com.

Why We Chose Sencha Touch

“We wanted to remain flexible and create a single code base that we could extend to other platforms.”

Nanocrowd started life as a desktop application, so our challenge was to convert our movie recommendation website into a mobile movie-watching platform. Our development team didn’t have expertise in mobile or touch; and, even though we were building our first mobile application specifically for the iPad, we wanted to remain flexible and create a single code base that we could extend to other platforms.

After evaluating several technologies, we found that Sencha Touch was the best fit for our needs. It took full advantage of HTML5 and CSS3, offering us the cross-platform framework we needed. We built a quick prototype and found it easy to learn. Most important, Sencha instantly put an elegant face on our mobile application.

To develop our mobile app, we started with lists of channels and movies. To become an intuitive mobile application, it was crucial that we convert our desktop grids and scrolling lists into touch-centric scrolling lists. Sencha Touch made it easy to inject movie and channel data into a pane that had three independent scrolling lists, and the first piece of our application was done.

We also needed to present a wealth of information about the movies our users selected. Sencha allowed us to create multimedia overlays which we could float over any other application pane. We created our “Movie details” overlay which includes a thumbnail image, a JavaScript tag cloud, text about the movie, and checkbox forms for flagging whether a movie has been seen or for clearing alerts.

Finally, we wanted to create a fun trailer-viewing experience. Of course, we had to load the trailer for the movie users selected, but then we also wanted our users to be able to scroll through and watch the trailers for any of the movies in the channel. We created a new pane (with an elegant transition, naturally) that included an embedded YouTube viewer, thumbnails for “next” and “back” scrolling, and information about the movie and the channel.

On this pane, we took full advantage of the HTML5 video display and controls, including not only pause and play but also pinch-zoom for full-screen viewing. These same controls and viewer will be available to us on any platform that supports HTML5. When users are ready to watch a movie, a simple sheet flies in, populated with more information from our database showing them where they can watch the movie. One click launches the website or application where they can watch their movie instantly on their iPad.

Our decision to use Sencha wasn’t based on any single element, but rather on how comprehensive the framework is and how easy it is for us to make our applications feel both native and elegant.

Business Value of Using Sencha Touch

Sencha Touch enabled us to cross over from being a desktop web application to a touch and mobile application without extensive training or hiring. We appreciated how easy it was to get started with the framework—we had a prototype application up and running in a couple weeks and understood what it would take to build the real thing. The “Kitchen Sink” examples and code samples were consistent time-savers, as we frequently found just what we needed by snagging source code straight from the Sencha website. After finishing the prototype, we developed a rich, multimedia mobile application with about 6 person-months of development, all with well-designed elements that give our users a familiar touch experience.

Perhaps even more important to our future is that we’re relying on Sencha to solve problems and issues that arise with device OS upgrades and with new hardware platforms. In the coming year, we plan to release our applications on several different platforms, and not only will the application function well out of the box, but as cross-device browser issues arise with these new devices, we’re depending on Sencha to address them.

Finally, we continue to benefit from the Sencha team’s enthusiastic customer support. They are responsive and helpful in our coding efforts as well as getting us up-to-speed on the touch and mobile platform. As we’ve progressed, Sencha has become a valuable technology partner.

Our Advice to New Developers

Don’t worry about mastering the framework before you begin coding—the sooner you begin to prototype and write some code, the faster you’ll learn to take advantage of all the tools and support that is available. When we started, we thought we were building a prototype, but before we even realized it we’d developed pieces of our application. This prototype/experiment/build process has been very successful for us.

There are two things we wish we’d done sooner. We were slow to take advantage of the theming capabilities in Sencha Touch. We thought we’d add them at the end, but it would’ve been more effective and easier to build them in from the beginning. Be sure to spend some time working with theming sooner rather than later. Also, jump into the forums and establish yourself as an active participant as soon as you get started. Although we used the forums as a resource, we didn’t think we should contribute actively until we were “experts,” and we wish we’d participated more fully from the start.

Final Thoughts

Looking to the future of consumer applications, there will continue to be a variety of platforms and operating systems we’ll need to support. Our customers will be adding new “screens” where they’ll want to watch TV and movies and you know they’ll expect all of their devices to play nicely together. By developing in Sencha Touch, we’re building a foundation that we can extend to those platforms as they emerge and change.

New Tutorials for Ext JS 4 and Sencha Touch 2

New Tutorials for Ext GWT 3 Beta

Catch up with Ext Designer & Sencha Animator

If any of these articles are a surprise to you, sign up for our newsletter to get them earlier. Get started now, and happy learning!

For us, about midway through our upgrade, we realized that we badly needed a tool to help us verify that what used to work in the Ext JS 3 version still worked in the Ext JS 4 version. Doing the testing manually for each feature and API method would simply have taken way too much of our time. After evaluating a few popular options, we realized that none really fit our needs, so we started to design and write our own tool: Siesta. Siesta can help you test plain JavaScript or code built with popular JS frameworks such as Ext JS or NodeJS.

But before we get into the details of Siesta, let’s take a step back and give some more background.

Why testing JavaScript UIs is hard

Testing Ext JS, or any other JavaScript centric UI framework, is hard because the available tools are not really suited for the task. When it comes to DOM and user interaction testing, most popular web UI testing tools don’t offer enough help unless your application uses simple static HTML pages. Using Ext JS, the HTML markup is usually generated by JavaScript code, meaning that you cannot safely rely on pixel coordinates, element IDs or XPath/CSS selectors. Brittle tests become very time consuming, if you have to update them every time that you make a slight change to your UI. A tool to test Ext JS must know about Ext JS and make use of its power. This is where Siesta is different from the rest, because its top priority is Ext JS testing.

What we wanted from a test tool

There are a few underlying reasons why we decided to write our own tool. Here are the main features we needed in a good Ext JS test tool:

• Write tests in JavaScript — we don’t want to have to learn a new language to write tests.
• Automatable — we should not have to open a browser to run our tests
• Extensible — we should be able to easily add our own assertion methods and abstractions.
• Optimized for Ext JS — it should offer high level abstractions to assist with Ext JS testing.
• Simple and user friendly UI — low learning curve, should be very easy to get started

Together, we believe these features provide a very powerful testing tool. Let’s take a peek at the Siesta UI. Below you can see the two main panels of Siesta: The left hand side holds the test suite tree, and the right panel shows the test assertion list for one of the recently executed tests.

How to write a simple Siesta test.

Let’s look at how to write a simple Hello World test. It would look something like this:

StartTest(function(test) {
  var myTextField = Ext.create("Ext.form.TextField", {
      renderTo : Ext.getBody()
  });
 
  test.click(myTextField);
 
  test.type(myTextField, 'Hello world', function() {
      test.is(myTextField.getValue(), 'Hello world', 'We did it!');
  });
});

A test starts in its StartTest method, which is similar to how you use Ext.onReady in your application. A text field is created and then typed into using the type() method. This method operates asynchronously and in the provided callback function we simply assert that the text field value is what we expect it to be — “Hello world”. When running this and enabling the “View DOM” mode, this is what you see:

Since Siesta can be automated easily using tools like Selenium or the excellent Phantom JS, you could just as well run the test above on the command line. You would then see the following output:

Even complex tests are made trivial by Siesta, for example testing moving, resizing and closing an Ext.Window:

StartTest(function(t) {
  var win = new Ext.Window({
      height : 200,
      width : 200,
      // Set window position to known state
      x     : 0,
      y     : 0
  });</p>
 
  win.show();
 
  t.ok(win.rendered, 'The window is rendered');
 
  t.hasPosition(win, 0, 0, 'Correct initial position');
  t.hasSize(win, 200, 200, 'Correct initial size');
 
  // Use component query to drag the header 20 px right/down
  t.drag(win.down('header'), null, [20, 20], function() {
      t.hasPosition(win, 20, 20, 'Window could be moved to new position');
 
      // Use regular CSS selector to drag the east resize handle 20 px to the right
      t.drag(win.getEl().down('.x-resizable-handle-east'), null, [20, 0], function() {
          t.hasSize(win, 220, 200, 'Size increased');
 
          t.click(win.down('tool[type=close]'));
 
          t.notOk(win.el.dom, 'The dom element of the window is gone');
      });
  });
});

What unit testing can do for your codebase

Testing your code brings lots of advantages, perhaps the biggest one is that it increases your confidence in your codebase. How do you know your code actually works? How do you know if a small change in the core of your application is safe or if it breaks some feature? The only way is to actually manually verify each and every feature of your system—but that’s not realistic unless you have a test suite.

There are other advantages that are definitely worth thinking about:

• You will save lots of time if you can automate your cross-browser testing prior to pushing out a new release of your application. Doing this will move the quality of your releases to a whole new level.

• If you use a write-tests-first approach, you are forced to think about your spec and requirements one extra time, before even writing a single line of code.

• Unit tests help you find tightly coupled code. If you cannot test component A, without also creating a component B and C, then you should probably refactor your code.

• Siesta can automatically detect global variable leaks for you by analyzing the window at the end of a test.

Another advantage, especially for custom components, is that unit tests provide real usage examples for your APIs, which is like extra documentation built into your project.

When refactoring your code or when upgrading the underlying Ext JS version of your application, it is a huge plus to have a test tool to help you verify the state of your application. Or as someone wrote on Twitter recently: “Without unit tests you’re not refactoring. You’re just changing sh—”.

That is why, for big systems without a test suite, programmers are often afraid of refactoring, and instead only make minor cosmetic changes on the surface, patching here and there. As a result, such systems accumulate a lot of cruft, making further development much more costly.

Summing it up…

I hope this post has given you an idea of what Siesta is and how you can benefit from using it. We still have many features to implement. In the next couple of months we’ll be adding support for Sencha Touch testing, code coverage, performance benchmarking, and lots more. I’d like to invite everyone to join our forums and try Siesta. We are constantly looking for new ideas and ways to improve it, so please let your voice be heard in our community forums.

As part of our continuing series on the HTML5 capabilities of new mobile platforms, today we’re taking a look at the Samsung Galaxy Nexus, the first device to ship with Android 4.0, aka Ice Cream Sandwich. We’ve been hearing rumors over the last few months about the involvement of the Chrome team in Android 4, so we had our hopes up that the browser would be a major step forward. In the past, we’ve reviewed Android 2.x (Gingerbread) devices, like the Galaxy Tab and Android 3 (Honeycomb) devices, and the Motorola Xoom —and have been disappointed by the performance and correctness of the browsers.

“Ice Cream Sandwich is a major step forward for the Android Browser, but still falls short of iOS 5.”

After putting the Galaxy Nexus through our test wringer, we can say that Ice Cream Sandwich is a major step for the Android browser. However, it still falls short of iOS 5. It’s a solid browser for normal page browsing and it adds major new features that support most of the HTML5 spec. It also has taken a big step forward in correctness of rendering, which is a welcome change for people who want to push their mobile browsers to the limit.

Our First-Look “Methodology”

Our HTML5 scorecard consists of a series of tests aimed to help mobile web developers understand new devices and new form factors as they come to market. We test in a number of areas, namely JavaScript performance, HTML5/CSS3 features, rendering performance and rendering accuracy. To get there, we use a variety of tests, including Modernizer, Acid3, SunSpider, Sencha Animator demos and our Sencha Touch Kitchen Sink.

Acid3 and Modernizr

The Galaxy Nexus scores a perfect 100/100 on the Acid3 test, just like Android 3. However, a close look at the Acid3 results reveals that there are still rendering artifacts. In the top right of the test image there is a telltale faint red/pink box which should not be there, since Acid3 requires pixel-for-pixel of the reference image. In practice, this won’t impact web browsing or web development much, but it’s a bit of fit-and-finish that “we’re not quite there yet” on Android.

We then turned to Modernizr, one of our favorite tools to look under the hood of a browser. This time, we used the implementation of Modernizr on haz.io which provides a clean and easy way to look at Modernizer results. The verdict? Ice Cream Sandwich offers very good HTML5 support! Font-face, geo-location, and full support for the CSS3 suite. Support for the various CSS3 effects is probably what we’re most excited about: animations, reflections, 2D and 3D transformations, as well as transitions are all supported. For web developers, you can finally rely on HTML5 in Android 4.0 to build rich user interfaces. We do note that with @font-face support, the device does in fact support it, but TypeKit does not yet detect it correctly. As with Playbook support, Typekit usually has a lag between first ship and support, so don’t be discouraged just because your TypeKit web fonts don’t work yet.

With all the good news, there were features missing. Things of note that were absent from Ice Cream Sandwich were Web Workers, Web Sockets (so no real-time web on Android just yet), weak support for the new Input Types (like datetime or range), and WebGL. SVG was fully supported. We also decided do a head-to-head between iOS 5 and Android 4 on HTML5 support, and extracted some notable differences between the two platforms. This list isn’t comprehensive, but it shows some gotchas for web devs. Developers should use this guide to decide which APIs to take advantage of on a specific platform, or if they want to stick to the common set.

Performance Testing

When checking the user agent received, web servers report that our Galaxy Nexus was using WebKit version 534.40, which is a very modern and up-to-date WebKit. Under the hood, according to the BoyGeniusReport, the Galaxy Nexus contains a dual-core ARM processor, specifically the TI OMAP 4460, which is in the same family (Cortex-A9) as BlackBerry PlayBook and the Kindle Fire. We therefore expected SunSpider scores in the same range as other tablets. As we’ve mentioned before, this current generation of tablets all ship with dual-core processors and all have roughly the same JavaScript optimizations. So the results are again fairly predictable and look like other devices we’ve tested in this generation of hardware.

The SunSpider tests are synthetic tests that push the JavaScript engine to its limit. So, next we turned our attention to some more real world tests, looking at CSS3 performance using our own Sencha Animator demos as well as a few other tests.

Like we tried with the Kindle Fire, we threw caution to the wind and started off on our most challenging CSS3 animation test, the Kick Fu game that was developed for the launch of Sencha Animator. To our surprise, the game didn’t even start. We were a bit flummoxed by this given the fact that the whole CSS3 animation suite is supported in ICS. It’s unclear to us at the moment why this occurs. Our running theory is that the JavaScript game controls might be at fault, but it’s a wild guess at this point.

We ran through the rest of our Sencha Animator demos, some of which are very complex but are all JavaScript free, and were pleasantly surprised to see them all work beautifully. We haven’t seen an Android device run these demos well to date, and Ice Cream Sandwich shines here. For developers who want to use CSS3 2D, 3D, animations, and transitions, we’re happy to report that support on Ice Cream Sandwich is now near parity with other leading platforms.

We also tested a few other real world areas for performance and correctness. We tried a Canvas based GitHub network graph. Rendering performance was fine and the result was accurate. Pinch/zoom also worked well and didn’t exhibit the low-quality mode toggling, we’ve found in earlier Androids. The resolution and dithering of the page stayed constant as we zoomed and moved around the page. We also tried out Canvas Cycle and it worked reasonably well. The frame rate was solid but it rendered to a very very small part of the screen, most likely due to the very high resolution of the Galaxy Nexus. When we zoomed in, the device managed to keep up reasonably well. The FPS easily dropped by half and audio was never dropped, and the FPS recovered when we zoomed out to the page’s natural size. Very impressive improvement over earlier Androids.

Finally we tested embedded HTML5 audio and video. In one word: finally. We used the test player on html5video.org, which gives you a video tag inline to the page. The Galaxy Nexus is the first phone we’ve seen that actually plays the video inline! iOS 5 on iPad and the iPhone do not play video inline, and we were impressed to see it work very well on Android 4. The video not only plays, but plays inline to the page. This is a big deal for web developers looking to use Video to enhance their web experience.

“The Galaxy Nexus is a big step forward for developers looking to leverage HTML5 on Android.”

Sencha Touch Kitchen Sink

Our Kitchen Sink app is built with Sencha Touch and tests all aspects of our mobile web app framework. The Kitchen Sink gives mobile browsers a good workout as it exercises a huge set of browser features including a wide range of CSS3 effects.

Right off the bat, it’s obvious that the device is more HTML5-friendly than any other Android when using the Kitchen Sink. Rounded corners look beautiful (not pixelated as in earlier Androids), icon mask work correctly, multi-touch is supported and scrolling is substantially improved. It’s not all perfect though: full-screen white flashes were still noticeable when scrolling, even if greatly reduced from the seizure-inducing levels in Honeycomb. Page transitions also occasionally caused the browser to “blink” as it re-renders. Re-renders are most notable when scrolling a page that’s been fully laid out. When starting a scull, the page does a white screen-flash, then begins to scroll fluidly. Our best guess is that the browser is dumping the rendered page to the GPU to use hardware accelerated scrolling, and the blink occurs during that transition. Our guess is the CPU->GPU texture transition is the main culprit here.

Sencha Touch supports 3D transitions, specifically Flip and Cube, and they now work on Android for the first time, although screen-flashes are again a problem artifact. The other big issue we found is that address-bar hiding has changed between Android 3 and 4. This will impact web developers widely. In an single page app, like our Sencha Touch Kitchen Sink, it’s hard to get a hidden address bar to re-appear. On older Androids, pulling the whole page down would side the address bar back and push the page down with it. In ICS, this doesn’t happen reliably, and instead of adjusting the page geometry it actually overlays the address bar on top of the page content. This is not a deal breaker, but a definite change of behavior that developers should watch for.

Ice Cream Sandwich: Suggestions for the HTML5 App Developer

In summary, the Galaxy Nexus and Ice Cream Sandwich are a major step forward for the Android platform. Feature by feature, HTML5 support has gotten much better, rendering has become more accurate, and performance has gotten much faster. Although still behind the current HTML5 gold standard of iOS5, Android 4.0 is night and day compared to previous versions. We’re excited to see Google put this level of effort into Android’s web capabilities. And we hope they keep their foot on the gas! (And we’re keeping our fingers crossed that the Kindle Fire will get an upgrade to ICS in the New Year!)

Today we are happy to announce the availability of Ext GWT 3.0 Beta!

We consider this Ext GWT 3.0 Beta to be feature complete (with one exception, the tri-state tree). Moving forward we will focus solely on fixing bugs that we find and that the community reports. In the time since Developer Preview 5, the team has been hard at work finishing the new 3.0 features and working to fix bugs that have been reported by the community. We're excited in Ext GWT 3.0 to include the following major features:

• Adoption of GWT Events and Handlers
• First class support and interoperability with GWT Widgets
• Interface based design (supports easier testing and the MVP pattern)
• Improved model support (POJO based)
• Compile time templates
• Cells, including support for cells in data widgets
• Cell based fields
• New and improved strongly typed layout engine
• Full UiBinder support
• New native Draw and Charting API (no plugins!)
• Custom theming based on Appearance pattern and ClientBundle

For a list of changes in 3.0 Beta, please refer to the release notes.

Download Ext GWT 3.0 Beta View Demo

The improvements in Ext GWT 3.0 allow you to take advantage of new functionality with a minimal learning curve. Also, the addition of the new plugin free charting components enable you to extend your applications with powerful data visualization and analytics capabilities, all without needing brower plugins. The new charting components leverage SVG and VML giving developers compatibility across all desktop browsers. And because v2 and v3 can coexist in the same applications (stay tuned for detailed instructions in a upcoming blog post), you can plan for an orderly upgrade that fits your development cycle.

Special promotion through the end of 2011

We’re also offering a discounted special for the Ext GWT 2.x commercial bundle. From now until the end of the year, if you purchase an Ext GWT 2.x bundle, you’ll receive a 20% discount off the current price and receive Ext GWT 3.0 GA when it’s available at no additional cost! This special is available until the end of 2011, so take advantage of it now to lock in savings.

You can take advantage of this offer immediately at the Sencha store.

Additionally, we are pre-announcing updated Ext GWT 3.0 commercial pricing that will take effect after the release of Ext GWT 3.0 GA in the early half of 2012. Of course, Ext GWT 3.0 will continue to be available under the GPLv3 license, giving you the flexibility to choose the license that works best for your scenario.

Maven

<repository>
  <id>sonatype-snapshots</id>
  <name>Sonatype Snapshots</name>
  <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
  <snapshots>
    <enabled>true</enabled>
  </snapshots>
</repository>

• gxt-release - A zip of the release, similar to how Ext GWT was released before 3.0
• gxt - The core component and data classes
• gxt-charts - The new drawing and charting API
• gxt-legacy - Classes to ease porting projects from earlier Ext GWT versions
• uibinder-bridge - Optional support to allow complete configuring non Widget types using in UiBinder XML. Will not be required when Google releases 2.5

Update (12/23): Ext JS 4.1 Beta 1 is now available

Download Ext JS 4.1 Beta 1 more info

The primary focus of the upcoming Ext JS 4.1 release is performance. We have been hard at work to improve across the board, but we have concentrated on two main areas: rendering and layout. While the majority of our time has been dedicated to this effort, there are many other exciting developments to share. Chief among these are some major improvements to grid and border layout and a preview of the new Neptune theme.

Performance

The necessary precursor to improving performance is measuring it. To successfully and permanently increase performance, however, measurement has to become part of the regular build and test process. This was the first piece we put in place for Ext JS 4.1. Going beyond the use of profilers like dynaTrace, we created some simple measurement tools to use on a continuous basis. We use these tools to track key metrics on every build.

The performance metrics we track correspond to the page life cycle: Load, Initialize, Render and Layout.

Load

An Ext JS application comes to life when its “onReady” function is called. Prior to that time, many things have to take place. When we say “page load”, we can mean many different things, but for the sake of simplicity, here we define page load as the time period that starts at the execution of the first line of “ext-all.js” and ends just before any onReady functions are called. This primarily includes time spent executing all of the Ext.define statements that populate the Ext namespace, and also the detection of when the page’s DOM is ready.

Initialize

When the onReady functions are called, the application takes over. Applications perform whatever custom initialization they may need, but at some point they will create components and containers to display. In some applications, there will be literally hundreds of components created. Each of these components and containers has to be constructed, initialized and wired together.

In Ext JS 4, many more things are components compared with previous releases. Consider the header of a panel. The Header component is actually a container that contains a basic component for the title and (optionally) a set of Tool components: all managed by an hbox layout. This means you can add components to the panel’s header quite easily. It also means that there are more components and containers created in Ext JS 4 given the same panel configuration. Looking at the Themes example in Ext JS 3, there were 148 components in 50 containers. That same configuration in Ext JS 4 generates 271 components in 97 containers. This makes optimization of this area essential.

Render

The next step is the conversion of these initialized components and containers into HTML. In previous versions of Ext JS, rendering was a mixture of calls to the createElement API and setting innerHTML. In Ext JS 4.0, each component’s primary element was created using createElement and its internal structure was produced using an XTemplate instance referred to as the “renderTpl”.

If a component happened to be a container such as a Panel, additional elements were created using createElement and the child components repeated the process as they rendered into the panel’s body element. At each step, special component methods were called and events were fired to allow derived classes and applications to extend this process.

In version Ext JS 4.1 we have optimized component rendering, so components are rendered in bulk. Instead of alternating calls to createElement and innerHTML, bulk rendering creates the entire component tree as HTML and then adds it to the DOM with a single write to innerHTML.

To support this change we added a new method to components called “beforeRender”. There has always been the “beforerender” event, but derived classes typically had to choose between overriding the “render” or “onRender” method if they needed to do any work just before their primary element was created. They could do what they needed and then call the base version of the method which would then create the element.

The general flow of rendering in 4.0 vs 4.1 is shown in Figure 1. In both cases, the process starts at a particular component and descends the component tree.

Layout

Once the DOM has all the necessary elements, the final step is to determine the size and position of any elements that need special handling. Or in other words: the final step is to lay out the components. This process is the most complex and time consuming. It represented just over half the total time in loading the Themes example in 4.0.7. The challenge with layouts comes from how browsers handle requests for style information (such as margins, width and height), especially if these are being changed along the way.

The first rule of performance is that CSS calculations are expensive. Because of this, browsers cache these results. When JavaScript comes along and sets a width or height, however, the browser has to invalidate some or all of this cache. How much of the cache this affects is a function of what was changed and the cleverness of the browser’s CSS engine. The next request for style information will typically then trigger a “reflow” to refresh the cache. In general, one could say “write + read = reflow”. Given that reflows are expensive, an obvious way to increase performance is to reduce the number of reflows that occur during a layout.

In Ext JS 4.0, an hbox layout, for example, buffered all of its calculations and wrote those results only after it had read all that it needed from each component. If the hbox needed to know the size of a component, it had to measure the component’s element (read), but before it could do that, the layout of that component had to do its work first. In other words, the component’s layout performed some calculations (reads) and then stored the results to the DOM (writes). The hbox then measured the component’s element (read).

What started out as a sequence of reads followed by a sequence of writes often became a highly interleaved set of reads and writes, which, of course, resulted in a large number of reflows. To eliminate these reflows the child layouts needed a way – external to the DOM – to report their results to their owner.

Layouts in Ext JS 4.1 have been refactored to use a layout context object to share results while avoiding the write/read to the DOM (and its associated reflow). This change, while largely internal, breaks custom layouts. While we believe this is a fairly rare practice, it is something to be aware of when upgrading.

From 4.0.7 to 4.1 PR1

All of these optimizations produced some very significant gains. One of the key examples used to benchmark the performance of Ext JS is the Themes example. The performance difference of 4.1 PR1 compared to 4.0.7 in this example is shown in Figure 2, as tested on IE8.

Next Steps

While 4.1 is clearly a big improvement over 4.0, it is not yet as fast across the board as 3.4. This is not the last word on optimizing performance. In fact, we have many other performance optimizations planned for 4.x that just could not fit in this release. Our goal right now is to stabilize and ship a final release of Ext JS 4.1 as quickly as possible. We will then be hard at work to accelerate getting those additional gains delivered in subsequent releases.

Other Goodies

As promised, this release is not purely about performance. We demonstrated the new Neptune theme at SenchaCon this year, and we are very pleased that a Neptune preview will be part of this release. Much to our delight, the Calendar example will be returning as well.

The list could go on with the many other improvements, but let’s dive in to some of the more exciting changes.

Grid

By popular demand, we went back and investigated other solutions to the buffered scrolling and “infinite” scrolling mechanisms in Ext JS 4.0. We wanted to see if we could solve our technical problems without resorting to so-called “virtual scrolling”, and we are happy to report that, in fact, we can.

In 4.1, grids of (almost) every kind now use native scrolling. This vastly improves the user experience because things like acceleration, momentum and friction all work as well for grid as they do for any other scrolling content. Another welcome improvement is that this also means that scrolling is done by pixels and not whole rows. This is also true for “infinite” grids, even when the rows are variable height.

The only situation where virtual scrolling is still used is on the locked half of a locking grid. Since it has no scrollbar, native scrolling is not an option there.

Lastly, though not part of grid per se, metadata handling is now supported by Store.

Border Layout

In the process of working on layouts, border layout in particular benefited from some internal restructuring. It has always been a very popular layout, but it has also suffered from some long-standing limitations:

• You could only have one region that is north, south, east or west. If you needed multiple south regions, you needed to use nested border layouts.
• You could not configure the layout such that an east or west region had priority over a north or south region. To achieve this, again, you needed to use nested border layouts.
• Components could not be added to the container after creation.
• Components could not be removed from the container after creation.

We are pleased to say that all of these limitations have been removed in Ext JS 4.1.

XTemplate

Internally, Ext JS uses the XTemplate class for many things. It is a critically important part of the framework but was missing one important feature: it could not efficiently append to an array for a subsequent join operation. When we started work on bulk rendering, we decided that both DomHelper and XTemplate needed to collaborate on markup production by pushing their output onto a shared array.

We then discovered that the internals of XTemplate could not be surgically modified to support this, which allowed us to reconsider just how this piece needed to work. Some long-standing challenges and issues with XTemplate:

• It only supported the most basic control structures: “for” and “if”.
• The code generated from the template was somewhere between very hard and impossible to debug. As a result, errors in the template text were very difficult to track down.
• The template text was compiled at XTemplate construction time, which was undesirable because many XTemplate instances were never actually used.
• Executing the compiled code for a template was not as fast as it could be because it contained many internal function calls and string concatenations.

In 4.1, XTemplates are now compiled the first time they are used. This makes construction of an XTemplate nearly free. Further, the compiled code is now a single function that can be stepped into using the debugger, and it looks very much like the original template.

With this approach, many things became simple to support. Like “else” and “else if” statements and “switch” statements. Even literal code insertion (similar to JSP or ASP) was now a trivial extension.

var tpl = new Ext.XTemplate(
    '<tpl for="orders">',
        'Order {id} is ',
        '<tpl if="total &gt; 100">',
            'large',
        '<tpl elseif="total &gt; 25">',
            'medium',
        '<tpl elseif="total &gt; 0">',
            'small',
        '<tpl else>',
            '{% continue; %}',
        '</tpl>',
        'Items:',
        …
    '</tpl>');

The “<tpl for>” statement generates a proper “for” loop while the “<tpl if>”, “<tpl elseif>” and “<tpl else>” generate the obvious “if” and “else” blocks.

The new “{% x }” syntax is used similar to “{[ x ]}”. The body of both of these is treated as arbitrary code. In the “{[ x ]}” expression, x is an expression that produces a value that is placed into the output. In the “{ x %}” case, “x” is simply inserted into the function. In this case, it will continue the for loop when reached.

Overrides

In Ext JS, it has long been a common practice to share bug fixes and enhancements in the form of an “override”. In the past, these had to be manually managed as special entities. They operated on existing classes, whereas just about all other code in Ext JS 4.0 uses class names as strings. For example, to derive from Ext.panel.Panel:

Ext.define('My.app.Panel', {
    extend: 'Ext.panel.Panel',
 
    method: function () {
        this.callParent();
    }
});

But to apply an override to the same Panel class (in Ext JS 4.0), the shape changes completely:

Ext.panel.Panel.override({
    method: function () {
        this.callOverridden(); // not possible before 4.x
    }
});

And this code will fail if the Panel class is not loaded already. The inheritance use case would not fail, but would instead inform the loader/builder that Ext.panel.Panel was required.

Overrides are now first-class citizens. They can be named and loaded when needed. In fact, writing an override is just about identical to writing a derived class.

Ext.define('My.app.PanelPatch', {
    override: 'Ext.panel.Panel',
 
    method: function () {
        this.callParent();
    }
});

Not only does this support the classic uses for override in a managed way, but overrides can actually become tools in your designs similar to a mixin. Where a mixin is always part of the class (like the base class), overrides can be bolted on later and only if desired or needed.

Conclusion

We hope you get a chance to download and try out the new features and improvements as we approach the final release of Ext JS 4.1. We are looking forward to getting feedback from everyone on how this release has benefited you, and where we should look at further improvements.

Sencha.io Src is one of the cloud services offered as a part of Sencha.io, and solves a common problem that mobile developers face: how to design for multiple screen resolutions.

We're thrilled that the service is now handling many hundreds of images per second for mobile sites and applications all around the world. And we also very pleased to announce a set of new and experimental features to the service, available today.

Support for device orientation

Sencha.io Src recognizes devices according to their user-agents, and scales images to their known screen sizes. This however, is not able to take account of the orientation of the device. An iPhone is well-known to have a screen of 320×480 pixels, but when an app is being used in landscape orientation, an image ought rather be constrained to 480×320.

To solve this, you can now explicitly set screen orientation, and to do so, the service's API now accepts 'portrait' or 'landscape' in the URL:

<img
  src='http://src.sencha.io/landscape/http://sencha.com/files/u.jpg'
  alt='Constrained to WxH, W greater than H'
/>

More importantly, the service now also provides a small JavaScript library which you can include in your page, and which will detect orientation if the browser's window API supports it, and set a cookie accordingly. Subsequent requests to sencha.io Src will then indicate the current orientation, which can be detected using 'detect' in the URL:

<script src='http://src.sencha.io/screen.js'></script>
<img
  src='http://src.sencha.io/detect/http://sencha.com/files/u.jpg'
  alt='Constrained to WxH, W greater than H'
/>

Try out the test page with an iPhone, for example, and try reloading the page with different orientations.

(As the documentation points out, you cannot always guarantee that the cookie has been set prior to a non-deferred image download, so you may need to use this in conjunction with document load events in regular web pages, as we do in the example above.)

Client-side measurements

The same screen.js script also takes various screen-size measurements through the browser's DOM and BOM APIs, and these can be also be used to adjust screen sizes as an alternative to user-agent detection.

For example, if you want an image to be declaratively constrained by the screen.width value:

<script src='http://src.sencha.io/screen.js'></script>
<img
  src='http://src.sencha.io/screen.width/http://sencha.com/files/u.jpg'
  alt='My JS-measured image'
/>

This approach anticipates a 'future-friendly' alternative to user-agent detection, and also allows you to specify other types of measurements: for example, document.body.clientWidth will measure the inner width of your document's body, taking its margin into account. The trade-off is the possible race-condition between cookies, initial image requests, and also the way in which some measurements will vary during the loading of a page. There are more notes in the documentation, and real-device testing remains highly recommended!

New formulaic manipulation

You've long been able to manipulate image dimensions using operators like '-' (to deduct pixels) or 'x' (to scale by percentage).

Sencha.io Src now adds support for rounding (using 'r') and explicit maxima (using 'm' and 'n') in these formulae.

For example, r20 will ensure that an image is always constrained by a multiple of 20 pixels. This is often important when creating tile- or column-based layouts:

<img
  src='http://src.sencha.io/x50r20/http://sencha.com/files/u.jpg'
  alt='Half the screen, rounded down to nearest 20 pixels'
/>

The maxima operators allow you to indicate different size limits for mobile- and non-mobile devices. This is useful to ensure that, even if the actual browser cannot be recognized, its genre can be used to ensure sensible images are sent for client-side resizing. The code below, for example, will display an image no larger than 500 pixels on a desktop browser, and no larger than 100 pixels on a mobile browser:

<img
  src='http://src.sencha.io/n500m100/http://sencha.com/files/u.jpg'
  alt='Max 500 or 100, depending on browser'
/>

Take it for a spin

The full documentation for the API is available here, with a summary of its syntax, new formulaic operators, and client-side measurements here.

Please let us know how you get on with these new features, and what else you might like to see form the service in the future. Enjoy!

“Instead of worrying about the interface, I could focus on building my application—enabling me to be more creative.”

It’s my personal project and the result of an idea that I developed after struggling to find an easy way to ask my friends about a product I was planning to buy. My goal was to build a tool that lets people ask a question on the go and get answers fast with the most basic privacy options and notification abilities.

Viewbeat also lets you discover more about your friends and find new like-minded people based on the answers they give. Thanks to the unique matching algorithm, you can find like-minded people with similar interests at the touch of a button and group them, as well as the topics and even topic options you like so you can follow them separately.

Why I Chose Sencha Touch

I carefully considered whether to go native or use a mobile framework that supports open web technologies. Being able to port my applications to several mobile platforms without a hassle was an important part of my criteria. After carefully examining my options, I decided to choose HTML5/JavaScript and add some PhoneGap to the mix, so I can use native application features such as notifications and access to the contacts list.

Before starting development, it was clear that I needed a touch-based UI framework that had components like sliding panels and action sheets with the look-and-feel of modern touch devices. Among the touch frameworks I reviewed, I decided to use Sencha Touch because it has all of the required components, packaged in an easy-to-use framework that I can use to build robust applications. Instead of worrying about the interface, I could focus on building my application — enabling me to be more creative.

With its strong Ext JS background, Sencha Touch also enabled me to develop my application using an MVC pattern that ensures that my application has the flexibility to be extended easily. As a developer with strong MVC experience, having a familiar pattern at hand made the development process more relaxing and less stressful.

Finally, the object-oriented approach of Sencha Touch let me create custom widgets and extend the capabilities of provided elements, making it a breeze to create custom functionality which is crucial for my application.

Business Value of Using Sencha Touch

Using the Sencha Touch framework, I completed the application in three months, mostly in my spare time, and cut my development time in half. I also got the benefit of a modern, rich UX, while having the freedom to focus on the details of designing and developing the internals of my application.

Advice to New Developers

Learning to use Sencha Touch was easy. Newcomers should start by watching the Sencha Touch video tutorials which provide a good overview. I also recommend going through the Kitchen Sink demo — it includes a lot of good examples for creating a rich, high quality UI.

Final Thoughts

I am quite satisfied with the outcome of this project and I’m going to continue building my upcoming mobile projects with Sencha Touch and PhoneGap. I believe that mobile is the way of the future for computing, and Sencha Touch will definitely be a big part of it.