What do you do if you want to quickly test your sites on mutliple versions of Android at the same time?

There are couple of solutions, such as Adobe Edge Inspect, but what if you want to create and manage your own in your own workflow? I haven’t seen single solution yet.

Here is a simple shell script that I created that starts to get you on your way to your own testing lab. It connects to every single Android device that is attached to your machine by using adb (Android Debugging tool).

The process is as follows (and please suggest better ways):

• Kill any existing adb servers
• Get a list of attached devices
• For each device set up port forwarding (required for Chrome Dev tools)
• Fire Android intent to open the browser (with a url if one is on the command line)

It’s not a complete solution, but it is a nice way to start. My ultimate goal is to have a Raspberry PI hosting adb and all the devices that I can attach to it with an attached proxy that will route all my devtools requests to the correct device.

How do you test across mutliple devices?

Just before Christmas I wanted to build a site that helped developers understand the impact that using Web Platform features would have on there potential reach. For example, if I used WebGL what is my target reach and what additional features can I use without impacting my potential audience figures.

I launched iwanttouse.com. Sweet. Anyway, that is not the point of this post. One of the features of this site is.

One of the core features I wanted to implement was a traffic light system that graded the features like a traffic light. Green = Good, Red = Bad, Amber = Be Warned.

My original implementation was just using some simple CSS classes.

.good {
  color: green;
}

.ok {
  color: amber;
}

.bad {
  color: red;
}

I knew this was bad, but using RGB I couldn’t work out sanely how to grade between 255,0,0, 255,126,0 and 0,255,0 without having logic in my code that looked like:

if (support < 25%) then .bad
if (support >25% and support < 75%) then .ok
if (support > 75%) then .good

added to that, I wanted the color to be more red than amber if it was at 35%.

Anyway, after a little chat with the awesome Paul Lewis, he mentioned that HSL (Hue, Saturation, Light) color scheme would be good for this problem because naturally the Hue value (0-359) rotates from Red, through Amber to Green (0 = Red, 45 = Amber, 90 = Green)

Red = color: hsla(0, 50%, 50%, 1) Amber = color: hsla(45, 50%, 50%, 1) Green = color: hsla(90, 50%, 50%, 1)

It is then simple given a value for percentage support to map that to 0-90 range and produce your traffic light colors.

element.styles.color = "hsla(" + ((percentage / 100) * 90) + ", 50%, 50%)";

It’s not me. It’s you!

Ok. thats a little harsh. Without AppCache we wouldn’t even be able to think about building Offline enabled web apps. But it seriously does have some issues, one of which I am blogging about today has been not discussed in depth before (as far as I can tell).

Imagine you building an offline enabled app that integrates with registerProtocolHandler or registerContentHandler. These two API’s use query parameter substitution to pass data from the client page to the service page (http://mailfoo.com/createmail.php?t=paul.kinlan@gmail.com&s=Test Message for example opens up your mail client at createmail.php when you click on a mailto link). This works well for purely online apps, but as we will see when used with apps built with AppCache you won’t get the experience you are expecting, at worst you could DoS your site.

Your createmail.php will likely render a manifest=”cache.manifest” attribute in your html element, which when visited is cached offline and works as expected. The problem lies in the fact that AppCache treats the entire URI (including query strings) as an identifier to the page, therefore if you have a unique query string each of these pages are downloaded and added to the AppCache group.

Ok, cool, but what does this mean? Well it means that http://mailfoo.com/createmail.php?t=paul.kinlan@gmail.com is cached separeately to http://mailfoo.com/createmail.php?t=paul.kinlan@hotmail.com, all the resources will be quickly fetched as the manifest has already got hold of the data and they are already cached in AppCache.

Whilst you are online, this is all gravy. It works beautifully. However now go offline and create an email to paul.kinlan@gmail.com (it works because it is cached), but try instead creating an email to paulkinlan@google.com(via a mailto link)… hmm, where did my app go? It is not there because it has not yet been cached for offline use. Big problem.

You thought that was bad? Now for the kicker.

You happily make and send 100’s of emails over a couple of weeksr. Whilst you are online, all works well. The developer of the app decides to upload a new version of their code so updates their app cache. What happens? Every single unique url (so every email you might have sent via a mailto) is requested and downloaded again (even if it is not in the manifest, it is in the app cache group). If I have sent 100 unique emails via mailto, then every single page with that query sting is fetched quickly by the browser… Seems like a good way to add a lot of load to your machine.

It is pretty hard to change a specifictation in flight so we need to start documenting patterns for building offline apps than we do today because AppCache is not easy to use, and there are lots of gotchas like this that make developers not even bother using the API.

I was thinking about this the other day. I remember being in the Apple store in Liverpool about 2 months ago and I distinctly remember hearing the following: "Do you have any of the new iPads in?" several times over the space of about 30 minutes (I was playing with MacBook Airs).

Come to think of it there were several other products people asked for as "the new X".

It is pretty cool. No product name obsolescence. You go in to a store you ask for the new product, they give it to you.

You either have the new one or the old one.

I predict the iPad series will only ever now be known as iPad and The New iPad. I also believe they will do it for more products the next being The New iPhone.

There is a lot of chatter about Mozilla considering implementing some webkit specific prefixes - I encourage everyone to read ”Platform/Layout/CSS compatibility”

Browsers need to:

• Fucking drop experimental prefixes. It’s unacceptable and a disservice to the developers working with your browser. You need to give timelines to dropping these things.

• Non-production ready browsers should support experimental prefixes, production ready releases should not. If it’s Chrome 16 - the stable version - experimental support should not be baked in. The properties should be full available without the prefix.

Chrome just got Web Intents support in Dev and Canary builds (18 onwards).  This is a huge milestone and I am very excited by this first step along the path of building a more connected web of apps.

{
  “name”: “Share to Gmail™”,
  “version”: “0.0.0.2”,
  “icons” : {
    “16” : “favicon.ico”
  },
  “intents” : {
    ”http://webintents.org/share” : {
       “type” : [“text/uri-list”],
       “title” : “Share to Gmail”,
       “path” : “/launch.html”
    }
  }
}

