Tales of a Developer Advocate

Telling people about your web app in the Chrome Web Store is just as important as making your landing page rock. The more people that you can drive to your detail page the better your application will do, but you want to do it in a targeted way.

For this reason I created Badgemator – an app that creates badges for you to put on your website. It is about a month old, so why am I telling you now? Well the answer is simple, I posted it on twitter, and then forgot to post this blog – DOH!

It is an interesting project because it does a couple of cool things that make it super easy for you to use.

All you need is your Web Store URL – for example see http://badgemator.appspot.com/#https://chrome.google.com/webstore/detail/dhbgookgdfbbinnmmkbmjgolhikbbhpj to get started.
It is self contained – it base64 encodes your initial logo and css so that all you need to do is drop a single script tag into your HTML and BOOM, you have a great looking badge with no extra HTTP requests. Check out the source of Appmator and you will see there is a simple html tag that points to an embedded script.
It will only appear for Chrome users.
If installed on your app, it will detect if your app is installed using the window.chrome.app.isInstalled variable and not show it to users who already have your app running.
It will scan your listing page and pluck out all the important information including your Logo
The default style is “basic” to say the least, but you can style this up to look however ever you want, it could look like the Butter bar, or it could be some crazy 3d transform.

My good friend Mike Mahemoff suggested a neat use of URL fragments a while ago to enable quick sharing of links, hence you will see all my services support #URL at the end, so that if you wanted you could share it on Twitter and any reader would see the completed action – most of my service logic is on the client side.

I really need some more designs for default badges, so feel free to fork this project and make some changes to the CSS and I will incorporate it into the project and give you credit and links from the app.

If you follow me on Twitter – @Paul_Kinlan – you will know I yap on a lot about many of my projects on Github. This post is no exception, I want to introduce LeviRoutes, a client-side JS routing framework that is loosely based on a Rails like approach to URL handling.

There are plenty of frameworks that do this already so why did you create this? I hear you ask. Well it is pretty simple. I wanted a framework that would: * execute specific methods when the URL changed and matched a certain pattern; * is quick and easy to use; * listened for changes in the URL fragment; * worked with HTML5 History APIs; * worked on browsers that don’t support any of these features; * and most importantly doesn’t try to do anything else.

Thus LeviRoutes was born. It came about because I am working on a project that uses NodeJS with the Express framework, and the URL handling is very simple to access and I wanted to replicate this behavior in the browser, not just the server. My ultimate goal is for me to be able to share a lot of the logic that is on the server with the client and thus cut down the amount of code that I need to do.

The LeviRoutes project started with juat the ability to listen to changes in the HTML5 History by listening to the “onpopstate” event. When there is a “pop”, the matching code is invoked with the current window.location object. It later included a onhashchange event listener to listen to changes in the fragment and finally included a listener for the onload event. By listening to these three events.

Lets have a look at the simplest app that we can build with this.

var app = new routes();
app.get("/", function(req) { alert("On /"); });

Pretty simple right! Under the hood, the system is listening for when the URL is just “/” and nothing more, if your URL was “/index.html” the code would not be executed. If you wanted to watch for when the URL is “/index.html” you would need a route with that as the exact string.

Looking for just the root directory by itself is not very interesting, and neither are simple static URL’s. Thus the named parameters from Rails and other frameworks is built straight in, and this is the most interesting part.

It also supports named parameters for route syntax:

!#javascript
app.get("/:category", function(req) { alert("In " + req.params.category); });
app.get("/:category.:format", function(req) { alert("format: " + req.params.format); });

This is simple, yet powerful, LeviRoutes allows you to treat the URL as an input event to your controller, or as the controller.

Have a play, let me know what you think, and look out for my next post about FormFactorJS.

Badgemator .... it is all in the how you tell people about your app

The skinny on LeviRoute JS routing framework

About

Archive

Get Updates