Mobile Articles

This past March, some of the most creative web developers out there showed us what they could do for the mobile Web in the March Dev Derby contest. After looking through the entries, our our three expert judges–Craig Cook, Franck Lecollinet, and Guillaume Lecollinet–decided on three winners and two runners-up.

Not a contestant? There are other reasons to be excited. Most importantly, all of these demos are completely open-source, making them wonderful lessons in the exciting mobile experiences you can create today using only the skills you already have.

The Results

Winners

• First place: Memory Cube by sophomore Jesus Perez
• Second place: Writerrific by designer and developer Laurens Debackere
• Third place: Loc Tag by newcomer bzub

Runners-up

• Paint my dash by mobile Web lover Giovanny Andrés Góngora Granada
• Ubercalc by the always impressive JoanC

The March Derby saw some great entries, from games to productivity applications to wonderfully useful location-based services and more. Please join me in congratulating these winners and all of our contributors for making the wireless world a better and more exciting place.

Want to get a head start on an upcoming Derby? We are now accepting demos related to getUserMedia (May) and WebGL (June). Head over to the Dev Derby to get started.

One common aspect of making a website or application “mobile friendly” is the inclusion of tweaks, additional functionality or interface elements that are particularly aimed at touchscreens. A very common question from developers is now “How can I detect a touch-capable device?”

Feature detection for touch

Although there used to be a few incompatibilities and proprietary solutions in the past (such as Mozilla’s experimental, vendor-prefixed event model), almost all browsers now implement the same Touch Events model (based on a solution first introduced by Apple for iOS Safari, which subsequently was adopted by other browsers and retrospectively turned into a W3C draft specification).

As a result, being able to programmatically detect whether or not a particular browser supports touch interactions involves a very simple feature detection:

if ('ontouchstart' in window) {
  /* browser with Touch Events
     running on touch-capable device */
}

This snippet works reliably in modern browser, but older versions notoriously had a few quirks and inconsistencies which required jumping through various different detection strategy hoops. If your application is targetting these older browsers, I’d recommend having a look at Modernizr – and in particular its various touch test approaches – which smooths over most of these issues.

I noted above that “almost all browsers” support this touch event model. The big exception here is Internet Explorer. While up to IE9 there was no support for any low-level touch interaction, IE10 introduced support for Microsoft’s own Pointer Events. This event model – which has since been submitted for W3C standardisation – unifies “pointer” devices (mouse, stylus, touch, etc) under a single new class of events. As this model does not, by design, include any separate ‘touch’, the feature detection for ontouchstart will naturally not work. The suggested method of detecting if a browser using Pointer Events is running on a touch-enabled device instead involves checking for the existence and return value of navigator.maxTouchPoints (note that Microsoft’s Pointer Events are currently still vendor-prefixed, so in practice we’ll be looking for navigator.msMaxTouchPoints). If the property exists and returns a value greater than 0, we have touch support.

if (navigator.msMaxTouchPoints > 0) {
  /* IE with pointer events running
     on touch-capable device */
}

Adding this to our previous feature detect – and also including the non-vendor-prefixed version of the Pointer Events one for future compatibility – we get a still reasonably compact code snippet:

if (('ontouchstart' in window) ||
     (navigator.maxTouchPoints > 0) ||
     (navigator.msMaxTouchPoints > 0)) {
      /* browser with either Touch Events of Pointer Events
         running on touch-capable device */
}

How touch detection is used

Now, there are already quite a few commonly-used techniques for “touch optimisation” which take advantage of these sorts of feature detects. The most common use cases for detecting touch is to increase the responsiveness of an interface for touch users.

When using a touchscreen interface, browsers introduce an artificial delay (in the range of about 300ms) between a touch action – such as tapping a link or a button – and the time the actual click event is being fired.

More specifically, in browsers that support Touch Events the delay happens between touchend and the simulated mouse events that these browser also fire for compatibility with mouse-centric scripts:

touchstart > [touchmove]+ > touchend > delay > mousemove > mousedown > mouseup > click

