Hidden Gems in Chrome Developer Tools

As a software developer building applications with web technology, I naturally spend lots of time in my browser. For many years web developers struggled to build cross-browser applications because many browsers (notably older versions of Internet Explorer) failed to offer even minimal debugging tools — but thankfully today every browser ships with helpful developer tools and supports modern standards.

I use Google Chrome as my primary browser simply because its set of developer tools offers more features than the competition. I often joke that Chrome Developer Tools has so many features that they ran out of space to show them, so I wanted to share a few hidden gems I’ve found.

A Quick History Lesson

Google Chrome was first released in 2008. At that time, web developers didn’t have many options when it came to choosing even the most basic debugging tools — Internet Explorer did not offer any developer tools (in spite of holding the majority of the worldwide browser market share), and Safari and Firefox only offered limited tooling. Firebug (an extension for Firefox) was by far the most advanced tool available, and many of us relied on it.

But after Chrome was released, this picture quickly began to change. Chrome (at that time) extended WebKit and the built-in “WebKit Inspector” to include a variety of additional tools (like Profiles) — and soon thereafter surpassed the feature set of Firebug.

Today, Google pushes a new version of Chrome every six weeks, and these updates often include changes to the Chrome Developer Tools. At that cadance, it becomes difficult to stay on top of new features or UI changes.

Hidden Gems

When I spoke about this topic at SenchaCon a few weeks ago, I skipped what I considered to be the “basic” features of Chrome Developer Tools in order to spend more time talking about the advanced and hidden features. Chrome DevTools has what seems like 10,000 individual features, and we could literally spend days talking about them — so let’s jump right into three features I have found incredibly helpful.

Layers Panel

Although most web developers conceptually understand how nesting DOM elements affects the way the browser layers CSS applied to those elements, the fact remains that the browser displays a 2D plane. However, Chrome DevTools has a hidden feature that allows us to view the DOM layering in 3D.

To access this feature, we need to complete a few steps:

  1. Go to chrome://flags and enable “Enable Developer Tools experiments.”
  2. Restart Chrome
  3. Open Chrome DevTools
  4. Click “Settings” (the gear icon in the upper right corner)
  5. Click on “Experiments” in the left menu
  6. Check the “Layers panel” option
  7. Close, then re-open Chrome DevTools
  8. Now you should see the “Layers” tab

The Layers panel can be incredibly helpful in understanding how your DOM elements are structured on the page, and therefore how CSS rules may apply to them. It’s also very helpful in building anything involving CSS 3D Transforms — as I did in my blog post Creating Custom Layouts in Ext JS.

ESC Drawer

Sencha applications are notoriously different from web apps built with other frameworks in that Sencha applications generally involve writing very little HTML. Therefore, we tend to spend the majority of our time in the Sources tab debugging JavaScript at runtime. However, it becomes inconvenient to set breakpoints on the Sources tab, then switch to the Console tab to interact with the scope variables, then switch back to Sources (and so on).

Thankfully, Chrome DevTools offers a hidden feature to open the Console on any tab — simply hit the ESC key and the “ESC drawer” magically opens from the bottom.



The ESC Drawer allows you simultaneous access to the Console, which is certainly convenient — but it also does a whole lot more! The “Emulation” and “Rendering” tabs are full of amazing features that you should explore.

Asynchronous Call Stacks

Few things in JavaScript can be as frustrating as debugging code inside of the callback of an AJAX request. Depending on how your code is written, the scope of the callback may be set to the window object — and even worse, you might hit an error and have no idea how your runtime got to that point in the first place.


In the example above, we hit a runtime error complaining that foo() is not defined. Although we can pause on the caught exception and see which line of code throws the error, the call stack does not give us a lot of helpful information. In this case, we might be able to deduce that this function call exists in the callback for a store’s load operation, but we have no way of telling what caused the store to load in the first place.

To remedy that problem, check the “Async” checkbox on the “Call Stack” divider. The next time you hit a breakpoint you’ll be given a more comprehensive call stack — one that even tells you from where an asynchronous callback was executed.


Conclusion

Google continues to innovate and create exceptional tools for building amazing web applications. With a little bit of exploration, you’ll find a treasure trove of additional debugging functionality in Chrome Developer Tools that you may not have realized existed!

Do you have a favorite feature? Share yours in the comments below.

4 Comments   Read more

How to Create Google Chrome Apps and Extensions from your Ext JS App

Introduction

How to Create Google Chrome Apps and Extensions from your Ext JS AppGoogle Chrome is an important delivery mechanism for web content. As of September 2014, Chrome has a 59.6% browser market share.

It’s not just the browser; it’s also Chrome OS, the operating system that runs on Chromebooks. According to Gartner, 5.2 million units are expected to be sold this year. The demand for Chromebooks is rising, particularly in the US education market.

Google Chrome is an important delivery mechanism for web content. As of September 2014, Chrome has a 59.6% browser market share.
Source: w3schools.com, 2014

The Google Chrome Web Store is a great place to get exposure for your applications because everyone who uses the Google Chrome browser can install these apps.

Ext JS helps you build powerful web applications. Just like web apps, Chrome apps are written in JavaScript, CSS and HTML, so Ext JS is the right framework for creating great looking and performing Chrome apps.

There are different types of installable Chrome apps: extensions, packaged apps and hosted apps.

  • Hosted web apps are regular web applications, served from a web server.
  • Packaged web apps are bundled and are completely installed in Chrome browser with access to special Chrome APIs
  • Extensions are small apps that can modify and enhance the functionality of Chrome browser.

Today we will examine how to build a hosted app in detail; the process of creating a packaged Chrome app or extension is much different and may be covered in future posts. If you are interested in building packaged apps or Chrome extensions, please see the following resources that have been created by the Sencha team:

