Have you ever wondered what it would be like to live like rock royalty? Well now is your chance! We are giving away the chance to win one of THREE Rockstar Packages to anyone who registers for SenchaCon 2013 by June 7, 2013.

Picture this...

You are greeted at the airport by one of those people holding a sign with your name on it. On the 40 minute ride from the airport to the Swan & Dolphin Resort, you sip a cold beverage and think about how awesome you are.

When you arrive at the Swan & Dolphin, you are escorted to your PRESIDENTIAL suite complete with Wet Bar, Jacuzzi, and maybe even a Grand Piano. Say what?!

You enter the impressive foyer to find a Welcome Gift Basket and BlackBerry Z10 waiting for you. You take a leisurely stroll around your 2500+ square foot suite to check out the massive bedroom and expansive parlor only to be distracted by the sprawling views of the Swan & Dolphin Resort overlooking Crescent Lake.

You decide to head out to the terrace to relax and truly appreciate how awesome it is to be you. After killing time being awesome, you decide to grab your BB10 and call up a few colleagues to brag to them (I mean, invite them) to join you in the parlor before you head down to the SenchaCon Welcome Reception.

You crack open some tasty snacks and a couple drinks from the gift basket to share with your friends and listen to them incessantly praise you on how lucky you are. Someone starts playing the piano and surprisingly they aren’t bad.

It’s now about 7:15pm, so you decide it’s time to make a fashionably-late appearance at the Welcome Reception. As you and your posse head downstairs, you notice people staring at you wondering if they should ask to take a picture with you.

When you arrive at the registration desk, you are donned with the SenchaCon Rockstar Badge, and as you walk through the door to the party, heads turn, mouths drop and you think...

It rocks to be me.

Want this? Register for SenchaCon 2013 now and enter to win Rockstar treatment!

Only one person can win the Presidential Suite upgrade, but we’re also giving away a pretty slick Governor’s Suite upgrade, and a very nice Executive Suite upgrade as well! Get the full story here.

Windows Phone theme example:

Sencha Touch provides a base theme that you can customize, or built-in themes for Sencha Touch, Internet Explorer 10, and BlackBerry 10 devices. You can create themes using Sass, which installs for you with the new Sencha Cmd 3.1. Sencha Cmd works with Ruby 1.9.3 to provide Compass and Sass for managing the packaged themes or creating custom themes for your applications.

You can use the base theme as a starting point. The base theme contains minimal styling information for just the framework. From there, you can build your own custom theme using your CSS.

In the following example taken from an application’s app.json, the Apple theme loads if the platform is iOS.

 
"css":  [
 {
  "path": "resources/css/sencha-touch.css",
  "platform": ["ios"],
  "Theme": "Apple"
 } ]
 

You can test themes by using the theme parameter in the URL when running your app:
http://localhost/sdk/touch/examples/kitchensink/index.html?theme=Apple

Platforms

Platforms give you the ability to load specific resources in your app based on the platform your app is running on. In the following example, the sencha-touch.css file is available if the platform is Chrome, Safari, iOS, Android, or Firefox:

 
"css":   [ 	
{
  "path": "resources/css/sencha-touch.css",
  "platform": ["chrome", "safari", "ios", "android", "firefox"]
} ]
 

You can also specify multiple platforms, and use it to load JS resources. The following example loads the vendorfiles.js resource if the platform is Chrome, Safari, or iOS:

 
"js":   [
 {
  "path": "vendorfiles.js",
  "platform": ["chrome", "safari", "ios"]
} ]
 

Each of these examples only loads the resource if the platform of the device running the application matches a platform that you specify for the resource. You can use the ?platform parameter in a URL to test platform functionality.

The following example URL tests for Internet Explorer 10: http://localhost/sdk/touch/examples/kitchensink/index.html?platform=ie10

You can also detect which platform the device is running on from within your application by using the platformConfig function.

The list of available platforms are:

• Phone
• Tablet
• Desktop
• iOS
• Android
• BlackBerry
• Safari
• Chrome
• IE10
• Firefox

Icons

One element of themes in Sencha Touch 2.2 is the new use of icons as fonts. Previously, scaling icons required a great deal of overhead where the application had to draw the picture for the icon and then redraw, rescale, and change it as the app appeared on different browsers and devices.

An icon can be like this button symbol:

New in Touch 2.2, icons are now handled as fonts, which enables very fast scaling without the need to redraw the picture. Icons appear on buttons and tabs.

To convert your existing icons to fonts, you can use Pictos Server, Pictonic, icomoon.io, or http://fontstruct.com/ — some of these are free or available with trial subscriptions.

Using the Pictos Font

The Pictos font provides a large collection of free icons. You can find a full list of characters available for the Pictos font at http://www.pictos.cc. Sencha Touch provides free access to the Pictos Font Pack:

When you build your application using Sencha Cmd, the font libraries are copied to your application file.

Sencha Touch conveniently maps icon names to actual icons, so you can use them within your application.

Here’s an example:

 
{  xtype: 'button',  iconCls: 'home',  title: 'Home'  }
 

Alternatively, you can use the Compass icon mixin to map a specific character of the icon font to an iconCls which you can use in your app:

 
@include icon('home', 'H');
 

Using Other Icon Fonts

The Pictos font is not the only font you can use in your application. If you know of another font or you have custom converted your icons to fonts, it is very easy to use that font with the icon mixin.

Just like with the Pictos font, you need to specify the iconCls and character to be used for the icon. Additionally, you need to specify the name of the icon font, which needs to match the font family of the icon font you have, plus you need to make sure the font has been included in your CSS using the icon-font mixin.

This example specifies the Home icon in the custom MyFont:

 
@include icon('home', 'H', 'MyFont');
 

The following example shows how to include the Pictos font using the icon-font mixin:

 
@include icon-font('Pictos', inline-font-files('pictos/pictos-web.woff', woff, 'pictos/pictos-web.ttf', truetype,'pictos/pictos-web.svg', svg));
 

The first parameter is the name of the font face, which must match the name you use as the CSS font-family. The second parameter uses the inline-font-files Compass function to base64-encode the font file inline into the CSS file with paths to the WOFF, TTF, and SVG versions of the font files.

Here’s a good list of other icon fonts (some paid and some free): http://css-tricks.com/flat-icons-icon-fonts/

Conclusion

With the new Sencha Touch themes, you have the power you need to target your applications to specific mobile devices and platforms. Themes and icons help make your applications visually appealing with better performance. With the Sencha Touch themes, you can portray your application consistently across a wide range of device types. Consistency helps reduce documentation and support needs, so you reduce costs and can focus on building new features.

Nervana Group is an interactive innovation firm that focuses on developing solutions for clients who want to interact better with their customers. Nervana Group won the Chicago Innovation Awards based on our hospitality technology and was featured as one of the Top 100 Most Innovative Companies in Chicago.

We use Sencha Touch to build mobile apps and large format touch screens for many different clients including Hard Rock Hotel, Swissotel and DePaul University. What’s unique about the applications we build is our methodology and approach to make emotion a key element in scoring our software before delivering to the client. Our five pillars of measurement are Features, Functionality, Design, Usability and Emotion.

Why We Chose Sencha Touch

We chose Sencha Touch because it reduces our development time and lets us work interactively with our clients. And, we’ve used Sencha Architect as a starting point for all of our most recent projects. Rather than presenting static Photoshop layouts, we walk into a meeting with an actual working, interactive prototype. Sencha Touch is a fast, clean, high-performance framework that fits our thinking and helps us to win new clients. We’ve used Sencha Touch since it came out in early beta, so we’re very experienced with the framework and thrilled with how much faster we can build apps.

The Sencha Touch MVC pattern gives us the assurance that whatever we build, we can expand. It’s a big advantage over other frameworks like JQuery Mobile. That’s critical for our strategic direction in development because we always need to be ready for changes as our clients’ requirements evolve. Having the ability to separate out components, both MVC and the whole component library is key to reducing development time. We can have developers work on different parts of the project, and the framework provides development patterns that ensure we’re using best practices to organize our code. We’ve done a lot of customization to carousel components, and it’s allowed us to separate that one feature, so it’s really easy to change it later.

We’re huge fans of HTML5. We’ve been working on replacing full-blown native apps with HTML5 apps. We use all of the Sencha Touch components including templates, carousel, scroll lists, buttons, theming, and more. Sencha Touch gives us a rich component suite, and we use the components to create a native-like feel. We rely on Sencha Touch because it’s a complete framework that is always on the leading edge. Something new comes out and Sencha is on top of it — iOS, Android, BlackBerry 10, Windows Phone 8. It makes it so much easier for developers to keep up with the latest devices.

Multi-platform support is a key part of our products. Using Sencha Touch, we know that our apps will work seamlessly across all platforms. The rich components are incredible right out of the box, but the best part is how easy it is to change their functionality and styling. The flexible layout model scales to lots of different devices as well as orientations. Our confidence in Sencha allows us to focus on building great features for the app rather than testing cross-platform compatibility. Products are increasingly catering to the bring your own device trend, and it is important to be as widely compatible as possible. One of our event apps allows attendees to access event data on their own devices. In this scenario, we had to build our app to work on phone and tablet form factors as well as any orientation. It would have been insanely labor intensive to account for all of those things without Sencha.

One of our favorite features is the built-in templates. Complex data can be presented in a very clean manner using the built-in conditional and looping features. Having the whole component driven by a store instead of dealing with complex object layouts also helps to simplify everything. When looking back on our old techniques of building dynamic applications with a hodge podge of AJAX calls, string concatenation and dom manipulation, they seem like tools of the stone age.

The event model in Sencha Touch is so complete that it’s enabled us to drive our business based on interaction with our users. We’ve built analytics on top of our products, so we can make changes based on real-world feedback. Capturing this data was very simple. The vast number of events available provided the perfect method to capture every user interaction. After capturing the events, we do some basic filtering before we send them off to our own analytics engine along with Google analytics.

Business Value of Using Sencha Touch

Before we chose Sencha Touch, we were using a mixture of JQuery Mobile, Adobe Flash and Microsoft Silverlight, and our project timeframes were 4–6 weeks on small projects; bigger initiatives were 8-10 weeks. Now, with Sencha Touch, we are doing full-blown app delivery in 4–6 weeks on big projects. From a cost perspective, we’ve gotten 33% upside on deals because delivery time is that much faster.

One of the unique things about using Sencha Touch is that we can hire new developers and train them in-house. With a background in HTML5, Java or .NET, they can be trained and productive in four weeks. The Sencha Touch framework makes it possible for them to contribute much faster, and we can build qualified staff more quickly, so we’re not resource strapped. Previously, we had to hire developers with a particular skill set and then spend as long as four months on training to get them up to speed.

Our Advice to New Developers

Sencha Touch is the fastest way to develop prototype applications, so you can determine the viability of your project. Once you’ve settled on the approach for your app, it takes just a few more modifications to make it ready for prime time. The speed from idea to market is lightning fast with Sencha Touch and Sencha Architect, so use them to prototype and iterate quickly.

You should be active in the forums because there are so many resources. It’s amazing how many people share their expertise and help new developers. You should also be active in your local Sencha user group (we’re active members of the user group in Chicago). Get to know people and take advantage of the many resources out there.

The docs are amazing, especially the latest version that includes live examples that you can play with. They’re very complete and a powerful tool for new developers who can review the examples and then make changes to learn the framework.

Final Thoughts

Our choice of Sencha Touch has really paid off. It has been the defining factor of why we’ve been so successful. We won the Chicago Innovation Award with Sencha framework. The product is proven and works, and it’s always on the leading edge. If you’re a company building apps in this new generation: mobile or touch world, you should use Sencha Touch. You can build prototypes rapidly — you share a URL, win business, and move on. So much simpler and faster.

In Part 1 and Part 2 of our series on Developing Mobile Applications with Force.com and Sencha Touch, we built out a simple mobile application hosted in a Salesforce.com Visualforce page to display a list of Leads, and allowing add, edit and delete capability using an Apex controller.

In this third part of the series, we want to highlight the enterprise data capability of Sencha Touch, so we’ll focus on how the framework allows us to work with large datasets by adding paging and search capability to the PocketCRM application.

Along the way, we’ll show you how well the Sencha data proxy works in conjunction with querying data in Apex using SOQL and its OFFSET paging feature, and we’ll leverage the concept of Sencha plugins for component reusability and extensibility.

Here’s what we’ll accomplish in part three of the tutorial:

1. Add ‘scroll down’ paging to automatically fetch the next ‘n’ records when a user scrolls to the bottom of a list.
2. Redesign the query capability of our Apex controller class to provide efficient data paging using SOQL OFFSET and a search filter.
3. Add a Search Field in the list view, allowing a user to filter records fetched from Salesforce by a search on any portion of a Lead’s first or last name.
4. Display a count of how many records are currently contained in the list, and include listeners to properly refresh the count whenever the list changes.

So let’s get started.

Let's Dig Back In

What differentiates Sencha Touch from other JavaScript libraries and frameworks is how well it supports large and complex mobile applications. This makes it a great fit for mobile in the enterprise, where there are typically more stringent requirements regarding identity, security, business rules, and of course large volumes of data. As such, it’s perfect for building mobile apps to extend Salesforce.com CRM functionality, or Force.com custom enterprise applications. In addition, as we’ve already seen, it is easily hosted in Visualforce. We’ll pick up where we left off, to introduce the concept of list paging and search in Sencha Touch

It’s a given that any effective enterprise mobile application must provide the capability to manage large sets of records for any data entity that a user has access to. Our Salesforce.com implementation could store thousands or even tens of thousands of Leads, and there’s no telling just how many records our application will need to serve up for any particular user, as different users have different sharing rights on the data. Therefore, we must provide a user experience that makes it easy and fast for any user to find and browse a reasonable number of Leads for which they have access.

Sencha Touch includes a variety of tools to provide just what we need. We’re going to add a plugin component that automatically provides a “Load More...” paging feature to our Lead list. This component allows us to set a default page size for the initial record load, and as the user scrolls to the bottom of the populated list, the application automatically fetches the next ‘page’ of records based on that default. It also manages adding the newly fetched records to those already in the list, and when all of the records available have been fetched, a “No More Records” message is displayed.

It’s always a best practice to use a maximum fetch limit to ensure that device memory is not exceeded, and because there is likely a ceiling beyond which it makes little sense to continue fetching records into a mobile device. The maximum SOQL offset allowed is 2000, more than enough for our purposes, (and if you really need to be able to fetch more records with SOQL, you can utilize alternate Apex query patterns in your controller.)

However, it isn’t likely that users of mobile devices will be required to manage lists of more than a few hundred records. Even though the Sencha list component can effectively manage lists of up to 1000 items, (depending on device memory and record configuration,) we’ll put a limit of 500 records on the query method in the Apex controller. We’ll also set our pageSize configuration to 25 in the Sencha data store component. The page size value is passed to the Apex controller with the query request, and is used to control paging by the SOQL OFFSET feature.

Fire up your development environment for the PocketCRM app that you last completed in Part 2, (if you're just tuning in now to the series, you'll need to go back to Part 1 and Part 2 to build out the application.) We'll remind you to use Safari with its development tools as a desktop emulator and development environment for your tracing and debugging.

Login to your Salesforce org, and launch the PocketCRM Visualforce page so that the mobile application is up and running in a Safari browser, so that you’ll be able to test the changes we’re about to make to the code.

Step 1: Add The ListPage Plugin To The ListView

Plugins are JavaScript classes that can add additional behavior or appearance to existing components upon their instantiation. You can write your own custom plugins, use those provided by Sencha in the framework, or tap into those built by developers in the Sencha community, many of which are posted and freely available in public repositories such as Git. We're going to use one of the Sencha provided plugins for our paging mechanism, as it does exactly what we want for our “Load More...” feature.

Open the PocketCRM_APP Visualforce component in your development environment and add the code for the plugins configuration below to the PocketCRM.views.LeadsList component, just after the disableSelection and before the template configurations. It doesn’t have to be placed in any particular sequence in the configuration section, just make sure you have comma delimiters for each configuration that precedes or follows it:

 
//The main list and its properties. 
xtype: "list",
store: "Leads",
itemId:"leadsList",
...
disableSelection: false,
 
plugins: [
    {
        xclass: 'Ext.plugin.ListPaging',
        autoPaging: false  //set true for automatic fetching when user reaches bottom of the list
    }
],
 