See the event listener test page to see the order in which events are being fired, code available on GitHub.

This delay has been introduced to allow users to double-tap (for instance, to zoom in/out of a page) without accidentally activating any page elements.

<meta name="viewport" value="... user-scalable = no ...">

Although this affordance is clearly necessary, it can make a web app feel slightly laggy and unresponsive. One common trick has been to check for touch support and, if present, react directly to a touch event (either touchstart – as soon as the user touches the screen – or touchend – after the user has lifted their finger) instead of the traditional click:

/* if touch supported, listen to 'touchend', otherwise 'click' */
var clickEvent = ('ontouchstart' in window ? 'touchend' : 'click');
blah.addEventListener(clickEvent, function() { ... });

Although this type of optimisation is now widely used, it is based on a logical fallacy which is now starting to become more apparent.

/* suppress default touch action like double-tap zoom */
a, button {
  -ms-touch-action: none;
      touch-action: none;
}

False assumptions

It’s important to note that these types of optimisations based on the availability of touch have a fundamental flaw: they make assumptions about user behavior based on device capabilities. More explicitly, the example above assumes that because a device is capable of touch input, a user will in fact use touch as the only way to interact with it.

This assumption probably held some truth a few years back, when the only devices that featured touch input were the classic “mobile” and “tablet”. Here, touchscreens were the only input method available. In recent months, though, we’ve seen a whole new class of devices which feature both a traditional laptop/desktop form factor (including a mouse, trackpad, keyboard) and a touchscreen, such as the various Windows 8 machines or Google’s Chromebook Pixel.

The implications of this change are slowly beginning to dawn on developers: that touch support does not necessarily mean “mobile” anymore, and more importantly that even if touch is available, it may not be the primary or exclusive input method that a user chooses. In fact, a user may even transition between any of their available input methods in the course of their interaction.

The innocent code snippets above can have quite annoying consequences on this new class of devices. In browsers that use Touch Events:

var clickEvent = ('ontouchstart' in window ? 'touchend' : 'click');

is basically saying “if the device support touch, only listen to touchend and not click” – which, on a multi-input device, immediately shuts out any interaction via mouse, trackpad or keyboard.

Touch or mouse?

So what’s the solution to this new conundrum of touch-capable devices that may also have other input methods? While some developers have started to look at complementing a touch feature detection with additional user agent sniffing, I believe that the answer – as in so many other cases in web development – is to accept that we can’t fully detect or control how our users will interact with our web sites and applications, and to be input-agnostic. Instead of making assumptions, our code should cater for all eventualities. Specifically, instead of making the decision about whether to react to click or touchend/touchstart mutually exclusive, these should all be taken into consideration as complementary.

Certainly, this may involve a bit more code, but the end result will be that our application will work for the largest number of users. One approach, already familiar to developers who’ve strived to make their mouse-specific interfaces also work for keyboard users, would be to simply “double up” your event listeners (while taking care to prevent the functionality from firing twice by stopping the simulated mouse events that are fired following the touch events):

blah.addEventListener('touchend', function(e) {
  /* prevent delay and simulated mouse events */
  e.preventDefault();
  someFunction()
});
blah.addEventListener('click', someFunction);

If this isn’t DRY enough for you, there are of course fancier approaches, such as only defining your functions for click and then bypassing the dreaded delay by explicitly firing that handler:

blah.addEventListener('touchend', function(e) {
  /* prevent delay and simulated mouse events */
  e.preventDefault();
  /* trigger the actual behavior we bound to the 'click' event */
  e.target.click();
})
blah.addEventListener('click', function() {
  /* actual functionality */
});

That last snippet does not cover all possible scenarios though. For a more robust implementation of the same principle, see the FastClick script from FT labs.

Being input-agnostic

Of course, battling with delay on touch devices is not the only reason why developers want to check for touch capabilities. Current discussions – such as this issue in Modernizr about detecting a mouse user – now revolve around offering completely different interfaces to touch users, compared to mouse or keyboard, and whether or not a particular browser/device supports things like hovering. And even beyond JavaScript, similar concepts (pointer and hover media features) are being proposed for Media Queries Level 4. But the principle is still the same: as there are now common multi-input devices, it’s not straightforward (and in many cases, impossible) anymore to determine if a user is on a device that exclusively supports touch.