Let’s take a look at the steps you’ll need to follow to package your Ext JS app for Google Chrome.

Requirements:

  • Ext JS 5 and Sencha Cmd
  • An Ext JS application originally generated with Sencha Cmd
  • A Google account, which will be used as a developer account to access your apps
  • One icon for the Google Chrome Web Store (128×128 pixel PNG)
  • Artwork, which will be used to feature the app in the Web Store:
    • 440×280 PNG used as a tile in the search results
    • At least one 1280×800 PNG screenshot of the app
  • Access to a web server (hosted apps require a network connection; load the application from a whitelisted url).

For demo purposes, I’ve created a simple Ext JS 5 todo application. The namespace of my app is called: ExtTodo. This application was originally generated with Sencha Cmd 5.

I’m sharing this example in my GitHub repository.

Here are the steps:

1. Disable the image slicer

By default, the build process enables the image slicer to create fallback images for legacy browsers. Google Chrome is a modern browser, so we don’t need fallback images. Therefore, we’ll disable the slicer to reduce the build time and minimize our production output.

Open ~/exttodo/.sencha/app/sencha.cfg and then add the following under the namespace:

# Skip the image slice process
skip.slice=1

2. Build with Sencha Cmd

After disabling the image slicer, let’s create a production build. Run this command from the application folder:

sencha app build production

The build process creates a single, compressed .js file containing everything needed to run your application. It contains all Sencha Ext JS classes that are used as well as all of your own custom application code. The build process will also create a minified stylesheet for production, which contains the framework theme and maybe custom styling.

3. Verify your build

With your file explorer, browse to the build/production/MyApp folder, to locate the exttodo application (e.g. ~/exttodo/build/production/ExtTodo).

Notice the following file structure:

  • app.js – the single minified JS file
  • app.json – contains app specific settings
  • index.html – landing page for our application
  • resources/ – folder that contains all of the configured images, fonts and other resources for our application
  • ExtTodo-all.css – the CSS theme

4. Upload the build to your webserver

Now, it’s time to upload your build to a web server.

Note: If you don’t have a web server and just want to test how to create a Google Chrome app with Ext JS and Sencha Cmd, you can skip this step. Later, in the manifest file, link to the build/production/MyApp folder on localhost.

5. Create a new empty folder

Create the googlechromeapp folder:

~/exttodo/googlechromeapp/ExtTodo

This folder will contain Chrome Webstore assets and a manifest file.

6. Copy the icon and artwork into the root of the googlechromeapp/MyApp folder

7. Create a manifest file

It’s actually very easy to create hosted Google Chrome apps. All you need is a manifest.json file, which you put in the root of the ~/exttodo/googlechromeapp/MyApp folder. It looks like the following:

{
        "name": "ExtTodo",
        "description": "A simple Ext JS 5 Todo app",
        "version": "0.1",
        "manifest_version": 2,
        "app": {
                "urls": [
                        "http://localhost/exttodo/build/production/ExtTodo"
                ],
                "launch": {
                        "web_url":  "http://localhost/exttodo/build/production/ExtTodo"
                }
        },
        "icons": {
                "128": "icon_128.png"
        }
}

Note: In this example, I am setting the app url to localhost, just for testing purposes. As soon as I am hosting my web application online, I can set it to http://mydomain.com/mychromeapp/

Let’s review each of the important properties in this JSON configuration object:

  • nameRequired. The name of the application; this is displayed in the store and in Chrome’s launcher.
  • descriptionRecommended. A brief description of the app.
  • versionRequired. The version of this metadata; each time you update the metadata this number must be incremented.
  • manifest_versionRequired. The current supported manifest version is 2.
  • appRequired. The remote URLs that the app uses.
    • urlsRecommended. Array with the URLs for the pages in the hosted app.
    • launchRequired. Specifies what happens when the user launches the app.
      • web_urlRequired. Specifies the launch page as an absolute URL.
  • iconsRecommended. Specifies the icon shown in the launcher.
  • For a complete overview see, the Google Developer Guide on Installable Web Apps.

8. Create a zip file

Now, create a zip file from the contents of ~/exttodo/googlechromeapp/MyApp. the manifest.json and the icon, those files should be the root of your zip file.

Now, create a zip file from the contents of ~/exttodo/googlechromeapp/MyApp. the manifest.json and the icon, those files should be the root of your zip file.

9. Upload the file to the Google Dashboard

Open the Google dashboard (you need to be logged in to Google).

Click the Add new item button, and accept the Google web store agreement.

Upload the file to the Google Dashboard

Next, click the Choose file button, and select the ~/exttodo/googlechromeapp/MyApp/myapp.zip file. This action
will upload the package.

After uploading, it will forward you to the set up publish screen, where you can write a detailed app store description and showcase app screenshots, etc. We don’t need to do this for our tutorial.

Click Save draft and return to dashboard button.

Note:If you want to publish the web app or want to sell applications through the app store, then there are some additional steps. See the last steps in this guide, Publishing Your App.

Basically, you will need to fill out the publish settings. Publishing apps requires a one-time registration fee of $5, to make sure developers upload serious web applications.

If your hosted app is listed in the Chrome Web Store, you must prove that you control each domain specified in this field.

10. Test it

To test your application running as a Chrome App, go to the Chrome settings. See the screenshot below.

Test it

Open the Extensions tab.

Check the Developer Mode checkbox, and click the Pack extension button.

The pop-up window below will be shown. For the Extension root directory, select ~/exttodo/googlechromeapp/MyApp folder. Then click the Pack extension button.

The pop-up window below will be shown. For the Extension root directory, select ~/exttodo/googlechromeapp/MyApp folder. Then click the Pack extension button.

