Fortunately, Dojo 1.7 has evolved with a powerful new feature detection infrastructure. Dojo now uses the popular has() pattern for feature detection in combination with a has()-aware build system. While it is easy enough to write feature detection tests with ad-hoc JavaScript expressions, the has() pattern defines a specific syntax such that the build system can detect these feature-based branches, and one can create application builds that are highly optimized for specific devices, with known feature shims factored out.

Since Dojo’s codebase in 1.7 has already been significantly refactored to use the has() pattern, we can instantly start making platform-optimized builds without even using has() in our own code. Certainly the most common and likely target for an optimized build is the modern WebKit platform used on the majority of mobile devices. Now there are some small variations between different WebKit versions used in the mobile world, but there a significant number of important known features that we can rely on to create builds for WebKit browsers and mobile devices. To specify the known features, we include an object with the features in the staticHasFeatures property of a build profile file. Here is a sample start to a build profile that covers the major features that Dojo uses:

dependencies = {
	stripConsole: "normal",
	staticHasFeatures: {
		"dom-addeventlistener": true,
		"dom-qsa": true,
		"json-stringify": true,
		"json-parse": true,
		"bug-for-in-skips-shadowed": false,
		"dom-matches-selector": true,
		"native-xhr": true,
		"array-extensible": true,
		"quirks": false
	},
	...

With this profile, the build system will find any feature branches in the code, and substitute the known features (or bugs) provided. You will want to ensure that this type of a build is combined with the closure compiler, which will then proceed to remove code blocks that won’t ever be used due to the known conditional branches (dead code removal). To use the closure compiler, you can specify closure as the layer optimizer:

build action=release profile=my-profile layerOptimize=closure

After running a build, we now have a built version of Dojo (or our application) without any of the extra code that compensates for a lack of a standard W3C addEventListener(), querySelectorAll(), and other standard features that are missing in earlier versions of Internet Explorer. When this optimized build is run on base dojo.js, it will save us about 9KB compared to the version of Dojo equipped for running on all supported browsers. This 9KB can be an important saving for size sensitive applications. We can use this build for a mobile version of our application, or choose this build when we detect a WebKit browser. The former option is simply a matter of pointing to this build for the mobile pages. If we want to create a page that actually selects the appropriate build at run-time based on the host browser, we can do that with some simple browser detection. While there are a number of different ways we could do this, this is perhaps the simplest:

<script>
	// choose the appropriate dojo script based on the user agent
	// will match FF, Safari, Chrome, mobile browsers, not IE
	var dojoScript = /Gecko/.test(navigator.userAgent) ? 
		'dojo-webkit.js' : 'dojo.js';
	// now create and append a script element to load it:
	var hd=document.getElementsByTagName("head")[0],
		el=document.createElement("script");
	el.async=true; // set it to async
	require = { // configure Dojo for async mode
		async: true
	};
	el.src='path/to/dojo/' + dojoScript;
	hd.insertBefore(el,hd.firstChild); // insert it so it will load
</script>

The script above will asynchronously load Dojo, which will allow your page to load quicker. However, if you need to load Dojo synchronously, you could use document.write instead:

<script>
	// choose the appropriate dojo script based on the user agent
	// will match FF, Safari, Chrome, mobile browsers, not IE
	var dojoScript = /Gecko/.test(navigator.userAgent) ?
  		'dojo-webkit.js' : 'dojo.js';
	document.write('<script src="path/to/dojo/' + dojoScript + '"></s' + 'cript>');
</script>

You may have noticed that we used browser sniffing in this example, despite the fact that we advocate feature detection. In general, using feature detection in your source code is definitely preferred because it makes your code robust and agnostic to browser platforms. However, using separate code like the example above to avoid the expense of running multiple feature detections (they can be expensive in time and space) at run-time, based on known user agents can be a valuable optimization. When doing this, make sure the optimization stays distinct from the code that will be using feature detection so there is a clean separation of purposes. Placing this in the HTML, separate from modules can be a good way to achieve this organization.

Because the build system is based on feature sets, we could go further and create even more platform specific builds. We could define additional features and make specific builds for different versions of IE (newer versions of IE include more features of course), and separate out Firefox and Opera from WebKit. The feature set based builds allow for limitless permutations of device specific optimizations.

Another build setting that we can also define to create lighter weight builds is the query selector engine. By default, Dojo is built with the “acme” engine that has long been a part of Dojo. However, 1.7 introduced an alternate selector engine called “lite”. The “lite” engine leans much more heavily on the native querySelectorAll capabilities of modern browsers, and does not have full CSS3 support for older browsers. However, it does support the core CSS2 features that are the workhorse queries predominantly used for most applications (see the dojo/query documentation for more information about the lite engine capabilities). You can choose to use the lite engine if you are targeting modern browsers or if your application does not need to use any fancy CSS3 queries. Select the lite engine in your build profile like this:

dependencies = {
	selectorEngine:"lite",
	...

The lite engine will save another 6KB of size in dojo.js.

Using has()

In running a build with known features, so far we have simply been taking advantage of the existing feature detection branching in the Dojo code base. However, we may want to use has() in our own application. While Dojo normalizes most of the major discrepancies between browsers, there may still be situations where your application needs to detect a feature or bug in the browser and respond accordingly. We can use the dojo/has module to access the has() function. If we are using an existing feature that Dojo detects, this is very simple:

require(["dojo/has"], function(has){
	if(has("touch")){
		// show our touch interface
	}else{
		// show our mouse-driven interface
	}
});

A list of the features that Dojo detects and provides are available on the dojo/has reference page. If the Dojo tested features are not sufficient, you can also easily create your own feature detect tests, by calling has.add():

require(["dojo/has"], function(has){
	// test if we have video
	has.add('html5-video', !!document.createElement('video').canPlayType);
	if(has('html5-video')){
		// show our video with a <video> element	
	}else{
		// use flash or something
	}
});

Both of these examples use the has() pattern so the build system can properly identify these feature branches, and you can create builds with known features to eliminate unused branches for specific browsers.

The new feature detection infrastructure and integration with the build system helps modernize Dojo, using the latest and most advanced techniques for cross-browser web application development and highly optimized mobile web applications.

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

You are not alone, brave developer. We feel your pain – the type that results from banging your head on a keyboard until the room spins – and that is why we have an amazing gift for you! Read on…

Dojo users and SitePen customers alike have needed a grid since the Dojo Toolkit project began. At first, we and several other companies banded together to purchase a non-open source grid. Enter Dojo DataGrid. We contributed our shiny new code to the Dojo Toolkit for the benefit of everyone and we’ve spent years maintaining and incrementally improving it in Dojo. But the web evolved, faster and faster, demanding more functionality, more performance, and more data! Others tried to keep up as well, enter EnhancedGrid and LazyTreeGrid. Kudos to everyone for building and contributing to Dojo!

Finally, last year, we took a long, hard look at how our customers were using DataGrid and EnhancedGrid. We agonized over the time and effort spent developing and maintaining such crucial functionality. We knew something needed to change. Enough was enough! Our choice was to attempt a DataGrid refactor or start over. The SitePen Team spoke: We started over.

To date, we’ve invested thousands of hours in developing the new dgrid, a grid that goes beyond any other, enabling developers to make awesome things faster than ever.

So, without further ado, we’re delighted to announce that dgrid, a new JavaScript component for creating advanced, high performance data grids, is now in Beta!

Alpha, Beta, and beyond

The Alpha release of dgrid represented a baseline which gave a fair indication of its design direction, as well as the types of features it intended to support. While some modules were in an unfinished or rough state, it was possible to demonstrate and harness their abilities, and we were thrilled to hear from several early adopters who shared some early success stories and feedback.

This Beta release represents the culmination of months of work by the SitePen team to fix bugs and work toward a stable API release. While many companies and individuals have already successfully used alpha versions of dgrid in their production applications, dgrid beta represents the first release of dgrid we know to be feature-complete and API-stable for regular use.

Beyond Beta, we’re on the path to greatness, most notably finishing work on keyboard accessibility and improving mobile compatibility. Mobile compatibility, in particular, will be a continued focus for development as the mobile landscape continues to evolve.

Usability, Portability, Compatibility

We’ve designed dgrid with your needs in mind. First of all, because dgrid is a completely portable AMD package, any application written with AMD can use dgrid—even if the rest of the application isn’t using Dojo!

As for compatibility, we’re currently targeting the following desktop browsers:

• Firefox ESR and latest release (currently 10 and 11, respectively)
• Chrome stable (currently 17)
• Internet Explorer 6-9
• Safari 5.1
• Opera 11.61

And the following mobile platforms…

• iOS 4.3 and 5
• Android 2.3 and 4.0

dgrid’s Modular Features

dgrid’s extremely modular design helps to ensure that core functionality can be easily modified and that extremely small, lightweight grids can be created with minimal effort. Whereas grid modules like DojoX DataGrid are at least 55KB in compressed size, dgrid starts at just 12KB! Additionally, dgrid includes a huge number of modular features out-of-the-box, rivaling or exceeding nearly every other grid component currently available:

• Keyboard navigation & ARIA role support for accessibility
• i18n support
• Asynchronous data retrieval & row rendering
• Row & column drag’n'drop
• jQuery ThemeRoller theme support
• Native dojo/store API support
• Automatic updates with Observable stores
• Inline cell editors, including support for Dijit form widgets as editors
• Unlimited-depth tree support
• Support for multiple independent column sets
• Support for records rendered to multiple rows
• Support for custom formatting functions for cell contents
• A complete row selection engine, including multi-row and indirect (checkbox-based) selection
• Licensed using the same CLA & open-source licensing as the Dojo Toolkit
• ColumnHider: Shows and hides columns via a simple menu (Beta Feature!)
• ColumnReorder: Reorders columns in simple layouts using drag’n'drop (Beta Feature!)
• DijitRegistry: Enables integration with the Dijit registry and other Dijit layout widgets (Beta Feature!)
• Virtual & traditional paging options
• Pagination: A UI component that changes the behavior of the grid to with discrete pages rather than virtual scrolling (Beta Feature!)

dgrid, Where have you been all my life?

We really wanted to make sure you didn’t miss out on this extraordinary opportunity to simplify and improve your ongoing development efforts and application performance. We knew we need to illustrate how dgrid can be used to create amazing experiences with a minimum amount of effort and convince you that this was the way to go! So, here’s what we did:

First, we documented the heck out of our code and put in on Github. THEN, we wrote some tests and demos and THEN we created some handy tutorials AND THEN, we gathered everything up, organized it to the nines and put it right here:
http://dgrid.io/

Development & Support – We’ve got your back

Wow! Thanks for reading this far! You must be seriously over your current grid fiasco!

We’re working hard with our customers to replace their massive grid implementations with dgrid and we can do the same for your application! Call us today to get on the schedule to receive a full grid migration effort or sign up for one of our valuable SitePen Support plans to keep your developers productive and informed!

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

Learn Dojo - We are dedicated to providing you with the highest quality Dojo Toolkit workshops in the industry.  Whether you want to learn the basics of Dojo or sharpen your Dojo skills, we have a workshop just for you.  All of our Dojo Workshops are taught by our Dojo experts.  We promise you won’t be subjected to listening to some trainer who can’t live without his slides.  Wondering if our Dojo Workshops will cover Dojo 1.7?  The answer is yes!

Ready to learn Dojo?  Check out our full list of 2012 workshop dates and locations.  Sign up for any of our 2012 Dojo Workshops by January 31, 2012 with promo code IHEARTDOJO and get 10% off!

Here to help - Did you know we also have support plans to fit every size and every need?  No matter which support plan you choose, our expert engineers will help you by answering questions, resolving bugs, and solving problems. We offer no-hassle ways to get in touch with your SitePen Support team, which means no waiting on hold, or having to explain your issue over and over again until you get to the right person.  With us, you always have access to the right people. If your project runs in to a critical issue, our expert SitePen engineers will jump in to help you quickly get back on track. Oh, and yes, all of our support plans include support for dGrid and Dojo 1.7! Having a SitePen Support plan is preparing for possibilities.  Even football teams have backup quarterbacks.

From 2 support hours to 200 support hours, SitePen has a support plan to fit your needs.  Take a look!

Perfect match of design and development - We are your one stop shop for your next project, including mobile web applications! Our expert team will take your web application from concept to launch.  We’ve mastered the front end and are here to help you build powerful, simple, and usable web apps, every single time.

Whether you need a traditional web application, mobile web application or installable mobile web app store application, SitePen can help!

Still not sure how we can help you?  Contact us today! (You can even call us if you want.)  Celebrate 2012 – The Year of Dojo!

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

This is an updated version of the post Touching and Gesturing on the iPhone, published in 2008.

In the beginning…

Before we discuss the new features in Dojo 1.7 that make touch interfaces easier to create, it helps to understand some of the underlying technology and concepts. With iPhone, Apple introduced two new event concepts: touches and gestures. Touches are important for keeping track of how many fingers are on the screen, where they are, and what they’re doing. Gestures are important for determining what the user is actually doing when they are interacting with the device at a higher level: pinching, rotating, swiping, double-tapping, and so on.

While touch events are available on most platforms (the touch event model originally established on iOS has been standardized in the W3C Touch Events specification and is supported by iOS, Android, and BlackBerry), native gesture events are not available everywhere, and the gesture event API in iOS is limited in the sorts of gestures it supports. The dojox/gesture package steps in to fill these gaps in functionality; we’ll discuss it shortly.

Touches

When you put a finger down on the screen, it kicks off the lifecycle of touch events. Each time a new finger touches the screen, a new touchstart event happens. As each finger lifts up, a touchend event happens. If, after touching the screen, you move any of your fingers around, touchmove events happen. If too many fingers are on the screen, or another action (such as a push notification from the phone’s OS) interferes with the touch, a touchcancel event happens.

The following touch events exist:

• touchstart: Occurs when a finger is placed on the screen
• touchend: Occurs when a finger is removed from the screen
• touchmove: Occurs when a finger already placed on the screen is moved across the screen
• touchcancel: Occurs when a touch is cancelled before the finger is actually removed from the screen

While it might seem that there should be a 1:1 mapping between a touch event and a mouse event—after all, your finger works much like a cursor—it turns out that TouchEvent objects do not include properties that you might expect to see. For example, pageX and pageY properties are not populated. This is because, with a mouse, you really only have one point of contact: the cursor. With a multi-touch device, though, you could (for example) keep two fingers held down on the left of the screen while you tap the right side of the screen, and all three points are registered.

In order to provide information about all touch points at once, every TouchEvent object has a property containing information about every finger that’s currently touching the screen. It also has two other properties: one which contains a list of information for fingers that originated from the current target node, and one which contains only the information for fingers that are associated with the current event. These properties are:

• touches: A list of information for every finger currently touching the screen
• targetTouches: Like touches, but is filtered to only the information for finger touches that started out within the same node
• changedTouches: A list of information for every finger that has changed state due to the event (see below)

To better understand what might be in these lists, let’s go over some examples quickly.

• When you put one finger down, all three lists will provide the same information.
• When you put a second finger down, touches will contain two items, one for each finger. targetTouches will have two items only if the second finger was placed in the same node as the first finger (otherwise it will only contain the second finger). changedTouches will only have information related to the second finger, because it’s what triggered the event.
• If you put two fingers down at exactly the same time, you will get two items in changedTouches, one for each finger that triggered the event.
• If you move your fingers, the only list that will change is changedTouches. It will contain information about the finger or fingers that moved.
• When you lift a finger, it will be removed from touches and targetTouches, and will appear in changedTouches, since it’s what caused the event.
• Removing your last finger will leave touches and targetTouches empty, and changedTouches will contain information about the last finger.

Using these lists, it is possible to keep very close tabs on what the user is doing. Imagine creating a(nother) Super Mario clone in JavaScript—you’d be able to tell what direction pad the user currently has his or her thumb on, while also being able to watch for when the user wants to jump or shoot a fireball when they touch another virtual button elsewhere.

So far, we’ve been discussing lists of information about fingers on the screen, but we haven’t talked about what this information looks like. The objects contained in the touches lists have properties similar to what you’d see on a MouseEvent object. The following is the full list of properties for these objects:

• clientX: X coordinate of touch relative to the viewport (excludes scroll offset)
• clientY: Y coordinate of touch relative to the viewport (excludes scroll offset)
• screenX: Relative to the screen
• screenY: Relative to the screen
• pageX: Relative to the full page (includes scrolling)
• pageY: Relative to the full page (includes scrolling)
• identifier: An identifying number, unique to each touch point (finger) currently active on the screen
• target: The DOM node that the finger is touching

One of the annoyances of writing Web applications for smartphones has been that even if you set a viewport for your application, dragging your finger around will move the page. Fortunately, the touchmove event object has a preventDefault method that can be used to keep the page still.

Drag and drop with the Touch API

Creating drag and drop functionality on touchscreen devices is made easier due to the fact that touchmove events only fire when a finger is already touching the screen’s surface. This means we don’t need to track button states like we would with a mousemove event. A basic drag and drop implementation, then, can look as simple as this:

node.addEventListener("touchmove", function(event){
    // Only deal with one finger    
    if(event.touches.length == 1){ 
        // Get the information for finger #1
        var touch = event.touches[0], 
            // Find the style object for the node the drag started from
            style = touch.target.style; 
        // Position the element under the touch point
        style.position = "absolute"; 
        style.left = touch.pageX + "px";
        style.top = touch.pageY + "px";
    }
}, false);

Better touching in Dojo 1.7

One of the problems with using low-level touch events is that, if you are creating an application that you want to function on both touch-enabled or mouse-enabled devices, you end up needing to set up two sets of event listeners. The new dojo/touch module in Dojo 1.7 normalizes these two types of events, using touch events where available and falling back to mouse events on other platforms in order to provide device-neutral events. Using it is just as easy as listening for a regular event, except instead of passing a string for the event name, you instead pass a function in place of the event name:

require([ "dojo", "dojo/touch" ], function(dojo, touch){
    dojo.connect(dojo.byId("myElement"), touch.press, function(event){
        // handle a mousedown/touchstart event
    });
    dojo.connect(dojo.byId("myElement"), touch.release, function(event){
        // handle a mouseup/touchend event
    });
});

Gestures

On iOS devices, a gesture event occurs any time two or more fingers are touching the screen. If any finger lands in a node you are listening for gesture events on (gesturestart, gesturechange, gestureend), you’ll receive the corresponding gesture events.

Gesture events provide a GestureEvent object with these properties:

• rotation: The amount the user has rotated their fingers, in degrees.
• scale: A multiplier indicating the amount the user has pinched or pushed their fingers, where numbers larger than 1 indicate a push, and numbers smaller than 1 indicate a pinch.

When listening for both gesture events and touch events, the event pattern looks like this:

1. touchstart for finger 1.
2. gesturestart when the second finger touches the surface.
3. touchstart for finger 2.
4. gesturechange sent every time both fingers move while still touching the surface.
5. gestureend when the second finger leaves the surface.
6. touchend for finger 2.
7. touchend for finger 1.

Resizing and rotating with the Gestures API

Using the CSS transform, width, and height properties, we can easily rotate and scale any element in response to these gestures.

var width = 100,
    height = 200,
    rotation = 0;

node.addEventListener("gesturechange", function(event){
    var style = event.target.style;
    // scale and rotation are relative values,
    // so we wait to change our variables until the gesture ends
    style.width = (width * event.scale) + "px";
    style.height = (height * event.scale) + "px";
    style.webkitTransform = "rotate(" + ((rotation 
      + event.rotation) % 360) + "deg)";
}, false);

node.addEventListener("gestureend", function(event){
    // Update the values for the next time a gesture happens
    width *= event.scale;
    height *= event.scale;
    rotation = (rotation + event.rotation) % 360;
}, false);

Better gestures with Dojo 1.7

Dojo 1.7 includes a new package, dojox/gesture, that provides functionality for handling more complex gestures on touch-sensitive devices. In addition to defining a basic framework for creating your own custom gestures through extension of the dojox/gesture/Base module, it comes with built-in support for several common gestures, including tap, tap and hold, double tap, and swipe.

Using dojox gestures couldn’t be much simpler. Just like dojo/touch, in order to listen for a gesture, you simply connect to a gesture event using dojo.connect, passing the gesture function in place of the event name:

require([ "dojo", "dojox/gesture/swipe", "dojox/gesture/tap" ], 
        function(dojo, swipe, tap){
    dojo.connect(dojo.byId("myElement"), swipe, function(event){
        // handle swipe event
    });

    dojo.connect(dojo.byId("myElement"), tap.doubletap, function(event){
        // handle double tap event
    });
});

In time, dojox/gesture will be extended to include more complex event types and behaviors, such as pinching and zooming. For now, it provides several new events that were difficult to handle before, as well as an excellent framework that can be used to create complex gesture events across all platforms.

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

config.json

The main configuration file defines all of the dependencies, application behaviors, top level views and scenes, and any other information required for the application to function.

Example config

{
	/* global application dependencies */
	"dependencies": [
		"dojox/mobile/Heading",
		"dojo/mobile/RoundRect",
		"my/custom/module"
	],

	/* Application Modules.  These are implicitly added
	  to the above set of dependencies */
	"modules": [
		"dojox/app/module/history",
		"my/custom/appModule"
	],

	/* The html template for the application itself */
	"template": "example.html",

	/* the view to start on by default */
	"defaultView": "home",

	/* transition to use if none has been provided */
	"defaultTransition": "slide",

	/* Views and Scenes */
	"views": {

		/* home is a top level dojox.app.view */
		"home": {

			/* class to instantiate this view as */
			"type": "dojox.app.view",

			/* dependencies specific to this view */
			"dependencies": [
				"dojox/mobile/ListItem",
				"dojox/mobile/EdgeToEdgeCategory"
			],

			/* template to use for this view */
			"template": "views/home.html"
		},
	
		/* tabscene is a dojox.app.scene,
		  and it contains three child views */
		"tabscene": { 
			/* class to instantiate, a scene in this case */
			"type": "dojox.app.scene",

			/* the scene's template */
			"template": "tabScene.html",

			/* the default view within this scene */	
			"defaultView": "tab1",

			/* when transitioning between tabs,
			  use a flip animation by default */
			"defaultTransition": "flip",

			/* the views available to this scene */
			"views": { 
				"tab1":{
					"template": "views/tabs/tab1.html" 
				},
				"tab2":{
					"template": "views/tabs/tab2.html" 
				},
				"tab3":{
					"template": "views/tabs/tab3.html" 
				}
			},

			/* dependencies specific to this scene */
			"dependencies": [
				"dojox/mobile/RoundRectList",
				"dojox/mobile/ListItem",
				"dojox/mobile/EdgeToEdgeCategory"
			]
		}
	}
}

Configuration property descriptions

• dependencies – When defined at the root of the configuration, this property defines the modules that are required for the whole application. When defined under a scene or a view, this property defines which modules must be loaded before that view/scene can be instantiated.
• modules – This property defines application modules that will be mixed into the Application class to control the lifecycle and behavior of the application. In other words, the Application class that is instantiated for a given site is dynamically created at runtime using the base Application class plus this list of modules.
• template – When defined at the root of the configuration, this property defines the template that is used for the application’s layout. Within the context of a view or a scene, this property defines the template used to define the view or scene.
• defaultView – This property defines the initial view that is loaded by the application.
• defaultTransition – When defined at the root of the configuration, this property defines the default visual transition method used for top level views/scenes. When defined under a scene, it is the default transition method for the associated scene only.
• views – The views property is a nested set of objects defining the views and scenes available to an application or scene. These will be discussed in greater detail later.

Some additional properties, such as models, stores, id, name, and description are reserved for future use; their exact definitions and usages are still under development.

The Application class

The Application class itself is actually an abstract class and is never used directly. It is a very simple extension of the Scene class (described below). dojox.app provides a generator function, which, when passed a configuration object, will build and automatically start the actual Application instance for the site. Its usage looks like this:

require(["dojo/json", "dojox/app", "dojo/text!./config.json"],
function(json, makeApplication, config){
	makeApplication(json.parse(config));
});

The Scene class

The Scene class provides a templated container for views. Its purpose is to allow the layout of a scene to be provided using an HTML template and to define a set of child views that the scene can transition between. For example, to display a set of tabs, you would use a Scene configured with a child View for each tab. The scene’s template would define where to display the tab controls and the view.

Internally, Scene steals some concepts from dijit.layout and dijit._Templated. The default template for the base Scene class is pretty simple and not really much of a template—it simply outputs whatever content is in the current view. Elements within a scene’s template can use the region attribute to define where that element and its children should be displayed, similar to a dijit.layout.BorderContainer. For example, to implement a tab scene, the template might look like this (using components from dojox.mobile):

<div style="background:#c5ccd3;" class="view mblView"> 
	<div region="top" dojoType="dojox.mobile.Heading">
		Tab Scene
	</div>
	<ul region="top" dojoType="dojox.mobile.TabBar"
		barType="segmentedControl">
		<li dojoType="dojox.mobile.TabBarButton"
			icon1="images/tab-icon-16.png"
			icon2="images/tab-icon-16h.png"
			transitionOptions='{title:"TabScene-Tab1",
				target:"tabscene,tab1",
				url: "#tabscene,tab1"}' selected="true">Tab 1</li>
		<li dojoType="dojox.mobile.TabBarButton"
			icon1="images/tab-icon-15.png"
			icon2="images/tab-icon-15h.png"
			transitionOptions='{title:"TabScene-Tab2",
				target:"tabscene,tab2",
				url: "#tabscene,tab2"}'>Tab 2</li>
		<li dojoType="dojox.mobile.TabBarButton"
			icon1="images/tab-icon-10.png"
			icon2="images/tab-icon-10h.png"
			transitionOptions='{title:"TabScene-Tab3",
				target:"tabscene,tab3",
				url: "#tabscene,tab3"}'>Tab 3</li>
	</ul>