The more generic approach taken in Microsoft’s Pointer Events specification – which is already being scheduled for implementation in other browser such as Chrome – is a step in the right direction (though it still requires extra handling for keyboard users). In the meantime, developers should be careful not to draw the wrong conclusions from touch support detection and avoid unwittingly locking out a growing number of potential multi-input users.

Further links

• The Good & Bad of Level 4 Media Queries
• Handling Multi-touch and Mouse Input in All Browsers
• Hand.js: a polyfill for supporting pointer events on every browser
• Touch And Mouse – Together Again For The First Time
• Prototype Chromium build with support for MS Pointer Events
• Webseiten zum Anfassen (in German)
• Generalized Input On The Cross-Device Web

If you’ve wanted to contribute to Gaia, or have been writing a webapp for Firefox OS, one of the pain points you probably ran into, when using either B2G desktop or testing on a device, is the lack of developer tools to inspect and debug your HTML, CSS and JavaScript.

Currently we have two tracking bugs, go ahead an vote on them to bump their priority, to track the work going into developing a native remote inspector and style editor for Firefox OS but, I have some pretty exciting news. You can have access to a remote debugger today.

And how is this possible I hear you ask? Well, one word: Weinre. Weinre is a project of the Apache Foundation and stands for WEb INspector REmote and is exactly what it’s name suggests, a tool in the same vein as Firebug or Webinspector but, able to run and debug web pages remotely. So, if you have used tools such as the Firefox Developer Tools or Chrome Dev Tools, using Weinre will be second nature. But enough talk, let’s get this up and running.

Setting Up Weinre

As Weinre runs on top of Node.js your first port of call would be to install Node.js. Node.js comes with NPM (Node Package Manager) bundled nowadays and this is then then what we are going to use to install Weinre. From a terminal run the following:

npm -g install weinre

NOTE: The -g flag is used to install Weinre as a global Node.js module for command line goodness but, on Linux and Mac, this means you most likely are going to need to run the above by prepending sudo to the above command.

Once the installation process is complete, we are ready to use Weinre to debug. But first, let’s make absolutely sure that Weinre was indeed installed successfully. In your terminal, run the following:

$ weinre --boundHost 127.0.0.1 --httpPort 9090
2013-01-28T10:42:40.498Z weinre: starting server at http://127.0.0.1:9090

If you see a line similar to the last line above, your installation was a success and the Weinre server us up and running. With that, fire up a browser (NOTE: The UI for Weinre is built specifically for Webkit based browsers so, while it might work to some degree in other browsers, I would suggest you use Chrome) and point it to http://127.0.0.1:9090

Above then is the landing page for the Weinre server giving you access to the documentation, some other trinkets, as well as the Weinre client, the page we really want to head to so, go ahead and click on the debug client link.

From the above you can see that we have one connected client, this is the current instance of the web inspector, some general properties of our server but, no targets. Let’s get our target set-up.

NOTE: If the UI of winery looks very familiar that’s because Winery uses the same UI code as the web inspector in Chrome and Safari.

Setting Up A Weinre Target

In Weinre targets are the web pages or apps that you want to debug, and in order for the target to be able to connect, we need to add a one liner to the relevant file of our app. For this post, let’s inspect the Calendar app. Go ahead and open up gaia -> apps -> calendar -> index.html and scroll right to the bottom. Just before the closing body tag, insert the following line:

<script src="http://127.0.0.1:9090/target/target-script-min.js#anonymous"></script>

Before we can launch B2G Desktop and try this out however, there is one more step. Gaia uses a Content Security Policy and as part of that scripts are said to only be allowed to load, if from the same origin as the application. So, if we were to try and load the Calendar now, the script from above would be blocked as it is not being loaded from the specified origin.

To overcome this, we need to temporarily disable CSP. To do this, open up gaia -> build -> preferences.js and add the following line, around line 24:

prefs.push(["security.csp.enable", false]);

Debugging Using Weinre and B2G Desktop

Now we are ready to test Weinre. If you are not already inside the Gaia root directory, change into it now and execute:

DEBUG=1 make

Once the profile is built, launch B2G desktop:

/Applications/B2G.app/Contents/MacOS/b2g-bin -profile /Users/username/mozilla/projects/gaia/profile

Once B2G launches, unlock the screen, swipe two screens to the right and click on the Calendar icon to launch the Calendar app. Once the app launches, you will see a new item appear on Weinre’s client dashboard:

As you can see, the Calendar has successfully connected and is now listed as one of our targets. Go ahead and click on the ‘Elements’ tab.

Listed here is the HTML of our app on the left and our CSS on the right! You can go right ahead and edit either the HTML or the CSS as you normally would and see the changes reflect live. Note that even though the CSS looks grayed out and disabled, it if fully editable. You can also add completely new styles to the current element using the empty element.style block or amending existing rules. You will also notice you have access to the computed styles as well as metrics of the current element.

Working With The Console

The next tab of interest to us is the Console tab. Here you can code away and run any JavaScript you want directly against the current app or execute code exposed by the app. To see how this works, let’s interact with the call log portion of the Dialer.

First step then is to move our script import from Calendar to Dialer. Grab the code from Calendar and then open up gaia -> apps – > communication -> dialer -> index.html and paste the code. Next rebuild your profile using ‘make’ and finally relaunch B2G desktop.

Once it is launched again, click on the Dialer icon at the bottom left of the home screen. Once loaded, confirm that the communication channels are open to Weinre by opening http://127.0.0.1:9090/client/#anonymous and confirming that the target now looks as follows:

127.0.0.1 [channel: t-7 id: anonymous] - app://communications.gaiamobile.org/dialer/index.html#keyboard-view

With the dialer open, click on the call log icon, bottom left. Currently the call log is already populated with some dummy data but, let’s create our own. Click over to the Console tab in Weinre, type the following and press enter.

RecentsDBManager.deleteAll();

If you look at the view on desktop now, it would seem that nothing has happened but wait, there is more. Type in the following and press enter:

Recents.refresh();

Aha! As you can see, our call log is empty. Next step then, is to add an entry back. To do this, we will create a dummy call entry Object and then pass this to the add function of the RecentsDBManager to store it:

// Dummy entry
var recentCall = {
    type: 'incoming-refused',
    number: '555-6677',
    date: new Date()
};
RecentsDBManager.add(recentCall);
Recents.refresh();

And as you can see now, the entry we just created has been added to storage, IndexedDB to be exact, and is visible in the call log view. As you might very well have noticed, another of the great features that comes with the console is auto-complete which will further speed up development.

The combination of features that this exposes already opens new doors and will make working on Firefox OS, or writing apps for the OS, much easier with less time spent between building profiles, tearing down and relaunching B2G. Which all makes for happier developers.

But hey wait a second, what about debugging on the device? This will work exactly the same as the above with one small difference, the IP. When you want to debug on the device you first need to know the IP address of your host computer. Then you need to start up Weinre using this IP as the buondHost and also as the IP when including the script into you target documents.

On Mac and Linux you can get this address using ifconfig and on Windows it is ipconfig. Once you have the new IP, just stop the current instance of Weinre and then do the following:

weinre --boundHost 192.168.1.1 --httpPort 9090

Then inside you target document add:

<script src="http://192.168.1.1:9090/target/target-script-min.js#anonymous"></script>

Make and push your Gaia profile to the device using:

make install-gaia

Launch your target app and you are in business!

Conclusion

While this solution is not perfect, you need to remember to undo your changes before committing anything to source control, having to manually add the script every time is not ideal and then there are also some things that do not work 100%, such as, highlighting DOM elements as you hover over the HTML source and debugging JavaScript with breakpoints and such, this does go a long way towards improving the lives of developers both working directly on Gaia as well as those writing exciting new apps for Firefox OS.

