The current Aurora release of Firefox includes the Vibration API, a very simple system for making devices rumble.
The API consists of a single call to navigator.mozVibrate().
The function accepts a single parameter. Pass a positive integer to indicate the number of milliseconds the device should vibrate. Pass an array of these integers to create a vibrate pattern. Finally, pass 0 to stop any current vibration.
navigator.mozVibrate(2000);//Vibrate for 2 seconds
navigator.mozVibrate([1000,1000,500]);//Vibrate for a second.//Then pause for a second.//Then vibrate for another half-second.
navigator.mozVibrate(0);//An empty array is also valid//Stop vibrating
Obviously, this is only meaningful on devices that support vibration, like mobile phones, tablets and game controllers. However, in both the Firefox implementation and pending W3C specification, calls are silently ignored when the device does not support vibration or vibration is not allowed.
The W3C added a NotSupportedError that is thrown when invalid values are passed to the function. Obviously, it has also generalized mozVibrate() to navigator.vibrate().
The specification also checks document.hidden before the rumble begins and at any time the visibilitychange event is triggered. If document.hidden is false, any requested vibrations must be ignored and any current vibration must cease immediately. No feedback is provided to your code in either of these events.
This means that spam pages can’t drain your battery (unless you leave the offending page up), a concern expressed on the WebKit mailing list and is implemented as navigator.webkitVibrate() in the development builds of the WebKit core.
The bug occurs on AJAX-heavy sites that let you download content. Specifically, he experienced it when he clicked to view a PDF inside Mobile Safari and then used the back button to return to the site. Subsequent AJAX requests had the OPTIONS verb instead of the expected GET, something the web server obviously would not expect.
Fortunately, he came up with a fix. If you change the Content-Disposition HTTP header from attachment to inline, the browser does not lose track of the current domain and thus does not change the verb used for AJAX requests.
Remy Sharp has developed a tool for remotely debugging web pages. This works using code injection, so be very sure to keep it out of production environments. However, when you need to diagnosis issues remotely, say, because it’s on a mobile device, with limited console support, or because a client is reporting problems that you can’t repeat locally.
Implementing this is a snap!
:listen
This returns an UUID which you will need to insert into the page markup:
From then on, calls to console.log() will return their output to your listening machine.
The really handy library has one more trick up its sleeve. You can specify the UUID to which you will listen.
:listen FAE031CD-74A0-46D3-AE36-757BAB262BEA
When the remote device loads the debugging module, you’ll see something like this in your console:
:listen FAE031CD-74A0-46D3-AE36-757BAB262BEA
Creating connection...
Connected to "FAE031CD-74A0-46D3-AE36-757BAB262BEA"
Connection established with Mozilla/5.0(Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
The plain reality is that the vast majority of mobile web traffic is on Android and iOS devices. BlackBerry users have, by and large, been so disappointed by the poor web experience out of the box that they tend not to go on the web. Windows smartphones are still a small slice of the mobile market, especially when you focus on 3G and LTE devices, which use the lion’s share of the traffic, at least until Nokia ramps up its smartphone production.
The core engine and UI is 15KB gripped, which means that even when your user drops to EDGE, they’ll still have a good experience, since you still have 10KB leeway for images and markup. It is also optimized for simulating apps, including support for integration in tools like PhoneGap.
Further, it’s designed to make the interface as consistent as possible between Android and iOS devices, including fixed headers and footers and smooth CSS3 transitions. It’s not quite ready for tablet devices. If you watch the video, the interface during the Kindle Fire segment feels clunky, but they say they are working on tablet-optimized CSS.
In terms of syntax, jQuery users will feel at home. Still, be cautious with jQuery plugins, because while they should be run, many are still optimized for desktop environments and jQ.mobi is not intended for desktop use.
The long anticipated jQuery Mobile library has hit version 1.0 Final. With support for most mobile devices, it facilitates rapid development of mobile friendly sites.
Note that it does require jQuery 1.6.4 and the jQuery Mobile 1.0 CSS file, in addition to the jQuery Mobile 1.0 JavaScript file. This means that pages that use it will very likely exceed the 25KB limit of some very old phones, preventing the page from loading at all on them. That said, most phones sold since 2008 do not have this limitation, so it shouldn’t hinder you too much. Still, focus on keeping image assets, JS, CSS and HTML as optimized as possible, because mobile performance is still pretty slow for most users.
Also, it does require a number of custom attributes, so you will want to explore their Getting Started documentation.
Latest Posts