Everything tagged misc (15 posts)

On Leaving Sencha

As some of you may know, I left Sencha last week to move to another startup just up the road in San Mateo. Leaving the company was a hugely difficult thing to do for lots of reasons, some obvious, some less so. I'd like to share a few thoughts on my time there and look forward a little to the future.

I first came across Sencha's products when I saw an early preview of Ext JS 2 way back in 2007. I thought it was amazing stuff, and I started using it all over the place despite being a Ruby guy at the time. As time went by and I got deeper into the language and the framework, it became clear that JavaScript was the future, even though most people at the time still thought that was a little crazy.

I didn't really intend to join the company. I was having fun writing components and exploring the framework from the outside already, but a chance meeting in San Francisco with the team changed all that. What I found was a small but immensely talented group of people who loved what they did - writing awesome frameworks all day. Underqualified though I felt, being invited into that group was an honor I couldn't really refuse.

Early Days

When I started back in late 2009, Ext JS 3.1 was just being wrapped up for release so I leapt straight into creating 3.2. Having only ever consumed the framework before, making the leap to creating brand new components was quite a challenge. Thankfully Sencha can count many veterans in its ranks, and Jamie in particular demonstrated his saintly patience in bringing me up to speed.

Ext JS 3.2 saw the addition of animated DataView transitions, composite fields and a few Toolbar plugins. It also required some upgrades to Store, which was a horrifying enough experience that I'd spend a few weeks rewriting the entire data package for Sencha Touch and Ext JS 4. 3.2 also saw the first of my allegedly bombastic blog posts (I'm just enthusiastic...)!

All this time we were a very small group working out of a picturesque little office on University Avenue in Palo Alto. During that first year we grew to maybe 25 people and all fit happily into the one big open plan room, descending en masse upon one of the many restaurants along the strip or bringing food back to eat in the sunny courtyard outside the office.

The original Palo Alto office

I think of that time as the happiest part of my Sencha experience. Somehow I'd found myself in the heart of Silicon Valley surrounded by unbelievably talented people, creating groundbreaking products - some of which we were even allowed to give away for free! We worked like crazy, often well into the early hours of the morning, but it was a lot of fun and I think we created a lot we can be proud of in that time.

Creating Sencha Touch, Learning how to Conference

Not long after Ext JS 3.2 went final, and in parallel with Ext JS 3.3, we started creating Sencha Touch. The initial work was all from Tommy and Dave, before I got a chance to jump in and start writing the new data package. Over time most of the team got a chance to put their name on Touch as we raced to create the world's first HTML5 mobile app framework. Creating a new product from scratch like that was an awesome experience, and the final product was pretty good (though nowhere near as good as we'd get it with 2.0).

SenchaCon 2010 was scheduled for mid-November and we'd decided we wanted to make a big splash by releasing Sencha Touch - for free. Naturally, this meant a lot of work in a very short period of time in the months running up to the conference. I have vivid memories of a particular evening (read: 3am) in the office just before an imminent release. That can be stressful enough at the best of times but this particular evening our fire alarm would not stop going off. I don't know whether it was the people, the project or the pressure, but what should have been a dreadful night was a really fun experience. And I think it paid off - we shipped on time at the conference, but only just.

This would be a pattern we'd repeat more than once - working night and day to create both products and presentations that have an immovable deadline. Once more it amazes me how talented my friends at Sencha really are: how many developers do you know who can write great code and deliver world-class conference presentations? That all came from a lot of hard work but it's one more reason why it was so hard to leave that group of people behind.

Ed Asleep

Later Days

Later on, our time was dominated first by Ext JS 4, then by Sencha Touch 2. I was able to make a couple of contributions to Ext JS 4 - chiefly the new data package plus an evolution of the MVC architecture that debuted in Sencha Touch 1. I probably spent as much time writing documentation as I did writing code though, which is a pattern I'd later repeat on Sencha Touch 2. For whatever reason there's a misalignment in my brain that makes me pretty passionate about docs, so if you're reading the guides and class docs from those projects and none of it makes sense, well, sorry! (but you should see how it was before...)

By this time we'd outgrown our little office in Palo Alto and moved to a much bigger space in Redwood City. With 5x the floor space at our disposal the company started growing like crazy, easily expanding by a factor of 10 during the time I was there. That transition was harder than I expected - at 10 people it was like a large family, at 100 it was definitely a Company. I think a lot of that is down to Sencha's success, but it still caught me off guard having never been through that before.

I think the thing I'm proudest of during my time at Sencha was the release of Sencha Touch 2. This was the first release where we got (almost) everything right - the quality was high, the performance was great, and we finally cracked MVC. We even launched with relatively good docs and examples from day one, though I've learned by now that you can never have enough of that stuff.

People/Future

As well as getting to work with so many talented people inside the company, I've also been lucky enough to meet a huge number of people from the Sencha community. If anything you guys seem even more passionate about our stuff than we are. Until SenchaCon I could honestly say I'd never been mobbed but for those few days a year you make us all feel like rockstars. We may not say it at the time but I know everyone involves gets a huge high from those interactions, so thanks.

While I'm at a new company now I expect to stay active in the Sencha community, I'm far too attached to what we created together to leave that behind any time soon. I'll stay active on the forums and maybe even blog once a while - if you want to get in touch feel free to reach out here, on twitter or linkedin, or if you're near Palo Alto maybe I'll buy you a beer.

Sencha's best days are ahead of it and they have a great team there to deliver on the mission. I remain a big fan of the company, its people, its products and especially its community and can't wait to see what happens next.

Continue reading

Anatomy of a Sencha Touch 2 App

At its simplest, a Sencha Touch 2 application is just a small collection of text files - html, css and javascript. But applications often grow over time so to keep things organized and maintainable we have a set of simple conventions around how to structure and manage your application's code.

A little while back we introduced a technology called Sencha Command. Command got a big overhaul for 2.0 and today it can generate all of the files your application needs for you. To get Sencha Command you'll need to install the SDK Tools and then open up your terminal. To run the app generator you'll need to make sure you've got a copy of the Sencha Touch 2 SDK, cd into it in your terminal and run the app generate command:

sencha generate app MyApp ../MyApp
sencha generate app MyApp ../MyApp

This creates an application called MyApp with all of the files and folders you'll need to get started generated for you. You end up with a folder structure that looks like this:

Sencha Touch 2 Directory Overview

This looks like a fair number of files and folders because I've expanded the app folder in the image above but really there are only 4 files and 3 folders at the top level. Let's look at the files first:

  • index.html: simplest HTML file ever, just includes the app JS and CSS, plus a loading spinner
  • app.js: this is the heart of your app, sets up app name, dependencies and a launch function
  • app.json: used by the microloader to cache your app files in localStorage so it boots up faster
  • packager.json: configuration file used to package your app for native app stores

To begin with you'll only really need to edit app.js - the others come in useful later on. Now let's take a look at the folders:

  • app: contains all of your application's source files - models, views, controllers etc
  • resources: contains the images and CSS used by your app, including the source SASS files
  • sdk: contains the important parts of the Touch SDK, including Sencha Command

The app folder

You'll spend 90%+ of your time inside the app folder, so let's drill down and take a look at what's inside that. We've got 5 subfolders, all of which are empty except one - the view folder. This just contains a template view file that renders a tab panel when you first boot the app up. Let's look at each:

The resources folder

Moving on, let's take a look at the resources folder:

Sencha Touch 2 resources folder

Five folders this time - in turn:

  • icons: the set of icons used when your app is added to the home screen. We create some nice default ones for you
  • loading: the loading/startup screen images to use when your app's on a home screen or natively packaged
  • images: this is where you should put any app images that are not icons or loading images
  • sass: the source SASS files for your app. This is the place to alter the theming for your app, remove any CSS you're not using and add your own styles
  • css: the compiled SASS files - these are the CSS files your app will use in production and are automatically minified for you

There are quite a few icon and loading images needed to cover all of the different sizes and resolutions of the devices that Sencha Touch 2 supports. We've included all of the different formats with the conventional file names as a guide - you can just replace the contents of resources/icons and resources/loading with your own images.

The sdk folder

