Automating Unit Tests

One of the first questions I always hear when starting with a new client is “How can I build unit tests for my application?”

It’s obvious that many people understand the benefits of unit tests—developers want to minimize the number of bugs in their code and managers want to reduce the amount of time required to test an application before release. Although the concept of unit testing has existed for years, software teams are only now beginning to explore building tests for their Rich Internet Applications (RIAs).

In my experience, it’s obvious that most people don’t fully understand what it means to build unit tests for RIAs. Considering there are few tutorials explaining how to accomplish this, I wanted to share a recent experience with the community in hopes that it will stimulate ideas and discussion.

Keep an open mind as you follow along with this post and think about how these examples might fit into your own processes. This implementation is one of any number of possible solutions, and I don’t attempt to solve every problem. That being said, implementing unit tests into your project will produce cleaner, more stable code and will reinforce coding standards throughout your organization.

I. Unit Testing Web Applications: An Overview

Layers Diagram

In the diagram above, the “Presentation Layer” represents the user interface – which in the case of RIAs is frequently a JavaScript-driven DOM. This is the case for most Ext JS and Sencha Touch applications.

When building unit tests for RIAs, it’s important to remember that the user interface (the “presentation layer”) is very different from the supporting layers of the application.

The UI accepts random input from the user and is expected to look AND behave the same across many environments (which is both subjective AND objective). One language (JavaScript) performs multiple tasks (logic and presentation). Because its code is never compiled, syntax errors in JavaScript are often not discovered until runtime.

Thus developers more familiar with server-side unit tests often fail to realize the complexity involved in writing unit tests for JavaScript-driven applications. As a result, we cannot build unit tests for the presentation layer in the same way we would for the underlying data-driven tiers of an application.

Because the presentation layer has multiple responsibilities, it is important to separate unit tests into the following three areas:

  • Syntax Checks – Syntax checks are not exactly unit tests because there is no logic being tested. Instead we analyze our code for syntactical errors – errors that may or may not be caught before application execution.
  • Unit Tests – True to its contemporary meaning within software development, unit tests are a series of objective logic tests. Unit tests attempt to isolate small pieces of our code: given specific inputs, unit tests expect specific outputs. In this manner unit tests are essentially mathematical proofs (remember those from high school?) that confirm what our business logic is supposed to do.
  • UI Tests (aka Integration Tests) – UI Tests are not the same as unit tests. UI Tests attempt to subjectively verify that elements on the screen behave (and/or look) as expected when a user performs a given action. There is no math or logic involved: the tests render the environment as a whole (containing all runtime dependencies) and wait to verify that the DOM has changed in a desired way. You can think of these tests as a robot manually testing the application.

I do not attempt to solve the problem of UI Tests in this post, but there are helpful links are included at the end if you’re interested.

II. A Sample Application

The key to implementing unit tests is to automate the process – if the tests aren’t run every time the code changes (or at some regular interval), the tests become ineffective and useless.

I have created a sample project that uses shell scripts to run each individual part (syntax checks and unit tests). These scripts return status codes upon success and failure.

The specific process to integrate these automated tests may be quite different at every company. The shell scripts might provide automation by:

  • being integrated into a build process (e.g. via Ant)
  • being integrated into source control hooks (e.g. a Git pre-commit hook on your local machine)

III. Pre-Requisites

The sample project (and the concepts explained below) assume a certain degree of knowledge on the following tools:

  • Sencha SDK Tools (v2.0.0b3) – a suite of automation tools assisting with application creation, development and deployment
  • PhantomJS (v1.4.1) – a headless WebKit browser controller via an easy JavaScript API
  • JSLint (v2012-05-09) – a JavaScript code quality tool
  • PhantomLint (v1.2.1) – an add-on to Phantom.js that automatically lints all JavaScript files in a project
  • Jasmine (v1.2.0) – a behavior-driven development framework for testing JavaScript code

The shell scripts in the sample project were targeted towards Mac OSX/Linux users. However, Windows batch (.bat) files or Ant scripts can easily accomplish the same thing and should be easy to create.

Also, if you’re new to the world of unit testing I would highly recommend the book Test Driven JavaScript Development by Christian Johansen.