But there is already some light at the end of the tunnel with regards to managing the injection of the script manually, disabling CSP and ensuring things are cleaned up before pushing to source control. Jan Jongboom has opened a pull request against the Gaia repo that looks extremely promising and will alleviate a lot of this so, go on and give him a hand and let’s get this merged into Gaia. Happy Hacking!

An important note: None of the above would have happened if it was not for Kevin Grandon who remembered using Weinre and sent out the email that set the ball rolling. Thanks Kevin!

Firefox for Android has expanded its HTML5 video capabilities to include H.264 video playback. Web developers have been using Adobe Flash to play H.264 video on Firefox for Android, but Adobe no longer supports Flash for Android. Mozilla needed a new solution, so Firefox now uses Android’s “Stagefright” library to access hardware video decoders. The challenges posed by H.264 patents and royalties have been documented elsewhere.

Supported devices

Firefox currently supports H.264 playback on any device running Android 4.1 (Jelly Bean) and any Samsung device running Android 4.0 (Ice Cream Sandwich). We have temporarily blocked non-Samsung devices running Ice Cream Sandwich until we can fix or workaround some bugs. Support for Gingerbread and Honeycomb devices is planned for a later release (Bug 787228).

To test whether Firefox supports H.264 on your device, try playing this “Big Buck Bunny” video.

Testing H.264

If your device is not supported yet, you can manually enable H.264 for testing. Enter about:config in Firefox for Android’s address bar, then search for “stagefright”. Toggle the “stagefright.force-enabled” preference to true. H.264 should work on most Ice Cream Sandwich devices, but Gingerbread and Honeycomb devices will probably crash.

If Firefox does not recognize your hardware decoder, it will use a safer (but slower) software decoder. Daring users can manually enable hardware decoding. Enter about:config as described above and search for “stagefright”. To force hardware video decoding, change the “media.stagefright.omxcodec.flags” preference to 16. The default value is 0, which will try the hardware decoder and fall back to the software decoder if there are problems (Bug 797225). The most likely problems you will encounter are videos with green lines or crashes.

Giving feedback/reporting bugs

If you find any video bugs, please file a bug report here so we can fix it! Please include your device model, Android OS version, the URL of the video, and any about:config preferences you have changed. Log files collected from aLogcat or adb logcat are also very helpful.

Today, Mozilla announced the Firefox Aurora Marketplace release. We’re hoping that Aurora users, our awesome early adopters, will go experience the Firefox Marketplace on their Android phones and let us know what they think.

Our goal is to collect as much real-life feedback as possible about the Marketplace’s design, usability, performance, reliability, and content. Feedback from early adopters helps us enhance the quality of the Marketplace before it is released to larger audiences.

The developers we’ve talked to so far are excited to be listed in the Firefox Marketplace when it opens. They’re creating great app experiences with the Web technologies they’ve already mastered. They’re getting timely and thoughtful critiques from our Marketplace app reviewers.

In addition to being a cool site, Firefox Marketplace also offers APIs for app submission, payments, and app discovery. Like everything Mozilla does, this ecosystem is always open — users have choices and developers have control over their content, functionality and distribution.

The Mozilla Developer Network (MDN) and the DevHub contain extensive documentation, FAQs and emulation tools to help you get started building your App.

We need your feedback, and we need your Apps! Get Firefox Aurora for Android, learn about the Marketplace, and post your Apps to the Firefox Marketplace.

keep rockin’ the free web,
-Bill

One of our principles in the Mozilla Manifesto states that the Internet ”is a global public resource that must remain open and accessible”. Our goal is to remove barriers that traditionally block participation, such as affordability, language and disability.

We have been working hard to bring Firefox for Android to everyone on the planet, including blind and visually impaired users. Firefox 15 for Android introduced preliminary screen reader support. In Firefox 17 we have come full circle, and now support Jelly Bean’s advanced accessibility features. To get these great features right away, download Firefox for Android from the Google Play store.

What are Accessibility Features?