//The template for display if the Store is empty of records.
//Note the style to control visual presentation.
loadingText: "Loading Leads...",
...
 

Next, modify the PocketCRM.store.Leads component to reduce the pageSize configuration (on line 9 below) from 50 to 25, so that each successive fetch will add 25 records to the list. You can set this value to any page size you’d like while testing the behavior. The store component should look like this:

 
Ext.define("PocketCRM.store.Leads", {
    extend: "Ext.data.Store",
    requires: "Ext.data.proxy.LocalStorage",
 
    config: {
        model: "PocketCRM.model.Lead",
        autoLoad: true,
        //Set your desired PAGE SIZE.  
        pageSize: 25,
        groupField: "Status",
        groupDir: "ASC",
        sorters: [
            { property: 'LastName', direction: 'ASC'},
            { property: 'FirstName', direction: 'ASC'}
        ]     
    }
});
 

After you have modified your code, refresh your application in the browser. If no errors were introduced, it should display as many Lead records as you set for the pageSize, with a link at the bottom to “Load More...” records. Click the link, and you should see another “page” of records appended to the list, and the link displayed again. You can continue to load the list until you hit the LIMIT as set on the SOQL query in the Apex controller’s getAllLeads() helper method, which we had arbitrarily set to 50. Experiment with it to see what happens when the limit is reached, and try bumping up the LIMIT as well to get a feel for the the behavior as you load a larger set of records.

Also notice the plugin’s configuration setting on line 7 above:

 
autoPaging: false
 

Setting this configuration’s value to true will cause the paging to fire automatically each time the user scrolls to the bottom of the list. You can choose whether you want the paging to fire automatically or not for your application, but experiment with both settings now to experience the behavior.

Step 2: Refactor the Apex Controller Query Methods

Now that the paging plugin is in place and functioning, we need to optimize how it will work in conjunction with our SOQL in the Apex controller. Previously, we had included some rudimentary paging logic in the @RemoteAction query method which is why you’re seeing more records served up when each new page is requested.

You can see how we wrote the initial paging logic in the original Apex method. After all Lead records are fetched, a for loop partitions out just the page of records as defined by the start and recordCount properties passed in the request object from the Sencha data proxy.

The existing code looks like this:

 
@RemoteAction
public static Response Query(QueryRequest qr){
    Response resp = new Response();
    List<Lead> LeadList;
    filterString = qr.searchFilter;
 
    try {
        //Fetch all Leads for the user
        LeadList = getAllLeads();
    } catch (Exception e) {
        resp.success = false;
        resp.errorMessage = 'Query failed: ' + e.getMessage();
        return resp;
    }
 
    //Supply only the requested records
    for (Integer recno = qr.start; recno < (qr.start + qr.recordCount) && recno < LeadList.size(); ++recno) {
        resp.records.add(LeadList[recno]);
    }
 
    resp.total = LeadList.size();   
    resp.success = true;
    return resp;
}
 

The flaw in this pattern is that all Lead records available to the current user are fetched and iterated over with each request, even though only a small number are actually required to be returned; a most inefficient process. Salesforce has a few different patterns available for fetching sets of objects, and we will take advantage of the SOQL OFFSET feature which works well with the page size and record count properties that we have already built, and are available from our request object.

We need to change two methods in our Apex controller to implement the new version of the paging logic. First, we’re going to change the helper method that will return the page of records. The original method looks like this:

 
private static List < Lead > getAllLeads() {
    return [SELECT FirstName, LastName, Company, Title, Phone, MobilePhone, Email, Status        FROM Lead LIMIT 50];
}
 

Replace that method with the new version below; it’s a bit more code, but actually very straightforward. It simply calculates the paging values using the parameters passed in the request, builds one query to get a count of all records, and another query to fetch the exact page of records based on the calculated paging values. Note the OFFSET and LIMIT portions of the SOQL query.

Also note the SOQL whereClause variable which constructs a filter using the qr.searchFilter property. We’ll use this property shortly to pass a search string from the Sencha application to filter the query, and we’ll initially default its value to a SOQL wildcard so that all records will be fetched for the SELECT. Our code also checks to determine if an empty string is passed, in which case the WHERE clause will simply be omitted from the query.

 
private static void getAllLeads(QueryRequest qr, Response resp) {
 
    //Page size is set in the Sencha store as recordCount.    
    Integer pageSize = qr.recordCount;
 
    //Page number will be calculated.
    Integer pageNumber = 0;
 
    //Start is the record number indicating the start of the page.
    if (qr.start > 0) {
    	pageNumber = qr.start / pageSize;
    }
 
    //Calculate the offset for SOQL.
    Integer offset = pageNumber * pageSize;
 
    //Build the query in pieces.
    String fieldList = 'Id,FirstName,LastName,Company,Title,Phone,MobilePhone,Email,Status';
    String whereClause = (qr.searchFilter != '' ? 'WHERE Name LIKE \'' + qr.searchFilter + '\'' : '');
    String orderByClause = 'LastName, FirstName';
 
    //Construct a base query to which the page offsets will be added.
    String baseQuery = 'SELECT ' + fieldList + ' FROM Lead ' + whereClause + ' ORDER BY ' + orderByClause;
 
    //Construct a count query to pass back the total records matching a search criteria.
    String baseCountQuery = 'SELECT COUNT() FROM Lead ' + whereClause;
 
    //Construct the fetch query with the offset.
    String fetchQuery = baseQuery + ' LIMIT ' + pageSize + ' OFFSET ' + offset;
 
    try {
 
    	//Set the count.
    	resp.total = Database.countQuery(baseCountQuery);
 
    	//Set the fetched recordset.
    	resp.records = Database.query(fetchQuery);
 
    	//Set the status flag.
    	resp.success = true;
 
    } catch (Exception e) {
 
    	//Set the total count of records matching the query.
    	resp.total = 0;
 
    	//Set the recordset to return.
    	resp.records = new List < Lead > ();
 
    	//Set the status flag.
    	resp.success = false;
 
    }
}
 

The SOQL OFFSET processing is very efficient, fetching only the exact set of records requested. Notice the method takes both the QueryRequest and Response objects as parameters, and sets the properties of the Response object to be sent back to the Sencha application. Before you can save the controller class, you must also modify the @RemoteAction Query() method to work with the new version of the helper method above, replacing the old method with the following code:

 
@RemoteAction
public static Response Query(QueryRequest qr){
 
    Response resp = new Response();
 
    //Enforce a limit on the number of rows requested.
    final integer QUERY_LIMIT = 500;
    if( qr.start >= QUERY_LIMIT ){
        resp.success = false;
        resp.errorMessage = 'Maximum number of records (' + String.valueOf(QUERY_LIMIT) + ') exceeded!';
        return resp;
    }
 
    try {
        getAllLeads(qr, resp);
    } catch (Exception e) {
        resp.success = false;
        resp.errorMessage = 'Query failed: ' + e.getMessage();
    }
 
    return resp;
}
 

This new version of the method is much simpler. First, it ensures the request has not exceeded the maximum query limit established for the application, and then it sets up and calls the new helper method which does all the real work.

Save your changes to the Apex controller making sure it compiles correctly, and refresh your Sencha application in the browser; it should work exactly as before with the refactored Apex controller class.

Step 3: Clean Up the Proxy Error Listener

While I was running tests during development of the code for this part of the tutorial, I found some bugs in an error handling routine that we built out in the original posting of Part 2 of the series. If your code matches the original code below, please replace it now with the repaired version.

We had added a listener on the data proxy in the init() function of the PocketCRM.controller.Leads component to catch any errors passed back from the Apex controller. The original code below is flawed, and was not correctly displaying the error messages:

 
//THIS IS THE FLAWED CODE!
//Listen for exceptions observed by the proxy so we can report them and clean up.
Ext.getStore('Leads').getProxy().addListener('exception', function (proxy, response, operation, options) {
    // only certain kinds of errors seem to have useful information returned from the server
    if (response.data) {
        if (response.data.errorMessage) {
            Ext.Msg.alert('Error', response.data.errorMessage);
        } else {
            Ext.Msg.alert('Error', operation.action + ' failed: ' + response.data.message);
        }
    } else {
        Ext.Msg.alert('Error', operation.action + ' failed for an unknown reason');
    }
});
 

If your version is the flawed code, replace the original code with the repaired code as below that has corrected references to the response and operation objects, The improper references in the JavaScript were not actively breaking anything; the function was just failing silently, but will now properly report errors:

 
//THIS IS THE REPAIRED CODE!
//Listen for exceptions observed by the proxy so we can report them and clean up.
Ext.getStore('Leads').getProxy().addListener('exception', function (proxy, response, operation, options) {
    // only certain kinds of errors seem to have useful information returned from the server
    if (response) {
        if (response.errorMessage) {
            Ext.Msg.alert('Error', response.errorMessage);
        } else {
            Ext.Msg.alert('Error', operation.config.action + ' failed: ' + response.errorMessage);
        }
    } else {
        Ext.Msg.alert('Error', operation.config.action + ' failed for an unknown reason');
    }
});
 

Save your changes to the JavaScript and refresh your Sencha application in the browser to ensure no new errors were introduced; it should work exactly as before. You will see this routine in action if you page through the list requesting more records, and finally exceed the maximum number allowed by the query method. If you don’t have enough leads to reach the ceiling, simply lower the limit from 500 to a smaller number to see the error handling behavior.

Step 4: Add a Search Field to Filter the Leads

Now that the new paging mechanism and query methods are in place, we can add a Search Field for a user to enter a partial Lead name to filter the query results. We have to add a few moving parts to get this working.

First, we need to modify the PocketCRM.view.LeadsList component, adding a Search Field on the toolbar docked at the bottom of the view. While we’re at it, we’ll also change the position of the refresh button and it's display icon, which will be used to execute a search after a user has entered some search text.

The Search Field also has an embedded icon, (it appears as an x in a circle to the right of any entered text,) and when clicked or pressed, it clears the entered value. We will add a new listener and event handler on this icon so that when a user clears the search text, a refresh of the data is also fired off.

Since it’s useful to know how many records a user has accumulated in the list, we’ll also add a listener on the list itself, so that when it is refreshed or reactivated, we display the current record count as Badge Text on the refresh button. We could create a label somewhere on the toolbar to display this counter, but space is tight and this will give you an example of how you can set Badge Text on those components (such as buttons) that provide this feature.

Find the JavaScript for the PocketCRM.view.LeadsList component and modify the following code sections. First, find the code for the bottom toolbar in the Items configuration and replace it with the code below. This adds an itemId, a SearchField component, and adjusts the layout of these items with additional spacers. Notice also that we have changed the iconCls of the syncButton component to display a Search rather than a Refresh icon:

 
...		
{
    xtype: "toolbar",
    docked: "bottom",
    itemId: "bottomToolBar",
 
    items: [
        {
            xtype: 'spacer'
        },                  
        {  
            xtype: 'searchfield',                            
            itemId:'leadSearchField',  
            placeHolder: 'Name Contains...'  
        },                  
        {
            xtype: "button",
            iconCls: "search",
            iconMask: true,
            itemId: "syncButton"
        },	
        {
            xtype: 'spacer'
        }
    ]
},
...
 