IV. Syntax Checks

While there are a variety of syntax-checking tools available for JavaScript, perhaps the most widely recognized is JSLint. Those of you familiar with the tool should remember that “JSLint will hurt your feelings” – it complains about everything! On the other hand, it is also highly configurable and helps our code be clean, stable and consistent.

Because JSLint is written in JavaScript, it is traditionally run in the browser on Douglass Crockford’s website ( Although this manual process is sometimes convenient, it is difficult to run against multiple files and impossible to automate.

A better solution is to use PhantomJS – a headless WebKit browser that provides the web environment necessary to run JSLint and our own JavaScript code. Additionally, PhantomJS can access the filesystem; this allows us to execute multiple files against JSLint and report back some success or failure status.

To further simplify the process of checking all of our JavaScript files, I have incorporated a pet project of mine called PhantomLint which logs errors to an output file. In this way, a failure status can alert developers to take corrective action.

Taking a look in the sample project under /tests/, you should see a shell script named “”. This script launches the PhantomJS environment and initializes PhantomLint for us (JSLint-Runner.js). Given its configuration options, PhantomLint then dives into the filesystem to test our code against JSLint. Any errors are then output to a text file.

If you run the shell script, you should notice a single error in our application code:

     Line #: 37
     Char #: 21
     Reason: Unexpected 'else' after 'return'.

In this case, JSLint tells us that we have a redundant “else” statement.

V. Unit Tests

There are a variety of JavaScript unit test frameworks currently available, and I chose Jasmine for this sample app. Why Jasmine? It is one of the more popular frameworks currently available, it has an active development community, and Sencha uses it internally to test our own code. Jasmine also has a very fluent API – this makes our test suite easy to understand. By nesting test conditions appropriately, we can build very powerful and descriptive test suites.

The tests can be run locally by visiting the “spec_runner.html” file under the /tests/ folder in one’s browser. The individual test files are located under the /tests/app/ directory.

Let’s start by looking at the class ChicagoMeetup.MeetupApiUtil. This class is ideal for unit testing because it has very few dependencies and doesn’t directly interact with the DOM; it is simply a collection of utility methods that perform logical operations.

Taking a look at the tests inside /tests/app/MeetupApiUtil.js you can see how the unit tests objectively analyze the methods for this class. Each test condition provides a specific input value and expects a specific output value.

describe('ChicagoMeetup.MeetupApiUtil', function() {
        describe('getUsersUrl() method', function() {
                it('should be a function', function() {
                        expect(typeof ChicagoMeetup.MeetupApiUtil.getUsersUrl).toEqual('function');
                it('should return a string', function() {
                        expect(typeof ChicagoMeetup.MeetupApiUtil.getUsersUrl()).toEqual('string');

The ChicagoMeetup.MeetupApiUtil class and the related unit tests are a terribly simple example – in fact there’s very little logic involved. More often than not, we want to build unit tests for custom components in our Sencha applications. How can we achieve this?

Consider the class ChicagoMeetup.view.Events in our sample application. This is a custom class, extended from Ext.grid.Panel, that contains some specific methods and behavior for our app.

In our test code (/tests/app/view/Events.js) we first create setup and teardown methods that provide fresh instances of our custom component for each test case. We do this to avoid polluting our test environment with abandoned objects and DOM elements.

describe('ChicagoMeetup.view.Events', function() {
        //reusable scoped variable
        var eventGrid = null;
        beforeEach(function() {
                //create a fresh grid for every test to avoid test pollution
                eventGrid = Ext.create('ChicagoMeetup.view.Events', {
                        renderTo : 'test' //see spec-runner.html to see where this is defined
        afterEach(function() {
                //destroy the grid after every test so we don't pollute the environment
        it('should inherit from Ext.grid.Panel', function() {

It is important to note that we temporarily render our custom component to the DOM for each test (via the “renderTo” config). We do this in order to test any logic that might depend on the DOM – but the key is to destroy these components in-between tests so the greater test environment is not polluted (negatively affecting subsequent tests).

Although we are rendering the component to the DOM, I have to re-emphasize that we are not using Jasmine to build UI (or integration) tests. Jasmine doesn’t care what the components look like – our unit tests are only here to analyze the business logic.

Now that we understand how to properly unit test our components, the next step is automating this process. Similar to how we automated our syntax checks, we will again use PhantomJS to run our unit tests and output failure messages to a log file.

Taking a look in the sample project under /tests/, you should see a shell script named “”. This script launches PhantomJS and initializes the Jasmine parser for us (Jasmine-Runner.js). After our tests have run, any test failures are output to a text file.

If you run the shell script, you should notice a single test failure:

Spec: linkRenderer() method
     - should return a string (HTML link snippet)
Failure Message:
     - Expected 'string' to equal 'function'.

In this case, Jasmine tells us that a test against linkRenderer() failed. We expected that this method would return a function, but our test case encountered a string. This particular example fails because the spec incorrectly expected “function” – which demonstrates that unit tests can contain errors themselves!

describe('linkRenderer() method', function() {
        it('should return a string (HTML link snippet)', function() {
                var testUrl = '';
                expect(typeof eventGrid.linkRenderer).toEqual('function');
                expect(typeof eventGrid.linkRenderer(testUrl)).toEqual('function'); //THIS SHOULD FAIL! We should have written toEqual('string')
                //TODO: more robust regular expression checks to ensure this is *actually* an HTML link tag, correctly formatted

It is unrealistic and nearly impossible to achieve 100% code coverage. Because unit tests are designed to test small pieces of code in isolation, it becomes very difficult to write good tests for pieces with many dependencies or major DOM interactions. Try to focus on problem areas or base classes, and write tests that check for bugs as they pop up (to prevent regressions).

VI. UI Tests

As I mentioned earlier, I am not attempting to solve the problem of UI Tests in this post. Testing the look and the complex interactions of an application is a humongous task, and is a topic better suited for its own dedicated tutorial.

That being said, here are some of my thoughts on accomplishing UI Tests:

  • Building UI tests for dynamic RIA’s is sufficiently difficult because the DOM is always changing in unpredictable ways. Tools like Selenium use XPATH or CSS selectors to verify “success” – but because the DOM is unpredictable, the tests written for these tools become very brittle. Thus maintaining your tests often takes more time than creating new features.
  • Many prominent UI developers prefer to use “specification” rather than “UI tests” for exactly these reasons. A good resource for you is the book “Specification by Example”, in which tools like Cucumber are recommended.
  • Siesta is becoming a more popular tool for automated UI testing and is certainly worth a look.

VII. Conclusion

Unit tests are an important part of the software development process. By clearly defining what we expect from our code, unit tests allow us to develop a high degree of confidence that our applications will function as intended. Automating our unit tests reduces the number of bugs and decreases the amount of time we need to spend manually testing our code.

Take a look at the sample project on GitHub and consider how this solution might integrate with your own processes. This post is meant to foster ideas and discussion within the community – so please chime in with questions, comments and solutions of your own! Feel free to fork the sample project and add or edit the examples!

20120801-unit-tests.jpg 30 Comments   Read more

Sencha Touch 2 Beta 3: Kindle Fire and Chrome Support

Sencha Touch 2 Beta 3: Kindle Fire and Chrome Support Today we’re releasing Sencha Touch 2 Beta 3 with expanded device and browser support. Beta 3 is expected to be the final beta release and a drop-in replacement for Beta 2. While everything is detailed in the release notes, the most notable changes in b3 are improvements in application dependency management and a host of performance improvements.

Download Sencha Touch 2 Beta   View Release Notes

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

h3. 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 x 800 resolution, and the second is a Kindle Fire, which displays impressive performance for a device costing under $200:

Sencha Touch 2 Support Android Chrome and Kindle Fire. View video on Vimeo

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.

h3. 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.

h3. 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.

20120214-touch-2-thumb.jpg 29 Comments   Read more

HTML5 Scorecard: Chrome for Android Beta

Sencha HTML5 Developer Scorecard of Chrome for Android beta

Chrome for Android icon 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.

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

h3. 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.

h3. 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 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.

Chrome for Android running on a tablet and phone

Chrome for Android running on a tablet and phone

h3. 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.

h3. 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.

h3. 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.

h3. 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.

20120209-chrome-for-android-thumb.png 14 Comments   Read more

Sencha Touch 2 Beta—Raising The Bar

Two years ago, we set out on a journey to make the web mobile. Today, we’re raising the bar with the release of Sencha Touch 2 Beta.

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!

h3. 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.

h4. 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.

Sencha Touch 2 Docs

Touch 2 Docs feature 20 new guides, code samples, and editable examples.
Visit the Touch 2 Docs

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.

Jog with Friends, a new Facebook example app in Sencha Touch 2

h4. 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 on a WebKit browser.

h3. 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.

h4. 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.

h4. 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

Ext.define('MyApp.controller.Products', {
        extend: '',
        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.

h4. 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:

        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() {

And one for Phones:

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

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.

h3. 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.

Touch 2 beta Component Dataview

The KivaTouch demo app uses a Component DataView to show funding progress.

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.

Sencha Touch 2 Navigation View. View video on Vimeo

h3. 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.

h3. 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!

h3. 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.

touch-2-thumb.jpg 48 Comments   Read more

Android–Ice Cream Sandwich: The HTML5 Developer Scorecard

Samsung Galaxy Nexus

As part of our continuing series, we ran the new Galaxy Nexus through our tests to see how it stacks up as an HTML5 app platform.

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.

h3. 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.

h3. 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 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.

Feature Android 4 iOS 5
overflow-scrolling No Yes
File API Yes No
History Management No Yes
Shared Workers No Yes
Web Sockets No Yes
Web Workers No Yes
Various Input Types Half Full
Emoji (not part of HTML5) No Yes

h3. 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.

Galaxy Nexus SunSpider results

Like most devices in the dual-core Cortex-A9 family, the Galaxy Nexus has predictably good JavaScript performance. *Note:* This image was updated on Dec 14 at 1:30 PM PST.

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, 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.”

h3. 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.

h3. Ice Cream Sandwich: Suggestions for the HTML5 App Developer

HTML5 logo 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!)

sencha-samsung-galaxy-nexus.png 13 Comments   Read more

HTML5 Scorecard: Amazon Kindle Fire

As part of our continuing series, we ran the new Amazon Kindle Fire through our tests to see how it stacks up as an HTML5 app platform.

As part of our continuing series on the HTML5 capabilities of new mobile platforms, we’re taking the measure of the new “Amazon Kindle Fire”: When the Kindle Fire was announced, we were excited about getting our hands on it. As the first mass market tablet at the $200 price point, we knew it had a good shot at selling millions of units. But at the same time, we were apprehensive that Amazon might have skimped on hardware capabilities to reach that price. We were also concerned about the browser platform. The Fire runs a customized version of Android 2.3.4 (Gingerbread) and in the past, we’ve been disappointed with the quality and completeness of that browser. We were hoping that Amazon would improve the stock Gingerbread browser significantly.

The Kindle Fire is a competent but minimal HTML5 platform that reflects its $200 price and Android 2.x lineage.”

After putting the Kindle Fire through our test wringer, we can say that while it’s a solid browser for normal page browsing, it lags the best of the competition in HTML5 capabilities. Constrained by its Gingerbread foundation, it’s a competent but minimal HTML5 platform that reflects its $200 price point. At this stage in the tablet game, we would expect better.

h3. 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.

h3. Acid3 and Modernizr

The Fire scores a less than perfect 95/100 on the Acid3 test. Like other Android tablets, it lacks SVG support and incorrectly displays the Acid3 visual test compared to the reference implementation. With both the iPad2 and the BlackBerry PlayBook now scoring 100/100, this puts the Fire behind the pack. In addition. the Fire failed test 46 (media queries) and came in slower than required on three other tests including the self-described “challenging” test 26 for garbage collection speed.

We then turned to Modernizr, one of our favorite tools to look under the hood of a browser. Since the Fire hardware lacks a camera, an accelerometer and a GPS, some of the results (geolocation failure!) are predictable. What Modernizr did find was support for CSS 2D transforms and Canvas as well as other Android 2.x capabilities. Notably absent: 3D transforms, web sockets, web workers and many HTML form input types. Again, not that surprising considering the Android 2.x heritage.

Happily, web fonts seem to be well supported. Both Google Fonts and Typekit dynamic fonts render correctly. But Typekit font loading and page scrolling on the Google Fonts page (with tens of different onscreen web fonts) was noticeably slow.

h3. Performance Testing

When checking the user agent received, web servers report that our Fire was using WebKit version 533.1, which is much older than the WebKit found on the Xoom and PlayBook. On other hand, when the Kindle is put in “desktop browsing mode”, it advertises itself as Safari 5/Mac OS X/Webkit 533.16. Under the hood, according to the iFixit teardown, the Fire contains a dual-core ARM processor, specifically the TI OMAP 4430, which is the same processor as the BlackBerry PlayBook. 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.

Amazon Kindle Fire SunSpider results

For the most part, the Amazon Kindle Fire has similar SunSpider results compared to Apple iPad 2 and BlackBerry PlayBook.

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.

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. While the game did play, the frame rate was poor and touch responsiveness while animations were running was also substandard. The Fire lacks a separate GPU, but the CPU has a competent GPU core – and even so, it looks like it wasn’t leveraged for hardware acceleration. The Playbook, for example, does a far better job leveraging the same GPU core.

Next we tried simpler animations. The Fire performed more smoothly, but had a notably bad implementation of timing. In the video below, the wave movements are controlled by CSS3 animations and are declared at constant speed. Instead, the animation speeds of each element diverge and lag noticeably and visibly from each other. We’ve never seen artifacts of this magnitude before. This got us wondering about the Kindle’s general timer quality, so we ran John Resig’s classic JavaScript timer test and found that the quality of the timer is similar to other Androids: with setInterval triggered every 10ms +5/-3s, with some noticeable latency spikes. (This compares to iOS 5’s best-in-class implementation of 10ms +/-1ms.) This isn’t supposed to matter as much once people get used to using requestAnimationFrame for JavaScript animations, but the Fire doesn’t have that either.

CSS3 Animations on the Amazon Kindle Fire

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 happily also works although Android’s tendency to toggle into low-quality mode when moving content reared its head once again. We also tried out Canvas Cycle and it worked reasonably well. The frame rate was solid and we were able to change the scene without issue. However, like all webkit implementations, all bets were off when we zoomed and panned the page. Animation stuttered, froze and occasionally the accompanying audio cut out. We also looked at other Canvas animations and they worked at reasonable frame-rates.

Finally we tested embedded HTML5 audio and video. HTML5 audio playback seemed to work well, although the default playback controls were tiny, hard to touch and didn’t seem to work very well. HTML5 video is “supported’ but tapping play simply launches the video in the native player. Complete HTML5 video support with embedded playback and effects is not there. There also appears to be no Ogg Theora codec on the device as we couldn’t get any Ogg Theora demo to play.

The Kindle Fire doesn’t seem designed to run HTML5 apps as a primary goal.”

h3. 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.

The first thing we noticed were the crispy CSS rounded corners. They’re not anti-aliased properly on the Fire. Webkit masks are also not supported. Then we got our first really big surprise of our run through. We found that the Kindle Fire has problems processing touch events with good responsiveness. Update: and we’re not the only reviewers to notice this . And similar to early HTC phones (since fixed), the OS and browser seem to fight over who gets touch events. Sencha Touch 2 was designed to adapt to this behavior, so the Touch 2 preview kitchen sink works better than the Touch 1 version. And of course, since the Fire is based on Android 2.x, full multi-touch with independently tracked touches is not supported either.

As you’d expect with a device lacking a GPU, graphics effects like transitions were less than smooth, although display artifacts were not as bad as the full screen flashes and repaints that are a problem on honeycomb based tablets.

h3. No to low Impact from “Accelerated Browsing”

Amazon Silk One of the main selling points of the Kindle browser is supposed to be its cloud-caching and pipelined HTTP connection that uses the SPDY protocol. This does seem to speed up normal page browsing a little, but it’s not very noticeable and we didn’t test this rigorously. But for HTML5 web apps, where code is downloaded and executed, there doesn’t seem to be any performance difference when we tested with acceleration on and off. It doesn’t appear as if client JavaScript is executed on the server-side at all, so the Kindle does not seem to have Opera Mini-style server-side execution. And SunSpider scores were essentially the same when accelerated browsing was turned on or off.

Side-by-side comparison of accelerated vs. unaccelerated browsing for some popular web home pages.

h3. Kindle Fire: Suggestions for the HTML5 App Developer

In summary, the Amazon Kindle Fire doesn’t seem designed to run HTML5 apps as a primary goal. It does a good job of displaying ordinary web pages and its resolution and rendering capabilities meet that need well. But there are too many sharp edges, performance issues, and missing HTML5 features for us to recommend that any developer create web apps primarily for the Kindle Fire. The iPad 2 running iOS 5 continues to be the tablet to beat, with the PlayBook a respectable runner-up in HTML5 capabilities.

sencha-html5-kindle-fire-thumb.jpg 20 Comments   Read more

Apple iOS 5: HTML5 Developer Scorecard

Apple iPhone 4S with Sencha logo Whenever a new device or mobile operating system comes out, we do our HTML5 Developer Scorecard to help folks who are building mobile web apps understand how to take advantage of these new devices. In early October, iOS 5 (and the iPhone 4S) was released. In our last few reviews, iOS has come head and shoulders above other device platforms as the best platform for HTML5 developers. High performance, hardware accelerated rendering, super quick JavaScript, and speed of adoption of new HTML5 features, it’s been the best platform to build modern web apps on.

Mobile Safari continues to hold the crown as the best mobile browser, providing the best HTML5 developer platform.”

The latest Mobile Safari on iOS 5 continues in that tradition. Mobile Safari continues to hold the crown as the best mobile browser, providing the best HTML5 developer platform as well as adding new features and improving others.

As usual, we looked at the basics of the browser: JavaScript and HTML/CSS rendering. For raw JavaScript execution speed, iOS 5 (with the iPhone 4S) isn’t much of a surprise and looks a lot like any other dual-core mobile device (such as the PlayBook and the iPad 2). It scored 2,275ms on the SunSpider benchmark: a solid score, but nothing new in the current hardware landscape. Things that iOS was good at continued to be good, such as smooth and fast hardware accelerated CSS3 transitions and animations. Our typical Sencha Animator tests ran smoothly and continued to render at a higher frame-rate than any other mobile device we’ve seen.

Given how good Mobile Safari has been, we didn’t run the browser through the usual paces we would have. Instead for this HTML5 Developer Scorecard, we took a look at the things that are new or better on the latest Mobile Safari:

* Canvas is crazy fast. In iOS 5, Canvas is between 5x – 8x faster. We tried two examples to see this work. First, the IE HTML5 “Speed Reading”: Test. In iOS 4.x, the draw durations last roughly ~850ms, versus iOS 5, where they are a constant 10ms. Since that might be too synthetic, we also tried the Flash Canvas “image manipulation benchmark”: It reports the number of milliseconds the manipulation sequence takes. On iOS 4.x, this was ~19,000ms, but on iOS 5 it reported ~450ms. As with all benchmarks, take the result with a grain of salt, but for game developers building on Canvas, iOS 5 is a *much* more attractive platform for graphics.

* WebGL logoWebGL is supported. Sort of. If you’re an iAd developer, you can use WebGL in your ads, but you can’t use it through Mobile Safari or through a wrapped UIWebView. This is a limitation put in place intentionally by Apple as it’s possible to “work around”: the restriction in a wrapped UIWebView, but only by linking to private APIs — which means you can’t submit the resulting app to the app store.

* You can use compass directions! The DeviceOrientationEvent now supports compass headings via a new webkitCompassHeading property. The property gives you the device’s orientation relative to magnetic north. Check out James’ “sample”: on your iOS 5 device to see it working.

* Better CSS position and overflow support. In iOS 5, position: fixed and overflow: scroll both work. If you’re looking to add some scrollable areas with native feeling bounce, you can now do it with these CSS properties. You don’t get a ton of control but if you’re looking to have a scrollable area in your web app, this is a really quick way to get it. There’s also a special iOS property, -webkit-overflow-scrolling: touch, which changes the scroll behavior to be more “iPhone”-like.

* WebWorkers work! In our testing we confirmed that WebWorkers — the API to let you spin up background “threads” is now enabled in iOS 5. It makes sense that this arrives just as the iPhone goes multi-core. This is great for developers who need to do some background processing in their application. That can be data updates to a server, or preprocessing some information, or anything else you can imagine when you don’t want to block the main browser UI thread. Now that iOS 5 has support for the API, we’re interested to see how it’ll end up being used in mobile (and in using it ourselves).

* HTML5 form fields are supported, including number, range, and date picker. This is great for an HTML5 developer because iOS now opens the appropriate on-screen keyboard based on the input tag type.

* XmlHttpRequest, level 2 is supported. Anybody who builds complex apps that use XHR to talk to a server is used to the hacks that XHR level 1 required. In iOS 5, XHR level 2 is supported so you can use capabilities like cross-origin support, binary data support, and more.

Apple iOS5 icon Mobile Safari in iOS 5 continues Apple’s tradition of delivering a first class browser and innovating in device APIs. Of course, there are more we’d like to see soon, primarily the MediaCapture APIs so web developers can get better access to the device camera. We’re particularly happy about the super-fast Canvas and really interested to see what developers will do with WebWorker support in mobile.

ios5-sencha-thumb.png 10 Comments   Read more

Sencha Animator Released: A Revolution in Mobile Animation

Sencha Animator Released: A Revolution in Mobile Animation

h3. Introducing Sencha Animator 1.0

We spent the last few months working very hard (and very quietly) to bring you a product that we think will redefine the creation of animations on mobile devices. And now it’s here: today we’re very proud to announce the first release of Sencha Animator.

View Sencha Animator CSS3 Demos Download Sencha Animator

h3. What is Sencha Animator?

Sencha Animator is a desktop application that enables interactive designers to easily create rich media animations based on web standards for modern mobile devices. Until recently, rich media advertising on the desktop web has been enabled by the Flash plugin. But with no Flash support on iOS, interactive designers have been looking for a way to bring animations and rich interactivity to mobile devices without hand-coding hundreds, if not thousands of lines of JavaScript, CSS3, Canvas, or native code.

Museum of Science demo advertisement

Museum of Science demo advert, tailored for iPad dimensions

Last year, we looked at the various techniques for mobile animation and decided to focus initially on CSS3 Animations. Animations built with CSS3 have a considerable advantage over any other mobile animation technique: they look, feel, and run beautifully. And on most mobile browsers CSS3 is hardware accelerated, so it consumes very little CPU power while running at high framerates. In addition, since CSS3 Animations are just styling, browsers that don’t support them can still fall back to viewing un-animated content.

For these reason, we decided to start out using CSS3 animations. We try to be as faithful as possible to the underlying technology in Animator. We’re giving designers a simpler way to build animations while making the output friendly to hand-editing and further extension.

View Museum of Science Demo video

The road to CSS3 animations

During the last year, the Animator team at Sencha has worked to bring an innovative technology in a familiar working experience to interactive designers and creative agencies. Those of you who followed the evolution of Sencha Animator will appreciate how much we’ve refined your working experience.

Every area of the product has been honed and perfected with community feedback and a fantastic group of professional designers and user experience experts contributed to the creation of a user interface that is both easy to use, yet extremely powerful.

And while the first release of Sencha Animator produces WebKit compatible animations, but now that CSS Animations are also part of Firefox, Opera and IE10, we’ll be adding support for those browsers in time as well.

Each design decision has been made with a conscious effort to help designers be as productive as possible, as quickly as possible. So let’s go over the major features of Sencha Animator 1.0:

Sleek Dark UI

h4. A UI that gets out of your way

The Sencha Animator interface is designed using dark tones to let designers concentrate on what really matters — their own creative work — while the tool chrome fades into the background. Key actions in the UI are highlighted with accent blues to guide designers to available actions.

On top of the visual design, Animator focuses on productivity. To make it easier to work on small screens, almost every panel is collapsible so you can maximize the canvas area. Keyboard jockeys can use the arrow keys to nudge objects. Smart guides are triggered when moving objects on the canvas to help align things properly on the fly. To make it easier to see the results of edits, properties in the Property panel feature “drag to edit” and keyboard increments/decrements so designers can adjust properties to exactly the effect they want.

h4. Intuitive timeline, multiple scene support

The timeline is the heart of any animation: it’s here where you can take a static object and bring your artwork to life. For each object on the stage, the animation track shows its visibility, the presence of keyed animations and their timing. The track is easily editable with the mouse, and can be finely customized by using one of our pre-set easing curves or with the powerful custom easing tool.

Every object, and object group, can be locked and hidden to facilitate tweaking of individual elements, and a simple but effective “scene end” marker lets you define the length of each scene.

Animator supports complex nested objects, but it’s easy to tell if anything is happening inside a collapsed nested group at a glance by using the nested animation indicator.

Nested timeline collapsed

Nested Timeline Expanded

For bigger and interactive projects, putting everything in a single timeline can become confusing and hard to manage. The Scene system allows you to split your projects into several scenes keeping the timeline free from clutter and your project better organized.

By default, when a scene is finished, the animation will go to the next scene, however this can be customized in different ways (more on this later). Scenes can even be previewed by hovering on its thumbnail, making it easy to find the right one to edit.

Multiple scenes at your fingertips

h4. Object Library

Animator also offers an Object Library that lets you save your objects for later reuse in the same project, and for use in a different project via export. This new feature facilitates the creation of multiple animations using the same branded elements (logos, buttons, etc) and simplifies the job of maintaining a consistent look and feel across multiple projects and collaborators.

Object Library

h4. Templates

In studios and agencies, interactive designers often find themselves working on multiple projects for the same client, or building multiple creatives for the same device. Animator makes this easy for designers, letting you save a project as a template, then start a new project from that template. Templates are simple Animator files that can easily be shared with colleagues and collaborators and used as a consistent starting point for projects.

h4. Advanced interactivity and output options

This is the piece interactive designers are going to love the most: Animator lets you use JavaScript almost everywhere. You can add JavaScript to objects, to scenes or in the head of the exported HTML + CSS output. In a scene’s properties for example, you have the ability to add interaction at the scene’s start, at the end and on mouse/touch move. There’s a choice of pre-packaged interactions like opening a URL in the same window, skipping to another scene, or adding your own JavaScript. In addition to this, Animator output is intentionally highly human readable.

You can also choose to minify your export, or to activate ORMMA support. Designers unfamiliar with web technologies have direct access to the exported code, so they can easily understand how their creations work under the hood, while advanced users have complete control over the output, giving them the freedom to push the envelope. And pushing the envelope is not an expression we’re using lightly here. Just take a look at the demo that our beta tester agency created with Animator:

KickFu game demo

KickFu game demo, made with Sencha Animator by View video of demo

When we saw this for the first time, the offices at Sencha were speechless with what a skilled designer can do with Sencha Animator, and we hope you will be too.

h4. ORMMA Support

Animations are a key part of any interactive brand campaign, and Sencha Animator makes it incredibly easy to build advertising assets. Animator produces creatives that are compatible with any mobile ad network that can serve rich media ads. This is thanks to our support for an up-and-coming standard called ORMMA (Open Rich Media Mobile Advertising). All major mobile networks support it, and it eliminates the need to code an ad for a specific network, and reduces re-work that’s often required to run campaigns on multiple systems and apps.

ORMMA logo

With Sencha Animator, designers don’t have to develop for the lowest common denominator anymore, but build experiences that are designed to work on different devices, ad networks and delivery methods.

Go ahead, amaze us

As you can probably tell, we’re incredibly excited to release Sencha Animator, but we didn’t do it alone: we had the help and support of an incredible group of artists and developers from various backgrounds that were so gracious to help us test the product and helped us fine tune it. A special thanks goes to the many people that have contributed their critiques, suggestions and guidance to Animator. We should also note here that we built Sencha Animator itself using Ext JS wrapped with native packaging: this has allowed us to simultaneously ship versions for Mac, Windows and Linux.

Sencha Animator icon

We can’t wait to see what all of you will be able to do with Animator, and we are excited that you will surpass our wildest expectations. Go ahead, download the trial and we look forward to being amazed.

h3. Pricing and availability

Sencha Animator is available today at $199 from the Sencha Store. Discount packs are also available.

sencha-animator-1.png 21 Comments   Read more