Firefox is designed to meet the needs of the broadest population possible. Sometimes that is not enough. In the case of blind and visually impaired users, a conventional graphical interface with a touch screen is not usable. Assistive technologies such as screen readers exist to bridge that gap. They provide speech and audible feedback that represents the visual state of the application. They may also provide alternative interaction modes that make more sense for blind users. For example, a user could explore the visible items on a screen by moving their finger across the screen and have the screen reader tell them what is under their finger.

Accessible by Default

We believe that equal access requires Firefox for Android to be ready for any type of user once it is installed, with no extra setup steps or addons. When Firefox for Android launches for the first time on a blind user’s device, it should start talking and be responsive to the user’s input.
Firefox for Android is the first Android Web browser that integrates tightly with Android’s native accessibility framework and supports TalkBack, Android’s screen reader. This provides a consistent feel with the rest of the device, and the user’s specific screen reader configuration.

Under The Hood

Our Android accessibility solution leverages the same powerful accessibility engine we use on the desktop. This means that it is fast, and leads the industry in support of standards such as WAI-ARIA and HTML5.

Touch Exploration & Gestures

Android’s built-in accessibility features have been modernizing ever since Ice Cream Sandwich. Users can now explore the contents of the screen with the tip of their finger and have whatever is under their finger read out loud. Jelly Bean introduces “flick navigation”, a user could swipe left or right to navigate the contents of the screen in a linear fashion.
We have worked hard to support all of those features in Firefox for Android as well and stay apace with Android’s evolving Accessibility and offer a consistent user experience.

Quick Navigation

Web pages can be very big, complex, and contain a lot of content. When a screen reader user visits a large page it can be tiring and time consuming to step through every item on the page until they find what they are looking for. That is why we introduced Quick Navigation Keys. With the help of a physical keyboard or the Eyes-Free Keyboard, a user can press “k” repeatedly to step through all the hyperlinks on the page. Similar keys are available for headings, list items, various form fields, and more.
This type of feature is familiar to desktop screen reader users. But the Android screen reader does not have this kind of functionality, so we decided to implement ourselves.

Trying It Out

Accessibility on Jelly Bean is really easy to set up and play with. Go to System settings->Accessibility->TalkBack and enable it. Once TalkBack is enabled move your finger across the screen, you will hear audio feedback and speech telling you what your finger is resting on. Close your eyes and try to find different apps on the home screen. Are you getting the feel for it? If you want to sequentially step through items swipe your finger left or right quickly across the screen. If you want to activate an item (say, Firefox Beta?) double tap.

You already know everything you need to know about using Firefox with TalkBack. Launch it, explore the interface with your finger, swipe left and right, and double tab to activate items. This is a good opportunity to try out websites and applications you created and test to see how accessible they are. Could you manage with your eyes closed?

Here is a short video of Firefox Beta on a Nexus 7 working with TalkBack:

Conclusion

What we are most proud about in our accessibility story on Android is the invisibility of our solution. It integrates well, and it gets out of the way to allow blind users to enjoy the easy and fast mobile browsing experience that Firefox for Android provides.

It’s Thursday, which means it’s time for Mozilla’s Developer Engagement team to share some good links with you!

Continued…

A month ago we introduced the Debugger and other new developer tools introduced in Firefox 15. Our new Debugger lets you connect Firefox Desktop to Firefox on Android so that you can use your nice, roomy desktop monitor to troubleshoot JavaScript that is running on your mobile device. 95% of Android devices are running a Firefox-compatible version of the operating system (Android 2.2 and higher). Firefox won’t run on all of these devices, but there are certainly many millions of devices that you can pick up and begin remote debugging on.

We will now explain how to remote debug Firefox on your Android device. The following screencast also shows you how to setup and run the Remote Debugger:

Set up your desktop

First of all, make sure you’re running Firefox 15 at least. At the time of this article, Firefox 15 is in the beta channel.

Next, type about:config into the Firefox location bar so that you can change a setting in the browser. The browser will display a warning, but don’t worry… we’ll be careful.

In the search box at the top of about:config, type “remote-en“. The only setting that should match is “devtools.debugger.remote-enabled“. Set that to true by double clicking it.

