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

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.

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.

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

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.

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.

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

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.

No to low Impact from “Accelerated Browsing”

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.

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.

Dyad Communications is a design firm located in Philadelphia, PA. We build sophisticated mobile websites that integrate the same aesthetic decisions our clients expect in our desktop and print work. Our goal is to give clients the same experience on their mobile devices, like the iPhone and iPad, as they have on their desktop website or native apps.

Why We Chose Sencha Touch

Despite the imminent “demise” of Flash, our clientele remains adamant that we develop sites that operate with a level of design sophistication and elegance that require the use of Flash for a lot of our work. Of course, the lack of support for the Flash player in iOS left us with an issue: how do we best present clients’ websites on mobile devices, in a way that cohesively presents the pre-defined aesthetic of their Flash interface?

“Using Sencha Touch, a small development team of 1-2 people can translate a large Flash site into an mobile HTML5 version within 3 weeks.”

When Sencha Touch was released, we were impressed by the robust library of pre-built components and the responsiveness with which they performed. Suddenly, we could apply our proficiency with Web standards to create mobile re-interpretations that feel as rich as their desktop counterparts. It didn’t take us long to realize that the possibilities inherent in the Sencha Touch framework would help us to easily dive into the new challenges of mobile usability, without spending any time coding touch-based interaction logic.

Sencha Touch provides a powerful framework for developing websites that feel like native apps. With Sencha Touch, we can easily implement a Carousel of large images that the user just swipes through like a native app. Using Ajax or JSON, it’s easy to tap into a new or existing content management system, pull data and place it onto a page. This makes it very easy to maintain multiple versions of a site, which is a key part of our efficient work philosophy.

Business Value of Using Sencha Touch

Using Sencha Touch, a small development team of 1-2 people can translate a large Flash site into an mobile HTML version within 3 weeks. Smaller sites can be developed in a matter of days. This saves a considerable amount of time in development. Using the built-in components of Sencha Touch, we reduce development time by days since we don’t have to implement many usability features like Carousel swiping and multimedia loading including video and audio.

It also reduces the time we spend debugging for other devices, such as Android, since Sencha Touch has built-in support for those devices. The reliable structure of Sencha Touch ensures that if the site is functional on one device, it will work comparatively on all other devices that support it. In the end, our clients get a robust mobile version of their desktop website that is enhanced with special touch features.

Our Advice to Developers

When approaching a new Sencha Touch project, we aim to incorporate the latest usability paradigms we see gaining traction in popular native apps with the aesthetic already defined in the Flash site we’re adapting. This means extending the API to build custom interactive components, so a strong understanding of OOP is a must. Getting your head wrapped around Sencha layout management is a great place to begin, and extensive use of the Sencha Touch API will give you many new options you didn’t know existed. If you are just starting out, Sencha offers very quick and easy video tutorials that give you a jumpstart on learning the basics about the Sencha Touch framework.

Final Thoughts

Sencha Touch has allowed us to open up new business opportunities with existing clients and expand the scope of what we can offer new clients without compromising time and profit. We highly recommend using Sencha Touch for not only apps but for mobile websites as well.

It’s been a really exciting month of news in the mobile app development space. HTML5 is coming in to its own as the premier application platform for building mobile apps. And while it’s been around for a while, it’s still new and unfamiliar to a lot of developers. There are folks looking at HTML5 for the first time, as well as people who are looking to take their HTML5 skills to mobile.

So, today we’re excited to let you know that we’re hosting a free roadshow at five cities in the United States to help developers get up to speed on HTML5 and also Sencha technologies! This free, half-day workshop is designed to educate developers on how they can leverage HTML5 in mobile and how to build rich applications built on open standards. If you’re new to HTML5 or new to mobile, this is the perfect workshop for you.

Bring your own laptop and join us to learn how to build mobile HTML5 applications. We’ll have Sencha experts on hand to show you the ropes of HTML5, and help walk you through app development in a fun, workshop environment. We’ll have coffee ready in the morning and work with you all the way through the free lunch in the afternoon. You’ll be building mobile web apps that work on the best touchscreen devices in no time.

We’ll be covering the following three topics:

• HTML5 basics: what it is and how it’s different from other mobile platforms
• Sencha Touch 101: getting your environment ready, and getting started
• Building with Native Packaging: get your app to the App Store fast

Space is limited, so if you’re interested, sign up now!

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

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.

Day three of our awesome conference in Austin last week really reaffirmed our belief in the strength of the Sencha community. I’ve rarely seen such a concentration of talent, enthusiasm, and friendship—not mention amazing productivity—come together so well.

We wanted to stimulate competition and organized a number of prize categories for the event. The Google Chrome team sponsored the event as a whole, and also kindly offered Chromebook hardware as a prize for ‘Best use of HTML5 API’. We also offered ‘Best Desktop’ and ‘Best Mobile’ categories, as well as spot prizes for additional interesting application categories.

Once our introductory pleasantries were over, we decided to make sure that teams could get coding as quickly as possible. The amicable vibe of the whole conference helped immediately, as cohesive groups quickly formed around exciting ideas that community members proposed.

Caffeine, power, and a decent wifi connection are the other ingredients required to keep teams working hard during the day. We just about managed all three, and certainly the arrival of the Red Bull support team helped any flagging programmers get through the final few hours.

By the time we reached 4pm—after over 6 hours of frantic coding, an astonishing 20 teams were ready to jump up onto our vast stage and present the results.

And what results they were: we had news visualizations, signal strength detectors, web-based file sharing, games, database administration tools, collaborative drawing and learning tools, social networks, and many many more. The variety was almost as amazing as the quality.

After a very tough judging session, we announced the main winners. And they were:

Best use of an HTML5 API: Lamp Post

Multi-user music file sharing using Chrome’s File API, featuring real-time chat and notification of shared directories using a Node JS backend with node-extjs. The team won a Chromebook and $500, kindly sponsored by Google Chrome.

Best Desktop App: Code Cowboys

A crowd-sourced unit testing application for Ext JS and Sencha Touch. The team won an iPad 2 and $500.

Best Mobile / Tablet App: Presencha

Upload slides in PDF form, and present live to any device for collaborative viewing by an audience. The team won an iPad 2 and $500.

The Presencha team have made their code available on GitHub, and are aiming to have their service available soon.

We then had a number of additional categories which teams were gunning for. Each of these teams won $250.

Best Social App: LinkedUp
A mobile social network for entrepreneurs and innovators.

Best Austin-related App: Dirty 6th
Shows bars, clubs and other venues near a user’s location or and in downtown Austin.

Best Educational App: iKnow
A mobile application to learn or memorize anything

Best App by a Novice Team: Doodleshare
A screen-sharing application to allow games such as Charades and Pictionary on mobile and tablet devices.

We also had two discretionary prizes for apps that impressed the judges above and beyond these categories. These were TouchMySql and the German Rockstars team.

At events like this, we hope that every one feels they are a winner! If you were there, I hoped you enjoyed the experience of being able to rub shoulders with your peers and the Sencha teams. It was an awesome way to wrap up the whole conference, and we look forward to hosting you all next year!

We had a fantastic time last week in Austin, hosting the Sencha Community for SenchaCon 2011! Once again, we had record attendance, with over 600 developers attending more than 50 sessions over two days, and a full day hackathon that produced some pretty impressive apps. We were incredibly humbled by the huge commitment that so many of the community made to spend three days engaging with the Sencha team and sharing their experiences with us and with each other.

At Sencha, we want to equip application developers to create the next generation of awesome apps. What we’ve seen in the last four years is a huge discontinuity in how and where end-users want to interact with data and content. The most obvious trend is the rise of mobile devices, but equally as important is the now-ubiquitous integration of social sharing and the emergence of HTML5 as the consensus technology platform of the future. As we go forward, we see a world with an ever-increasing diversity of devices and device APIs. It’s a world where HTML5 powers the client apps, and they’re enriched with local APIs that execute on everything from traditional desktops to Smart TV’s. And cloud services provide the fabric that enables continuous, shared experiences across the diversity of end-devices. We think this is the platform for the web.

It’s clear that the world is going through what we call “The Big App Rewrite”. And one of our big goals at SenchaCon was to outline how our products are going to evolve to help you create applications for that world. As we shared in our keynote, we’re focused on the three building blocks you’ll need to build your apps: frameworks, tools and cloud services. In frameworks, we showed off the latest in Ext JS 4, Sencha Touch 2 and Ext GWT 3. In tools, we demonstrated the latest in Sencha Designer and Animator. And we were also very excited to launch the full set of Sencha.io mobile cloud services.

The Big Announcements and Introductions!

As mentioned above, SenchaCon attendees got first look at some pretty cool stuff that we’ve been working on. We’ll be blogging about these in more detail soon. But here are the highlights:

• The official beta of Sencha.io—an insanely easy-to-use set of mobile cloud services designed to plug easily into Sencha Touch.
• The developer preview of Sencha Designer 2.0, now with support for creating Sencha Touch apps, event bindings, code editing and even native packaging
• The preliminary performance numbers from Ext JS 4.1 showing the 2x performance improvement we’ve been able to engineer over 4.0
• Live demos of the developer preview of Sencha Touch 2 showing the much improved Android and orientation change performance
• The latest preview of the all-new Ext GWT 3 with Cell-based data widgets, Cell-based fields, a new data API, new charts, and theming.

We also announced that we’ve raised another $15M in Series B funding. The round was led by Jafco Ventures with the participation of our existing funding partners, Sequoia Capital and Radar Partners. We’d like to welcome Jafco to the Sencha community!

The Ever Growing Sencha Community

There are now over 1.6 million Sencha developers in 201 countries and in 33 different timezones. And 300,000 of you are now registered on our forums. We truly are a worldwide community! We’ve had 68 meet ups this year! And we’re proud to say that we see more and more community members starting up new groups in your cities. We gave sneak peeks of a couple of really cool things coming down the road for the community and our partners. The first was a new partnership program that adds two new tiers of service partnerships to the existing community tier of www.senchadevs.com. (We’ll be rolling this out fully in Q1 of next year.) And we also showed a super-fast sneak peek of the Sencha Marketplace, a listing service for the community to showcase their user extensions, themes, templates and plugins. We’re really excited about this and look forward to your feedback as we move toward launching this.

The Top Rated Sessions

This year’s session content got a huge thumbs up—thanks in part to listening to all of your suggestions from last year’s SenchaCon. By far the crowd favorite of the conference was Jacky Nguyen’s commanding performance on the new Ext JS 4 class system. Jacky also showed off some very cool performance wizardry for Sencha Touch that we hope to ship in Touch 2. In addition, we want to give a special shout-out to Craig Walker of Xero, whose node.js session also got huge thumbs up from our crowd.

Slides and Video Recordings

The Sencha Team and all our community code presenters made a huge effort to create fantastic content for this year’s conference. And soon, we’ll be able to share it with the whole community. We’ll start uploading session slides later this week, and as soon as the videos are finished in post-processing we’ll also be releasing those. Conference attendees will be able to access videos first, but shortly thereafter, we’ll release them to the general community.

We had an awesome time hosting SenchaCon 2011. We want to thank everyone for their amazing contributions and we look forward to seeing you at the next conference!