Finally there's the SDK directory, which contains the SDK's source code and all of the dependencies used by Sencha Command. This includes Node.js, Phantom JS and others so it can start to add up. Of course, none of this goes into your production builds, which we keep as tiny and fast-loading as possible, but if you're not going to use the SDK Tools (bad move, but your call!) you can remove the sdk/command directory to keep things leaner.

By vendoring all third-party dependencies like Node.js into your application directory we can be confident that there are no system-specific dependencies required, so you can zip up your app, send it to a friend and so long as she has the SDK Tools installed, everything should just work.

Hopefully that lays out the large-scale structure of what goes where and why - feel free to ask questions!

Continue reading

What do you want from Sencha Touch 2.1?

Disclaimers: this is the most unofficial, non-Sencha-backed poll of all time. There's no guarantee we'll ever do any of it, yada yada.

Touch 2.0 went GA last week to easily the best product launch reception I've seen. It was great and the feedback's wonderful but honeymoons are boring - I want to know what's wrong with it :)

So, what do you want to see in Sencha Touch 2.1? I asked on Twitter just now and got a bunch of responses so here are some ideas. Even if what you want is on this list already drop a reply in the comments so I know more than one person cares about it:

Some replies to my Twitter poll

We do of course have a few ideas up our sleeves too, but why spoil the surprise?

Continue reading

Sencha Touch 2 GA Released!

The last few months have flown by faster than almost any before them. The first Sencha Touch 2 release went out in October as a Developer Preview, coinciding with SenchaCon 2011, sparking a huge wave of interest from all over the HTML5 community. Today marks the GA release of Sencha Touch 2.0.0, and we couldn't be happier with how far we've come.

See the announcement on sencha.com

It was only 18 months ago that we released the first version of Sencha Touch 1. It ushered in a brave new world, bringing tried and true approaches from the desktop together with the exciting new capabilities of the mobile web. But it was, to many of us, very much a version 1 product. ST2 is as big a step up from ST1 as ST1 was from everything that went before it.

Similar themes, great execution

For me, there are three core themes that go into any game-changing software release: Performance, Stability and Ease of Use. These themes come up again and again, especially for products at the bleeding edge of what's possible. With the mobile web, each year can bring game changing developments - that's one of the reasons developing Sencha Touch is so exciting.

Touch 2 really nails all of those themes. Performance was definitely the top priority of the three, and I think we've been able to permanently alter expectations of what web apps can do with the improvements we've made. Not only do apps feel much faster when you use them, today's announcement on the incredible new fast startup performance is game changing in itself. It's amazing how fast ST2 apps start up now, it really changes how they're used when they consistently boot in a couple of seconds.

Stability is not sexy. It's not a particularly great marketing ploy but it's really important. Having a weekly release cycle and a huge developer community has really helped enable a fast turnaround on finding, fixing and verifying bugs. Lately new bug reports have been trickling in so slowly we almost wish there were more of them. Almost.

Oddly, documentation is something that's really close to my heart. Back when I joined Sencha, improving the Ext JS docs was a prime concern and I think we took it up several notches between Ext JS 3 and 4. But that's nothing compared to what we've done between Sencha Touch 1 and 2. As well as using the awesome new documentation app from Ext JS, we've added a ludicrous amount of new content including 35 brand new guides (up from zero) and way more examples than ever before.

We've also been creating new screencasts, augmenting the awesome material Drew Neil creates. For the Touch 2 GA release I created this 30 minute getting started video that covers everything from generating an app all the way through to packaging it for native app stores. This is the sort of material I always wished I had when I was first learning Ext JS:

Getting Started with Sencha Touch 2

These take a lot of time to produce so if you like this sort of thing make sure you drop a comment here or on the sencha.com blog so I know to create more. I try to record them in a single take so you know there's no magic going on behind the scenes - I think it shows it's all real but it involves a lot of takes :)

Step One

All of the hard work to date has been to ship 2.0.0 - the first stable 2.x release. 2.0 itself is a step change over what went before it but there are already some incredible things lined up for the next few releases. Over the next couple of months we'll continue to polish, optimize and act on the wonderful feedback you guys are providing, but first I think we've earned a break!

Continue reading

Building a data-driven image carousel with Sencha Touch 2

This evening I embarked on a little stellar voyage that I'd like to share with you all. Most people with great taste love astronomy and Sencha Touch 2, so why not combine them in a fun evening's web app building?

NASA has been running a small site called APOD (Astronomy Picture Of the Day) for a long time now, as you can probably tell by the awesome web design of that page. Despite its 1998-era styling, this site incorporates some pretty stunning images of the universe and is begging for a mobile app interpretation.

We're not going to go crazy, in fact this whole thing only took about an hour to create, but hopefully it's a useful look at how to put something like this together. In this case, we're just going to write a quick app that pulls down the last 20 pictures and shows them in a carousel with an optional title.

Here's what it looks like live. You'll need a webkit browser (Chrome or Safari) to see this, alternatively load up http://code.edspencer.net/apod on a phone or tablet device:

The full source code for the app is up on github, and we'll go through it bit by bit below.

The App

Our app consists of 5 files:

  • index.html, which includes our JavaScript files and a little CSS
  • app.js, which boots our application up
  • app/model/Picture.js, which represents a single APOD picture
  • app/view/Picture.js, which shows a picture on the page
  • app/store/Pictures.js, which fetches the pictures from the APOD RSS feed

The whole thing is up on github and you can see a live demo at http://code.edspencer.net/apod. To see what it's doing tap that link on your phone or tablet, and to really feel it add it to your homescreen to get rid of that browser chrome.

The Code

Most of the action happens in app.js, which for your enjoyment is more documentation than code. Here's the gist of it:

/*
* This app uses a Carousel and a JSON-P proxy so make sure they're loaded first
*/
Ext.require([
'Ext.carousel.Carousel',
'Ext.data.proxy.JsonP'
]);

/**
* Our app is pretty simple - it just grabs the latest images from NASA's Astronomy Picture Of the Day
* (http://apod.nasa.gov/apod/astropix.html) and displays them in a Carousel. This file drives most of
* the application, but there's also:
*
* * A Store - app/store/Pictures.js - that fetches the data from the APOD RSS feed
* * A Model - app/model/Picture.js - that represents a single image from the feed
* * A View - app/view/Picture.js - that displays each image
*
* Our application's launch function is called automatically when everything is loaded.
*/
Ext.application({
name: 'apod',

models: ['Picture'],
stores: ['Pictures'],
views: ['Picture'],

launch: function() {
var titleVisible = false,
info, carousel;

/**
* The main carousel that drives our app. We're just telling it to use the Pictures store and
* to update the info bar whenever a new image is swiped to
*/
carousel = Ext.create('Ext.Carousel', {
store: 'Pictures',
direction: 'horizontal',

listeners: {
activeitemchange: function(carousel, item) {
info.setHtml(item.getPicture().get('title'));
}
}
});

/**
* This is just a reusable Component that we pin to the top of the page. This is hidden by default
* and appears when the user taps on the screen. The activeitemchange listener above updates the
* content of this Component whenever a new image is swiped to
*/
info = Ext.create('Ext.Component', {
cls: 'apod-title',
top: 0,
left: 0,
right: 0
});

//add both of our views to the Viewport so they're rendered and visible
Ext.Viewport.add(carousel);
Ext.Viewport.add(info);

/**
* The Pictures store (see app/store/Pictures.js) is set to not load automatically, so we load it
* manually now. This loads data from the APOD RSS feed and calls our callback function once it's
* loaded.
*
* All we do here is iterate over all of the data, creating an apodimage Component for each item.
* Then we just add those items to the Carousel and set the first item active.
*/
Ext.getStore('Pictures').load(function(pictures) {
var items = [];

Ext.each(pictures, function(picture) {
if (!picture.get('image')) {
return;
}

items.push({
xtype: 'apodimage',
picture: picture
});
});

carousel.setItems(items);
carousel.setActiveItem(0);
});

/**
* The final thing is to add a tap listener that is called whenever the user taps on the screen.
* We do a quick check to make sure they're not tapping on the carousel indicators (tapping on
* those indicators moves you between items so we don't want to override that), then either hide
* or show the info Component.
*
* Note that to hide or show this Component we're adding or removing the apod-title-visible class.
* If you look at index.html you'll see the CSS rules style the info bar and also cause it to fade
* in and out when you tap.
*/
Ext.Viewport.element.on('tap', function(e) {
if (!e.getTarget('.x-carousel-indicator')) {
if (titleVisible) {
info.element.removeCls('apod-title-visible');
titleVisible = false;
} else {
info.element.addCls('apod-title-visible');
titleVisible = true;
}
}
});
}
});
/*
* This app uses a Carousel and a JSON-P proxy so make sure they're loaded first
*/
Ext.require([
'Ext.carousel.Carousel',
'Ext.data.proxy.JsonP'
]);