Finally, restart your browser. After you do, you’ll spot “Remote Debugger” in the Web Developer menu (either in the main Firefox menu or in the Tools menu on Macs).

Set up your Firefox for Android

For this to work, you need to use Firefox 15 on your Android device as well, and you can get that by downloading Firefox Beta from the Google Play store.

Now, fire up Firefox Beta on your phone. As on Desktop, you’ll need to go to about:config to change settings. Search for “debugger” and

1. toggle devtools.debugger.force-local to false
2. toggle devtools.debugger.remote-enabled to true

To get the remote debugging server started, you’ll need to restart Firefox. Tap the home button to exit Firefox.

On a Galaxy Nexus running Jelly Bean you can force Firefox to restart by opening the task switcher and sliding the Firefox Beta task off to the right.

Extra note: if you’re uncomfortable with the idea of having your Firefox listening for connections on the network, you can leave force-local set to true and follow Mark Finkle’s instructions for getting remote debugging running over USB.

Find your IP address

Before we’ll be able to connect to the device, we need to know its IP address. To find the address of your phone:

1. open the Settings app
2. tap Wifi
3. tap the network that you are currently connected to

The display you’re presented with will include your IP address.

Make the connection

You’re now all set for remote debugging!

On your mobile device, browse to a page that you want to debug. Fire up the Remote Debugger on your desktop Firefox. The Remote Debugger appears as a new window and it will prompt you for the address to connect to. Replace “localhost” with the IP address of your phone. By default, the remote debugging server on your mobile device will be running on port 6000, so leave the “:6000″ there in the connection address.

You should see a dialog on your phone warning you about a new incoming connection. You should only accept connections that you start as otherwise someone might be trying to hijack your browser. In this case, we’ve started the connection, so go ahead and allow it.

Once you’ve connected successfully, you’ll be able to inspect the scripts loaded in the page, set breakpoints and so forth.

Let us know what you think!

Give it a try and let us know what you think of this feature and what more you’d like to see. You can respond in the comments below or email us on the dev-apps-firefox mailing list.

At Mozilla, we are dedicated to keep the web open and independent of a single company or technology. This means that users should have a choice of browsers and technology to use to go online and should not be blocked out because they can’t afford a certain device or are forbidden to change their browser.

In the world of mobile web development there is currently a massive debate going on about the need for support of various browsers seeing that the most successful phone systems both use the same browser engine. This is good, and we need this debate. It is not good though when developers block out users because they concentrate on targetting a browser. Sometimes this is not by choice of the developer – they are simply using tools that do that blocking for them and the usefulness of the tool outweighs the qualms developers have about that.

We are now planning to talk to library and tool developers and help them support more than one browser engine to prevent this. As a start of that process we wanted to get a glimpse of what people are using right now so we make sure we have the most impact when we help. This is why we started a quick online survey asking developers about their tools for mobile development.

We are happy to report that to date we have 480 answers and it is time to take a first stab at looking at the data.

We are very aware that this is *not* a scientifically clean research and should be taken with a grain of salt (we haven’t asked how many times people used the tools or how much of their work is building mobile apps) but it gives us a good first glimpse at what makes most sense for us to do.

So without further ado, here are the raw numbers as charts:

Platforms

Not many surprises there, iOS and Android are in the lead, quite a lot of people see the web as a must-have (but this is a survey called out by Mozilla…) and Blackberry and Windows Mobile are not that hight on people’s radar.

What platforms are you targeting with your apps – iOS
	focus 208 43% must have 168 35% supported 43 9% sometimes 24 5% not at all 36 8% People may select more than one checkbox, so percentages may add up to more than 100%.

What platforms are you targeting with your apps – Android
	focus 147 31% must have 183 38% supported 85 18% sometimes 33 7% not at all 31 6% People may select more than one checkbox, so percentages may add up to more than 100%.

What platforms are you targeting with your apps – Blackberry
	focus 5 1% must have 11 2% supported 83 17% sometimes 136 28% not at all 244 51% People may select more than one checkbox, so percentages may add up to more than 100%.