We have a huge problem on the web today. If I built an image gallery application and I wanted to let users edit an image so that they can remove red-eye from a photo I either have to build an application that edits the images, or integrate with a 3rd party solution. Doing this is hard and stops you from building an awesome image gallery; and what happens if the user has a favorite service that they already use to remove red-eye? Simple, you have a frustrated user.

We have a solution!

In December 2010 I announced a project called Web Intents whose goal was to allow developers to build applications and services that could work with each other, but not need to explicitly know about each other – the concept has heavily inspired by the Intent system in Android, although the API bore no resemblance. It would allow you to build applications using just the functionality your cared about, and then delegate the other functionality to the users preferred choice of service.

After some conversations, I moved to try and support Web Introducer as a specification over Web Intents. For one reason or another this didn’t quite work out so I decided to plug away at revising the WebIntents work that I started back in November.

It turns out there is a lot of interest internally with the idea of Web Intents and how it can work in modern browsers. We set up a small crack team and after a flurry of work, speccing and prototyping how we think it might look we have put a prototype API on to Github. Have a play, it is really easy to get started.

So what changed?

A lot as it happens. It is not the same as the initial project that I experimented with, although the goals are the same. We have an objective to make the developer experience of the API so painless that most developers can start integrating with applications in 5 minute of reading the spec – in fact we want it so that most developers can just copy and past examples and it will work with their service. We have tried to drastically reduce the API surface and make it so there is literally only one or two lines of code you need to start an activity.

Service registration has been made even easier that my initial project through the use of a new tag, for example:

<intent
  action="http://webintents.org/share"
  type="text/uri-list"
  href="share.html"
/>

This small tag, that is included in the head of your application will signal to the browser the intention to handle a “share” action for a selection of URI’s (think “share this page”), and will register it in the system so that the user can choose it when a client application wants to provide “share” functionality in their app.

When the service is chosen by the user, and the service is loaded the intent data is passed to the open application and is available on the window.intent object.

For clients to initiate an Activity it is easy too. Simply declare an intent and start the Activity as follows:

var intent = new Intent();
intent.action = "http://webintents.org/share";
intent.type = "text/uri-list";
intent.data = "http://paul.kinlan.me";

window.navigator.startActivity(intent);

The system will take care of the service resolution for the action and compatible data formats and give the user the choice of using their favorite application to handle the “share” intent.

I have only just touched the surface of what you can do with the API. There are a lot of things that you can do with the API over and above what I have described in this 5 minute overview. A selection of examples can be found at http://examples.webintents.org/ where we show you how to build applications that solve some common use-cases. I particularly like the cloud kitten service provided by the “pick” example.

We are working with Mozilla to define a common approach to solving the challenges that web integrators face today. We are interested in hearing your thoughts and we are still thrashing out the API so bits of it might change but the intent is still the same.

My closing thoughts are: “This project will fundamentally change and improve the way we build applications on the web today for our users.”