</div>

This above template defines two areas with region="top": a header and list of tab buttons. They will both be placed at the top of this scene when rendered.

Normally, when using a BorderContainer, one would also have a region="center" section. In the case of a Scene, however, the “center” region will be applied automatically to the currently active view (the current tab, for example).

In addition to the code that supports the appropriate lifecycle of the scene and its rendering, Scene provides a transition method which controls the transition of content from one child view to another. Scenes can contain both views and other scenes.

The View class

Views, like scenes, are also containers of content. However, instead of containing additional views as children, they contain only the content defined by their template. Unlike a Scene, a View cannot contain any other scenes or views.

Summary

All three of these classes are intended to be as simple and feature-free as possible, providing only the basic structure and lifecycle described above (though additional core methods & lifecycle hooks will be added in time). A developer using the dojox.app framework can define additional custom view or scene types by extending the base classes (or implementing equivalent functionality) and defining them in the application’s configuration file.

TODO

dojox.app is an experimental framework with several key pieces still under development. This final release is expected to occur prior to Dojo 2.0. The following items are currently under development:

• Model/Store support – We have a couple of preliminary implementations of model/store support, including one for dojox.mvc. However, additional work is required to complete an agreed-upon API for these components. While MVC systems will be given first class support, they will not be required—an application developer will be able to “control” the HTML of a view just as well by extending the View class instead.
• Desktop/Mobile Branching – dojox.app is designed to be platform-agnostic. Using CSS media selectors and property definitions within the configuration file, there will be support for choosing which set of views and parameters to use based on the user’s browser.
• Intelligent build support – For performance, especially on the mobile side, an appropriate build of the application is required. Rather than add a separate build profile for the app, a wrapper utility will be created to intelligently generate builds directly from the configuration file.

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