The pop-up window below will be shown. For the Extension root directory, select ~/exttodo/googlechromeapp/MyApp folder. Then click the Pack extension button.

This will download two files. MyApp.pem and MyApp.crx. MyApp.pem is a file with a secure key. You need to save this file, outside the googlechromeapp/MyApp/ folder.

Pack Extension

I moved the MyApp.crx, which is the app launch file, into the ~/exttodo/googlechromeApp/MyApp/ folder.

After that, press the Load unpacked extension button.

In the next popup window, select the ~/exttodo/googlechromeapp/MyApp folder. Then, the app icon will show up in the extensions list.

To test the hosted application, open a new tab in Google Chrome, and select the apps button (or type the following url: chrome://apps). The 128×128 app icon will be visible and this will launch my extodo app.

Conclusion

Google Chrome is an app platform worth looking at because many people are using Google Chrome as their favorite browser. Ext JS 5 helps you build powerful applications, and because Chrome apps are web applications we can use this platform to get exposure. There are different types of Chrome apps you can build, such as packaged (offline) Chrome Apps, Chrome browser extensions (to enhance browser functionality) and hosted web applications. In this tutorial, I’ve demonstrated how developers can create hosted Chrome applications in a few easy steps.

What kind of Chrome Apps are you building? Let me know in the comments section below.

chrome-apps-teaser.png 1 Comment   Read more

Developing for Google Glass with Sencha Touch

Wearable electronics have seen a boom over the last year. This is mainly due to the adoption of advanced watches that can do anything from answer phone calls to play games. Google feels they have the next big thing in wearable technology, and today we are going to take a look at how that will affect us as developers.

Currently in its explorer state, which is just a nice way of saying beta testing, Google Glass is far from achieving mass adoption. This makes it the perfect time to get involved in how this technology will be used, what it needs to be capable of and how it will shape the future of wearable electronics. Who knows if Google Glass will explode into the next big thing, but I think its pretty safe to say it is unlike anything we have right now. How we use it, what problems we can solve and the ways we can make peoples lives easier, better, safer and more entertaining is up to all of us.

At Sencha, we have always stuck by our core belief that HTML5, and the technologies that support it, will always the top choice for any cross-platform mobile development. Google Glass is a perfect example because you’ll quickly find that you don’t need anything more than Sencha Touch to build apps.

Building apps for Glass will come naturally to developers in the hybrid app world because we’re really just dealing with a smaller screen resolution and some new UI constraints. We understand these requirements since we support tablets, desktops and mobile phones.

Video Demo

Since most of you will not have access to Google Glass, we have put together a short video demo of a simple Sencha Touch app running on Glass.

Getting Started

You will start your application just like any other Sencha Touch app, scaffolding the basic skeleton with Sencha Cmd.

sencha -sdk /path/to/sdk generate app {AppName} /path/to/app

The next step will be to serve up this application, so we can work on it through the browser. Navigate to the folder where you created your application (/path/to/app) and run the following command.

sencha web start

You will now have a web server running your application, and you can visit http://localhost:54321 to check out the app.

Local Development Workflow

Now, let’s start looking into the Google Glass specifics. We will focus on Google Chrome as our local development platform since most people don’t have access to Glass. Later, however, we will dive into generating a native Google Glass application with Sencha Cmd and Cordova.

At this point, you should have your application open in Chrome, then select Tools → Developer Tools from the Menu on the top right. The shortcut for this is Command + Option + i. From the Developer Tools window, you will select the gear icon in the top right corner and choose the Overrides Section. You will confirm that “Show‘Emulation; view in console drawer” is checked. You can then close out of the setting menu.

Next, you will select any tab other than Console from the developer tools window. We will use Sources for now. At this point, you can press the ESC key on the keyboard to bring up the console drawer. Select the Emulation tab from the top to display all the overrides Chrome can apply.

If you navigate to the Device section, you will notice a drop down list of devices you can emulate, but Google Glass will not be one of them. I’m assuming in the future this option will be listed, but for now we need to set it up ourselves. Select a Google Nexus 4 from the drop down list and click emulate. We will now customize all of the settings.

In the Screen section, apply the following Settings:

  • Resolution: 640×360
  • Device pixel ratio: 1
  • Font scale factor: 1
  • Emulate Viewport should be checked
  • Enable text autosizing should be checked
  • Shrink to fit should be unchecked
  • CSS Media should be unchecked

In the User Agent Section, apply the following settings:

  • Spoof user agent should be checked
  • Drop down should be set to “Other”
  • Set the user agent to: Mozilla/5.0 (Linux; U; Android 4.0.4; en-us; Glass 1 Build/IMM76L; XE12) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

In the Sensors section, you can enable any device sensor emulation you would like, but be sure to at least check “Emulate touch screen”.

You should not see your Sencha Touch application in a small 640×360 window inside of Chrome. This matches the view the user has overlayed on their eyes inside of Google Glass. I am not 100% sure these will be the final emulation settings, but I have tested with Glass myself looking through them at my screen, and the overlay matches the window in Chrome perfectly. This will definitely give you a great start into Google Glass development.

UI Notes

Now that we have everything up and running in Chrome, we can start developing our application. The UI for Glass is very simple since there is not much room for user input. I recommend starting with a Carousel as your primary navigation component. You can then use an ‘activeitemchange’ listener to determine which child is the main view. In Glass, you navigate around with swipes and select things with a tap, so normal application user flow would be something like:

  • Application begins
  • Users swipes to move the screen information that they need
  • Users tap to get action options for that information
  • Menu appears masking the original screen
  • User swipes to move menu around to the option they require
  • User taps to take action

You can find a lot more information on Google Glass UI on the Google Glass Developers UI Docs page.

Building Apps for Glass

Once you have completed your masterpiece and you are ready to bring it to the world of Glass explorers, you can rely on Sencha Cmd and its Cordova support to help. For more information on native packaging with Cordova, check out the Sencha Touch Cordova Guide, but we will cover the main points right now.

To add Cordova support to your application, make sure you have all the pre-reqs and run the following command from your application root. {AppID} should be a reverse domain descriptor for your application, for example com.sencha.glass.TestApp. {AppName} is optional and if not included will just default to the name of your Sencha Touch application. If you do wish to name your native application differently, you can pass it in here:

sencha cordova init {AppID} {AppName}

Open the cordova.local.properties file in the root of your project and set:

cordova.platforms=android

The next step is to add the Cordova plugins we have created to properly set up your application for Google Glass. To do this, navigate to {app-root}/cordova in your Terminal and run the following three commands.

cordova plugin add https://github.com/aphex/cordova-glass-core
cordova plugin add https://github.com/aphex/cordova-glass-touch
cordova plugin add https://github.com/aphex/cordova-glass-gesture

Plugin Notes

We will take a moment here to talk through what each of these plugins is providing for you.

cordova-glass-core: Modifies the Cordova Android project to properly run on Google Glass. This allows for configuration of the voice command that will open the application. It also, optionally, allows for voice prompts prior to your application launching and contains a JavaScript API to retrieve a string of what the user said. For example the “Launch Trigger” could be “open Sencha Movies” and the prompt could ask “What movie would you like to search for” — the JavaScript API would allow your application to get this information as soon as it opens.

cordova-glass-touch: This is a very simple plugin that dispatches touchstart and touchend events from the Google Glass touchpad on the webview. This allows the Sencha Touch event system to take over and manage all touch events as usual.

cordova-glass-gesture: This plugin is optional, but developers will likely want to use it in their application. Sencha Touch will automatically detect gestures from touch events. This is how it is built and will always work, but if a developer would like to get native gestures from the touchpad instead of Sencha Touch gestures, that ’s where this plugin comes in. It will dispatch all touchpad gestures on the webview document object. For more information on how to listen for these events, check out the README on this plugins GitHub repo.

Launch Customization

Now that you have added Glass support to your application, there is only one more customization that needs to happen. You first want want to add the Android platform to your Cordova project by running the following command from your {app-root}/cordova folder:

cordova add platform android

Next, open the file located at ‘{app-root}/cordova/platforms/android/values/glass.xml ’.
You will then find an element that looks like this:

<string name="app_launch_voice_trigger">hello cordova</string>

You can now modify the value “hello cordova” to any string you would like used to launch your application. Optionally, you will also find the element:

<string name="app_launch_voice_prompt">prompt question</string>

If you would like your application to prompt for user input prior to launching, you can change “prompt question” to any question you would like. In order to enable the prompt question, you will then need to open “{app-root}/cordova/platforms/android/xml/app_launch_voice_trigger.xml” and uncomment the line that says:

<input prompt="@string/app_launch_voice_prompt"/>

That should do it for the Glass configuration. We’re working actively with the Apache Cordova team to try to streamline this process more, but currently we’re unable to change these settings properly via a plugin. We hope to have this sorted out soon but in the meantime you will need to set them yourself, which also means if you remove this plugin and add it again you will need to clean up those changes and reset the strings. We’re thinking this will be a rare case though.

Building and Deploying

You can now build your application for Google Glass by running the following command from your application root:

sencha app build native

This will invoke Sencha Command Cordova Support and bundle your application up into a native Android apk file. You can find this file at {app-root}/cordova/platforms/android/bin/{AppName}-debug.apk. At this point, you can sideload this application onto Glass (if you own a pair) with the command:

adb install -r /path/to/{AppName}-debug.apk

Quick Tip

For those of you that would like to speed up Android device development, Sencha CMD allows for running an application in an emulator via the command:

sencha app build -run native

If you would rather install your application on a USB connected Android device (such as Google Glass), you can open the file “{app-root}/.sencha/app/cordova-impl.xml”and inside the “-cordova-emulate”target change the command from:

cordova emulate ${cordova.platforms.clean}

to

cordova run ${cordova.platforms.clean}

Now when you run a “sencha app build -run native”, the application will be installed on the attached device.

To the Future

We hope this information is helpful for developers trying to understand native Android packaging and those who want to push the boundaries of current technology and start making the applications of the future. We plan on being there with you, and we can ’t wait to see what you come up with, so please share your feedback in the comments. Thanks for tuning in.

1 Comment   Read more

Announcing Sencha Blink 1.0

Sencha Blink 1.0Today we’re pleased to announce the first release of Sencha Blink, a cross platform UI toolkit for the coming wave of spectacle-based devices. Sencha Blink offers a full set of display components, fully abstracted eye events (using the new W3C HTML5 Eye Events), and a rich set of image query primitives. It also offers a breakthrough input system that replaces traditional keyboard entry based on eye blinks. Sencha Blink currently supports Google Glass, but we hope to soon support the forthcoming Apple iPane, and Microsoft EyeWindows Premium Home Edition.

Display Components

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

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

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

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

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

Eye Gestures

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

Innovative Keyboard Replacement

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

And Even More

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

Sencha Blink

Start Your Engines

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

20130401-sencha-blink-preview.png No Comments   Read more

Survey Says: Windows Phone 8 Support Strong, HTML5 Important for Multi-Device App Dev

We recently conducted a survey to our developer community about the impact that today’s multi-device world has on businesses and application development. Over 1,400 developers, managers, and IT execs responded and shared their insights on a variety of topics, including Windows Phone 8, Apple’s iOS 6, and the challenges of IT in a Bring Your Own Device (BYOD) world.

A key finding from the survey is that almost half (46%) of companies intend to support Windows Phone 8 within the next 6-to-12 months. This early indication of broad support for Microsoft’s mobile platform continues the growing trend of corporate support for multiple mobile platforms.

In addition:

  • 83% of companies support two or more mobile operating systems, with 34% supporting three or more.
  • Apple’s iOS is the first or second most important mobile platform for 63% of companies (33% ranked it as the most important) while Android was selected as first or second by 57% (20% ranked it as the most important).

58% of companies either have or will have a formal BYOD policy within the next 12 months.

The continued broad acceptance and importance of HTML5 to multi-device application development was apparent as well. The survey showed:

  • 61% replied that they conduct mobile app development in house for deployment across multiple platforms.
  • 68% of the companies polled believe that their greatest skills in development are in Web technologies such as HTML5, JS, and CSS rather than in native development (iOS was selected by only 14% and Android by 13% as the biggest programming skill in their organization).

It’s clear to us from this survey and other sources that the mobile market will continue to fragment, and the need for application developers to support multiple platforms and devices will only grow. You can see the formal press release on the survey results here.

20121120-blog-survey-thumb.png 3 Comments   Read more

A Survey of JavaScript Timers on Mobile

It wasn’t too long ago that web developers were struggling with poor implementations of JavaScript timers in desktop browsers. John Resig’s survey of desktop browser timers at the end of 2007 showed serious problems with timer resolution and/or timer consistency on all tested browsers. The practical effect of this was that JavaScript animations could run at different rates in each browser, choke up when too many concurrent timers were active, and often display stutter and jerkiness. (For more background on how timer resolution affects the user experience (and why we need a special Animation timer), Nicholas Zakas blog post on JavaScript animation is quite helpful.)

Chrome 1.0 was the first to introduce a high resolution, deadly consistent JavaScript timer platform.”

Since then, JavaScript timers on desktop browsers have improved vastly. Chrome 1.0 was the first to introduce a high resolution, deadly consistent JavaScript timer. This was soon matched by other browsers, and as a result, web developers have become used to respectable performance from JavaScript animations in desktop browsers. The most recent version of every major browser except IE has a 4ms timer with very good consistency even as the number of concurrent timers gets larger than 100. Internet Explorer before Windows 7/IE9 used the low resolution system timer as its JavaScript timer – which gave a 15.6ms timer resolution. This changed in Windows 7, which now offers two different resolutions, the old 16ms timer when your device is in power-saving mode and a new 4/5ms timer when in normal mode. (This configuration can be changed in advanced power options.)

Chrome 20

Firefox 12

Figure 1: Chrome 20 and Firefox 12 have high resolution, scalable and consistent timer implementations

JavaScript Animation on Mobile

However, mobile browsers have been a different story. The conventional wisdom has been that JavaScript animations on mobile can suffer from stutter and synchronization problems. This is one of the reasons that CSS Transforms and Animations have become a popular way to perform mobile animations since content movement is performed in hardware by the GPU and gets the benefit of sub-pixel tweening. However, there hasn’t been much written about mobile timers, so we decided to do a semi-scientific study of timer performance by running John Resig’s timer test on 20 or so of our mobile test lab devices. The test animates a pixel using setInterval() at 0ms timeout at various levels of concurrency and call stack depth. We tested devices running iOS3 through iOS5 on iPhones, iPads and iPods, Android 2.2 through 4.1 on Samsung, LG, HTC, Huawei and Motorola devices, as well as the RIM Playbook 1 and 2. Here’s what we found:

Timer Resolutions

Most mobile devices we tested had timers set at 10ms resolution. This was the case for the vast majority of Android devices, as well as devices running iOS3 and iOS4. Chrome for Android and iOS5 had faster timers: their timer resolution was 4ms. And the Blackberry Playbook 2 had the slowest timer: approximately 17ms. One outlier for the Android browser was the Motorola Droid 2 Global which had a timer resolution of 16ms. Finally, when we ran the timer test on our “straight-from-Google-IO” Nexus 7 tablet running Android 4.1 and Chrome for Android, we got an odd result which showed the timer whipsawing from 4ms to 10ms. (This may due to some webkit behavior that backs the timer off to 10ms, if it’s already processing a timer callback, but would love to see if anyone from the Chrome team has insight on this.)

In other words, the most recent devices running Android 4, Chrome for Android and iOS5 have desktop-class timer resolutions, while older Androids and RIM devices have timers that are 2x to 4x coarser grained.

Timer Consistency and Scalability

Next we looked at the variability of the timer measurements at various levels of timer concurrency and stack depth. The ideal performance result is a horizontal line at the y coordinate of the timer resolution—whatever that is. Here the results were a little varied.

Our star performers were the iPhone and iPad2 (below left), as well as the Motorola Xoom running the stock Android ICS browser (below right). Each were highly consistent at their respective timer resolutions of 4ms and 10ms, with no deterioration as the number of timers increased, and just one or two spikes. Other notable performers were Chrome for Android on the Motorola Xoom and one of our Samsung Android 2.3 devices.

iPad2 running iOS5

Motorola Xoom running Android ICS

More typical, however was a drift of anywhere from -5ms to +10ms around the expected timer resolution, particularly when the number of concurrent timers exceeded 8. This was true across all Android handset makers and all versions of Android 2. The typical result from an Android 2.x device looked something the example below—in this case, a Samsung phone running Android 2.3.5.


A Samsung phone running Android Gingerbread


Finally our worst performing devices. Surprisingly, one of these was from Apple. While all our iPods had noisy performance graphs, our iPod/iOS5 was particularly poor—with a few spikes that were literally off the chart. We also found the Playbook 2 timer to be extremely noisy, regularly spiking to 2x the 18ms timer resolution.

iPod running iOS5

Blackberry Playbook running Blackberry OS

Lessons learned and conclusions drawn

Our survey of mobile timers shows mostly good news. The most recent mobile browsers on Android—both stock Android and Chrome for Android now have desktop quality timers. Surprisingly, it doesn’t look like Apple is taking particular care to achieve good performance on the iPod browser. For highest performance on iOS, this probably means it’s best to stick with GPU-accelerated 3D transforms for the moment. It also reiterates the need for wide adoption of the work-in-progress animation timing spec.

20120712_survey-javascript-timers.png 1 Comment   Read more

HTML5 Scorecard: Chrome for Android Beta

Sencha HTML5 Developer Scorecard of Chrome for Android beta

Chrome for Android icon As part of our continuing series on the HTML5 capabilities of new mobile platforms, today we’re taking a look at the new Chrome for Android mobile browser beta. There have been rumors of Chrome for Android for quite some time, and we were encouraged but a little underwhelmed by the stock Android 4 browser. We were hoping that there was more to come.

And we didn’t have to wait long. After testing Chrome for Android, we’re happy to say that it’s a very solid HTML5 browser, and even in its beta form, is a “must-install” for any Android 4 owner. Hopefully Chrome for Android quickly becomes the *only* browser for Android 4.

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

h3. Our First-Look “Methodology”

Our HTML5 scorecard consists of a series of tests aimed to help mobile web developers understand new devices and new form factors as they come to market. We test in a number of areas, namely JavaScript performance, HTML5/CSS3 features, rendering performance and rendering accuracy. To get there, we use a variety of tests, including Modernizer, Acid3, SunSpider, Sencha Animator demos and our Sencha Touch Kitchen Sink.

h3. Acid3 and Modernizr

Chrome for Android scores a perfect 100/100 on the Acid3 test, just like the Android 4 browser. However, the tell tale rendering artifact (a very faint red/pink box in the upper right corner) that has marred a perfect score on other Android browsers, once again rears its head. (Chrome Desktop doesn’t have this artifact, so perhaps this is an OS/graphics stack issue rather than a browser problem). In practice, this won’t impact web browsing or web development much, but it would be nice to fix this for the final release.

Next up, Modernizr! Once again, we used haz.io which is a clean and mobile friendly Modernizr checker. The verdict? High marks on HTML5 support — as one might expect from the folks who brought you Chrome. Once again, the browser does have @font-face support — Google Fonts display perfectly — but TypeKit does not yet detect Chrome for Android correctly. As with the original Playbook, and Android 4 stock browser support, Typekit has a lag between first ship and support, but I’m sure the Typekit folks are on top of this.

Compared to the stock Android 4 browser, there is a substantial number of additional HTML5 features: Web Workers, Web Sockets, HTML5 Input Types, overflow: scroll, requestAnimationFrame and more. That’s not to say that Chrome for Android has absolutely everything. As detected by the other handy testing site for HTML5, many newer features are absent, notably Shared Workers and WebGL. The video codec cold war also continues: Ogg Theora and Ogg Vorbis support is still not there — which is not a surprise.


Chrome for Android running on a tablet and phone

Chrome for Android running on a tablet and phone

h3. Performance

For performance benchmarking, we use SunSpider. In the last 9 months, all the mobile browsers have converged at basically the same SunSpider performance levels. This also holds true for Chrome for Android. Although it’s slightly faster on one or two tests vs. Android 4 browser, it’s in the same general ballpark, which is not too surprising since they’re both using the V8 engine on the same hardware. Since Chrome for Android is visually much faster and smoother than the Android stock browser, this is probably a good time to consider putting SunSpider on the shelf as a good predictor of user-perceived performance.

h3. Real World Tests

As we’ve said many times previously, many mobile browsers do well on the checkbox tests like Modernizr, but fall short when it comes to real world applications and content. (In some cases, mobile browsers have even reported support when none exists.) So for real world testing, we use a collection of our own favorite HTML5 sites and demos.

First up, the new CSS properties for mobile content. On our HTML5 wish list for 2011 we asked for high performance position: fixed. And Chrome for Android delivers. For simple pages, Chrome for Android does a top notch job of glueing fixed position content to the screen. Fixed headers and footers for simple mobile optimized pages are now easily implemented without having to use a framework. However, the browser struggled when trying to maintain fixed positioning on more complex pages, particularly when combined with pinch/zoom. We saw poor frame rates and occasionally content disappeared or was misplaced. Happily, the *very new* @-webkit-overflow-scrolling: touch@ property, which debuted in iOS 5, is also now available in Chrome for Android. It’s smooth and fast. (Nice job Chrome team!)

On to SVG. On Chrome mobile, basic SVG worked very nicely. Our Raphael vector demos were very smooth, and many other SVG effects like text on a path, and animated gradients worked smoothly at a good frame rate. For more advanced effects (demos at David Dailey’s page), there’s still work to be done: SVG effects like complex filtering were either not supported or ran at low frame rates. Since there is little popular content that relies on these advanced effects yet, this is not such a big deal. However, when CSS Filters start to percolate into general usage, getting these right will become more important.

We next tried Canvas and here Chrome for Android has a good implementation. Basic Canvas drawing is unproblematic, and our favorite Canvas stressor — Canvas Color Cycling was smooth and high performance even under pinch/zoom. The most complex demos we could find (that can cause even desktops to pause), such as the demos at Mr. Doob did cause some problems — with long wait times and occasional complete display failures.

Our testing of embedded HTML5 audio and video went well. Plain inline HTML5 video works, (although don’t try to combine it with other effects or Canvas). This is an area where Chrome Beta has the advantage over iOS 5 which still lacks inline video playback.

Finally, we took a look at CSS3 Animations & Transforms. This is an area that we’ve invested in here at Sencha with Sencha Animator. Poor Android performance on 3D transforms has been a limitation on the complexity of CSS animations that can deploy cross platform. Our most complex animation — our Sencha Animator KickFu game — was playable, but the frame rate was too low for a smooth experience — I’d estimate a 5-10 frames per second performance. More basic CSS3 animations — even 3D ones — worked well, although we did uncover our first official bug for the Chrome team which we will be filing — transformed elements seem to drop border-radius. In addition, there are a few layout quirks that are present in desktop Chrome for transformed elements that also show up in Mobile Chrome.

h3. Sencha Touch 1.0 Kitchen Sink

Although we’re in late beta with Sencha Touch 2, we decided to test Sencha Touch 1.1 instead. Compared to Android 4, the Chrome for Android experience is vastly improved. Full-screen flashes and screen flicker are absent. Other things that we take for granted such as smooth border radii, masking etc. are also well implemented. But it’s also true that some of the browser properties that we rely on for layout in Android are now different in Chrome Beta and these result in minor artifacts in layout and list scrolling that we’ll need to be address.

h3. Chrome for Android beta: tips for the HTML5 developer

Chrome for Android is a big leap forward for web browsing on Android devices — even in its beta form. We suspect that many of the browser limitations are limitations more of the device processors than the browser itself. There is still work to be done before general release, but in all we’re very happy to have a top notch browser for Android. If you own an Android 4, there is no question you should download and use Chrome for Android as your primary browser as soon as you are able.

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

Android–Ice Cream Sandwich: The HTML5 Developer Scorecard

Samsung Galaxy Nexus

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

As part of our continuing series on the HTML5 capabilities of new mobile platforms, today we’re taking a look at the Samsung Galaxy Nexus, the first device to ship with Android 4.0, aka Ice Cream Sandwich. We’ve been hearing rumors over the last few months about the “involvement”:http://androidandme.com/2011/10/news/google-chrome-is-finally-coming-to-an-android-device-near-you/ of the Chrome team in Android 4, so we had our hopes up that the browser would be a major step forward. In the past, we’ve reviewed Android 2.x (Gingerbread) devices, like the “Galaxy Tab”:http://www.sencha.com/blog/samsung-galaxy-android-tablet-the-html5-developer-scorecard/ and Android 3 (Honeycomb) devices, and the “Motorola Xoom”:http://www.sencha.com/blog/motorola-xoom-the-html5-developer-scorecard/ –and have been disappointed by the performance and correctness of the browsers.

Ice Cream Sandwich is a major step forward for the Android Browser, but still falls short of iOS 5.”

After putting the Galaxy Nexus through our test wringer, we can say that Ice Cream Sandwich is a major step for the Android browser. However, it still falls short of iOS 5. It’s a solid browser for normal page browsing and it adds major new features that support most of the HTML5 spec. It also has taken a big step forward in correctness of rendering, which is a welcome change for people who want to push their mobile browsers to the limit.

h3. Our First-Look “Methodology”

Our HTML5 scorecard consists of a series of tests aimed to help mobile web developers understand new devices and new form factors as they come to market. We test in a number of areas, namely JavaScript performance, HTML5/CSS3 features, rendering performance and rendering accuracy. To get there, we use a variety of tests, including Modernizer, Acid3, SunSpider, Sencha Animator demos and our Sencha Touch Kitchen Sink.

h3. Acid3 and Modernizr

The Galaxy Nexus scores a perfect 100/100 on the Acid3 test, just like Android 3. However, a close look at the Acid3 results reveals that there are still rendering artifacts. In the top right of the test image there is a telltale faint red/pink box which should not be there, since Acid3 requires pixel-for-pixel of the reference image. In practice, this won’t impact web browsing or web development much, but it’s a bit of fit-and-finish that “we’re not quite there yet” on Android.

We then turned to Modernizr, one of our favorite tools to look under the hood of a browser. This time, we used the implementation of Modernizr on haz.io which provides a clean and easy way to look at Modernizer results. The verdict? Ice Cream Sandwich offers very good HTML5 support! Font-face, geo-location, and full support for the CSS3 suite. Support for the various CSS3 effects is probably what we’re most excited about: animations, reflections, 2D and 3D transformations, as well as transitions are all supported. For web developers, you can finally rely on HTML5 in Android 4.0 to build rich user interfaces. We do note that with @font-face support, the device does in fact support it, but TypeKit does not yet detect it correctly. As with Playbook support, Typekit usually has a lag between first ship and support, so don’t be discouraged just because your TypeKit web fonts don’t work yet.

With all the good news, there were features missing. Things of note that were absent from Ice Cream Sandwich were Web Workers, Web Sockets (so no real-time web on Android just yet), weak support for the new Input Types (like datetime or range), and WebGL. SVG was fully supported. We also decided do a head-to-head between iOS 5 and Android 4 on HTML5 support, and extracted some notable differences between the two platforms. This list isn’t comprehensive, but it shows some gotchas for web devs. Developers should use this guide to decide which APIs to take advantage of on a specific platform, or if they want to stick to the common set.

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

h3. Performance Testing

When checking the user agent received, web servers report that our Galaxy Nexus was using WebKit version 534.40, which is a very modern and up-to-date WebKit. Under the hood, according to the BoyGeniusReport, the Galaxy Nexus contains a dual-core ARM processor, specifically the TI OMAP 4460, which is in the same family (Cortex-A9) as BlackBerry PlayBook and the Kindle Fire. We therefore expected SunSpider scores in the same range as other tablets. As we’ve mentioned before, this current generation of tablets all ship with dual-core processors and all have roughly the same JavaScript optimizations. So the results are again fairly predictable and look like other devices we’ve tested in this generation of hardware.

Galaxy Nexus SunSpider results

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

The SunSpider tests are synthetic tests that push the JavaScript engine to its limit. So, next we turned our attention to some more real world tests, looking at CSS3 performance using our own Sencha Animator demos as well as a few other tests.

Like we tried with the Kindle Fire, we threw caution to the wind and started off on our most challenging CSS3 animation test, the Kick Fu game that was developed for the launch of Sencha Animator. To our surprise, the game didn’t even start. We were a bit flummoxed by this given the fact that the whole CSS3 animation suite is supported in ICS. It’s unclear to us at the moment why this occurs. Our running theory is that the JavaScript game controls might be at fault, but it’s a wild guess at this point.

We ran through the rest of our Sencha Animator demos, some of which are very complex but are all JavaScript free, and were pleasantly surprised to see them all work beautifully. We haven’t seen an Android device run these demos well to date, and Ice Cream Sandwich shines here. For developers who want to use CSS3 2D, 3D, animations, and transitions, we’re happy to report that support on Ice Cream Sandwich is now near parity with other leading platforms.

We also tested a few other real world areas for performance and correctness. We tried a Canvas based GitHub network graph. Rendering performance was fine and the result was accurate. Pinch/zoom also worked well and didn’t exhibit the low-quality mode toggling, we’ve found in earlier Androids. The resolution and dithering of the page stayed constant as we zoomed and moved around the page. We also tried out Canvas Cycle and it worked reasonably well. The frame rate was solid but it rendered to a very very small part of the screen, most likely due to the very high resolution of the Galaxy Nexus. When we zoomed in, the device managed to keep up reasonably well. The FPS easily dropped by half and audio was never dropped, and the FPS recovered when we zoomed out to the page’s natural size. Very impressive improvement over earlier Androids.

Finally we tested embedded HTML5 audio and video. In one word: finally. We used the test player on html5video.org, which gives you a video tag inline to the page. The Galaxy Nexus is the first phone we’ve seen that actually plays the video inline! iOS 5 on iPad and the iPhone do not play video inline, and we were impressed to see it work very well on Android 4. The video not only plays, but plays inline to the page. This is a big deal for web developers looking to use Video to enhance their web experience.

The Galaxy Nexus is a big step forward for developers looking to leverage HTML5 on Android.”

h3. Sencha Touch Kitchen Sink

Our Kitchen Sink app is built with Sencha Touch and tests all aspects of our mobile web app framework. The Kitchen Sink gives mobile browsers a good workout as it exercises a huge set of browser features including a wide range of CSS3 effects.

Right off the bat, it’s obvious that the device is more HTML5-friendly than any other Android when using the Kitchen Sink. Rounded corners look beautiful (not pixelated as in earlier Androids), icon mask work correctly, multi-touch is supported and scrolling is substantially improved. It’s not all perfect though: full-screen white flashes were still noticeable when scrolling, even if greatly reduced from the seizure-inducing levels in Honeycomb. Page transitions also occasionally caused the browser to “blink” as it re-renders. Re-renders are most notable when scrolling a page that’s been fully laid out. When starting a scull, the page does a white screen-flash, then begins to scroll fluidly. Our best guess is that the browser is dumping the rendered page to the GPU to use hardware accelerated scrolling, and the blink occurs during that transition. Our guess is the CPU->GPU texture transition is the main culprit here.

Sencha Touch supports 3D transitions, specifically Flip and Cube, and they now work on Android for the first time, although screen-flashes are again a problem artifact. The other big issue we found is that address-bar hiding has changed between Android 3 and 4. This will impact web developers widely. In an single page app, like our Sencha Touch Kitchen Sink, it’s hard to get a hidden address bar to re-appear. On older Androids, pulling the whole page down would side the address bar back and push the page down with it. In ICS, this doesn’t happen reliably, and instead of adjusting the page geometry it actually overlays the address bar on top of the page content. This is not a deal breaker, but a definite change of behavior that developers should watch for.

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

HTML5 logo In summary, the Galaxy Nexus and Ice Cream Sandwich are a major step forward for the Android platform. Feature by feature, HTML5 support has gotten much better, rendering has become more accurate, and performance has gotten much faster. Although still behind the current HTML5 gold standard of iOS5, Android 4.0 is night and day compared to previous versions. We’re excited to see Google put this level of effort into Android’s web capabilities. And we hope they keep their foot on the gas! (And we’re keeping our fingers crossed that the Kindle Fire will get an upgrade to ICS in the New Year!)

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

The Sencha Hackathon Recap

The Sencha Hackathon Recap There are hackthons. And then there is the SenchaCon hackathon.

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

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

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


Hackathon hackers.
Arthur Kay

Hackathon hackers. Photos by Nils Dehl.

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

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

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


Hackathon hackers.
Andrea Cammarata

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

Best use of an HTML5 API: Lamp Post

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

Best Desktop App: Code Cowboys

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

Best Mobile / Tablet App: Presencha

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

The “Presencha”:http://www.presencha.com/ team have made their code available on “GitHub”:https://github.com/cianclarke/Presencha, and are aiming to have their service available soon.

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

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

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

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

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

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

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

senchacon-hackathon.jpg No Comments   Read more

The Sencha Hackathon Recap

There are hackthons. And then there is the SenchaCon hackathon.

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

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

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

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

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

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

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

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

Best Desktop App: Code Cowboys
A crowd-sourced unit testing application for Ext JS and Sencha Touch. The team won an iPad 2 and $500.

Best Mobile / Tablet App: Presencha
Upload slides in PDF form, and present live to any device for collaborative viewing by an audience. The team won an iPad 2 and $500.

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

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

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

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

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

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

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

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

No Comments   Read more