/**
* Our app is pretty simple - it just grabs the latest images from NASA's Astronomy Picture Of the Day
* (http://apod.nasa.gov/apod/astropix.html) and displays them in a Carousel. This file drives most of
* the application, but there's also:
*
* * A Store - app/store/Pictures.js - that fetches the data from the APOD RSS feed
* * A Model - app/model/Picture.js - that represents a single image from the feed
* * A View - app/view/Picture.js - that displays each image
*
* Our application's launch function is called automatically when everything is loaded.
*/
Ext.application({
name: 'apod',

models: ['Picture'],
stores: ['Pictures'],
views: ['Picture'],

launch: function() {
var titleVisible = false,
info, carousel;

/**
* The main carousel that drives our app. We're just telling it to use the Pictures store and
* to update the info bar whenever a new image is swiped to
*/
carousel = Ext.create('Ext.Carousel', {
store: 'Pictures',
direction: 'horizontal',

listeners: {
activeitemchange: function(carousel, item) {
info.setHtml(item.getPicture().get('title'));
}
}
});

/**
* This is just a reusable Component that we pin to the top of the page. This is hidden by default
* and appears when the user taps on the screen. The activeitemchange listener above updates the
* content of this Component whenever a new image is swiped to
*/
info = Ext.create('Ext.Component', {
cls: 'apod-title',
top: 0,
left: 0,
right: 0
});

//add both of our views to the Viewport so they're rendered and visible
Ext.Viewport.add(carousel);
Ext.Viewport.add(info);

/**
* The Pictures store (see app/store/Pictures.js) is set to not load automatically, so we load it
* manually now. This loads data from the APOD RSS feed and calls our callback function once it's
* loaded.
*
* All we do here is iterate over all of the data, creating an apodimage Component for each item.
* Then we just add those items to the Carousel and set the first item active.
*/
Ext.getStore('Pictures').load(function(pictures) {
var items = [];

Ext.each(pictures, function(picture) {
if (!picture.get('image')) {
return;
}

items.push({
xtype: 'apodimage',
picture: picture
});
});

carousel.setItems(items);
carousel.setActiveItem(0);
});

/**
* The final thing is to add a tap listener that is called whenever the user taps on the screen.
* We do a quick check to make sure they're not tapping on the carousel indicators (tapping on
* those indicators moves you between items so we don't want to override that), then either hide
* or show the info Component.
*
* Note that to hide or show this Component we're adding or removing the apod-title-visible class.
* If you look at index.html you'll see the CSS rules style the info bar and also cause it to fade
* in and out when you tap.
*/
Ext.Viewport.element.on('tap', function(e) {
if (!e.getTarget('.x-carousel-indicator')) {
if (titleVisible) {
info.element.removeCls('apod-title-visible');
titleVisible = false;
} else {
info.element.addCls('apod-title-visible');
titleVisible = true;
}
}
});
}
});

This is pretty simple stuff and you can probably just follow the comments to see what's going on. Basically though the app.js is responsible for launching our application, creating the Carousel and info Components, and setting up a couple of convenient event listeners.

We also had a few other files:

Picture Model

Found in app/model/Picture.js, our model is mostly just a list of fields sent back in the RSS feed. There is one that's somewhat more complicated than the rest though - the 'image' field. Ideally, the RSS feed would have sent back the url of the image in a separate field and we could just pull it out like any other, but alas it is embedded inside the main content.

To get around this, we just specify a convert function that grabs the content field, finds the first image url inside of it and pulls it out. To make sure it looks good on any device we also pass it through Sencha IO src, which resizes the image to fit the screen size of whatever device we happen to be viewing it on:

/**
* Simple Model that represents an image from NASA's Astronomy Picture Of the Day. The only remarkable
* thing about this model is the 'image' field, which uses a regular expression to pull its value out
* of the main content of the RSS feed. Ideally the image url would have been presented in its own field
* in the RSS response, but as it wasn't we had to use this approach to parse it out
*/
Ext.define('apod.model.Picture', {
extend: 'Ext.data.Model',

config: {
fields: [
'id', 'title', 'link', 'author', 'content',
{
name: 'image',
type: 'string',
convert: function(value, record) {
var content = record.get('content'),
regex = /img src=\"([a-zA-Z0-9\_\.\/\:]*)\"/,
match = content.match(regex),
src = match[1];

if (src != "" && !src.match(/\.gif$/)) {
src = "http://src.sencha.io/screen.width/" + src;
}

return src;
}
}
]
}
});
/**
* Simple Model that represents an image from NASA's Astronomy Picture Of the Day. The only remarkable
* thing about this model is the 'image' field, which uses a regular expression to pull its value out
* of the main content of the RSS feed. Ideally the image url would have been presented in its own field
* in the RSS response, but as it wasn't we had to use this approach to parse it out
*/
Ext.define('apod.model.Picture', {
extend: 'Ext.data.Model',

config: {
fields: [
'id', 'title', 'link', 'author', 'content',
{
name: 'image',
type: 'string',
convert: function(value, record) {
var content = record.get('content'),
regex = /img src=\"([a-zA-Z0-9\_\.\/\:]*)\"/,
match = content.match(regex),
src = match[1];

if (src != "" && !src.match(/\.gif$/)) {
src = "http://src.sencha.io/screen.width/" + src;
}

return src;
}
}
]
}
});

Pictures Store