Next, find the listeners configuration, and add these additional listeners after the one for the #leadslist delegate:

 
...	
listeners: [{
...
    ,{
        //Handles the clear of the Search Field.      		
        delegate: "#leadSearchField",
        event: "clearicontap",
        fn: "onLeadSearchFieldClearIconTap"
    },
    {
        //Handles the refresh of the list.      		
        delegate: "#leadsList",
        event: "refresh",
        fn: "onLeadsListRefresh",
    },
    {
        //Handles the activate of the view when redisplayed by transition.
        event: "activate",
        fn: "onLeadsListViewActivate",
}]
 

Finally, add the new functions for each of the new listeners after the final function for the onLeadsListDisclose event, (be sure to precede the new set of functions with a comma delimiter:)

 
onLeadSearchFieldClearIconTap: function () {
    console.log("clearSearchLeadCommand");
    this.fireEvent('clearSearchLeadCommand', this);
},
 
onLeadsListRefresh: function () {
    console.log("onLeadsListRefresh");
    this.updateListCounter();
},
 
onLeadsListViewActivate: function () {
    console.log("onLeadsListViewActivate");
    this.updateListCounter();
},
 
//Function to get count of records in the list and show on the search button's badge. 
updateListCounter: function () {
    var listCount = Ext.getStore("Leads").getCount();
    this.getComponent("bottomToolBar").getComponent("syncButton").setBadgeText(listCount);
}
 

We will add the event handler logic for the clearSearchLeadCommand in the controller shortly. The final function in the set (updateListCounter) is called from both the onLeadsListRefresh and onLeadsListViewActivate event handler functions, and contains logic to update the Badge Text of the syncButton with the current record count. Note how it gets the record count from the data store, and sets the value to the Badge Text of the syncButton in the bottomToolBar component. This is just one example of how to obtain references to components and get/set values within functions.

Save your changes and refresh your Sencha application in the browser to ensure no errors were introduced. You should now see the new Search Field and adjusted button and record count. You can enter a search value, but it won’t yet apply the filter when you reload the list.

Step 5: Refactor the Load to Include the Search Value

We have to modify our reload logic to include the new search value. As this logic is called from more than one place in our code, it will be best to isolate into its own function, and then call as needed from other functions. We’ll also have to make a few other supporting modifications to the PocketCRM.controller.Leads component.

First, we need to add a new controller reference for the new Search Field in the controller’s refs configuration section, it will look like this:

 
refs: {
    ...
    //Add a new search field.
    leadsListSearchField: "#leadSearchField" 
},
 

Next, we need to add a new control for the new event fired by List View’s event handler function on the Search Field’s clear icon. It will be added in the control configuration section, and will look like this, (make sure to add a comma delimiter after any configuration that precedes the new clearSearchLeadCommand):

 
control: {
    leadsListView: {
        // The commands fired by the list container.
        ...
        ,
        //Add an event when clearing the search text.
        clearSearchLeadCommand: "onClearSearchLeadCommand"
},
 

Now we must add the logic to manage the reload of the data, and include any search values entered by the user. Once this function is available, we will call it from a number of other event handlers. Add the new function below all the other event handler functions, but above the launch function:

 
//Add separate load function to be called by multiple event handlers.
loadList: function () {
 
    //Get a ref to the store and remove it.
    var leadsStore = Ext.getStore("Leads");
 
    //Get any search text.
    var leadSearchField = this.getLeadsListSearchField();
    var searchText = leadSearchField.getValue(); 
 
    //Validate for at least 2 or more characters.
    if (searchText.length > 0 && searchText.length < 2) {
        var msg = 'Search requires more text.';
        Ext.Msg.alert('Please correct errors!', msg, Ext.emptyFn);
        return;
    }
 
    //Add wild cards to the search string.	
    if (searchText != '') {
        //Surround the search value with wildcards for SOQL LIKE search.
        searchText = '%' + searchText + '%'; 
    } else {
        //Set wildcard for wide open filter.	
        searchText = '%'; 
    }
 
    //Set the value of the searchFilter param to pass with the request for the query.
    var model = Ext.ModelMgr.getModel('PocketCRM.model.Lead');
    model.getProxy().setExtraParam('searchFilter', searchText);
 
    //Clear all data in the store before reloading it.
    //This is necessary to make sure that the proxy doesn't get confused by 
    //the loss of records removed but not reloaded with a new filter. 
    //Without the clear(), the proxy assumes a deletion was processed and 
    //calls a destroy to be executed on missing records with the next sync() operation.
    leadsStore.getData().clear();	
    leadsStore.loadPage(1); 
 
    //Show the list.
    this.activateLeadsList();
},
 

Add the following new function to handle the search field clear event, place it after the onBackToHome event handler:

 
//Reload the list when clearing the search value. 
onClearSearchLeadCommand: function () {
    console.log("onClearSearchLeadCommand");
 
    //Get a ref to the search field. 
    var leadSearchField = this.getLeadsListSearchField();
    leadSearchField.setValue('');
    console.log("Cleared Field Value: " + leadSearchField.getValue());        
 
    this.loadList();
}, 
 

Modify the following event handler functions to also call the new load function:

 
onSyncLeadCommand: function () {
    console.log("onSyncLeadCommand");
    this.loadList();
},
 
...
launch: function () {
    console.log("launch");
    this.callParent(arguments);
 
    //Load up the Store associated with the controller and its views. 
    console.log("load Leads");
    this.loadList();
},
 

Remember to take care to include all commas and curly braces as needed or your JavaScript will break. This was a lot of code to change, hopefully we will not have introduced any errors. Save your changes and refresh your Sencha application in the browser to ensure all is well.

Now, enter a search value into the new Search Field and click the search button. If all your changes are working properly, the list should refresh showing only records matching your search criteria. If there are more records matching your search than the default page size, you should be able to load additional records by clicking the “Load More...” link. Continue to fetch more records until you see the “No More Records” message. If the number of records you have loaded into the list exceeds the maximum as configured in the Apex controller’s Query method, you should see an error message alert, (thanks to our repaired Apex error listener.)

Clicking the clear icon in the Search Field should remove the search value from the text box and refresh the list with the original record set displayed. In each case, you should see the record counter change in the search button’s Badge Text. To ensure that the counter refresh events are also working properly after CRUD operations, try to add and then delete a new lead. Each time the List is re-displayed following such an operation, you should see the record counter adjust correctly reflecting the newly added or removed record in the count.

Using the Web Inspector developer tool from Safari, you can trace the proxy request when the search and reload operations are executed. You can inspect the JSON request payload sent to the Salesforce remoting service which should look like this for a search, note the value of the searchFilter which includes the SOQL wildcards:

 
{
    "action": "PocketCRMLeadController",
    "method": "Query",
    "data": [{
            "searchFilter": "%22%",
            "start": 0,
            "recordCount": 25
        }
    ],
    "type": "rpc",
    "tid": 8,
    "ctx": {
        "csrf": "rUvT8gN3e0D50m2xK4bzRzvhRMlOLqNZFO6QZu3l2T.D2NrF6T0VUggRNmn4ssjNER_At7gsWui4U2yWpxSnzXzawt2Dn6jhpM2ez15tL5ztVihbH63dBQ.2F4c29tY4QYuAWtSuZreRdWbl1hGz67ZH1q3RI2m6By2201K6g6sVdrVF",
        "vid": "06650000000DAsF",
        "ns": "",
        "ver": 24
    }
}
 

Each request for more data will increase the start property. Here’s what it looks like for a request of the third page with no filter value, (note the passed wildcard character for an empty search value:)

 
{
    "action": "PocketCRMLeadController",
    "method": "Query",
    "data": [{
            "searchFilter": "%",
            "start": 50,
            "recordCount": 25
        }
    ],
    "type": "rpc",
    "tid": 11,
    "ctx": {
        "csrf": "rUvT8gN3e0D50m2xK4bzRzvhRMlOLqNZFO6QZu3l2T.D2NrF6T0VUggRNmn4ssjNER_At7gsWui4U2yWpxSnzXzawt2Dn6jhpM2ez15tL5ztVihbH63dBQ.2F4c29tY4QYuAWtSuZreRdWbl1hGz67ZH1q3RI2m6By2201K6g6sVdrVF",
        "vid": "06650000000DAsF",
        "ns": "",
        "ver": 24
    }
}
 

Summary

Let's recap what we accomplished:

1. We added a Sencha ListPaging plugin to provide “scroll down” paging to automatically fetch more records when a user scrolls to the bottom of the list. There are other plugins available with similar but alternate behavior, some provide next and previous paging, others provide a “Pull Down” type fetch. If you want to get adventurous, you can even write your own.
2. We redesigned the querying capability of our Apex controller class to provide efficient data paging using SOQL OFFSET and a search filter, and we set an upper limit on the number of records that can be fetched by the client application.
3. We added a Search Field in the list view, allowing a user to filter records fetched from Salesforce by a search on any portion of a Lead’s first or last name. You can also rewrite the Apex controller to use SOSL for a fulltext search, or build out a more complex dynamic query capability.
4. We added the display of a record count reflecting the current list content that refreshes with each reload of data.
5. Finally, we fixed a bug in the data proxy listener to properly display errors returned from our Apex controller.

You can find the full code for the completed application for Part 3 here at GitHub.

Closure

In the next part or our series, we'll expand our application to provide an appropriate user interface for a tablet device, in addition to a phone, by leveraging the Sencha Touch profile feature. This feature adds the capability to identify the device type loading the application, permitting a single code base to support multiple form factors. By isolating alternate sets of components to support different devices, applications can also share larger collections of components for common functionality in the remainder of the codebase.

In the meantime, I encourage you to continue your Force.com and Sencha Touch mobile ramp-up by watching videos, playing with and dissecting samples, and reading through the great online guidance documentation. You should now also have enough knowledge under your belt to build a simple application of your own using all the design patterns from the tutorial to date. Also, definitely check out the features and functions of the recently announced Salesforce Touch Platform; you can go here to download a free eBook and read all about it.

Knowing these 7 productivity-enhancing features can make you even more productive than you already are!

1. Property filter keyboard shortcut: Ctrl-E (⌘-E on Macs)

How it’s done

Type Ctrl-E (⌘-E on Macs) to place the cursor in the config/property filter field.

Discussion

I’m always using the property filter to narrow down what is often a huge list of config properties into three or four that I can quickly click on and edit.

Here’s the editing sequence that I use a lot:

1. Click on a component in the Project Inspector
2. Type Ctrl-E to put the cursor in the property filter
3. Type two or three characters to narrow down the list of configs
4. Edit the property that I want to change

2. Lock the filter

How it’s done

Click the “lock” icon in the config/property field. This will lock the current filter in place as you click on different items in the Project Inspector.

Discussion

You may have noticed that when you click on a new item in the Project Inspector or in design view, the filter is not applied until you type “Ctrl-E (or ⌘-E)” and then ENTER. However, if you click the “lock” icon in the filter area, your filter will be applied automatically as you change items.

You can use this feature to quickly edit the same feature on many similar items. For example, you can type “align” in the filter field (or even “al”), then click on the grid columns where you want to change the alignment.

3. Collapse the Toolbox categories or the entire Toolbox

   

How it’s done

To close just the Toolbox categories, click the little arrow (barely visible) about halfway down the categories splitter. To close the entire Toolbox, click the arrow at the far right side of the Toolbox header.

Discussion

I almost always keep the Toolbox categories pane hidden. I keep “Everything” selected and then filter for what I need. After hiding the categories, you can then reduce the Toolbox’s width to give yourself more room.

If you need even more space, you can collapse the Toolbox completely by clicking on the collapse arrow on the right-hand side.

4. Add a reference to an external Third Party JavaScript API

   

How it’s done

Click on the [+] button in the Project Inspector, click on “Resource”, then click the “JS Resource” sub-menu item.

Discussion

When you add a reference to an external JavaScript API in Sencha Architect, you can then call those library functions from anywhere in your Architect application. Some examples of the hundreds of third party JavaScript libraries available include Google Maps, Google Analytics and jQuery.

If you want to see a fully functioning Google Maps Tab Panel in an Architect app written in about 30 lines of code, add a comment below, and I’ll be happy to cover this in a future blog article.

5. Promote to Class

How it’s done

RIGHT-CLICK on the container or component that you want to promote (i.e., save to a separate class file). Choose “Promote to Class” from the context menu.

Discussion

When you first start building your Sencha Architect application, you add components to the viewport or to a Tab Panel. As you start adding more components, the items array of these containers becomes unwieldy, and at that point it’s best to create separate classes for your bigger components.

When you create a separate class, you assign it a custom xtype, which will be used to reference your class in the parent’s item array. You can also use the custom xtype in a ref selection or a ComponentQuery.query() call in your controller.

6. Add a Store without a Proxy attached

How it’s done

To create a Store with no proxy attached, click the top level “Store” after clicking the [+] button in the Project Inspector, as shown in the screen shot above.

Discussion

Normally, when you click the [+] button and then hover over the “Store” menu item, you will see a list of different Stores in the sub-menu. Whichever Store you choose will have a proxy attached to it.

Sometimes you’ll want to create a Store without a proxy attached, maybe because you already have a proxy attached to your model. Clicking on the top-level Store menu item adds a Store without a proxy attached.

Additional Notes

A “proxy”, when attached to either the Model or the Store, is how you define where the API resides. The “url” and “type” (json and xml types are built in) properties are required.

When would you attach a proxy to a Model versus a Store? If you are using the Model.save() method and creating Models instances individually, then you would attach the proxy to the Model.

7. List Tabs keyboard shortcut: Ctrl-L (⌘-L on Macs) – New for version 2.2!

How it’s done

Type Ctrl-L (⌘-L on Macs) to see a list of currently open tabs. Arrow up and down to move within the listing, and hit ENTER to select and focus a tab.

Discussion

New for Sencha Architect 2.2: each class in your Architect application can be placed in its own tab. This allows you to quickly edit different areas of your application (for example, a grid and its associated store) without having to scroll back and forth in your Project Inspector. You can close tabs at any time.

The problem arises when you have more tabs than can fit in the tab area. The solution is to type “Ctrl-L (⌘-L on Macs)” to list all open tabs. (You can also click on the “List Tabs” icon on the right side of your tab area.)

Then, using your up and down arrow keys, you can quickly navigate to a tab and hit ENTER to focus that tab. For now, you can’t move tabs by dragging them, but you can close and re-open tabs if you want to change the order and put related tabs near each other.

Conclusion

I hope that some of these features are new to you, and that this article helps to save you some time.

The Sencha Architect features covered here are only a tiny fraction of what’s available. Sencha Architect is covered in great detail in the 5-day Ext JS and Sencha Touch classes offered all over the world through Sencha Training, taught by Sencha-certified instructors. Visit sencha.com/training for more details.

If you have any feedback, please add it to the comments section.

In our tests, we found that the Z10 is a worthy addition to the top tier of mobile HTML5 devices that includes the iPhone 4+, the iPad gen 2/4 and the Microsoft Surface. We found solid advances in HTML5 feature implementation and very good performance in general. Most exciting to us is the support for getUserMedia(), which allows streaming video capture directly from the browser. We think BlackBerry’s UI for video capture is nicely designed. We did find a few feature glitches in our version 10.0 device that we expect to be cleaned up in the 10.1 release.

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. Since the feature scope of HTML5 is enormous, we focus on testing newer features and graphics and animation performance. We use a variety of homegrown and third party test-sites, including modernizr, html5test, html5rocks, haz.io, and in-the-wild web demos to check feature presence and correctness.

Device Essentials

First up, some essentials for the web developer. If you’re looking for traffic from the Z10 (or the forthcoming Q10, search for the following user agent string:

Mozilla/5.0 (BB10; Touch) AppleWebKit/537.10+ (KHTML, like Gecko)
Version/10.0.10.822 Mobile Safari/537.10+

The Z10 supports at least 10 simultaneous touches, which we gamely verified by cramming our fingers and thumbs onto the test screen. Multiple touches were very reliable up to 4 simultaneous touches: above that new touches and a move of an existing touch seemed to get a little mixed up. Since there are practically no applications that rely on more than 4 fingers on a screen, this is just fine.

“In our tests, we found that the Z10 is a worthy addition to the top tier of mobile HTML5 devices that includes the iPhone 4+, the iPad gen 2/4 and the Microsoft Surface.”

Next, JavaScript timer resolution. BlackBerry has changed its default timer resolution from 17ms to 4ms in this release. This is the same interval supported by iOS and desktop browsers, so script animations paced by a setTimeout() loop will now run at the same pace (last we checked Android was still at anywhere from 4s to 17s though). The timer is a little noisy with occasional spikes to 20ms or more, so the even better news is that BB10 now supports requestAnimationFrame so animation can be smoother and more efficient.

HTML5 Features

The Z10 has a very complete set of HTML5 features, scoring 485 on the current html5test.com feature test. New this year is IndexedDB, File API, Microdata, in-browser WebGL, some new HTML5 form features, getUserMedia(), as well as support for the Ogg audio codecs Ogg Vorbis and Ogg Opus.

What deserves showcasing is the Z10’s WebGL support: it’s pretty darn good. The standard WebGL demos worked extremely well. We were excited to see the many planets animated demo running happily at 35fps. In fact, the only demo that showed any noticeable stutter was Mozilla’s animated raytracing demo.

In addition to WebGL, the new audio codecs played perfectly, and seamless iframes displayed correctly. We also tested getUserMedia() and it worked correctly for video capture (although audio-only is not supported yet).

On the other hand, we found some bugs in other newly implemented features. IndexedDB demos did not run correctly or crashed the browser. The W3C test page for Microdata crashed, and scoped styles did not appear to work in a minimal demo. We talked to BlackBerry, and found out that all three bugs are being investigated already and should be fixed in dot releases. Lastly and as a side note, some of the built-in HTML5 form inputs look like they were ported directly from the Playbook OS without adjustment for the smaller screen of the Z10. For example, the HTML5 color input was not sized correctly and we had to scroll within the control in order to select colors.

Graphics & Animation Performance

In real world tests, Canvas and SVG performance was respectable. Canvas color cycle was very smooth. In Microsoft’s fishbowl demo which stresses the compositor, with 50 fish sprites and the fps meter active, we got 50fps. With all effects active, the performance dropped to 20 fps. Zynga’s informal goal for casual games is 125 sprites at 60fps, so Canvas could be a little better. CSS3 animation demos worked well, handling multiple simultaneous animations smoothly and consistently. CSS filter shorthands as well as more complex SVG filters were also properly supported. We did find some SVG regressions: a problem with SVG filter light sources, malfunctioning gradient animations and a crash with David Dailey’s classic SVG floating balloon. Talking to BlackBerry, many SVG bugs are fixed and will roll out in dot releases.

Finally, we’re happy to say that BlackBerry continues to have a fantastic implementation of position: fixed, and overflow scrolling. It’s rock solid.

A Solid Upgrade to an Already Fine HTML5 Browser

With the release of BlackBerry Z10, the BlackBerry browser team once again delivers a very solid HTML5 platform. An industry leading HTML5 score, solid WebGL performance and a terrific getUserMedia implementation are the standouts for us. With the forthcoming performance and bug fixes, the Z10 has a solid shot at being the best mobile platform for HTML5 app deployment.

This is your opportunity to discuss ideas with Sencha experts from around the world! The unconference can be about anything and everything - so if you want to discuss responsive design, learn more about WebRTC or express your thoughts on CoffeeScript this is your time to shine!

Unconferences have been a part of thousands of events and are known to leave lasting impressions on conference attendees. Attendees often cite the unconference as the best part of the event, and with the strength and energy of our community, we are confident the SenchaCon Unconference will garner this sort of reaction as well.

Unconference sessions are all about conversation, and anyone attending the conference can propose a topic and lead a discussion. The goal for the SenchaCon “unconference” is to stimulate community discussion so that everyone has an opportunity to participate and have their ideas heard.

Here’s how it will work...

1. On Wednesday morning, we will remind you and everyone else about the unconference, and ask you to start thinking about potential topics.
2. On Thursday morning we will post the unconference board so you can place your topics on the schedule.
3. If you submit a topic, you will start the discussion; everyone else will simply show up and participate in the conversation.

The SenchaCon “unconference” will consist of two 45-minute sessions on the second day (Thursday, July 18th) after lunch. There will be a break after both of the unconference sessions so that you have ample time to wrap up any conversations before moving to your next session.

That’s it. Show up to the session you are interested in and have a conversation with fellow attendees. If you are not finding what you want, feel free to move to another conversation (this is the “Law of Two Feet”).

For more information please read or watch Bruce Eckel’s explanation of an “unconference”.

We look forward to seeing and hearing from you at SenchaCon 2013 in Orlando!

It’s not likely that you’ll start developing an enterprise HTML5 application without using one of the JavaScript frameworks. One of the most feature complete frameworks is Sencha Ext JS. Farata Systems has developed an open source software tool called Clear Toolkit for Ext JS. Clear Toolkit includes an Eclipse plugin called Clear Data Builder. This is a productivity tool — a code generator — that can create a CRUD application for you in no time. This application has an HTML/JavaScript/Ext JS client and Java-based server. In this article, you will learn how to jumpstart development of enterprise web applications.

Part One: Ext JS MVC Application Scaffolding

In Part One, I’ll cover the following topics:

• What is Clear Toolkit for Ext JS
• How to create an Ext JS MVC application for a Java-based project
• How to deploy and run your first Ext JS + Java application on Apache Tomcat server

Clear Toolkit for Ext JS contains the following parts:

• Clear Data Builder (CDB) — Eclipse plugin that supports code generation of Ext JS MVC artifacts based on Java code. CDB comes with wizards to start a new project with plain Java or with popular frameworks like Hibernate, Spring, MyBatis.
• Clear JS — a set of JavaScript components that extend Ext JS standard components. For example, Clear JS contains
ChangeObject — a universal way to trace the state changes between old and new versions of the same item in a store.
• Clear Runtime — Java components that implement the server side of ChangeObject, DirectOptions, etc.

CDB helps you to be more productive which means you write less code and produce results faster. You’ll see how CDB helps you to integrate the client side with the back-end using RPC style and how to implement data pagination for your application.

CDB distribution is available as a plugin for Eclipse IDE. You can download CDB here. The current version is 4.1.4. You can install this plugin via the Install New Software menu in the Eclipse IDE. Figure 1 shows how you can validate the plugin installation. If you see “Clear Data Builder for Ext JS feature” in the list of Installed Software in your Eclipse IDE, you’re good to go.

Important: You must have “Eclipse for Java EE Developers” installed, which includes the plugins for automation of the Web applications.

Figure 1. Verifying CDB Installation

Clear Data Builder comes with a set of prepared examples that demonstrate the integration with popular Java frameworks — MyBatis, Hibernate, and Spring. Also, a plain Java project example that doesn’t use any of the frameworks is available. Let’s start with the creation of a new project by selecting the menu File → New → Other → Clear, and then press Next.

Figure 2. New CDB Project Wizard

First, let’s call the new project episode_1_intro. CDB supports different ways of linking the Ext JS framework to the application. In my case, I have already installed Ext JS libraries under my Web server (Apache Tomcat). I’m going to use this local Ext JS URL, but you can just specify any folder on your machine, and CDB will copy the Ext JS file inside your project. Lastly, you can use Ext JS from the Sencha CDN, if you don’t want to store these libraries inside your project. Besides, using a common CDN will allow the Web browser to reuse the cached version of Ext JS.

For this project, we are not going to use any server side platform (like MyBatis or Hibernate). Just click the Finish button. First, CDB will print some initial messages on the Eclipse console. When CDB runs for the first time, it initializes a directory structure in the WebContent folder. Inside the WebContent directory, CDB creates a directory structure, which is recommended by Sencha for MVC applications. Also, you’ll get the HTML wrapper — index.html — for this application, which contains the link to the entry point of our application.

CDB generates an empty project with one sample controller and one view — Viewport.js. To run this application, you need to add the newly generated Dynamic Web Project to Tomcat and start the server (right-click on the Tomcat in the Servers view of Eclipse).

Figure 3. Adding a Web Project to Tomcat

Let’s switch to the web browser to open this application on http://localhost:8080/episode_1_intro . Voila! In just a couple of minutes, we’ve set up a new Dynamic Web Project with the Ext JS framework support and one fancy button on the UI.

Figure 4. Running a Scaffolded Application

The next step is to make something useful out of this basic application.

Part Two: Generating a CRUD Application

CRUD stands for Create-Retrieve-Update-Delete. It’s a well-known term for describing the applications that support data manipulation. The apps can retrieve data from some data source and update the data too.

In Part Two, I’ll cover the following topics:

• Create a simple CRUD Ext JS + Java application
• Create a POJO and the corresponding Ext.data.Model
• Create a Java service and populate Ext.data.Store with data from the service
• Use the auto-generated Ext JS application
• Extend the auto-generated CRUD methods
• Use ChangeObject

Now, I would like to show you how to use CDB to create a CRUD application. I’ll show you how you can turn your Java POJO class into the Ext JS model. I’ll explain the following:

• How you can populate the Ext JS store from a remote service
• How you can use automatically generated UI for that application
• How you can extend it
• How to use the ChangeObject class

I will extend the application from Part 1. For my CRUD application, I need a Java POJO. First, I’ve created the class Person.java in the package dto. Then I’ve added the fieldsfirstName, lastName, address, ssn and phone and id. Also, I need getters and setters for these fields. It’s good to have a constructor that uses these fields, and a DTO class should have a toString() method.

Now, I need the same corresponding Ext JS model for my Person. I just annotate this class with the CDB annotation called @JSClass to ask CDB to generate the Ext JS model.

Person Data Transfer Object

 
	package dto;
 
	import com.farata.dto2extjs.annotations.JSClass;
	import com.farata.dto2extjs.annotations.JSGeneratedId;
 
	@JSClass
	public class Person {
 
	@JSGeneratedId
	private Integer id;
	private String firstName;
	private String lastName;
	private String phone;
	private String ssn;
 
	public Person(Integer id, String firstName, String lastName, String phone,
	String ssn) {
	super();
	this.id = id;
	this.firstName = firstName;
	this.lastName = lastName;
	this.phone = phone;
	this.ssn = ssn;
}
 
// Getters and Setter are omitted
 
}
 

Next, I need to annotate the id field with the CDB annotation @JSGeneratedId. With this annotation, I’ll instruct CDB to treat this field as an auto-generated id. Let’s examine the directory of the Ext JS MVC application and take a look inside the model folder. Inside the model folder (the JavaScript section), we have the folder dto which corresponds to the Java dto package where the class PersonModel.java resides.

Figure 5. Generated from Java Class Ext JS Model

As you can see Clear Data Builder generated two files as recommended by the Generation Gap pattern, which recommends keeping the generated and handwritten code separate by putting them in different classes, linked by inheritance. Let’s open the Person model. In our case, the PersonModel.js is extended from the generated_PersonModel.js. In case we need to customize this class, we’ll do it inside thePersonModel.js, but this underscore-prefixed file will be regenerated each and every time when we change something in our model. CDB follows this pattern for all generated artifacts — Java services, Ext JS models and stores. This model contains all the fields from our Person DTO.

Now, we need to create a Java service to populate the Ext JS store with the data. Let’s create an interface PersonService in the package service. This service will return the list of persons. This interface contains one method -List<Person> getPersons().

I need to ask CDB to expose this service as a remote object, which is done by the annotation @JSService. Another annotation @JSGenetareStore will instruct CDB to generate the store. In this case, CDB will create the destination-aware store. This means that the store will know from what remote service to populate its content. All configurations of the store’s proxies will be handled by the code generator. With @JSFillMethodannotation, we will identify our main read method (remember the “R” from CRUD).

Also, it would be nice to have some sort of UI to test the service — the annotation @JSGenerateSample will help here. CDB will examine the interface PersonService, and based on these annotations will generate all Ext JS MVC artifacts (models, views, controller) with the sample application.

PersonService Interface Annotated with CDB Annotations

 
	@JSService
	public interface PersonService {
	@JSGenerateStore
	@JSFillMethod
	@JSGenerateSample
	List<Person> getPersons();
}
 

When the code generation is complete, you’ll get the implementation for the service — PersonServiceImpl. The store folder inside the application folder (WebContent\app) has the store, which is bound to the PersonModel. And my person model was generated previously. In this case, Clear Data Builder generated the store that binds to the remote service.

Figure 6. Structure of Store and Model Folders

All of this intermediate translation from the JavaScript to Java and from Java to JavaScript is done by DirectJNgine, which is a server side implementation of the Ext Direct protocol.

There is one more thing you don’t want to miss — Clear Data Builder generated a UI for us! Check out the samples directory shown in Figure 7.

Figure 7. Folder with Generated Samples

You can see the SampleController and SampleGridPanel inside the samples folder. CDB also generates the JavaScript application entry point — sampleApp.js. To test this application, just copy the file SampleController.js into the controller folder, SampleGridPanel.js into the view folder, and the sample application in the root of ourWebContent folder. You need to change the application entry point with sampleApp in index.html.

This is how the generated UI of the sample application looks:

Figure 8. Scaffolded CRUD Application Template

Let’s return to the server side code. For services, CDB also follows the Generation Gap Pattern, and it generated stubs for the service methods. Override these methods when you’re ready to implement the CRUD functionality.

Implementation of PersonService Interface

 
	package service;
	import java.util.ArrayList;
	import java.util.List;
 
	import clear.data.ChangeObject;
	import dto.Person;
	import service.generated.*;
 
	public class PersonServiceImpl extends _PersonServiceImpl { // 1
 
	@Override
	public List<Person> getPersons() {				// 2
	List<Person> result = new ArrayList<>();	
	Integer id= 0;
	result.add(new Person(++id, "Joe", "Doe", "555-55-55", "1111-11-1111"));
	result.add(new Person(++id, "Joe", "Doe", "555-55-55", "1111-11-1111"));
	result.add(new Person(++id, "Joe", "Doe", "555-55-55", "1111-11-1111"));
	result.add(new Person(++id, "Joe", "Doe", "555-55-55", "1111-11-1111"));
	return result;		// 3
}
 
@Override
public void getPersons_doCreate(ChangeObject changeObject) {  // 4
Person dto = (Person) deserializeObject(
(Map<String, String>) changeObject.getNewVersion(),
Person.class);
 
System.out.println(dto.toString());
}
 
@Override
public void getPersons_doUpdate(ChangeObject changeObject) {	// 5
// TODO Auto-generated method stub
super.getPersons_doUpdate(changeObject);
}
 
@Override
public void getPersons_doDelete(ChangeObject changeObject) {	// 6
// TODO Auto-generated method stub
super.getPersons_doDelete(changeObject);
}
 
}
 

1. We need to extend the generated class and provide the actual implementation.
2. getPerson is our retrieve method (the R in CRUD).
3. For this sample application, we can use java.util.ArrayList class as the in-memory server side storage of the Person objects. In real world applications, you’d use a database or other persistent storage.
4. fillmethod+doCreate() is our create method (the C in CRUD).
5. fillmethod+doUpdate is our update method (the U in CRUD).
6. fillmethod+doDelete is our delete method (the D in CRUD).

Click on the Load menu, and you’ll get 4 persons from our server.

To demonstrate the rest of the CRUD methods, we’ll ask the user to insert one new row, modify three existing ones and remove two rows using the generated Web client. The Clear.data.DirectStore object will automatically create a collection of six ChangeObject’s — one to represent a new row, three to represent the modified ones and two for the removed rows.

When the user clicks on the Sync menu, the changes will be sent to the corresponding do… remote method. When you sync(), a standard Ext.data.DirectStoreExtJS is POST-ing new, modified and deleted items to the server. When the request is complete, the server’s reply data is applied to the store, expecting that some items can be modified by the server. In the case of Clear.data.DirectStore, instead of passing around items, we pass the delta, wrapped in the ChangeObject.

Each instance of the ChangeObject contains the following:

1. newVersion — it’s an instance of the newly inserted or modified item. On the Java side, it’s available via getNewVersion().
2. prevVersion — it’s an instance of the deleted old version of the modified item. On the Java side, it’s available via getPrevVersion().
3. array of changepropertyNames — this ChangeObject represents an update operation.

The rest of ChangeObject details are described in the Clear Data Builder wiki on Github (see the Useful Links section below).

The corresponding Java implementation of ChangeObject is available on the server side, and Clear Toolkit passes ChangeObject instances to the appropriate do* method of the service class. Take a look at the getPersons_doCreate() method from the code sample above. When the server needs to read the data that arrived from the client, your Java class has to invoke the method changeObject.getNewVersion(). This method will return the JSON object that you need to deserialize into the object Person. This is done in the code sample above and looks like this:

 
	Person dto = (Person) deserializeObject(
	(Map<String, String>) changeObject.getNewVersion(),Person.class);
 

When the new version of the Person object is extracted from the ChangeObject, you can do whatever has to be done to persist it in the appropriate storage. In our example, we just print the new person information on the server side Java console. This is why we said earlier, that it may be a good idea to provide a pretty printing feature on the class Person by overriding method toString(). Similarly, when you need to do a delete, the changeObject.getPrevVersion() would give you a person to be deleted.

Part Three: Data Pagination

The pagination feature is needed in almost every enterprise web application. Often, you don’t want to bring all the data to the client at once — a page by page feed is a lot more responsive. The user can navigate back and forth between the pages using pagination UI components. To do that, we need to split our data on the server side into chunks, so we can display it when the specific page is required.

In Part Three, I’ll cover Implementing Pagination including:

• Add the data pagination to our sample CRUD Ext JS + Java application:
• Add the Ext.toolbar.Paging component
• Bind both grid and pagingtoolbar to the same store
• Use DirectOptions class to read the pagination parameters

We are going to extend our CRUD application by adding the paging toolbar component bound to the same store as the grid. The class DirectOptions will handle pagination parameters on the server side.

In Parts 1 and 2, you learned how to generate the UI from the Java back-end service and how to generate the Ext JS store and Ext JS model. In this part, you’ll learn how to add the pagination functionality to your CRUD application by asking the server to send only portions of the data. We’ll need to refactor the service code from the previous example to generate a little bit more data than the five records.

Refactored implementation of PersonService Interface

 
	public class PersonServiceImpl extends _PersonServiceImpl {
	@Override
	public List<Person> getPersons() {
	List<Person> result = new ArrayList<>();
	for (int i=0; i<1000; i++){
	result.add(new Person(i, "Joe", "Doe", "555-55-55", "1111-11-1111"));
	}
return result;
}   
}
 

The Google Chrome Console shows that PersonStore was populated with one thousand records. Let’s add the pagination component using the Ext toolbarpagingcomponent, and let’s add it to the file sampleApp.js above.

Sample Application Entry

 
	Ext.Loader.setConfig({
	disableCaching : false,
	enabled : true,
	paths : {
	episode_3_pagination : 'app',
	Clear : 'clear'
}
});
 
Ext.syncRequire('episode_3_pagination.init.InitDirect');
// Define GridPanel
var myStore = Ext.create('episode_3_pagination.store.dto.PersonStore',{});		// 1
Ext.define('episode_3_pagination.view.SampleGridPanel', {
extend : 'Ext.grid.Panel',
store : myStore,
alias : 'widget.samplegridpanel',
autoscroll : true,
plugins : [{
ptype : 'cellediting'
}],
dockedItems: [
{
	xtype: 'pagingtoolbar',		// 2
	displayInfo: true,
	dock: 'top',
	store: myStore			// 3
}
],
columns : [
{header : 'firstName', dataIndex : 'firstName', editor : {xtype : 'textfield'}, flex : 1 },
{header : 'id', dataIndex : 'id', flex : 1 },
{header : 'lastName', dataIndex : 'lastName', editor : {xtype : 'textfield'}, flex : 1 },
{header : 'phone', dataIndex : 'phone', editor : {xtype : 'textfield'}, flex : 1 },
{header : 'ssn', dataIndex : 'ssn', editor : {xtype : 'textfield'}, flex : 1 }],
tbar : [
{text : 'Load', action : 'load'},
{text : 'Add', action : 'add'},
{text : 'Remove', action : 'remove'},
{text : 'Sync', action : 'sync'}
]
});
// Launch the application
Ext.application({
name : 'episode_3_pagination',
requires : ['Clear.override.ExtJSOverrider'],
controllers : ['SampleController'],
launch : function() {
Ext.create('Ext.container.Viewport', {
items : [{
xtype : 'samplegridpanel'
}]
});
}
});
 

1. Let’s manually instantiate this store — create a separate variable myStore for this store with an empty config object.
2. Add the xtype pagingtoolbar to this component docked items property — I’d like to display the information and dock this element at the top.
3. Now, the paging toolbar is also connected to same store.

Next, we need to fix the automatically generated controller to control loading of data on the click of the Load button.

Controller for Sample Application

 
	Ext.define('episode_3_pagination.controller.SampleController', {
	extend: 'Ext.app.Controller',
	stores: ['episode_3_pagination.store.dto.PersonStore'],
	refs: [{								// 1
	ref: 'ThePanel',
	selector: 'samplegridpanel'
}],
 
init: function() {
this.control({
'samplegridpanel button[action=load]': {
click: this.onLoad
}
});
},
 
onLoad: function() {
// returns instance of PersonStore
var store = this.getThePanel().getStore();		// 2
store.load();
}
});
 

1. We can bind the store instance to our grid panel. In the controller’s refs property, I’m referencing our simplegrid panel with ThePanel alias.
2. In this case, I don’t need to explicitly retrieve the store instance by name. Instead, we can use getters getPanel() and getStore() automatically generated by the Ext JS framework.

When the user clicks the button next or previous, the method loadPage of the underlying store is called. Let’s examine the directprovider URL — server side router of remoting calls — and see what the direct request looks like. Open Google Chrome Developer Tools from the menu, View → Developer, refresh the Web page and go to the Network tab. You’ll see that each time the user clicks on the next or previous buttons on the pagination toolbar, the component sends directOptions as a part of the request.

Figure 9. Request Payload Details

The default Ext Direct request doesn’t carry any information about page size. Clear JS, the client side extension of the Ext JS framework, adds some extra functionality to the Ext.data.DirectStore component to pass the page start and limit values to the server side. At this point, the directOptions request property shown in Figure 9 can be extracted on the server side to get the information about the page’s boundaries. Let’s return to the code of PersonServiceImpl and add some extra code there. Right now, the pagination doesn’t work. The server sends the entire thousand records, because the server is not aware that the data has to be paginated. We’ll fix it in the code below.

Implementation of PersonService with Pagination

 
	package service;
	import java.util.ArrayList;
	import java.util.List;
 
	import clear.djn.DirectOptions;			// 1
 
	import dto.Person;
	import service.generated.*;
 
	public class PersonServiceImpl extends _PersonServiceImpl {
	@Override
	public List<Person> getPersons() {
	List<Person> result = new ArrayList<>;();
	for (int i=0; i<1000; i++){
	result.add(new Person(i, "Joe", "Doe", "555-55-55", "1111-11-1111"));
}
// 2
int start = ((Double)DirectOptions.getOption("start")).intValue();
int limit = ((Double)DirectOptions.getOption("limit")).intValue();
 
limit = Math.min(start+limit, result.size() );		// 3
DirectOptions.setOption("total", result.size());	// 4
result = result.subList(start, limit);			// 5
 
return result;
}
}
 

1. On the server side, there is a special object called DirectOptions, which comes with Clear Toolkit.
2. We’re interested in start and in limit options (see Figure 9).
3. Calculate the actual limit. Assign the size of the data collection to the limitvariable if it’s less than the page size (start+limit).
4. Notify the component about the total number of elements on the server side by using DirectOptions.setOption() method with total option.
5. Before returning the result, create a subset, an actual page of data. In this case, we need to use the method java.util.List.sublist(), which produces the view of the portion of this list between indexes specified by the start and the limitparameters.

If you’d like to repeat all of the above steps on your own, watch the screencasts where I perform all the actions described in this article.

Conclusion

The development of an enterprise web application involves many steps that need to be done by the developer. But with the right set of tools, the repetitive steps can be automated. Remember the DRY principle — don’t repeat yourself. Try to do more with less effort.

Additional Useful Links

• Clear Toolkit on Github
• Clear Data Builder Eclipse update site
• Ext JS MVC Application Architecture
• Ext.data.Model
• Ext.data.Store
• Ext JS Grid Panel
• Ext.toolbar.Paging
• Ext Direct
• DirectJNgine: Direct for Java
• Change Object: Synchronization Keystone
• Data Pagination in Clear Toolkit
• Farata YouTube channel

“The Facebook Technology Partners program connects developers to 3rd party resources that are built on top of Facebook Platform and SDKs to enable Facebook integration.”

Sencha Touch, our JavaScript framework that enables you to build high performance, touch-based web apps, allows you to easily integrate these apps into any back end, including Facebook. We’ve built a sample application, called The Watch List that leverages a Node.js server, a MongoDB database (hosted by MongoLab), the Facebook Open Graph API, Login with Facebook and of course Sencha Touch. The client side Sencha Touch app authenticates the user with Login with Facebook and talks to the node.js server to make Facebook Open Graph API calls and to store what movies you’re watching in MongoDB.

We’ve recorded a code walkthrough that goes through the core pieces of The Watch List sample app, and shows how it implements Facebook integration both on the Sencha Touch client and on the node.js server side.

You can find the source code for the The Watch List on GitHub: https://github.com/senchalearn/Watchlist.

To learn more about building your apps with Sencha Touch, don’t miss SenchaCon 2013 July 16–19 in Orlando where Sencha engineers will present an entire track dedicated to Sencha Touch covering new features, advanced topics, insider tips and tricks. This is a great opportunity to meet 1:1 with Sencha engineers, meet other HTML5 and Sencha developers in the community, share best practices and network. We are also offering a pre-conference Sencha Touch Bootcamp where you will use Sencha Touch and Sencha Architect to create a working, enterprise mobile application in just one day. You can read more about this year’s event at www.senchacon.com.

If you’re new to Sencha Touch, check out the documentation and get started building your first Sencha Touch app. When you’re done, let us know and submit your app to the Sencha Touch app gallery. Happy coding!

Ext JS 4.2 contains many exciting enhancements and features. You may have read about some of these in previous posts, such as the improvements to the Grid component. In this article, we’ll take a tour of the new Neptune Theme and Right-to-Left (RTL) support.

Neptune

With Ext JS 4.2, we are excited to welcome “Neptune” to the family as an official, fully supported theme. Building applications that have a modern, contemporary look has always been incredibly important for application developers and with the new Neptune theme, Ext JS now supports four core themes out of the box: Neptune, Classic, Gray and Accessibility.

Neptune gives your application a clean, modern and lighter look by minimizing unnecessary visual elements such as borders and increased padding in many places to make the overall interface feel more relaxed and open.

Our goal for Neptune is far more than just providing a new and pretty face. We want to enable you to create the best application experience easily and on as many browsers as possible. To support this, we have made some significant advances in how we do theming that will make it easier to customize and share themes.

Flexibility

The key to creating the best applications is easy customization. Making changes has to be as simple as possible, because when it comes to themes: one size never fits all.

To make the Ext JS themes as flexible as possible, we’ve greatly expanded the use of Sass variables. The variables are chained together, so variables calculate their default values from other variables, and whenever possible, changes (such as setting the “$base-color”) propagate as you would expect.

Theme Packages

Sencha Cmd 3.1 adds support for “packages”: self-contained bundles of code, styling and resources. Neptune and the other Ext JS 4.2 themes are now delivered as theme Packages which enables many exciting possibilities.

In general, packages allow you to easily share code between your applications as well as with other developers. Sharing JavaScript classes is something that the Ext JS loader and previous versions of Sencha Cmd handled very well, but now, with packages, Sencha Cmd can connect the world of JavaScript classes to the world of Sass.

Internally, Ext JS leverages the Sencha Cmd ability to relate JavaScript and Sass to build its themes. That is, Cmd produces the “all.scss” and ultimately “all.css” that we ship with Ext JS. This build process ensures that the individual SCSS files defining Sass variables and rules are always in the right order based on the JavaScript class hierarchy. This allows us to share Sass logic between the various themes as easily as we do JavaScript classes.

Of course, these Sencha Cmd features are not limited to building Ext JS. If you use Cmd to build the “all-classes.js” file containing a concatenation and compression of all your JavaScript, you can extend this to build your application’s Sass. If you do, you gain another exciting first: your CSS file will contain only the CSS needed for the components you are actually using. This also works for views you define, so your application can organize its Sass as a mirror image of its JavaScript — a huge help as your application grows over time.

In the same way we improved user experience by not downloading lots of unused JavaScript, removing unused CSS can also be a big help. This is even more true of CSS because unnecessary rules are not so easily ignored by the browser. Some browsers also have limits on the number of rules you can have in your CSS file. Going forward, this will be increasingly important as new components are added and new features (like RTL) are added that span all components.

Custom Themes

Themes are special types of package that have one important, additional feature: themes can “extend” other themes. This capability is used by Ext JS 4.2 to create its theme hierarchy:

The build process for theme packages has an extra step that allows a theme to inherit any of the resources of its base(s) or elect to replace them with a version of its own. Also, for IE compatibility, the image “slicer” is automatically invoked to transform your CSS3 border radius and linear gradient styles into background images.

All of this allows you to create new themes by adding only what you want to change (style rules, JavaScript code or static resources like images). There is no need to “copy and paste” anything from your base theme. This ensures that your themes will inherit bug fixes and other enhancements as we maintain the core themes.

You can learn a lot more about this process in the Theme Guide found here and about packages in general in the package guides http://docs.sencha.com/ext-js/4-2/#!/guide/command_packages and http://docs.sencha.com/ext-js/4-2/#!/guide/command_package_authoring.

RTL

The support for Right-to-Left languages (such as Hebrew and Arabic) has been a long-requested feature, so we are delighted to say that RTL is now here. We are equally happy to say that if you don’t need RTL support and do not enable it, there is only a minimal amount of additional code added to the core of the framework.

The first step to enabling RTL is to require the “Ext.rtl.*” namespace. This namespace contains many overrides that look like this:

 
Ext.define(‘Ext.rtl.button.Button’, {
    override: Ext.button.Button’,
    …
 

This family of overrides takes over key positioning methods on various classes in the framework and adds the necessary RTL checks and logic.

The second step once you have the supporting code injected into the framework is to set the “rtl” config on the containers you want — such as the viewport:

 
Ext.define(‘MyApp.views.Viewport’, {
    extend: Ext.container.Viewport’,
    requires: [
        ‘Ext.rtl.*’
    ],
    rtl: true,
    …
 

RTL in Sass

On the CSS side, RTL support is enabled by setting this Sass variable:

 
$include-rtl: true;
 

This will add the CSS rules for RTL using the “.x-rtl” selector.

Mixing LTR and RTL

The “rtl” config is inherited down the Component hierarchy. By setting it on the Viewport, you are effectively setting RTL globally. This setting can be enabled at a lower level or changed back by setting “rtl: false” which is then inherited from that level down.

Due to CSS limitations in IE6 and IE/Quirks, nesting is not supported. Loading the CSS with RTL support must only be done when RTL is desired globally on these browsers.

Locales

To streamline this process for your applications, Sencha Cmd supports a package type of “locale”. Ext JS 4.2 now provides its locale support in this form, so your applications can simply require the appropriate locale package. The JavaScript needed will automatically be included and the include-rtl Sass variable set accordingly. Using this approach, you can produce an optimized JavaScript/CSS build for each locale.

Performance

This article would be incomplete if I did not say a few words about performance in Ext JS 4.2 compared to Ext JS 4.1 and 4.0. While the majority of performance improvement work has been in relation to grid, several other changes were made largely for performance reasons.

These changes ranged from removing the CSS reset (its numerous “expensive” rules to reset, scope reset and unreset), to moving logic out of JavaScript to handle “framed” components (such as buttons), to simplifying the button component markup and its corresponding component layout logic.

In the previous article, I compared Ext JS 4.0.7 to Ext JS 4.1 using the Themes example. Since then, a good friend in the community submitted an example application mimicking his own that is definitely a better, real-world test than Themes. I have put the probes to that example on the same IE8 / Windows 7 laptop and here are the results.

The breakdown of performance by category in Ext JS 4.2 now looks like the chart below. The numbers from previous versions are “scratched out” to show the progression from 4.0.7 to 4.1.1 to current 4.2.0.

Performance is never done, and we will continue to look for ways to increase performance. If you want to read more about all the work we did on Grid and the new bufferedrenderer plugin, check out the original blog post here.

The Smaller Bits

There are lots of little improvements here and there. For more details on these, consult the Upgrade Guide.

Grid/Tree

There are several new examples that show how you can now combine many features which previously did not work together. Perhaps one of the most interesting is the locking TreeGrid.

The bufferedrenderer plugin also works on trees so you can now handle much larger trees (or tree grids) than before. To see a locking, buffered rendered TreeGrid, check out the example.

Check out all of the examples.

Tabs

Tabs can now go vertical. You can see them rotated and docked on the left or right in the new Side Tabs example

Glyphs

Many folks want to use web fonts to add scalable, cross-browser images to their application. To support this, we have added the “glyph” config which is very similar to “icon” and “iconCls”. You just set the “glyph” config to be the code point and the necessary text will be rendered into the component:

 
{
    xtype: 'button',
    glyph: 42
}
 

This is supported for buttons, tabs, panel headers and menu items. You can see this in action in the new Kitchen Sink example.

MVC

The introduction of Event Domains allows your Controller to respond to events fired by things like Stores or other Controllers.

Here’s what the code looks like:

 
this.listen({
    controller: {
        '*': {  // any controller
            foo: 'onFoo' // method names are now supported!
        }
    },
    store: {
        '#storeId': {
            remove: ‘onStoreRemove’
        }
    },
    component: { // same as this.control()
    }
 
});
 

XTemplate

You can now iterate objects more easily in your templates:

 
<tpl foreach=".">
    <tr>
        <td>{$}</td>
        <td>{.}</td>
    </tr>
</tpl>
 

The “{$}” expands as the property name and “{.}” is the property value.

Conclusion

Creating compelling, modern applications is hard work. Making them look awesome, run fast, and be delightful to use is even harder. With Neptune, RTL, the new grid improvements, enhancements to Cmd and all the various new features in Ext JS 4.2, delivering amazing experiences to your users has never been easier!

We’re excited to announce the general availability of Sencha Touch 2.2, the latest version of our JavaScript framework for building multi-device, touch-based applications. We’ve been hard at work on the latest version of Touch, adding in a whole host of new features as well as fixing issues and bugs (thank you to all our beta testers!).

Our focus for Sencha Touch 2.2 was to expand the footprint of device support to give you, our community, the broadest selection of devices to run your apps. In this release, we’ve enhanced our support for BlackBerry 10 devices and added support for Internet Explorer 10 for Windows 8 and Windows Phone 8. We’ve also made some big changes to improve performance in lists, themes, new debugging capabilities, added the new AnimationQueue feature, and more. This is the best Sencha Touch yet.

Updated BlackBerry 10 support

Sencha Touch already runs great on the recently released BlackBerry Z10 and also runs great on the forthcoming BlackBerry Q10. For Touch 2.2, we partnered closely with the folks at BlackBerry to take it even a notch higher, and now your Touch apps have everything they need to run lightning fast on BlackBerry 10 devices. You’ll find that the right markup, the right styling, and the right parameters for things like touch handling are all in place.

New Internet Explorer 10 Support

Sencha Touch 2.2 is the first version that works on Microsoft’s Internet Explorer 10 browser — goodbye WebKit dependencies! For the past few months, we worked with the Microsoft Open Tech team to remove all the WebKit specific code in Sencha Touch (or only use it when we’re on a WebKit browser). Under the hood, we’re using standard CSS3 flexible box layouts and HTML5 DOM selectors to get all of our layouts and rendering working beautifully wherever IE 10 runs (such as the Surface, Windows Phone 8, and Windows 8 devices).

We also built a new Windows 8 style modern theme that developers can use to build Microsoft-style looking applications just by switching to the new theme. It features the high padding, no-gradient, sans serif style that’s perfect for building Windows 8 and Windows Phone 8 applications. It’s pretty eye-catching, definitely check it out.

New Theming System

To make all the new platforms and new themes easy to support, Sencha Touch 2.2 features a revamped theming system. Switching your applications theme is as simple as changing the css property in your app.json file and the microloader and framework handle the rest. Our Kitchen Sink example now uses this system to display different themes based on which device it is being used on. You can see its app.json configuration here:

 
"css": [
    {        {
        "path": "resources/css/sencha-touch.css",
        "platform": ["chrome", "safari", "ios", "android", "firefox"],
        "theme": "Default",
        "update": "delta"
    },
    {
        "path": "resources/css/wp.css",
        "platform": ["ie10"],
        "theme": "Windows",
        "update": "delta"
    },
    {
        "path": "resources/css/bb10.css",
        "platform": ["blackberry"],
        "theme": "Blackberry",
        "update": "delta"
    }
],
 

We encourage you to try out the various built-in themes by using the “Theme” option in our Kitchen Sink demo app. Also check out our theming guide.

In Touch 2.2, we’ve changed the icons to use font-face — which are supported across all modern browsers, are more compact, and scale beautifully. Just like Sencha Touch 1 and 2.1, we conveniently map icon names to actual icons so you can use them within your application. For example:

 
{
    xtype: 'button',
    iconCls: 'home',
    title: 'Home'
}
 

For a full list of available iconCls's available, please refer to the Ext.Button class documentation.

Performance Improvements

In December, we demonstrated the power and speed of HTML5 with our Fastbook proof of concept application. We’re excited to announce that many of the techniques we pioneered in Fastbook are now built into Sencha Touch 2.2. Specifically,

• AnimationQueue is a centralized Event and Animation queue. When the browser has requestAnimationFrame, AnimationQueue uses that HTML5 API, and when it’s not, uses more vanilla JavaScript timers. This new system helps ensure that we handle animations and other events only in between frames, so everything runs smoothly.
• List DOM has been dramatically streamlined. Almost all Touch apps use a list and with the lighter DOM, scrolling will remain fast even as your list and templates get more complicated.
• The showfps debugging option lets developers see how fast Touch is rendering and will help you see when your application’s design is outpacing the performance of the device.

Sencha Architect 2.2 Support

Today we also released an update to Sencha Architect 2.2 that includes support for Sencha Touch 2.2, thus instantly allowing our Architect users to become Touch 2.2 developers. Architect can help build your next great Touch app, and if you have an existing Architect+Touch project, you can easily upgrade it to a Sencha Touch 2.2 project. Architect makes it easy to switch between the new built-in Touch themes.

Try It Out

Go ahead and take Sencha Touch 2.2 for a spin: try the Sencha Touch Bundle, which includes Sencha Touch, Sencha Touch Charts, Sencha Eclipse Plugin, and Sencha Architect; or download the free standalone Sencha Touch SDK. It’s available with a 30-day trial, so feel free to download it and give it a go: it gives you everything you need if you are serious about building great touch apps.

Meanwhile, we have been working hard to truly make SenchaCon 2013 bigger, better and more fun than ever. The big focus from our technical team right now is getting the first set of technical sessions ready to post on the website. Within a week, we should have a little more than half of the 60+ sessions available to peruse (spoiler alert: it’ll probably actually be more than 70 when all is said and done).

For those of you that submitted a session proposal to our call for papers and are awaiting a response before you register, we will be notifying everyone by end of next week. If you want to register now and take advantage of the early bird price, you can go ahead — if you get accepted as a speaker, we will simply refund your ticket cost.

We’ve also had better than expected response to our “build your vacation around SenchaCon” concept. Seems lots of you are taking advantage of the discounted room rates and booking some of the “shoulder days” (the few days prior or few days after the event) to enjoy Florida. Although we still have plenty of hotel rooms available overall, rooms at the conference rate on shoulder days are limited, so if you’re thinking about staying an extra long time make sure you book sooner rather than later.

Never been to SenchaCon? Check out this montage video we pulled together to see how this community rolls. If you were there with us in Austin, see if you can spot yourself. Either way, this should get you pumped up for Orlando in July!

KiteDesk funnels your most important cloud information into a single data stream. The idea is simple: consumers use Dropbox, Facebook, Gmail, Twitter, LinkedIn, etc., but switching between apps is a pain. KiteDesk brings them all together, so users can view emails, social media posts, calendar items, contact info, docs, pictures and videos in one place — no more "app-flipping." Users can also build custom streams, for things like work, book clubs and softball leagues.

Why We Chose Sencha Ext JS

We selected Ext JS because it offers a very complete and robust client-side framework with beautiful built-in controls, and a simple but powerful programming model. We needed to enable a team of experienced Java developers to deliver a very sophisticated HTML5 based application with minimal startup time. Ext JS does a wonderful job of promoting a model, view, controller (MVC) architecture which is very familiar to programmers from a number of backgrounds. We designed KiteDesk’s user experience to feel like an app, and that required the latest web standards and capabilities like offline storage. Ext JS made it easy to load information from our existing REST services, store it, and to link it to our user interface controls using a convention over configuration approach.

The screenshot above shows KiteDesk’s Messages. The left column uses a subclass of the Ext JS Grid Panel to list email accounts and folders. The Grid Panel ties an interactive view with an underlying data store, in this case the mail accounts and folders. As accounts are added or updated with new messages, the list is automatically updated to match. Here we display accounts as icons, each with its own tooltip describing it in more detail.

The middle column lists mail messages for an account, and it also uses a Grid Panel filtering messages on the account and label selected in the navigation.

KiteDesk makes heavy use of many Ext JS built-in components like Panels, GridPanels, Windows, Buttons, Stores, etc. We also created a number of application-specific components to give the app its unique look and feel. In the Messages mail client, for example, we wanted to display messages using a distinctive and interactive card-like format. Since a user checking their inbox will be viewing one message thread after another, we wanted those cards to be as lightweight as possible and for the user experience to be fast and responsive.

“We selected Ext JS because it offers a very complete and robust client-side framework with beautiful built-in controls, and a simple but powerful programming model.

Our early versions of MessageCard were built using standard Ext JS buttons and other components, which made it easy to rapidly prototype and try out different approaches and layouts. Once we settled on the best one, we then customized the component to generate hand-crafted HTML and minimize the JavaScript objects needed for each card to further improve performance.

The Ext JS documentation is top notch, and it was easy for our team to learn quickly and get the most out of the framework. We were pleased to discover that the online version of the doc includes user comments which we were very helpful. And, of course, the Sencha Forums were incredibly valuable and useful as well.

All in all, Ext JS is a solid and mature framework, and one we trust to build our product on. We have also found the Sencha community to be friendly and knowledgeable, which helped us tremendously.

We make extensive use of the powerful Event support Ext JS provides to seamlessly wire our application. For example, clicking the star icon on a message adds that message to your favorites. Behind the scenes that click fires a starMessage event which is handled by the MailController which takes care of the logic behind that action. That event could also be triggered by choosing the “Star Message” menu item, or by whatever other method you wish, but regardless of its source the event is captured and handled by the MailController. This is just one example of how Ext JS makes it easy to leverage MVC architecture, which cleanly separates the view (that users see and interact with) from the underlying controller logic.

Business Value of Using Sencha Ext JS

Ext JS offers an environment that is completely extensible and does not box developers into corners. It’s a core part of our product strategy because it allowed us to migrate our team of Java developers to an HTML5 based project faster and more efficiently. We got our team up to speed quickly using the extensive, high quality documentation. We didn’t face challenges of having to use disparate 3rd party controls and competing core programming models. Our initial prototype was delivered in much less time than it would have been using other JavaScript frameworks, and we were able to create a clean and modern UI. By using Ext JS, we were able to get our initial product to beta sooner which allowed us to get user feedback early in the cycle saving us time and money beyond the pure productivity gains offered by the framework.

Our Advice to New Developers

Ext JS will make it easy to develop your applications. It’s tempting to jump in and start writing your application immediately because the framework is so approachable. We recommend that you spend some time up front reviewing the examples and the documentation. Take advantage of the MVC convention that is built into Ext JS because it will minimize the code you write. If you find yourself writing a lot of code, it’s likely that you have missed some of the core capabilities and best practices of the framework. The event handling, CSS compilation, and other features of the framework should be invested in and understood at the onset of your project because using these capabilities will save you a huge amount of time over the long run.

Final Thoughts

Ext JS is a great framework and the Ext core that is largely shared between Ext JS and Sencha Touch is a powerful programming model for HTML5 based applications. It’s made our developers more efficient and has helped us to evolve KiteDesk quickly.

It turns out that the compiler is customizable, and can be instructed to change its output based on your needs, to produce a better build. What is a better build though? This definition will change based on the project, and based on the team member. For many developers, the best build is the one that happens as fast as possible, letting you get straight to testing. For some teams, the best build is often the one that produces the smallest browser download, or sometimes the smallest total compiled size.

In this article, we’ll discuss several different ways to customize what the compiler is building for you, and how it can impact build times and output sizes. We’ll use the Sencha GXT Explorer as an example. While it is not as complex as many applications out there, it does use almost every single widget Sencha GXT has to offer. Using Sencha GWT 2.4.0 and GXT 3.0.4, the Explorer builds in about 183 seconds, and the largest permutation is 2,608,783 bytes.

Permutations

A ‘normal’ build is one where you get 6 basic permutations, one for each category of browser. These have been selected by the GWT team as related enough to always treat as the same. These browsers are:

• Firefox, all versions
• All Webkit browsers (Safari, Chrome, Android Browser, etc)
• IE6 and IE7
• IE8
• IE9 (and IE10)
• Opera

GXT is configured by default to use these same 6 permutations — it is a good middle ground between all possible configurations and lumping everything together. GXT adds several possible browsers that are not normally listed — IE6 and IE7 are kept apart, as are IE9 and IE10. Chrome and Safari are treated as two different browsers, with several distinct versions, where required. Firefox is lumped into two categories — before Gecko 1.9 and after, allowing for some tests of specific cases. GXT also adds another degree of possibility — Operating System. There are unique features to each OS that make it important to allow GXT to tell the difference.

With all of these variations in the build, it’s possible to end up with 52 permutations in 3.0.4! This makes the build times much longer than the normal 6 permutations — but do we gain anything?

To test this question, I made a few changes to the application’s module file. Instead of

 
  <inherits name="com.sencha.gxt.ui.GXT" />
 

which is the standard inherits statement to load GXT, I replaced this statement with the specific modules we were interested in. We can load just the widgets and the State handling code instead, as well as a theme:

 
  <inherits name="com.sencha.gxt.widget.core.Core" />
  <inherits name="com.sencha.gxt.state.State" />
  <inherits name="com.sencha.gxt.theme.blue.Blue" />
 

At present, Charts do not allow for this particular change, so I had to make the same change to the Charts.gwt.xml file to allow it to make this change overall.

This is a massive overkill and doesn’t save us much. The largest permutation is now down to 2,587,780 bytes — a difference of about 21K, or a savings of less than 1%, and the build took 20 minutes, up from about 3 minutes. Interestingly, it also only produced 26 actual permutations — while the OS check allows our code to differentiate between Windows/Mac/Linux/Unknown, it turns out that we rarely need to take advantage of this check, so half of our build time is essentially wasted. We’re still seeing savings though — some teams may find it worthwhile to create very specific builds for supported browsers, then limit which browsers they support when debugging and allow very long builds for production.

We can also take this in the other direction in two different ways by combining browsers into fewer permutations or by limiting which browsers we intend to support.

First, we can restrict which browsers we intend to support:

 
  <inherits name="com.sencha.gxt.ui.GXT" />
  <set-property name="gxt.user.agent" value="ie9, ie10, gecko1_9, safari5, chrome, opera" />
 

By inheriting GXT again, and limiting the browsers we are most interested in, we are limiting the build down to 4 permutations — ie8, ie9/ie10, gecko1_9, and safari5/chrome. These 6 browsers only require 4 permutations because once again, we are condensing similar browsers into the same build. By following the previous step (not inheriting GXT directly), we can expand this back to 6 if we wanted — and be slightly more specialized than we were to begin with. Or, we can keep our smaller set. With this smaller set, we can compile in about 140 seconds, and the largest of our four permutations is 2,608,785 bytes, about the same as we started.

The second option is to further condense supported browsers into fewer permutations. There are two tools for this option and both rely on the idea of merging permutations. First, we can specify that one or more property should be collapsed:

 
  <inherits name="com.sencha.gxt.widget.core.Core" />
  <inherits name="com.sencha.gxt.state.State" />
  <inherits name="com.sencha.gxt.theme.blue.Blue" />
  <set-property name="gxt.user.agent" value="ie9, ie10, gecko1_9, safari5, chrome, opera" />
 
  <!-- merge gecko1_9, safar5, and chrome into one permutation -->
  <collapse-property name="gxt.user.agent" values="gecko1_9, safari5, chrome" />
 
  <!-- merge ie9 and ie10 into one permutation with a wildcard-->
  <collapse-property name="gxt.user.agent" values="ie*" />
  <!-- merge all operating system permutations -->
  <collapse-property name="user.agent.os" values="*" />
 

This gives us a different set of 4 permutations, the largest at 2,608,785 bytes, and completes in 144 seconds — still faster than our baseline, supporting fewer browsers, and at nearly the same size.

Finally we can tell the compiler that every single property should be collapsed into one permutation:

 
  <collapse-all-properties />
 

This is the big one — no matter how many permutations you had configured before this line, only one file will be created. This is especially handy for very fast builds or cases where you want to keep the build size small (such as only one 1.5MB file instead of six 1.0MB files). In the case of the Explorer, we bring the compiled size up to 3,376,120 bytes, about 700K larger, but the compile time drops to just over a minute, from just over three minutes. The total compiled directory also drops in size, from about 22MB to less than 6MB.

If you would like more information, you can learn about properties and permutations on the GWT wiki.

Optimization levels and other flags

When the GWT compiler rewrites Java into JavaScript, it transforms the code in many ways. Some rewrites are necessary to change Java expressions into JavaScript — instanceof operators and casts are turned into method calls, and all classes and inheritance are tracked in a lookup table. It also looks for cases where code is easy to read but hard to execute, and rewrites them — fields left at their default values are turned into constants and sometimes compiled away, among many others. All modifications to the way the optimizer works are set when running the compiler, not in the module files. How you set these modifications may vary based on how you build your project — for command line and Ant users, these are arguments passed to the compiler, while for Maven users these are configuration options.

Faster builds

By default, the compiler runs and runs until it is no longer making a difference in the files it is touching. For many applications, this results in 8 to 15 steps through the optimizer before starting on browser-specific details. This too is configurable, but must always be run at least once to properly transform Java into JavaScript. If we set the optimization level to 0, we are asking for as little optimization to be done as possible, whereas setting it to 9 (the default) asks the compiler to run until it is no longer able to find anything to optimize.

There is also a set of expensive optimizations called ‘Aggressive Optimizations’. By default, these are enabled but can be turned off.

There is also a handy option called ‘draft mode’ — activating this option disables all aggressive optimizations and turns down the optimization level at the same time. This is the easiest way to limit the effort that the compiler is putting into building an app. Just turning on draft mode brings the Explorer build time down to 103 seconds, from 180, though it raises the size of the largest permutation to 3,426,639 bytes, some 800K larger. Combined with the collapse-all-permutations directive in the module, the compile time drops further to 49 seconds — less than a minute! Predictably, the compiled size also grows, now up to 4,459,653 bytes which is not a problem for local debugging, but not something you’d want to serve over the Internet to users’ browsers.

GWT Compiler:

Pass the -draftCompile flag to the compiler

GWT-Maven-Plugin:

Either set <draftCompile>true</draftCompile> in the plugin configuration, or set the gwt.draftCompile property to true

Smaller apps

There are also flags that can decrease the compiled size of the app by overly simplifying code. These flags are not a fit for every project but are worth considering. The first is to skip class metadata. This causes Class.getName() to return some generic string instead of the usual "org.package.to.my.client.Object", thus decreasing the number of strings that need to be baked into the output. Most applications don’t depend on those strings being the same every time, but you’ll need to consider your use cases.

GWT Compiler:

Pass the -XdisableClassMetadata flag to the compiler

GWT-Maven-Plugin:

Either set <disableClassMetaData>true</disableClassMetadata> in the plugin configuration, or set the gwt.disableClassMetadata property to true

This saves Explorer about 3.5%, bringing the size to 2,522,282 bytes. The compile time doesn’t change much, since we’re just removing the strings that are used to describe the packages and classes.

The second flag is somewhat more invasive, by removing all ClassCastExceptions from your compiled code. Where Java has a cast operator, letting you specify that you want to treat an object of type A as if it were type B, JavaScript has no such concept, so all type checks must be added through synthetic code. A block like

 
    if (obj instanceof HasMethod) {
    	HasMethod hasMethod = (HasMethod) obj;
    	hasMethod.doSomething();
    }
 

will by default compile to something like:

 
  if (instanceOf(obj, 5)) {
  	hasMethod = dynamicCast(obj, 5);
  	hasMethod.doSomething();
  }
 

If you enable this feature, instead, the compiled JavaScript will be something more like:

 
  if (instanceOf(obj, 5)) {
  	hasMethod = obj;
  	hasMethod.doSomething();
  }
 

This flag will also remove other cast operations elsewhere in your application. It can often be a good thing — the very fastest code is code that never runs — but you will miss out on any unexpected ClassCastExceptions in your compiled application. Instead, you’ll either see no errors at all, or you’ll see the JavaScript equivalent of a null pointer when a method or field is referenced. If you see such an error in production, you can run in Dev mode or without this flag set, and you will see the correct error.

GWT Compiler:

Pass the -XdisableCastChecking flag to the compiler

GWT-Maven-Plugin:

Either set <disableCastChecking>true</disableCastChecking> in the plugin configuration, or set the gwt.disableCastChecking property to true

By itself, removing cast checking saves less than 2%, though this can also have significant impacts on runtime performance by avoiding useless checks. As with the class metadata, dropping cast checks does not have much impact on compile times.

Enabling both of these features takes roughly the same amount of time to compile, and removing this possibly useless extra data and checks drops the compiled size by about 6%, down to 2,461,611 bytes.

CssResource classnames

Next, we have a configuration change that can be made to the way CssResources are generated by ClientBundle. By default, ClientBundle assumes that there might be more than one application running on the page and care should be taken to generated CSS classes, so they will never conflict. This set of features can be customized in several ways, either to make debugging easier or to make the application size smaller.

GXT 3 makes heavy use of CssResources and ClientBundles. They hold all of the styles and images used to render and update widgets. The appearance pattern lets the compiler include only the CSS that is actually used, making for smaller applications and more optimized styles.

If you know that no other content needs to be rendered except your application, you can remove all of that extra prefixing. This enables ClientBundle to rename all CSS classes to very short strings, usually less than three characters.

To enable this feature, add this line to your module file:

 
<set-configuration-property name="CssResource.obfuscationPrefix" value="empty" />
 

This isn’t a terribly powerful optimization, but every little bit helps. This change has no impact on compile times and brings the Explorer size down to 2,607,442 bytes, a savings of only about 1K.

Keep GWT and GXT up to date

One final thing we can do is keep the compiler up to date. While the main GWT library code isn’t changing too much beyond keeping up with browsers and fixing bugs, the compiler itself is slowly incorporating changes, fixes and improvements.

If you use UiBinder, don’t forget to remove the uibinder-bridge jar from your classpath and the inherits from your module. It is no longer necessary when using GWT 2.5.0 or later.

By itself, switching to GWT 2.5.0 brought the default build down to 2,388,364 bytes — almost 10% savings or about 200K, though it seemed to increase compile times slightly.

The Closure Compiler

The release of GWT 2.5.0 brought an additional compilation step that can be added to the process. The Closure Compiler, a JavaScript optimizing compiler, is able to rewrite JavaScript that follows certain rules to be smaller and more efficient. While many of these same optimizations are available to the GWT compiler, there are some that are not present. Allowing the Closure Compiler to run after GWT has done its work can often take a pretty big chunk out of the compiled size.

While any GWT/Java code is already compatible with the Closure Compiler, some JSNI is not. As part of the GXT 3.0.4 release, we’ve made some internal changes to ensure that this optimization will not break GXT applications.

While this produces smaller downloads, it comes at a cost — compile times can skyrocket, depending on the size of the application. This optimization must be performed on each permutation of the application, after it has been compiled, which can negatively affect multi-permutation apps.

GWT Compiler:

Pass the -XenableClosureCompiler flag to the compiler

GWT-Maven-Plugin:

Either set <enableClosureCompiler>true</enableClosureCompiler> in the plugin configuration, or set the gwt.compiler.enableClosureCompiler property to true

Enabling just the Closure Compiler saved an additional 20K over just switching to 2.5.0, bringing the compiled size to 2,388,364 bytes, though adding over four minutes to the build time. This is less than the combined savings of disabling cast checks, class metadata, and CSS classname prefixes, but on the other hand, it can stack with those optimizations. Combining all of these optimizations brings the compiled size down to just over 2MB, an overall savings of 300K, or 15%.

Combining these optimizations

Based on all of these options, what seems to be the ‘best’ set of optimizations?

Smallest individual permutations (best for production):

• Switch to GWT 2.5.0
• Enable Closure Compiler
• Disable Class cast checks and Class metadata
• Disable CSS class name prefixes

Rapid compilation:

• Select only desired browsers (optional)
• Collapse all permutations into one
• Enable Draft mode

If you need very small total output (such as for compiling for embedded servers), you can mix and match — enable the compiler to do as much work as possible and leave draft mode off, but collapse all properties into one permutation.

Legend

• A — draft
• B — collapse-all
• C — disableClassMetaData
• D — disableClassChecking
• E — empty css classname prefix
• F — Closure Compiler (GWT 2.5 and above only)

In these charts we can see that there is nearly an inverse relationship between compiled size and time — the longer we let the compiler work, the more productive it can be. At its best, the compiler can either finish the Explorer in under a minute, or just over 2MB. However, it’s important to note that build times are somewhat inconsistent — building with the same settings does not always complete in the same amount of time.

Conclusion

What we get out of a build depends, of course, on the code we put in, but also on how we ask the compiler to produce the output. By specifying what work we need or do not need to have done, we can choose that additional work be completed, or that the build be finished as soon as possible.

What do you need out of your build?

Display Components

Sencha Blink’s flagship component is the Ext.grid.eyeGrid (xtype: eyegrid), a port of the Ext JS grid to spectacle-based devices. Scrolling an eyeGrid is as simple as focusing on the scrollbar and then making a quick eyeroll. Activation time thresholds can be specified in the configuration. Cut and paste is activated by glaring at the target cell, pinching your eye shut and then re-opening your eye while focused on the destination cell. In our usability tests, no more than 1 minute of practice was required to achieve a 95% success rate with this operation.

But what makes Sencha Blink most exciting is our system of transparent overlays. We use Canvas and hardware-accelerated real-time image filtering to automatically tag appropriate elements in the currently viewed scene. We’re shipping the following example overlays to better power your applications.

• HomelessOrHipster: an overlay that correctly identifies over 90% of the time whether that guy is wearing expensive vintage clothes or is actually homeless.
• SprayTan: this overlay selectively desaturates the orange glow from spraytan using ColorMatrix transforms. We’ve made this even more accurate by using the CIELab color space rather than the traditional RGB space.
• FoodOrMole: if you’ve ever done the “you’ve got food on your cheek” gesture, only to find out that the person actually has a mole, you’ll recognize the utility of this overlay.
• FiveSecondRule: whenever some food item falls from your hands, we object track and clock the amount of time that food object has been on the ground. Of course, you can use configurations if you follow a TenSecondRule.

Stay tuned for tutorials on how to create your own custom overlays.

 
{
   xtype:'eyegrid',
   config:{
      overlay:'hipsterorhomeless',
      sensitivity:'medium',
      vendor:'googleglasses'
   },
   listeners:{
      onBlink:myOnBlinkHandler
   }
}
 

Eye Gestures

Since each spectacle device ships incompatible gestures (the Google Glass onStare vs. the iPane onGlare) we’ve shipped a set of gesture abstractions. Sencha Blink 1.0 supports the following gestures: onPinch, onEyeRoll, onFlutter, onOgle, onGaze, onWink, onDoubleTake. For standard usage see our “Staring Match” demo application.

Innovative Keyboard Replacement

Sencha Blink ships an amazing replacement for traditional keyboard input: the Morser component. Users can activate this component by simply blinking the Morse Code sequence for “Open Keyboard”. Once this occurs a keyboard overlay will pop up, ready to receive Morse Code input via eye blinks. With the layout system we’re known for, Blink components know how to move out of the way and beautifully reflow the “document” to adapt for the Morser keyboard.

And Even More

We’re also announcing two optional accessories that work with Sencha Blink. The first is “KeepItDown” — a powerful loudspeaker equipped with a System on a Chip. If the user’s environment is too noisy for audio input, KeepItDown will blare “Hey guys can you keep it down, I’m trying to use my [device name]”. The whine level is configurable. The second is “Hide-My-Glasses” a clever accessory that disguises your user’s spectacle under a wig and pirate patch. We even have an early adopter.

Start Your Engines

We’re excited to launch Sencha Blink. We look forward to seeing your furious Morse Code blinks on the streets soon!

At mzSolutions, I work on creating components for Ext JS and Sencha Touch. In this post, I will show you how to use mzPivotGrid with Sencha Ext JS.

What is a pivot grid?

The Ext JS grid panel is perfect for displaying large sets of data, and it provides many features for all kinds of data display. One type of data display that it doesn’t provide is a pivot grid. When it comes to reporting, a pivot grid is the way to go because it helps you organize and summarize data and create reports; and it enables users to make more informed decisions about their data.

What is mzPivotGrid

mzPivotGrid is a component that you can use with Ext JS to create a pivot grid. Let’s imagine the following scenario. You have some sales data with the following fields: country, salesperson, order date, order amount and order ID. If you want to edit this data, you could easily use an Ext JS GridPanel with CellEditing or RowEditing plugins.

What would you do if you had to answer the following questions?

1. What are the order amounts of each salesperson?
2. What are the order amounts of each salesperson in a specific country?
3. How did salespeople perform in a specific year?

You could use mzPivotGrid to create those reports, and this is how they would look:

Using mzPivotGrid

mzPivotGrid inherits the Ext JS Grid Panel component, so you can use most of the features you are already familiar with: column resizing, locking, cell renderers, row/cell events etc. The mzPivotGrid can be used when you want to get summation and pivot features that aren’t provided in the default GridPanel.

To break down the dataset into salespeople and years, you just have to configure the top and left axis:

 
leftAxis: [{
    width:      80,
    dataIndex:  'salesperson',
    header:     'Salesperson'
}],
 
topAxis: [{
    dataIndex:  'year',
    header:     'Year',
    direction:  'ASC'
}]
 

Multiple levels are supported, so you can just specify them in the top and left axis. Grouping the rows and/or columns could be handy here, so you can simply do that by setting “enableGrouping” to true.

Now that you broke down the dataset on the top and left axis, it’s time to aggregate the cell values. Several kinds of aggregations are available including: sum, average, min, max, count etc. If these are not enough, you can provide your own aggregation function.

 
aggregate: [{
    measure:    'amount',
    header:     'Sales',
    aggregator: 'sum',
    align:      'right',
    width:      85,
    renderer:   Ext.util.Format.numberRenderer('0,000.00')
},{
    measure:    'orderid',
    header:     'Qnt',
    aggregator: function(records, measure, matrix, rowGroupKey, colGroupKey) {
        // do your own algorithm
        return records.length;
    },
    align:      'right',
    width:      85,
    renderer:   Ext.util.Format.numberRenderer('0,000.00')
}]
 

As you have probably noticed in the above example, you could aggregate multiple data fields, say “sales” and “quantity.” You can easily achieve this by configuring all required aggregations.

Showing the grand totals for rows and/or columns is pretty easy to configure (“enableRowGrandTotals: true” or “enableColGrandTotals: true”). The group totals are also available via “enableRowSummary” and “enableColSummary” configs. Styling is also easy, and you can even define cell renderers.

The pivot grid uses any kind of Store available in Ext JS, so filtering the data is pretty easy to do on the Store object. This means you can implement a plugin to handle the filtering.

The Ext JS Data Model class is awesome, so you should use its powerful “convert” function to extend your model and break down your data in custom group intervals. Check out this example:

 
fields: [
	{name: 'orderid',   	type: 'int'},
	{name: 'salesperson',   type: 'string'},
	{name: 'country',   	type: 'string'},
	{name: 'orderdate', 	type: 'date', dateFormat: 'd/m/Y'},
	{name: 'amount',    	type: 'int'},
	{
    	name: 'person-range',
    	convert: function(v, record){
            if(/^[a-j]/i.test(record.get('salesperson'))) return 'A-J';
            if(/^[k-s]/i.test(record.get('salesperson'))) return 'K-S';
            if(/^[t-z]/i.test(record.get('salesperson'))) return 'T-Z';
        	return v;
    	}
	},{
    	name: 'year',
    	convert: function(v, record){
        	return Ext.Date.format(record.get('orderdate'), "Y");
    	}
	}
]
 

...it will look like this:

A sample use case

 
 var pivotGrid = Ext.create('Mz.pivot.Grid', {
    title:          'Pivot grid',
    height:         400,
    width:          600,
    enableLocking:  false,
    enableGrouping: true,
    viewConfig: {
        trackOver:      true,
        stripeRows:     false
    },
    store: store,
    aggregate: [{
        measure:    'amount',
        header:     'Sales',
        aggregator: 'sum',
        align:      'right',
        width:      85,
        renderer:   Ext.util.Format.numberRenderer('0,000.00')
    }],
    caption:  'Sales report',
    leftAxis: [{
        width:      80,
        dataIndex:  'salesperson',
        header:     'Sales Person'
    }],
    topAxis: [{
        dataIndex:  'year',
        header:     'Year',
        direction:  'ASC'
    }]
});
 

Future

Since mzPivotGrid is a commercial product, it will constantly be improved with new plugins and features. Feel free to contact us if you need something special implemented.

To learn more about mzPivotGrid licensing, click here.

Additional resources:

• Pivot grid example used in this article
• Try some more mzPivotGrid examples
• mzPivotGrid API docs

Sencha.io is a backend-as-a-service, providing a set of APIs that helps developers to build and run their applications. It enables you to build web applications using services provided through our mobile JavaScript framework Sencha Touch. Sencha Cmd is a command line tool that gives you access to a lot of functionality that is helpful when building applications with Sencha Touch including, as of version 3.1, Sencha.io support.

In this article, we will highlight the Sencha.io functionality available in Sencha Cmd by walking through the process of creating an application, deploying it to the cloud, and managing its settings.

Getting Started — Hosting a Web App on Sencha.io

To begin using the system, you will need a Sencha ID (same as your Sencha forum ID). If you don’t already have one, visit the registration page to get one. You’ll also need a recent version of Sencha Cmd (version 3.1 or later). You can get a copy of Sencha Cmd for your specific OS platform from the official Sencha Cmd download page.

For information about how to develop an application using the Sencha.io SDK and Sencha Touch, please visit the Sencha.io Dashboard. You’ll find downloads and examples of how to leverage the SDK in your own applications.

Let’s start by creating an application that we can modify and configure. The following steps were executed in a command line window with access to a Sencha Cmd installation.

In this example, test user extraordinaire Testy McTesterson is creating an app, called testApp. From the Sencha.io service response, you can see that the above service request was successful and a unique AppId and AppSecret has been created for this application to use. Since these values will be used in the client framework SDK to identify your application with the Sencha.io service, you may want to record them for future use. However, if you ever need them again, you can get them from the Sencha.io Dashboard or by using the Sencha.io list-apps command:

When applications are deployed on Sencha.io, cloud hosting is automatically allocated for that app on Senchafy (Sencha.io’s hosting service) and that app becomes available on the Internet at a unique Senchafy subdomain URL. You can see from the previous example that the output of the list-apps command includes the AppId and AppSecret, as well as this unique Senchafy URL for this specific app. Additionally, you can also register a CNAME for your app to use and assign it through the Sencha.io Dashboard.

Now that cloud hosting has been allocated for our app, we can create a version of that app and upload it to the cloud. Here, our test developer has prepared a small app that he wants to upload, in a zip file named app.zip, and use Cmd to upload it as version 1.0 of his app.

Even though we’ve successfully uploaded the application to the cloud, it must then be deployed in order to be accessible through its Senchafy URL. The deployment service allows you to keep multiple versions of your app stored in the system, and lets you switch between them as you see fit by deploying the appropriate app version. We will now execute the following command to deploy version 1.0 of our app that we just uploaded:

Now the test app will be accessible through its Senchafy URL and is now published in the cloud. Just to confirm that the application has been unpacked and deployed correctly, we can use the Sencha.io io-fs command to query and modify the file system of the remote application. To confirm that our index.html file inside app.zip has made it’s way to the remote cloud file system, we can list all the files available:

The above results confirm that the zip file containing index.html was successfully uploaded and added to the currently deployed app version. If you want to modify the contents of the currently deployed app version, you can use the Sencha.io rm and put commands to remove existing files and add new ones to the remote file system.

Configuring Authentication in Sencha.io

One of the key features of Sencha.io is the user and authentication model. Users can log into the system either through an application specific username (email address) and password, or through their Facebook or Twitter accounts. Exactly which types of login are enabled for your application can be configured using the Authentication Groups settings for your application. You can see a really good illustration of this concept in the Sencha.io Todo App example from the Sencha blog; I’ve updated the code to work with the current version of Sencha.io, and I hosted it as the test application from the previous section.

To use Sencha.io Authentication Groups and User model, you first need to create an Authentication Group. Here our test developer is creating an auth group for the workers in his company:

When an auth group is created, by default, it is enabled to use Sencha.io-based authentication (i.e, application specific username/email & password). We can use Sencha Cmd to associate the Workers auth group that we just created with the test app we created earlier:

Now, we can specify the login mechanisms for the app. For example, if we want to enable Facebook auth for testApp, we can do so from Sencha Cmd as well.

The developer needs to supply the application key and secret values for Facebook along with the above command, and the auth group will be updated. Now, any app which has the Workers auth group associated with it will accept Facebook logins, and any app built with the Controller from the client framework will automatically adjust its UI to this new auth group configuration.

Summary

Sencha Cmd allows you to perform a wide variety of tasks, including managing how an application is configured and hosted in Sencha.io. As the Sencha.io platform grows and more services and configuration options are added to it, we will continue to add equivalent features to Sencha Cmd, so developers can automate their workflows and test effectively. Let us know if you have any ideas for Cmd integration that will make your life easier and join the discussion on the Sencha.io forum!

I recently had an opportunity to work with one of our enterprise clients, helping them define how Sencha should be used within their organization. I wanted to share some lessons and high-level concepts about enterprise architecture with the community that I think will benefit everyone.

Working with the Enterprise

Working at the enterprise-level can be both very cool and very frustrating. On the one hand, I get to build really challenging apps; but on the other hand, enterprise applications often target legacy browsers and are prohibited from using cutting-edge technologies.

Having said that, I am starting to see many of our enterprise customers rethinking their development strategies and IT infrastructures: workstations are being upgraded to modern versions of Windows, and workers are being given more choices for a web browser. In some cases support for IE6 and IE7 are being dropped completely!

More importantly, I am noticing that enterprises are standardizing their development platforms to create an ecosystem of applications that can be maintained by a diverse team of developers. Because Sencha tools and frameworks are becoming the preferred development platform in this ecosystem, the Professional Services team has been helping our customers define their internal policies, training procedures and best practices in order to facilitate a transition to this new standard.

Why Development Standards Matter

As a consultant, I constantly preach the benefits of having maintainable code:

• Applications are faster to produce
• Applications are easier to debug
• New features are easier to add
• Code has fewer bugs
• New developers can be trained quickly

We all know that time equals money, so applications that take less time to create and maintain cost less money. Ultimately this makes managers, executives and shareholders happy. Because enterprise companies have many applications in production (both internal and external), it is critical that each member of the development team be able to jump onto any project in order to deliver on time and stay under budget.

Enterprise development teams often employ many developers distributed across large areas and contain a wide variety of skill sets. By standardizing the training, tools and best practices enterprises hope to decrease development time and costs while increasing the quality and lifespan of their applications.

Sencha as a Standard Platform

When enterprises decide to make Sencha tools and frameworks a standard for application development, they’re often communicating a need for consistency across their internal and external applications. This consistency usually includes both the UI (styling, widgets, functionality) and the underlying code (architecture, libraries, best practices).

Every company using Sencha tools and frameworks should consider creating a centralized repository of resources and best practices for their development teams. While the specifics of these resources might differ between companies, the following areas should be clearly documented to help developers get started and maintain consistency across projects.

Developer Onboarding and Training

In my experience working in an enterprise, it can be difficult to get the tools you need installed on your machine.

Most enterprise companies have a highly defined IT infrastructure, so new developers are forced to wait while all required hardware and software meets approval. This process can often take days to complete, and afterwards workers remain unsure how to request additional resources. In short, new developers lack access to a clear onboarding roadmap.

For Sencha customers, I recommend that a handful of onboarding procedures be clearly documented to lubricate this process:

• Required development tools
• The process for requesting network credentials
• Standard development workflows
• How to access the Sencha forums and support portal
• What Sencha training opportunities are recommended/offered

It’s important to remember that while developers don’t need this information on a frequent basis they need to know how to access it.

Supported Platforms

One benefit of working in an enterprise is that developers usually know the exact specifications of the environments they need to support, but historically these environments have been troublesome for web applications.

As enterprises move forward with hardware and software upgrades, it is important that developers deliberately document their current list of supported environments. This list might include things like:

• Browsers (e.g. IE8, Firefox)
• Operating Systems (e.g. Windows XP,7)
• Devices (e.g. Lenovo ThinkPad)

Having this knowledge clearly defined before starting new projects (and while maintaining legacy applications) helps to improve the accuracy of the delivered products. It also allows developers time to request any new hardware/software for testing.

“In some cases support for IE6 and IE7 are being dropped completely!

On the other hand, this knowledge also helps to point out potential weaknesses. For example, the latest Firefox versions will auto-update themselves and support a wide variety of modern web standards; IE8 does not. Developers who understand those implications can avoid development practices that might collide with the defined supported platforms.

It is also important to document the specific products or platforms being used in the development process. This list might include:

• Frameworks (e.g. Ext JS 4.1.x, ASP.NET MVC 4)
• 3rd party libraries or components (e.g. other charting packages)
• Supporting technologies (e.g. SASS)
• Workarounds (e.g. using JSONP)

This supplementary list is not only helpful in defining what products or platforms are required for development, but it can also define the skill sets necessary for employee acquisition and training.

Internal Best Practices

Development teams should also decide on a list of best practices, so all developers can contribute code without compromising maintainability.

The list of best practices can be short and high-level or long and detailed; the choice often depends on the size of your team and how the developer roles are organized.

For example, some high-level best practices might include:

• Overall architectural decisions (e.g. namespacing, file structure)
• Security implementations
• Error handling
• Shared libraries and custom components (UX)
• Documentation
• Testing, builds and deployment

...while some low-level best practices might include:

• Whitespace usage
• Commit practices
• Console usage
• Browser Strict vs quirks mode

In my experience, enforcing the low-level best practices is difficult to do without mandatory code reviews. While code reviews are a fantastic way to teach junior developers, maintain code quality and stimulate creativity, it’s not something typically done in most enterprises.

What are your thoughts?

This article highlights some ideas for implementing development standards in large organizations but is far from a comprehensive plan. The Sencha Professional Services team provides a variety of services including high-level architectural reviews, deep analysis of application performance, custom UX development and everything in-between, and we can tailor an engagement to fit each customer’s specific needs. The concepts above are a good start and should translate easily into any business.

If your company has implemented a set of development standards, please share your thoughts and experiences!

Yesterday, we announced new versions of Sencha Architect and Ext JS. We gave a brief summary of Architect 2.2 new features in our Sencha March Madness blog post, and today we want to dive deeper into all of the improvements we’ve made over the last few months.

As Architect matures, we find many developers using it to develop large projects — frequently in collaboration with other developers. As these projects grow in complexity, developers face new challenges in managing them. Architect 2.2 is squarely focused on improving the experience for these users — in everything from Architect's raw performance, to ease of navigation, to better source control integration, and new features to make development easier.

The first thing we did was improve Architect's performance by using the newest version of Sencha Desktop Packager to package Architect. This brought significant improvements in memory footprint and performance. When opening real-world sample projects we are seeing Architect use only a quarter to a third as much memory as it used to. (For those who don't know: Architect is built with Ext JS, and this newest version replaces an older packaging technology with our own modern and fast Desktop Packager. We think Architect 2.2 is a pretty good demonstration of what can be accomplished with the Sencha frameworks and the packager. Eating our own dogfood and turtles all the way down — with great payoff in performance.)

Open and Save Projects Faster Than Ever

We also changed the way Architect opens and saves projects and files to get more performance improvements. When opening a project in Architect 2.2, only the project components that are selected are opened — making it much faster to open large projects. We were pleasantly surprised to see a full order of magnitude improvement in project load time: projects that used to take 30 to 50 seconds to open now open in 3 to 5 seconds.

Now that Architect is only opening project components as needed, we also made it more efficient when saving a project. Now when you click "Save", Architect only saves out metadata and application files that have been modified, making this much faster, especially if you are a frequent saver. Of course, there will still be times when you want to regenerate the entire application, and the "Build" button does exactly that.

Intelligent Source Control Integration

More efficient saving also improves integration with source control, as you are no longer changing all the generated application code each time you save a small change. We did one more thing to help with source control integration. We not only made Architect aware of file changes on disk, but also made sure Architect is able to handle those changes intelligently. Architect now watches your project folder so that it notices when items are changed by anything other than Architect itself (e.g., by your source control system). If the change detected is made to a component that isn't currently open, but is modified in Architect, Architect simply accepts the change and notes it in the log files. If the detected change is in a component that the developer is actively editing, Architect alerts the developer and lets them decide whether to keep the version detected on disk or the changes they are working on in Architect. This makes it much easier to collaborate with other Architect users on the same project without stepping on each other’s toes.

Improved Project Navigation

Performance and source control improvements are helpful, but if you have a massive project it is still hard to keep track of all your components. To help you find them we added a "Quick Open..." search box in the Project Inspector which helps you easily find and open top level components.

Once you've found your component, you often need to switch back and forth between different components, for example between the canvas layout of a view component and the related function code in a controller. To make this easier, Architect now allows you to open multiple tabs in the Canvas. You can open and then easily switch between the tabs using keyboard shortcuts.

Easier Coding

We’ve also learned that as Architect projects get bigger and more complicated, developers sometimes have to create custom overrides to accomplish their goals. We’ve made a change in in Architect 2.2 that will improve these situations. One of the scenarios that often generated overrides was bringing in external code into Architect (e.g., third-party JavaScript components or extensions). In Architect 2.2, you can add your component as a JavaScript resource and specify the alias to create it using Architect’s new CreateAlias and CreateClass configs.

Additionally, when a component starts its lifecycle, it’s now easier to insert your custom behavior code using the new processConfig (Ext JS) or initialize (Touch) configs in Architect. There is more information about this new functionality in the Architect docs.

Are You Mocking Me?

Architect already makes it easy to get store data from varied data sources, but sometimes it can be hard to get valid source data to Architect during development, which makes developing an application’s user interface hard. For example, the backend store might require an authentication token or geo-location data to provide useful information. Architect now allows the developer to enter mock data for a store’s data config. This mock data is displayed inside the Architect canvas in views that consume the store, but when you ship your app you don’t want to ship the mock data, so Architect does not include it in the code it generates.

Deep Support and Tight Integration for Latest Frameworks

Last, but by no means least, Architect now supports the latest releases of the Sencha frameworks. If you are as excited as us about the new Neptune theme, big data grids, and Right-to-Left (RTL) support in Ext JS 4.2, then you'll love how easy it is to work with Ext JS 4.2 in Architect 2.2. If you started your Architect project in an older version of the framework, then don’t worry. Architect will happily take care of all the details of upgrading to Ext JS 4.2.

That wraps up all the major new improvements we’ve made to Architect 2.2. Stay tuned for an upcoming blog post about the Ext JS 4.2 changes, and then try them out in Architect 2.2 — it’s a great way to see the new functionality in the framework.

You can download Architect 2.2 today, either to buy or as a 30 day trial. Architect is also a part of Sencha Complete and the new Sencha Touch Bundle. For existing users we will start pushing auto updates in about a week.

Lastly, we've reset expired Architect evaluations and extended existing Architect evaluations for an additional 30 days. To re-activate Architect, simply select "change user" in the Architect splash screen and enter your user credentials.

If there’s a common theme across all three of these announcements, it is developer productivity. Today’s releases make things faster, easier, and more convenient for developers. The new Sencha Touch Bundle brings all of our mobile development technologies together in a convenient and cost-effective package. The many new features in Architect 2.2 and Ext JS 4.2 range from better team capabilities in Architect to Internet Explorer 10 support and the Neptune theme in Ext JS. And better yet, they all work well together, letting you easily use these new Ext JS features from within Architect.

You can get a great introduction to the new releases in this video, where a few of our engineers and product managers talk about it in their own words.

Sencha Architect 2.2

Larger and larger projects are getting built in Sencha Architect with multiple developers working on the same project and in Architect 2.2, that’s exactly what we focused on: improving the experience for developers working on large projects and in multi-person teams.

• We start off with massive performance improvements. We upgraded the platform of Architect to our own Sencha Desktop Packager 1.1, resulting in a significant performance improvement. Additionally, Architect now selectively loads components as the developer opens them, instead of opening all project components at once. These changes reduce Architect’s memory footprint on real world projects by 60% to 80%, and speeds up project load times for large projects by an order of magnitude.


• To enable better integration with source control systems Architect now watches the developer’s file system for changes to project files that happen when synchronizing changes from other developers. When changes are detected, Architect handles all the updates to the underlying files seamlessly. If a collision happens, we now prompt the user about how to proceed.


• As projects grow in complexity, it can be hard to keep track of all the components and to navigate around the project. Architect 2.2 adds multiple tab support to the canvas enabling easy switching between components. There’s a new Quick Open feature to make it easy to find and open a component in your project — which is a major time saving on the business-scale projects being built in Architect.





• After making Architect faster, easier to navigate, and easier for teams to use, we also made it easier to write great apps with improvements for bringing in external libraries, inserting custom code into components, and mocking up data for stores. Many applications use other libraries with the Sencha frameworks, and Architect 2.2 allows simpler integration of these external JavaScript libraries without using code overrides by using createAlias and createClass configs to set up an xtype or class name for the external component. Additionally, when a component starts its lifecycle, it’s now easier to insert your custom behavior code using the new processConfig (Ext JS) or initialize (Touch) configs in Architect.
  
  If you have been using custom overrides before, this new method makes it easier to keep the application more streamlined and uses frameworks best practices. Lastly, for many applications, it is not easy during development to get good data from their store(s), for example the store may require geolocation information, or a user-specific authentication token. Architect 2.2 now supports mock-up data in a store’s Data config. This mock data is available to render in canvas views, but is not included in the final code that Architect generates, making it both easier and safer to design your application.


• And of course Architect 2.2 supports the latest released frameworks and all their features, about which you can read more below. Architect 2.2 makes it easy to get all the new framework goodness by upgrading existing projects to Ext JS 4.2 with just a couple of mouse clicks.

Sencha Ext JS 4.2

For the release of Sencha Ext JS 4.2, we’ve been working on some of the most demanded features from our customers and community, in addition to working on general stability, bugs, and performance improvements. For the full list of what’s new and changed, please check out the Release Notes.

• Big data grids: we’ve done a major overhaul of the bufferedrenderer in Ext JS 4.2 in order to support enterprise developers who are building high data point applications. Applications such as financial or insurance applications can take advantage of these new capabilities to show much larger data sets across a large variety of browsers. To see how dramatic the changes are, check out this video walkthrough.




• Neptune theme: The long awaited Neptune theme is finally here! Neptune gives developers a light and clean, fully modern UI with even more powerful customization capabilities. We’ve restructured how themes are built in Ext JS to be more flexible and integrated theme packaging with Cmd so it’s easy to share and also easy to minify themes. Pictures speak a thousand words, so check out any of the Ext JS demos, which now have Neptune enabled by default, but give you a convenient way to switch to the classic, grey and accessibility themes.




• Right-to-left support: if you’re a developer who has requirements to build applications for the Middle East or East Asia, the new support for right-to-left in Ext JS 4.2 will make your life significantly easier. We’ve enabled it as an optional package so the framework doesn’t carry extra weight for this support, but if you need it, it’s right there for you to enable it.


• IE10 support: Ext JS 4.2 now fully supports Internet Explorer 10, ensuring your applications have uninterrupted application compatibility as IE10 shows up in more businesses. (note: we’re also actively working on a patch for Ext JS 3.4 to add IE10 support, so stay tuned).

Sencha Touch Bundle

Sencha Touch has continued its amazing trajectory, and Touch adoption has continued to grow rapidly. In parallel with our constant improvements to Touch, we’ve been steadily building out a rich set of premium mobile development tools to help developers be very productive and efficient building apps with Touch — but we’ve left it up to developers to find and buy these, as well as technical support, individually. Today, we’re rolling out the Sencha Touch Bundle, to bring all of that together and make it easy for customers to buy a single package of mobile development tools, components, and business-grade support.

The Touch Bundle includes Sencha Touch, Sencha Touch Charts, Sencha Architect, Sencha Eclipse Plugin, plus business-grade support and maintenance for all the products. We’re making it available today at a special introductory price of $695 ($100 off of list price). If you’re a serious mobile developer who wants the best possible toolset with full support, this is a great deal.

Sencha Touch 2.2 (Beta)

We're also using today to call attention to Sencha Touch 2.2, which is currently in beta. Touch 2.2 brings you powerful new components, support for Windows Phone 8 and IE10, significant performance enhancements, and more. We're still working on additional betas and would love your feedback, so we invite you to check out the beta here.

Final Thoughts

Ext JS 4.2 delivers on our previous commitment to deliver a modern theme as well as RTL in the Ext JS 4 product train. We are still actively working on accessibility, which is the final remaining product commitment that we made for Ext JS 4.

Also, we wanted to give special thanks to our beta testers, who downloaded and tried early builds of these products, and gave us very valuable feedback. These releases are much stronger thanks to your help. We love your support and we’re excited to release these products to you and to the broader Sencha community.

Finally, Sencha Architect 2.2, Sencha Ext JS 4.2, and the new Sencha Touch Bundle are all available for download and purchase today. Please give them a try and let us know what you think!