What platforms are you targeting with your apps – Web
	focus 306 64% must have 121 25% supported 26 5% sometimes 18 4% not at all 8 2% People may select more than one checkbox, so percentages may add up to more than 100%.

What platforms are you targeting with your apps – Windows phone
	focus 8 2% must have 36 8% supported 112 23% sometimes 137 29% not at all 186 39% People may select more than one checkbox, so percentages may add up to more than 100%.

Libraries

jQuery rules supreme but Sencha touch and Zepto also have their place. Interestingly enough a lot of answers discarded libraries completely and considered them an overhead that will cause damage in the future.

What libraries do you use to build mobile web apps/sites?
	jQuery 349 73% jQuery mobile 248 52% Zepto.js 90 19% JO 5 1% XUI.js 18 4% Sproutcore 7 1% Sencha touch 72 15% JQTouch 50 10% Mootools mobile 11 2% M project 1 0% Nimblekit 2 0% Lime.js 9 2% Wink 1 0% Uxebu Bikeshed 1 0% Other 126 26% People may select more than one checkbox, so percentages may add up to more than 100%.

Conversion frameworks

You do love your PhoneGap / Cordova, it seems. There is not too much competition in this market and a lot of feedback was questioning the sense of converting apps as “building them natively makes more sense”.

Which frameworks do you use to convert apps to native apps?
	PhoneGap 257 90% Appcellerator 45 16% MoSync 2 1% Other 31 11% People may select more than one checkbox, so percentages may add up to more than 100%.

Visual editors

The space of visual editors seems to be not to frequented with this audience – would be interesting to see if there is already a mass market for WYSIWYG-like tools in the web app space.

Do you use any visual tools/converters to build apps? If so, which?
	Adobe Edge 14 35% Sencha Animator 9 23% Other 18 45% People may select more than one checkbox, so percentages may add up to more than 100%.

Webkit only?

71% of the audience saying they test on other browsers than webkit is making us happy of course, but seeing that a lot of the tools in use are webkit only makes that number questionable. Then again, we didn’t qualify what testing entices in this case.

Do you test on non-Webkit browsers?
	Yes 340 71% No 139 29% People may select more than one checkbox, so percentages may add up to more than 100%.

Reasons to test for webkit only

The main reason here is a lack of time to test on other platforms which is understandable – we can assume that a lot of projects from a planning perspective have 99% iOS/Android written all over them. The “lack of incentive” number is high, too, which is understandable – if you can’t show the numbers, you don’t get the time to support.

If no, can you tell us why?

Fixed environment defined by client needs 36 23% Lack of time to support more browser platforms 85 54% Lack of incentive – I don’t know what the benefit of supporting more is 65 42% Lack of documentation how to install and debug on non-webkit browsers 39 25% Bugginess of other browsers on test platforms 24 15% Lack of support for other browsers on target hardware 55 35% Other 16 10% People may select more than one checkbox, so percentages may add up to more than 100%.

More to come

These are just the numbers right now. Soon we’ll be publishing also the free-form comments we got but for now this should get some discussion going and gives us a great start.

And finally – a massive thank you for everybody who participated in this survey!

At Mozilla our main reason to be is to keep the web open and free for everybody. We are passionate about the web and love how easy it is to get started as a developer. A few years ago we fought against monoculture on the desktop and won. Now we have the new challenge to keep the mobile web open and allow anybody to use anything to consume content on their mobile devices.

When it comes to the mobile web there are a lot of open questions and there is a lot of misinformation floating around. We want to make sure that we are not working on false assumptions and paint a much darker or lighter picture than what is real which is why we’d love you to help us get started in our outreach to tool and library makers in supporting more than one browser engine and more platforms when it comes to tooling.

If you are a mobile web developer of apps or sites, we’d be very grateful for you to fill out our quick survey on library usage and cross-platform support on mobile to give us some more data to go on.

Thanks in advance! There is a lot from us to come on this topic, and you have the chance to be able to say “I helped”.

Cheers