Our Store is even simpler than our Model. All it does is load the APOD RSS feed over JSON-P (via Google's RSS Feed API) and decode the data with a very simple JSON Reader. This automatically pulls down the images and runs them through our Model's convert function:

/**
* Grabs the APOD RSS feed from Google's Feed API, passes the data to our Model to decode
*/
Ext.define('apod.store.Pictures', {
extend: 'Ext.data.Store',

config: {
model: 'apod.model.Picture',

proxy: {
type: 'jsonp',
url: 'https://ajax.googleapis.com/ajax/services/feed/load?v=1.0&q=http://www.acme.com/jef/apod/rss.xml&num=20',

reader: {
type: 'json',
rootProperty: 'responseData.feed.entries'
}
}
}
});
/**
* Grabs the APOD RSS feed from Google's Feed API, passes the data to our Model to decode
*/
Ext.define('apod.store.Pictures', {
extend: 'Ext.data.Store',

config: {
model: 'apod.model.Picture',

proxy: {
type: 'jsonp',
url: 'https://ajax.googleapis.com/ajax/services/feed/load?v=1.0&q=http://www.acme.com/jef/apod/rss.xml&num=20',

reader: {
type: 'json',
rootProperty: 'responseData.feed.entries'
}
}
}
});

Tying it all together

Our app.js loads our Model and Store, plus a really simple Picture view that is basically just an Ext.Img. All it does then is render the Carousel and Info Component to the screen and tie up a couple of listeners.

In case you weren't paying attention before, the info component is just an Ext.Component that we rendered up in app.js as a place to render the title of the image you're currently looking at. When you swipe between items in the carousel the activeitemchange event is fired, which we listen to near the top of app.js. All our activeitemchange listener does is update the HTML of the info component to the title of the image we just swiped to.

But what about the info component itself? Well at the bottom of app.js we added a tap listener on Ext.Viewport that hides or shows the info Component whenever you tap anywhere on the screen (except if you tap on the Carousel indicator icons). With a little CSS transition loveliness we get a nice fade in/out transition when we tap the screen to reveal the image title. Here's that tap listener again:

/**
* The final thing is to add a tap listener that is called whenever the user taps on the screen.
* We do a quick check to make sure they're not tapping on the carousel indicators (tapping on
* those indicators moves you between items so we don't want to override that), then either hide
* or show the info Component.
*/
Ext.Viewport.element.on('tap', function(e) {
if (!e.getTarget('.x-carousel-indicator')) {
if (titleVisible) {
info.element.removeCls('apod-title-visible');
titleVisible = false;
} else {
info.element.addCls('apod-title-visible');
titleVisible = true;
}
}
});
/**
* The final thing is to add a tap listener that is called whenever the user taps on the screen.
* We do a quick check to make sure they're not tapping on the carousel indicators (tapping on
* those indicators moves you between items so we don't want to override that), then either hide
* or show the info Component.
*/
Ext.Viewport.element.on('tap', function(e) {
if (!e.getTarget('.x-carousel-indicator')) {
if (titleVisible) {
info.element.removeCls('apod-title-visible');
titleVisible = false;
} else {
info.element.addCls('apod-title-visible');
titleVisible = true;
}
}
});

The End of the Beginning

This was a really simple app that shows how easy it is to put these things together with Sencha Touch 2. Like with most stories though there's more to come so keep an eye out for parts 2 and 3 of this intergalactic adventure.

Continue reading

Sencha Touch 2 PR4 - Big Improvements in Data and MVC

Today we released Sencha Touch 2.0 PR4 - the fourth and final preview release before we hit beta. While we're technically calling this one a preview release, we're pretty happy with the performance, stability and overall quality of this release and consider it exceptionally close to beta quality.

As well as a good number of enhancements and bug fixes PR4 brings a couple of long-awaited improvements to two of the most important parts of Sencha Touch - the data package and the application architecture.

First up, the data package has been ported to use the new config system, which normalizes all of the configuration options for every class in the data package, providing a clean and predictable way to configure and update your data classes. We're still cleaning up some of the data package documentation and given the scope of some of the changes we're expecting a few bugs to appear as a result but overall we're very happy with the improved capabilities of Ext.data.

MVC Improvements

The second big improvement in PR4 is to the application architecture. The MVC classes have also been upgraded to use the new config system, again yielding big improvements in the API and general flexibility of your code.

History support has been baked directly into Controllers, enabling you to easily define routes that your Controller cares about, as well as the functions that handle those routes right there in your Controller file. The Kitchen Sink example has been upgraded to use routes out of the box - try it on a mobile device or desktop browser and watch how it reacts to the back/forward buttons.

Equally important, Device Profiles have been upgraded to make creating apps that adapt to different screen sizes much simpler than ever before. Once again the Kitchen Sink has been upgraded to take advantage of device profiles. If you load it on a tablet device you'll see a split screen view with the menu on the left and the content on the right, whereas the phone version employs a nested list to save screen space.

To cap it off the deep linking support means you can navigate to any view on a phone, send the link to a friend on a tablet and they'll be taken to the same view customized for their screen size. As an example, try opening http://dev.sencha.com/deploy/sencha-touch-2-pr4/examples/kitchensink/#demo/forms on a tablet and a phone to see it show the Forms demo specialized for each type of device.

As PR4 is the first time we've exposed this expanded functionality to the public we expect that there will be bugs and edge cases that crop up. We'll be keeping a close eye on the bug forums and addressing any issues as quickly as possible, as well as creating additional MVC-driven examples for you to learn from. For now, the kitchen sink is the best example of Sencha Touch 2 MVC in action.

Docs

We've made a huge push over the last couple of years to radically improve our documentation, and I think that even in the pre-beta PR4 release Sencha Touch 2 has the best docs we've ever created. While there are still holes to be filled in, we already ship with 20 guides on how to use the framework, including 4 brand new guides for PR4:

As well as the guides, most of the classes now contain generous documentation explaining their function and the context in which they operate. As we move to beta and then to GA we'll be shifting our focus onto producing great demos and examples to showcase the framework's capabilities and provide realistic sample code to draw from.

There's a full set of release notes explaining the improvements in PR4 and the important known issues. We expect to be shipping regular releases from now until GA so be sure to keep an eye on the forums, twitter and the sencha blog for more details.

Continue reading

SenchaCon 2011: The Best Bits

SenchaCon 2011 is drawing to a close and it's been another awesome ride. We were joined by 600 of the best and brightest of the Sencha community and I think it's pretty safe to say we had an awesome time. Day 3 is just drawing to a close so here's a few highlights from the week.

Ext JS 4.1 Performance Preview Released

There were a number of big announcements on day 1. Probably the most exciting one for me was the release of Ext JS 4.1 Performance Preview. We've been working like fiends to improve Ext JS's performance profile on older browsers (IE6, IE7 and IE8 in particular) and on Monday we were able to share some of what we've achieved.

Page load, render and layout times are all enormously improved and have been the focus of our optimizations so far. Since 4.0 we've been building up a performance benchmarking rig that tests all of our 100+ examples (and a number of real-world customer apps) on consumer grade hardware with a range of browsers. We've seen massive improvements in loading time on these older browsers - for example the Themes Viewer example with its 300 Components all rendered at load time now starts up twice as fast as it did in 4.0.7.

To give a flavor for the breadth of the improvement we ran the tests on every example and summed up the loading time for each browser. As you can see below, 4.1 is able to speed through all of the examples significantly faster than 4.0.7, giving a massive performance boost across the board. It got so much faster that IE8 is now able to load all 100+ examples in a little under 20 seconds, compared with almost 60 in 4.0.7:

See the full announcement on the sencha.com blog, but like we said there, this is a pre-beta release with a number of known issues. We'd love for you to verify the speed improvements with your own apps but please don't take it anywhere near production yet! We'll have more content on what's in 4.1 in later blog posts.

Other Announcements

While Ext JS is closest to my heart, there were a number of other announcements made over the last few days. First up is Sencha.IO, our new cloud service and now launching in beta. This is a set of 4 services - data, messages, login and app deployment - that make creating and deploying web apps a snap, especially when you integrate the social aspects of Sencha.IO data and messages.

We also announced that we've just closed a second round of funding, raising another $15 million to further advance the state of the art in HTML5 technologies. This is going to enable us to push forward even faster and bring you some exciting new technologies. It was great that Sequoia Capital and Radar Partners were so happy with their first round with us that they decided to invest again. The future is definitely very exciting at Sencha right now.

Favorite Sessions

There were over 50 sessions this year and with several tracks going on simultaneously it was impossible to go to them all. Jacky Nguyen definitely stole the show with his talk on the Sencha Class System. He has a ridiculously over the top presentation style and totally brought the house down. We'll be sure to get him on stage more often!

Jamie and Nicolas' talk on charting was very cool and generated lots of spontaneous applause (that happened a lot during the conference, which must be a good thing), and Rob and Dave's demonstration of styling using the new beta Neptune theme was equally awesome.

Don lit the place up with his talk detailing the work that went into making Ext JS 4.1 so much faster, along with all the other new features in the release. Another mind blowing talk was given by John Willander, who demo'd a series of client-side attacks along with the BeEF Project, which happens to be writen in Ext JS. Based on what John presented we'll definitely be looking at what we can do to help you secure your apps with Ext JS.

Of course, I had a couple of sessions myself, though a few technical problems early on made them rather more challenging than expected (it's hard to talk to people when your microphone cuts out after every second word!). The Intro to MVC talk was a blast and the sacrifice to the gods of live demos seemed to pay off as the 20 minute live coding session went without a hitch. Anyone who wants the code I put together during that session can find it up on github.

Meeting Everyone

Although there were 600 people here this time it felt like I was able to meet almost everyone. Your intense enthusiasm for what we do really came through and to everyone who came up and gave us such great feedback it really drives us forward to keep improving your framework so thank you!

I saw more awesome Ext JS and Sencha Touch apps than I could count, and was pleasantly surprised to see how many people had been able to construct full applications using Sencha Touch 2 despite it only being in Developer Preview right now. It was also great getting to spend time hanging out with people and seeing them get excited when they start to see what's possible with these products. Spending time in the flesh with developers is probably the most important part of the whole conference so it was great to meet so many of you.

Finally, Grgur announced that the second SourceCon Europe will be taking place in London around April of next year. The first SourceCon was an awesome experience in beautiful Split, Croatia, and next year we'll be heading to London, England for this community-organized, Sencha-centric conference. They'll be launching the conference website in a couple of weeks and given how good it was last year you'll probably have to rush to get your tickets. Hope to see you there!

Continue reading

Ext JS 4.0.7 Released

I'm very happy to report that we released Ext JS 4.0.7 to the public today. This is the seventh patch release to the 4.0.x series and contains several hundred improvements and bug fixes compared to the last public version, 4.0.2a.

4.0.7 is all about robustness - we've found that our support subscribers have had a lot of success with the newer builds of Ext JS 4 so I'm really pleased that we can share this with you. We're releasing this publicly earlier than we would usually do because it has taken us longer than we expected to get Ext JS 4.1 into your hands.

Michael put out a post on our blog last week with some updates on 4.1 and our desires around releases and communications with the community. Not being able to ship 4.1 to you yet has been a frustrating experience but I think that once you see it you'll enjoy the vast improvements it brings.

In the meantime, I'm happy to answer questions in the comments, via twitter or email (ed @ sencha). You can download the build here and see the full release notes for 4.0.7 all the way back to 4.0.0.

Continue reading

SourceDevCon 2011 - an awesome conference

The inaugural SouceDevCon just wrapped up in Split, Croatia so I'd like to share a few thoughts on the last few days. The conference was an enormous success, featuring some great speakers, inspiring presentations and a fantastic group of attendees. Split itself is beautiful, and the weather was equally equitable. More than a few of us are returning a lot browner/redder than we came.

Photo of the Adriatic

Day 1

The conference was spread across 3 days - the first two were spent listening and learning across the three concurrent tracks, the third on a boat sailing around the Adriatic Sea. Day one kicked off with my colleagues Aditya and James setting out a little of what to expect from Sencha in 2011 in the opening keynote.

Straight after that I took to the stage to introduce a few of the features of Ext JS 4. My session started a little late and I forgot what I was talking about a couple of times (sorry guys :) ) but I think it turned out well enough. I spliced together the deadly combination of sleep deprivation and live coding but with a little help from the audience we were able to stumble through. I think it would make for a good screencast.

Aditya came on next and introduced our new Sencha.IO services, which seem to have garnered a lot of interest. James showed off the new Ext JS 4 theming support using SASS and Compass and Nils Dehl did a great job explaining the Ext.data and Ext.direct packages. Jay Garcia gave a well-received talk on creating extensions and plugins, during which I think a lot of people learned a great deal about how classes work in Ext JS 4. I also very much enjoyed Tomislav Car's investigation into getting Sencha Touch to run on phones other than Androids and iPhones.

Day 1 ended with a long party (I counted at least 8 hours) with inordinate amounts of Croatian beer, which went down very well. It was great meeting so many new people and hearing how much people are getting out of Ext JS and Sencha Touch, as well as what we can improve.

Day 2

Day 2 started in a somewhat hungover fashion with some awesome material from our very own Brian Moeskau, who demonstrated how to use the 3.x -> 4.x compatibility file, upgrading an application from 3.3.1 to 4.0.0 in front of our eyes. Nige (Animal) White demonstrated several of Ext JS's layout managers before giving one of the highlights of the conference in his debugging JavaScript presentation (by contrast he calls the introduction of errors into code "bebugging").

Tobias Uhlig showed off FieldManager, a sports centre management management application with a Sencha Touch mobile app, while Matz Bryntse and Brian Moeskau demoed their awesome Scheduler and Calendar components. Josef Sakalos (Saki) spent the afternoon teaching people to use Ext JS 4's new MVC package, which makes writing apps a faster and more enjoyable experience. He is an excellent teacher.

Our host the inimitable Grgur finished things off with a typically heartfelt ending keynote to wrap up the business end of the conference. The evening was a great opportunity to see some of Split and spend an enjoyable meal with Croatian locals Tomislav, Miro and the ever-logical Lucia. Unfortunately their attempts to teach me Croatian did not yield much success.

Day 3

Day 3 was a stroke of genius by Grgur. We took a chartered boat down to the town and looked around the old Roman-era palace. The boat was well stocked with beer and with so many community members in one place the conversation was pretty lively. All of this relaxing was great but with a head full of ideas I'm anxious to get back to California and better tune our products based on all the feedback I received this week.

All of the sessions were recorded on video and I believe they'll be made available in around a month's time. If you can't wait until then we have a meetup schedule for May 23rd hosted at Sencha HQ in northern California, to which you're all invited. Just in case you've never been to Split before perhaps the sight that greeted us when we arrived will prompt you to get yourself on a flight.

Photo of the Adriatic

Continue reading

Proxies in Ext JS 4

One of the classes that has a lot more prominence in Ext JS 4 is the data Proxy. Proxies are responsible for all of the loading and saving of data in an Ext JS 4 or Sencha Touch application. Whenever you're creating, updating, deleting or loading any type of data in your app, you're almost certainly doing it via an Ext.data.Proxy.

If you've seen January's Sencha newsletter you may have read an article called Anatomy of a Model, which introduces the most commonly-used Proxies. All a Proxy really needs is four functions - create, read, update and destroy. For an AjaxProxy, each of these will result in an Ajax request being made. For a LocalStorageProxy, the functions will create, read, update or delete records from HTML5 localStorage.

Because Proxies all implement the same interface they're completely interchangeable, so you can swap out your data source - at design time or run time - without changing any other code. Although the local Proxies like LocalStorageProxy and MemoryProxy are self-contained, the remote Proxies like AjaxProxy and ScriptTagProxy make use of Readers and Writers to encode and decode their data when communicating with the server.

Ext.data.Proxy Reader and Writer

Whether we are reading data from a server or preparing data to be sent back, usually we format it as either JSON or XML. Both of our frameworks come with JSON and XML Readers and Writers which handle all of this for you with a very simple API.

Using a Proxy with a Model

Proxies are usually used along with either a Model or a Store. The simplest setup is just with a model:

var User = Ext.regModel('User', {
fields: ['id', 'name', 'email'],

proxy: {
type: 'rest',
url : '/users',
reader: {
type: 'json',
root: 'users'
}
}
});
var User = Ext.regModel('User', {
fields: ['id', 'name', 'email'],

proxy: {
type: 'rest',
url : '/users',
reader: {
type: 'json',
root: 'users'
}
}
});

Here we've created a User model with a RestProxy. RestProxy is a special form of AjaxProxy that can automatically figure out Restful urls for our models. The Proxy that we set up features a JsonReader to decode any server responses - check out the recent data package post on the Sencha blog to see Readers in action.

When we use the following functions on the new User model, the Proxy is called behind the scenes:

var user = new User({name: 'Ed Spencer'});

//CREATE: calls the RestProxy's create function because the user has never been saved
user.save();

//UPDATE: calls the RestProxy's update function because it has been saved before
user.set('email', 'ed@sencha.com');

//DESTROY: calls the RestProxy's destroy function
user.destroy();

//READ: calls the RestProxy's read function
User.load(123, {
success: function(user) {
console.log(user);
}
});
var user = new User({name: 'Ed Spencer'});

//CREATE: calls the RestProxy's create function because the user has never been saved
user.save();

//UPDATE: calls the RestProxy's update function because it has been saved before
user.set('email', 'ed@sencha.com');

//DESTROY: calls the RestProxy's destroy function
user.destroy();

//READ: calls the RestProxy's read function
User.load(123, {
success: function(user) {
console.log(user);
}
});

We were able to perform all four CRUD operations just by specifying a Proxy for our Model. Notice that the first 3 calls are instance methods whereas the fourth (User.load) is static on the User model. Note also that you can create a Model without a Proxy, you just won't be able to persist it.

Usage with Stores

In Ext JS 3.x, most of the data manipulation was done via Stores. A chief purpose of a Store is to be a local subset of some data plus delta. For example, you might have 1000 products in your database and have 25 of them loaded into a Store on the client side (the local subset). While operating on that subset, your user may have added, updated or deleted some of the Products. Until these changes are synchronized with the server they are known as a delta.

In order to read data from and sync to the server, Stores also need to be able to call those CRUD operations. We can give a Store a Proxy in the same way:

var store = new Ext.data.Store({
model: 'User',
proxy: {
type: 'rest',
url : '/users',
reader: {
type: 'json',
root: 'users'
}
}
});
var store = new Ext.data.Store({
model: 'User',
proxy: {
type: 'rest',
url : '/users',
reader: {
type: 'json',
root: 'users'
}
}
});

We created the exact same Proxy for the Store because that's how our server side is set up to deliver data. Because we'll usually want to use the same Proxy mechanism for all User manipulations, it's usually best to just define the Proxy once on the Model and then simply tell the Store which Model to use. This automatically picks up the User model's Proxy:

//no need to define proxy - this will reuse the User's Proxy
var store = new Ext.data.Store({
model: 'User'
});
//no need to define proxy - this will reuse the User's Proxy
var store = new Ext.data.Store({
model: 'User'
});

Store invokes the CRUD operations via its load and sync functions. Calling load uses the Proxy's read operation, which sync utilizes one or more of create, update and destroy depending on the current Store delta.

//CREATE: calls the RestProxy's create function to create the Tommy record on the server
store.add({name: 'Tommy Maintz'});
store.sync();

//UPDATE: calls the RestProxy's update function to update the Tommy record on the server
store.getAt(1).set('email', 'tommy@sencha.com');
store.sync();

//DESTROY: calls the RestProxy's destroy function
store.remove(store.getAt(1));
store.sync();

//READ: calls the RestProxy's read function
store.load();
//CREATE: calls the RestProxy's create function to create the Tommy record on the server
store.add({name: 'Tommy Maintz'});
store.sync();

//UPDATE: calls the RestProxy's update function to update the Tommy record on the server
store.getAt(1).set('email', 'tommy@sencha.com');
store.sync();

//DESTROY: calls the RestProxy's destroy function
store.remove(store.getAt(1));
store.sync();

//READ: calls the RestProxy's read function
store.load();

Store has used the exact same CRUD operations on the shared Proxy. In all of the examples above we have used the exact same RestProxy instance from three different places: statically on our Model (User.load), as a Model instance method (user.save, user.destroy) and via a Store instance (store.load, store.sync):

Data Proxy Reuse

Of course, most Proxies have their own private methods to do the actual work, but all a Proxy needs to do is implement those four functions to be usable with Ext JS 4 and Sencha Touch. This means it's easy to create new Proxies, as James Pearce did in a recent Sencha Touch example where he needed to read address book data from a mobile phone. Everything he does to set up his Proxy in the article (about 1/3rd of the way down) works the same way for Ext JS 4 too.

Continue reading

Introduction to Ext JS 4

At the end of last 2010 we capped off an incredible year with SenchaCon - by far the biggest gathering of Sencha developers ever assembled. We descended on San Francisco, 500 strong, and spent an amazing few days sharing the awesome new stuff we're working on, learning from each other, and addressing the web's most pressing problems.

Now, we're proud to release all of the videos from the conference completely free for everyone. You can see a full list on our conference site, where you'll find days worth of material all about Ext JS 4, Sencha Touch and all of the other treats we're working on at the moment.

Some of the videos in particular stand out for me - Jamie's Charting and Layouts talks were spectacular, as was Rob's Theming Ext JS 4 talk. On the Touch side, Tommy's talks on Performance and Debugging are required viewing, as is Dave Kaneda's characteristically off the cuff Theming talk.

My personal high point was standing in front of all of you and introducing Ext JS 4 and its three core goals - speed, stability and ease of use. I think you're going to love what we've done with the framework in version 4.

If you're so inclined, you can find the slides for this talk on slideshare, and if you can still stand the sound of my voice check out my other presentation on Ext JS 4 Architecture, focusing chiefly on the new data package (slides).

Continue reading

Ext JS 4: The Class Definition Pipeline

Last time, we looked at some of the features of the new class system in Ext JS 4, and explored some of the code that makes it work. Today we're going to dig a little deeper and look at the class definition pipeline - the framework responsible for creating every class in Ext JS 4.

As I mentioned last time, every class in Ext JS 4 is an instance of Ext.Class. When an Ext.Class is constructed, it hands itself off to a pipeline populated by small, focused processors, each of which handles one part of the class definition process. We ship a number of these processors out of the box - there are processors for handling mixins, setting up configuration functions and handling class extension.

The pipeline is probably best explained with a picture. Think of your class starting its definition journey at the bottom left, working its way up the preprocessors on the left hand side and then down the postprocessors on the right, until finally it reaches the end, where it signals its readiness to a callback function:

The distinction between preprocessors and postprocessors is that a class is considered ‘ready’ (e.g. can be instantiated) after the preprocessors have all been executed. Postprocessors typically perform functions like aliasing the class name to an xtype or back to a legacy class name - things that don't affect the class' behavior.

Each processor runs asynchronously, calling back to the Ext.Class constructor when it is ready - this is what enables us to extend classes that don’t exist on the page yet. The first preprocessor is the Loader, which checks to see if all of the new Class’ dependencies are available. If they are not, the Loader can dynamically load those dependencies before calling back to Ext.Class and allowing the next preprocessor to run. We'll take another look at the Loader in another post.

After running the Loader, the new Class is set up to inherit from the declared superclass by the Extend preprocessor. The Mixins preprocessor takes care of copying all of the functions from each of our mixins, and the Config preprocessor handles the creation of the 4 config functions we saw last time (e.g. getTitle, setTitle, resetTitle, applyTitle - check out yesterday's post to see how the Configs processor helps out).

Finally, the Statics preprocessor looks for any static functions that we set up on our new class and makes them available statically on the class. The processors that are run are completely customizable, and it’s easy to add custom processors at any point. Let's take a look at that Statics preprocessor as an example:

//Each processor is passed three arguments - the class under construction,
//the configuration for that class and a callback function to call when the processor has finished
Ext.Class.registerPreprocessor('statics', function(cls, data, callback) {
if (Ext.isObject(data.statics)) {
var statics = data.statics,
name;

//here we just copy each static function onto the new Class
for (name in statics) {
if (statics.hasOwnProperty(name)) {
cls[name] = statics[name];
}
}
}

delete data.statics;

//Once the processor's work is done, we just call the callback function to kick off the next processor
if (callback) {
callback.call(this, cls, data);
}
});

//Changing the order that the preprocessors are called in is easy too - this is the default
Ext.Class.setDefaultPreprocessors(['extend', 'mixins', 'config', 'statics']);
//Each processor is passed three arguments - the class under construction,
//the configuration for that class and a callback function to call when the processor has finished
Ext.Class.registerPreprocessor('statics', function(cls, data, callback) {
if (Ext.isObject(data.statics)) {
var statics = data.statics,
name;

//here we just copy each static function onto the new Class
for (name in statics) {
if (statics.hasOwnProperty(name)) {
cls[name] = statics[name];
}
}
}

delete data.statics;

//Once the processor's work is done, we just call the callback function to kick off the next processor
if (callback) {
callback.call(this, cls, data);
}
});

//Changing the order that the preprocessors are called in is easy too - this is the default
Ext.Class.setDefaultPreprocessors(['extend', 'mixins', 'config', 'statics']);

What happens above is pretty straightforward. We're registering a preprocessor called 'statics' with Ext.Class. The function we provide is called whenever the 'statics' preprocessor is invoked, and is passed the new Ext.Class instance, the configuration for that class, and a callback to call when the preprocessor has finished its work.

The actual work that this preprocessor does is trivial - it just looks to see if we declared a 'statics' property in our class configuration and if so copies it onto the new class. For example, let's say we want to create a static getNextId function on a class:

Ext.define('MyClass', {
statics: {
idSeed: 1000,
getNextId: function() {
return this.idSeed++;
}
}
});
Ext.define('MyClass', {
statics: {
idSeed: 1000,
getNextId: function() {
return this.idSeed++;
}
}
});

Because of the Statics preprocessor, we can now call the function statically on the Class (e.g. without creating an instance of MyClass):

MyClass.getNextId(); //1000
MyClass.getNextId(); //1001
MyClass.getNextId(); //1002
... etc
MyClass.getNextId(); //1000
MyClass.getNextId(); //1001
MyClass.getNextId(); //1002
... etc

Finally, let's come back to that callback at the bottom of the picture above. If we supply one, a callback function is run after all of the processors have run. At this point the new class is completely ready for use in your application. Here we create an instance of MyClass using the callback function, guaranteeing that the dependency on Ext.Window has been honored:

Ext.define('MyClass', {
extend: 'Ext.Window'
}, function() {
//this callback is called when MyClass is ready for use
var cls = new MyClass();
cls.setTitle('Everything is ready');
cls.show();
});
Ext.define('MyClass', {
extend: 'Ext.Window'
}, function() {
//this callback is called when MyClass is ready for use
var cls = new MyClass();
cls.setTitle('Everything is ready');
cls.show();
});

That's it for today. Next time we'll look at some of the new features in the part of Ext JS 4 that is closest to my heart - the data package.

Continue reading

Classes in Ext JS 4: Under the hood

Last week we unveiled a the brand new class system coming in Ext JS 4. If you haven’t seen the new system in action I hope you’ll take a look at the blog post on sencha.com and check out the live demo. Today we’re going to dig a little deeper into the class system to see how it actually works.

To briefly recap, the new class system enables us to define classes like this:

Ext.define('Ext.Window', {
extend: 'Ext.Panel',
requires: 'Ext.Tool',
mixins: {
draggable: 'Ext.util.Draggable'
},

config: {
title: "Window Title"
}
});
Ext.define('Ext.Window', {
extend: 'Ext.Panel',
requires: 'Ext.Tool',
mixins: {
draggable: 'Ext.util.Draggable'
},

config: {
title: "Window Title"
}
});

Here we’ve set up a slightly simplified version of the Ext.Window class. We’ve set Window up to be a subclass of Panel, declared that it requires the Ext.Tool class and that it mixes in functionality from the Ext.util.Draggable class.

There are a few new things here so we’ll attack them one at a time. The ‘extend’ declaration does what you’d expect - we’re just saying that Window should be a subclass of Panel. The ‘requires’ declaration means that the named classes (just Ext.Tool in this case) have to be present before the Window class can be considered ‘ready’ for use (more on class readiness in a moment).

The ‘mixins’ declaration is a brand new concept when it comes to Ext JS. A mixin is just a set of functions (and sometimes properties) that are merged into a class. For example, the Ext.util.Draggable mixin we defined above might contain a function called ‘startDragging’ - this gets copied into Ext.Window to enable us to use the function in a window instance:

//a simplified Draggable mixin
Ext.define('Ext.util.Draggable', {
startDragging: function() {
console.log('started dragging');
}
});
//a simplified Draggable mixin
Ext.define('Ext.util.Draggable', {
startDragging: function() {
console.log('started dragging');
}
});

When we create a new Ext.Window instance now, we can call the function that was mixed in from Ext.util.Draggable:

var win = Ext.create('Ext.Window');
win.startDragging(); //"started dragging"
var win = Ext.create('Ext.Window');
win.startDragging(); //"started dragging"

Mixins are really useful when a class needs to inherit multiple traits but can’t do so easily using a traditional single inheritance mechanism. For example, Ext.Windows is a draggable component, as are Sliders, Grid headers, and many other UI elements. Because this behavior crops up in many different places it’s not feasible to work the draggable behavior into a single superclass because not all of those UI elements actually share a common superclass. Creating a Draggable mixin solves this problem - now anything can be made draggable with a couple of lines of code.

The last new piece of functionality I’ll mention briefly is the ‘config’ declaration. Most of the classes in Ext JS take configuration parameters, many of which can be changed at runtime. In the Ext.Window above example we declared that the class has a ‘title’ configuration, which takes the default value of ‘Window Title’. By setting the class up like this we get 4 methods for free - getTitle, setTitle, resetTitle and applyTitle.

  • getTitle - returns the current title
  • setTitle - sets the title to a new value
  • resetTitle - reverts the title to its default value (‘Window Title’)
  • applyTitle - this is a template method that you can choose to define. It is called whenever setTitle is called.

The applyTitle function is the place to put any logic that needs to be called when the title is changed - for example we might want to update a DOM Element with the new title:

Ext.define(‘Ext.Window’, {
//..as above,

config: {
title: 'Window Title'
},

//updates the DOM element that contains the window title
applyTitle: function(newTitle) {
this.titleEl.update(newTitle);
}
});
Ext.define(‘Ext.Window’, {
//..as above,

config: {
title: 'Window Title'
},

//updates the DOM element that contains the window title
applyTitle: function(newTitle) {
this.titleEl.update(newTitle);
}
});

This saves us a lot of time and code while providing a consistent API for all configuration options: win-win.

Digging Deeper

Ext JS 4 introduces 4 new classes to make all this magic work:

  • Ext.Base - all classes inherit from Ext.Base. It provides basic low-level functionality used by all classes
  • Ext.Class - a factory for making new classes
  • Ext.ClassLoader - responsible for ensuring that classes are available, loading them if they aren’t on the page already
  • Ext.ClassManager - kicks off class creation and manages dependencies

These all work together behind the scenes and most of the time you won’t even need to be aware of what is being called when you define and use a class. The two functions that you’ll use most often - Ext.define and Ext.create - both call Ext.ClassManager under the hood, which in turn utilizes the other three classes to put everything together.

The distinction between Ext.Class and Ext.Base is important. Ext.Base is the top-level superclass for every class ever defined - every class inherits from Ext.Base at some point. Ext.Class represents the class itself - every class you define is an instance of Ext.Class, and a subclass of Ext.Base. To illustrate, let’s say we created a class called MyClass, which doesn’t extend any other class:

Ext.define('MyClass', {
someFunction: function() {
console.log('Ran some function');
}
});
Ext.define('MyClass', {
someFunction: function() {
console.log('Ran some function');
}
});

The direct superclass for MyClass is Ext.Base because we didn’t specify that MyClass should extend anything else. If you imagine a tree of all the classes we’ve defined so far, it will look something like this:

Sample Inheritance Tree

This tree bases its hierarchy on the inheritance structure of our classes, and the root is always Ext.Base - that is, every class eventually inherits from Ext.Base. So every item in the diagram above is a subclass of Ext.Base, but every item is also an instance of Ext.Class. Classes themselves are instances of Ext.Class, which means we can easily modify the Class at a later time - for example mixing in additional functionality:

//we can define some mixins at definition time
Ext.define('MyClass', {
mixins: {
observable: 'Ext.util.Observable'
}
});

//it’s easy to add more later too
MyClass.mixin('draggable', 'Ext.util.Draggable');
//we can define some mixins at definition time
Ext.define('MyClass', {
mixins: {
observable: 'Ext.util.Observable'
}
});

//it’s easy to add more later too
MyClass.mixin('draggable', 'Ext.util.Draggable');

This architecture opens up new possibilities for dynamic class creation and metaprogramming, which were difficult to pull off in earlier versions.

In the next episode, we’ll look at how the class definition pipeline is structured and how to extend it to add your own features.

Continue reading

Writing Compressible JavaScript

Writing a library is a balancing act between the (sometimes competing) interests of API clarity, code clarity, performance and compressibility. In this article I'm going to detail three of the approaches we take to meet this balance and suggest them for your own usage.

1. Collecting var statements

Every time we declare variables we add 4 bytes to the compressed file size. Variables are declared sufficiently often that this can really add up, so instead of this:

var myFirstVar = 'something';
var myOtherVar = 'another thing';
var answer = 42;
var adama = true;
var myFirstVar = 'something';
var myOtherVar = 'another thing';
var answer = 42;
var adama = true;

One should use this form:

var myFirstVar = 'something',
myOtherVar = 'another thing',
answer = 42,
adama = true;
var myFirstVar = 'something',
myOtherVar = 'another thing',
answer = 42,
adama = true;

When this code is compressed, each variable name above is turned into a single-letter name, meaning that the wasted 4 bytes per useless additional 'var ' in the first example would have contributed significantly to code size with no benefit.

2. Local variable pointers to object properties

The following code (pruned from a previous version of Ext JS) is not as compressible as it could be:

var cs = {};
for (var n in this.modified) {
if (this.modified.hasOwnProperty(n)) {
cs[n] = this.data[n];
}
}
return cs;
var cs = {};
for (var n in this.modified) {
if (this.modified.hasOwnProperty(n)) {
cs[n] = this.data[n];
}
}
return cs;

We're better off aliasing 'this.modified' to a local variable first. Aside from the performance benefits some JS engines derive from not having to perform object property lookups over and over again, we save precious bytes this way too:

var modified = this.modified,
changes = {},
field;

for (field in modified) {
if (modified.hasOwnProperty(field)) {
changes[field] = this.data[field];
}
}

return changes;
var modified = this.modified,
changes = {},
field;

for (field in modified) {
if (modified.hasOwnProperty(field)) {
changes[field] = this.data[field];
}
}

return changes;

Again, the minifier will compress those variable names down to a single character each, so for our 'this.modified' example we're going to use 15 bytes to define the variable plus 1 byte each time we use it (totalling 15), vs the 26 bytes for that code previously. This approach scales especially well - were we to refer to this.modified a third time in the function, as our code will now minify to 16 bytes, vs 39 without the variable declaration.

Side note: in the first example here the variable 'n' was being used in the for...in loop. We can always safely exchange that for a meaningful variable name (in this case 'field') and leave the rest to the minifier.

3. Aliasing 'this' to 'me'

In Ext.data.Record's markDirty method we have the following code:

this.dirty = true;
if(!this.modified){
this.modified = {};
}
this.fields.each(function(f) {
this.modified[f.name] = this.data[f.name];
},this);
this.dirty = true;
if(!this.modified){
this.modified = {};
}
this.fields.each(function(f) {
this.modified[f.name] = this.data[f.name];
},this);

There are 7 references to 'this' in that method, taking 28 bytes and completely incompressible. We could rewrite it like this (note that the final 'this' can be removed in this format):

var me = this;

me.dirty = true;
if (!me.modified) {
me.modified = {};
}
me.fields.each(function(f) {
me.modified[f.name] = me.data[f.name];
});
var me = this;

me.dirty = true;
if (!me.modified) {
me.modified = {};
}
me.fields.each(function(f) {
me.modified[f.name] = me.data[f.name];
});

Again, our minifier will change the 'me' var to a single character, saving us 8 bytes in this instance. That might not sound like a lot but after minification it equates to a 7% reduction in code size for this function.

In each of the cases above we're generally talking about single-digit percentage savings after minification. There is value in that small slice though, especially as more and more applications shift onto bandwidth-constrained mobile platforms.

The first two approaches are no-brainers and must always be done but the third is slightly more controversial. Personally I find it makes the code a little harder to read, largely because my syntax highlighter doesn't recognise that 'me' is now the same as 'this'. Its value also varies significantly by function - some functions can contain over a dozen references to 'this', in which case this approach makes a big difference.

Continue reading

Answering Nicholas Zakas' JavaScript quiz

A current meme that's floating around the JavaScript geek corner of the internet is setting quizzes on some of the more unusual aspects of JavaScript. This time round Nicholas Zakas is providing the entertainment, so I thought I'd provide some answers. Let's get started:

Question 1

Question 1 looks like this:


var num1 = 5,
num2 = 10,
result = num1+++num2;

var num1 = 5,
num2 = 10,
result = num1+++num2;

We're asked what the values of result, num2 and num1 are. First, let's deconstruct what that +++ is doing. There is no +++ operator in JavaScript - instead we have a num1++ followed by a + num2.

JavaScript has two ways of incrementing a number by 1 - we can either put the ++ before the variable or after it. The variable is incremented either way - the only difference is what is returned. ++10 returns 11, whereas 10++ returns 10:


var a = 10;

var b = a++; //a is set to 11 now, but b is set to 10
var c = ++a; //a is set to 12 now, c is also set to 12

var a = 10;

var b = a++; //a is set to 11 now, but b is set to 10
var c = ++a; //a is set to 12 now, c is also set to 12

So 'result' is the sum of num1++ (which is 5) and num2, which is 10, so result equals 15. num2 remains at 10 as it was not modified. num1 is now equal to 6 because we incremented it by 1, though the incrementation did not affect the sum passed to result.

Question 2


var x = 5,
o = {
x: 10,
doIt: function doIt(){
var x = 20;
setTimeout(function(){
alert(this.x);
}, 10);
}
};
o.doIt();

var x = 5,
o = {
x: 10,
doIt: function doIt(){
var x = 20;
setTimeout(function(){
alert(this.x);
}, 10);
}
};
o.doIt();

We're asked what is alerted. This is mostly smoke and mirrors - there's some indirection with all the duplicate names but the important thing here is the setTimeout. The function we pass to setTimeout gets run in the global scope, meaning 'this' refers to the window object. Declaring x as a variable in the global scope (var x = 5) is the same as setting window.x = 5, so 5 is alerted.

Question 3


var num1 = "10",
num2 = "9";

var num1 = "10",
num2 = "9";

We're asked:

  • What is the value of num1 < num2?
  • What is the value of +num1 < num2?
  • What is the value of num1 + num2?
  • What is the value of +num1 + num2?

This question is all about type casting.

  • num1 < num2 is true - if both operands are strings JavaScript will compare them alphabetically, and "10" is lower alphabetically than "9"
  • +num1 < num2 is false - placing a "+" operator before a string casts it into a number, so we're actually testing 10 < "9". When testing a mixture of numbers and strings like this, everything is cast into a number, so we're testing 10 < 9, which is false
  • num1 + num2 === "109" - the plus sign can mean both addition and concatenation, depending on the operand types. Here we have 2 strings so we're concatenating them together
  • +num1 + num2 === "109" also - again we're casting num1 into a number, but the + operator means concatenation if at least one operand is a string

The confusion around this comes largely from the fact that the plus sign is used for both addition and concatenation in JavaScript. This causes the engine to have to test the typeof each operand and cast accordingly. All of the other math operators (e.g. /, *, % etc) cast both operands to numbers.

Question 4


var message = "Hello world!";

var message = "Hello world!";

We're asked:

  • What is the value of message.substring(1, 4)?
  • What is the value of message.substr(1,4)?

substring and substr do similar things. The first argument to each is the character index to start from, but whereas substring's second argument is the character index to end at, substr's second argument is the number of characters to return. Therefore message.substr(1, 4) will return a string of length 4, whereas message.substring(1, 4) will return a string of length 3 (4 - 1):

  • message.substring(1, 4); //"ell"
  • message.substr(1, 4); //"ello"

Question 5


var o = {
x: 8,

valueOf: function(){
return this.x + 2;
},
toString: function(){
return this.x.toString();
}
},
result = o < "9";
alert(o);

var o = {
x: 8,

valueOf: function(){
return this.x + 2;
},
toString: function(){
return this.x.toString();
}
},
result = o < "9";
alert(o);

We're asked the value of 'result', and what gets alerted. This requires an understanding of the special valueOf and toString functions available on every object. These functions are used internally by the JavaScript engine to pull out the best representation of an object's value based on the situation.

When alerting a value, we want a string representation so toString is called. When comparing the value to another object, valueOf is called instead. So alert(o) alerts "8", and result is set equal to the result of 10 < "9". The JavaScript engine will decide when to use which option, or we can specify it ourselves:

var num1 = 8, num2 = 9;

num1 + num2; //17
num1.toString() + num2.toString(); //"89"
num1.valueOf() + num2.valueOf(); //17
var num1 = 8, num2 = 9;

num1 + num2; //17
num1.toString() + num2.toString(); //"89"
num1.valueOf() + num2.valueOf(); //17

The 'result' assignment needs a little explanation. First, the engine calls valueOf on the object, which returns 10. Second, because one of the operands to the < operator is a number, the other is also cast into a number, so we are testing 10 < 9, which returns false. We could instead force it to use toString: o.toString() < "9" returns true.

Quizzes like this are great for getting your teeth into some of the guts of JavaScript, but don't mistake them for a good way to write code. The point is to demonstrate how quirky JS code can be unless you write it in a sensible way.

Continue reading