Using dojo/on

dojo/on has a similar API to dojo.connect. You still provide a target object or DOM node, the event name to listen for, and the listener. Dojo 1.7 now has full support for the AMD module format, so we will get a reference to the on function directly from the dependency list, and then use the on function:

define(["dojo/on"], function(on){
  var target = dojo.byId("target-id");
  on(target, "click", function(event){
    // executed when target is clicked
  });
});

The on function is also similar to dojo.connect in providing essential event normalization. The returned events should have standard W3C event properties including target and currentTarget and methods including stopPropagation() and preventDefault(), even on Internet Explorer (back to version 6). dojo/on does separate out some of the less used and non-standard keypress and mouseenter/leave normalization as extension events (it is still incorporated in dojo.connect for backwards compatibility).

Event Delegation

One of the exciting new features with the new event handling system is the addition of event delegation support in Dojo base/core. Event delegation is a powerful mechanism, where we register a single event listener on the DOM to handle events that can bubble up from multiple sources. The new event delegation system makes it easy to select acceptable DOM nodes to accept propagating events from, and properly react to. Event delegation has existed in Dojo previously in dojox/NodeList/delegate.js, but with support in the core event system, delegation is now very convenient to use. You provide an event name, colon prefixed with the a CSS selector to specify which nodes can bubble to the listener. The listener will be called if the an element inside the target element fires an event and that element matches the CSS selector in the scope of the target element. When the listener is called, the this object will be set to the child element that matched the selector. For example, if we had a form with several <button> elements on it, we could listen for click events on any of the buttons with:

form = dojo.byId("my-form");
on(form, "button:click", function(event){
  // event -> The event object
  // this -> The button element
});

Or we could listen for change events on an text inputs within the <div> with a class of “details”:

on(form, 'div.details input[type="text"]:change', changeHandler);

We can also comma-delimit multiple events to listen to. For example, to listen to submit events on the form and clicks on <button> elements, we could do:

on(form, "submit, button:click", submitHandler);

NodeList’s on()

One of ways to use the new event listening module is by using the on() method for NodeList‘s returned from dojo.query. The on() method is based on dojo/on, and gives us access to all the new features and performance, including event delegation. We use NodeList's on() just like Dojo on() except that we don’t need to provide a node as the first argument, all the nodes in the NodeList are targeted. For example, we could query for all <button> elements and listen for clicks:

define(["dojo/query"], function(query){
  query("button").on("click", clickHandler);
  ...

We could also use event delegation, here getting any <form> elements and listening for clicks on any <button> children:

query("form").on("button:click", clickHandler);

Extension Events

Another new feature of dojo/on is support for extension events, allowing for listening to custom events that may be aggregates of multiple events or emulation of events not supported by the browser. Dojo 1.7 now includes a whole library of gesture events that are extension events, like swipe, tap, and more. These events are particularly useful for mobile applications where high-level events are composed from low-level events. For example, to listen for a swipe event, we could do:

define(["dojo/on", "dojox/gesture/swipe"], function(on, swipe){
  on(node, swipe.left, function onSwipeLeft(){
    // called on a swipe left
  });
});

The swipe gestures are an example of an extension event that is based on other events (touchstart, touchmove, touchend).

Legacy Code as Extensions

To reduce the size of dojo/on and improve modularity, there are several other event emulation mechanisms there were moved out of the connect.js module into extension events (these are still included by connect.js for backwards compatibility), including extension events based on IE’s non-bubbling mouseenter and mouseleave events, (unfortunately the standard mouseover and mouseout do bubble, which makes them painful to use). You can use the use enter and leave extension events from dojo/mouse to emulate IE’s events cross-browser:

define(["dojo/on", "dojo/mouse"], function(on, mouse){
  on(node, mouse.enter, function hover(){
    dojo.addClass(node, "hovering");
  });
  on(node, mouse.leave, function unhover(){
    dojo.removeClass(node, "hovering");
  });
});

There is also an extension event for emulating Firefox’s keypress behavior, but this emulated behavior is not terribly helpful, and using this emulator is not recommended and exists purely for backwards-compatibility (it is used to retain dojo.connect‘s current behavior). Even with the dojo.connect API and the extension events for full backwards compatibility, the total module size is still smaller than the dojo.connect module from Dojo 1.6.

Touch Normalization

The new event system now includes normalization for standard touch events. dojo/on (dojo.connect) now ensures that touch events include the standard pageX, pageY, rotation, scale, and other touch properties on all devices. It also normalizes the orientationchange on non-conformant Android devices. You can listen for touch events like any other standard event:

on(node, "touchstart", function(){
  // called on a touchstart event
});

Emitting Events

The dojo/on module also adds support for emitting custom events using native browser event delegation mechanisms. The new on.emit function can be used to create custom native events that can trigger DOM listeners, and includes support for bubbling and cancelling. This is used in Dojo Mobile to create transition events, for example.

Faster, Lighter

The new dojo/on module is a compact, fast module with minimal dependencies designed for lightweight mobile applications. Along with these new features, a significant amount of heavy legacy code has been left out of dojo/on, and moved out to separate modules. The dojo/on module also leverages Dojo’s new has() feature branching capabilities for creating small lightweight, browser-specific builds.

This blog post should give you an introduction to the new capabilities of dojo/on, you can refer to the dojo.on documentation for more information.

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

TweetView: Android, Packaging, and Review

In the previous two posts, Getting Started with TweetView: Tweets and Mentions and TweetView: Creating the Settings View, we created the HTML, CSS, and JavaScript code required to power the TweetView mobile application. This tutorial will focus on implementing an Android theme, leveraging the Dojo build system to keep the application compact for production, and a basic review of the entire dojox.mobile-powered application. Want to read more? Check out the tutorial.

Want to see a specific Tutorial? Want to Learn More?

Is there something you’d like to learn how to do with Dojo? Always wanted to know how something in Dojo works? Leave us a message in the blog comments and we’ll see about getting a tutorial created for you. Or sign-up for an upcoming SitePen Dojo Workshop to get a fully immersive hands-on experience with Dojo.

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

Getting Started with TweetView: Tweets and Mentions

In the previous post, Introduction to TweetView, we introduced the mobile application we will be building with dojox.mobile: TweetView. We built the general layout template for our application and now it’s time to make TweetView work. This tutorial will focus specifically on the “Tweets” and “Mentions” views of our application. Before we begin coding our application, let’s set up our application file structure and review a few mobile app development concepts. Sound interesting? Check out the tutorial.

Want to see a specific Tutorial? Want to Learn More?

Is there something you’d like to learn how to do with Dojo? Always wanted to know how something in Dojo works? Leave us a message in the blog comments and we’ll see about getting a tutorial created for you. Or sign-up for an upcoming SitePen Dojo Workshop to get a fully immersive hands-on experience with Dojo.

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

Take Dojo Everywhere

Dojo 1.5 had initial support for creating mobile web apps and that work continued into Dojo 1.6. While you’ve been able to view the developer tests if you knew where to look, how to actually build an app with Dojo Mobile has been a trial and error process until now.

Getting Started with dojox.mobile

Before you can begin writing an app with Dojo Mobile you need to understand what Dojo Mobile is all about and how it works. Dojo Mobile is a framework of controllers, CSS3-based themes, and device-like widgets that will allow you to effortlessly create intelligent, flexible, and cross-device-compatible mobile web applications. Our first Dojo Mobile tutorial goes into detail on getting started with Dojo Mobile.

Creating an App: Introduction to TweetView

In the multi-part TweetView series, we’ll embark on creating our own fully functional dojox.mobile web application called TweetView. This tutorial will focus on familiarizing you with what TweetView is, what we want it to do, and we’ll get started on building the mobile application’s HTML and CSS layout. Sound interesting? Check out the tutorial.

Want to see a specific Tutorial? Want to Learn More?

Is there something you’d like to learn how to do with Dojo? Always wanted to know how something in Dojo works? Leave us a message in the blog comments and we’ll see about getting a tutorial created for you. Or sign-up for an upcoming SitePen Dojo Workshop to get a fully immersive hands-on experience with Dojo.

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!

Consider the following:

PhoneGap XUI

“We hear your words. Why another JavaScript framework?! When development of PhoneGap was under way we noticed slow load times for modern JavaScript frameworks (such as Prototype, MooTools, YUI, Ext and (yes) even jQuery. A big reason why these libraries are so big is because is mostly they contain a great deal of cross browser compatability code. The mobile space has less browser implementations (so far) and different needs. Thus XUI.

XUI strives to be a framework for first class mobile device browsers such as WebKit, Fennec and Opera with future support under consideration for IE Mobile and BlackBerry.”

Joe Hewitt’s iUI

“First and foremost, iUI is not meant as a “JavaScript library”. Its goal is simply to turn ordinary standards-based HTML into a polished, usable interface that meets the high standards set by Apple’s own native iPhone apps.”

John Resig’s war on War on Browser Sniffing

“As of 1.3, jQuery no longer uses any form of browser/userAgent sniffing internally – and is the first major JavaScript library to do so.

Browser sniffing is a technique in which you make assumptions about how a piece of code will work in the future. Generally this means making an assumption that a specific browser bug will always be there – which frequently leads to code breaking when browsers make changes and fix bugs.

Instead we use a technique called feature detection where we simulate a particular browser feature or bug to verify its existence. We’ve encapsulated all the checks that we use in jQuery into a single object: jQuery.support. More information about it, feature detection, and what this feature provides can be found in the jQuery.support documentation.”

Sizzle, a micro-toolkit for CSS Selectors that is now part of the Dojo Foundation

“Sizzle is a pure-JavaScript CSS selector engine designed to be easily dropped in to a host library.

A completely standalone selector engine (no library dependencies), Sizzle provides competitive performance for the most frequently used CSS selectors. At only 3KB minified and gzipped, it is highly extensible with an easy-to-use API.

Sizzle is designed for optimal performance with event delegation, provides meaningful error messages for syntax problems, uses a single code path (no XPath), uses no browser-sniffing (feature-detection only), and is Caja-compatible.”

TIBCO General Interface

GI builds an optimized code tree for each major browser release (the opposite of the approach jQuery 1.3 and others have taken, as code only makes it into a build for that browser if that browser is known to support that functionality).

dojox.gfx

GFX supports SVG, VML, Canvas, Silverlight, and Flash with the same simple procedural drawing API, so you can target native and plugin rendering environments with one simple API. In order to make this possible, dojox.gfx selectively loads only the code it needs based on the target rendering environment. Loading the code for all platforms would be prohibitively expensive from a performance perspective.

excludeStart(“webkitMobile”)

In recent discussions on the Dojo mailing list, discussions turned to how to make Dojo faster for mobile users. In most cases, this involves removing code and features that are not needed on that platform given the precious resources available on mobile devices and over mobile networks.

Alex Russell checked in some work he started last year that looks like this:

//>>excludeStart("webkitMobile", kwArgs.webkitMobile); 
!dojo.isIE &&  
//>>excludeEnd("webkitMobile"); 

The syntax is a bit verbose, but it excludes the code between the start and end in a Dojo build created for webkitMobile:

./build.sh profile=base action=clean,release webkitMobile=true

While we would love to switch to pure feature detection over browser version detection like John has done with jQuery 1.3, version detection is generally more concise and precise, and does not necessarily make Dojo any less forwards compatible.

Version detection also makes it easy to exclude code created solely for browsers that require major workarounds, such as IE 6. To get the most out of this though would require doing something similar for each major browser, which would make Dojo more challenging to understand and maintain, would probably require a build step even during development (not just in production to improve performance).

At this point, there are no clear answers, just a lot of questions on how to create a toolkit that offers edge of the web features for desktop users, and still preserves performance for mobile web users. What approach do you think is best?

SitePen offers beginner, intermediate, and advanced Dojo Toolkit workshops to make your development team as skilled and efficient as possible when creating dynamic, responsive web applications. Sign up today!