Since the Adobe logo does not have any gradients, and is fairly blocky to begin with, it made for an easy subject for a first attempt.  I was able to manipulate the border width and thickness, as well as width and height, to draw the triangles that make up the logo.  It may, however, surprise you to find that I have also drawn the letters of the logo with only CSS.  Letter stems are rectangular elements, and the circular parts are tuned corner radius values from CSS3.

Going to Extremes

Then I got to wondering “If I have reliable pixel control over elements with CSS, then it seems like I should be able to draw just about anything.”  Bitmaps are after all just two dimensional arrays of color values (pixels).  Of course I wouldn’t want to code every pixel by hand, but if there was a way I could get pixel color values in an automated fashion, that might lead to some interesting results.

Then I recalled that you can get pixel values from the canvas element in HTML5.  I could just code the canvas to have the image directly, but that wouldn’t be any fun – after all, if I was going to hard code the image, I could just use an image element.  To make the project really interesting I would need a way to load a user-supplied image.

At the HTML5 Live conference in London, Christian Heilmann of Mozilla fame gave a talk on many of the bad things web developers do that have since been replaced by more modern techniques – usually due to updated standards.  One such example was to avoid the old input element with a type of file for loading an image.  The more modern version of that technique is drag and drop, which is a preferable user experience pattern.

Now that I had an idea of how to get a reference to the image, I needed a way to actually load the user-provided image into the canvas.

The drag and drop operation gives you a file name, but no system-relative URL.  “But wait, the file name is provided as a File object from the W3C File API.”  If the File API is at play, then I could potentially read the file in directly, and then put the results into an image element.  From there I could draw the image element into the canvas, and dissect the pixel values.

Putting It All Together

Did it work?  Yes, it did!  Sure, it is a long ways around, but I think you will agree that the results are pretty impressive.  To test it out for yourself, you will want to get a small-ish image to use.  Keep in mind that a 100×100 pixel image is 10,000 elements to put into the DOM.  I have put some optimization in place to use the same element so long as the following pixel is the same color.  The test case I used is this image of Bart Simpson.  Right-click and save it to your desktop.

With our buddy Bart saved to your desktop, head on over to the scene with Moe waiting for a phone call from his nemesis.  Take the image from your desktop and drag and drop it to where the instructions tell you (roughly the center of the screen).  Once you have dropped the Bart image, moments later he will appear across from Moe.  That version of Bart is entirely CSS – 30,000 DIV elements to be more exact.

Don’t believe me?  Try it with your Twitter avatar, or make a small image from your latest family outing.  PNG (including transparency) and JPG will both work fine.  The magic is accomplished by iterating through the pixel values and creating a DIV element for each that is one pixel wide by one pixel tall, and positioning the element relative to the row/column that pixel is found in the image.  The background color of the element is set to match the pixel color.

Note: Safari does not implement FileReader yet, so this example will not work there.  I have tested on Chrome and Firefox without any problems.

Conclusion

What surprised me most was that it actually works as fast as it does.  When I have shown it in the past, most people just think the image itself has popped into the DOM.  Nope, that’s tens of thousands of iterations later, bub.  I have also found that the logic needed to dissect the image executes almost instantly.  The slow part is the actual rendering of the new DOM elements.

Drew Estates Dirty Rat

Among my all time favorite cigars is the Drew Estates Liga Privada No. 9.  It is a line that they continue to expand – the T-52 is also very good, if a bit more spicy.  With the Connecticut sun-grown wrapper from the T-52, the Dirty Rat takes that spiciness one step further.  At 5 inches by 44 ring gauge, the Dirty Rat is a smallish stick, but burns slowly lasting a solid hour.  I had no burn or construction problems.  Like all the of the cigars on this list, the Dirty Rat is a full-bodied stick that is not for the beginner.

La Gloria Cubana Artesanos de Tabaqueros

This is an unusual cigar, whose first third is a Connecticut shade-grown wrapper, and whose remainder is Sumatra wrapper.  It’s that split that really hooked me.  After lighting, most full-bodied cigars exhibit some harshness on the palette.  This stick tones that down with that Connecticut shade-grown up front.  From there, the flavor matures throughout the whole cigar, and the Sumatra really shows itself.  These guys come in a variety of size, but I like the 6 inch by 54 ring gauge.

Zino Z-Series (654T)

Davidoff cigars always have flawless construction.  I enjoy a Special T when I’m in the mood for something more on the mild side, that has a lot of flavor.  When I was introduced to the Zino Z-Series, in a beautiful maduro Dominican wrapper, I couldn’t pass it up.  At 6 inches by 54 ring gauge, the rest of the build is a mix of Peruvian binder and Nicaraguan filler.  This is a full-bodied cigar that produces ample creamy smoke.

Macanudo Vintage Maduro 1997

Macanudo is a brand that I don’t generally smoke in the United States.  I find them sub-par in construction and flavor to their Cuban counterparts.  At 6 inches by 54 ring, this one however comes in a fancy metal band that shines against the maduro Connecticut wrapper.  And it’s a good thing that it comes in a metal band, because you will want to smoke it to the point of burning your finger.  While I have still had problems with construction from time to time, the full-bodied characteristics and creamy smoke produced by the cigar simply shouldn’t be missed.

Montecristo Sublimes Edicion Limitada 2008 (Cuban)

Should you make your way out of the United States, have access to Cuban cigars, and can find this limited edition cigar from Montecristo, it is worth the price-tag (between $17 USD and $24 USD).  A formidable stick at 6.5 inch by 54 ring gauge, it will take you some time to get through – and will leave even the most experience smoker with a considerable buzz.  I found this at Boisdale of Belgravia where there is a “comfortable outdoor smoking area” (COSA) on the top floor (download).

About Web Sockets

Web Sockets have actually been under development as a specification for a few years.  The initial draft of the “Hixie” specification dates back to 2009, and made it through 76 iterations before recently giving way to the “Hybi” specification.  That specification for Web Sockets dates back to early 2010, and is now RFC-6455 – or essentially the path forward for implementing Web Socket functionality on the server.

In the early days there was a fair amount of contention around how exactly to make the connection to the server securely.  Both the Hixie and Hybi approaches use HTTP to make the opening request.  The Hixie approach focused on using various hashes in the headers to confirm a secure connection.  This created a lot of complexities in the client/server handshake.  The Hybi approach simplifies the handshake considerably, and puts security emphasis on the actual messages themselves.

Creating a Socket Server

As you might expect, to create a socket server with AIR, you use the class ServerSocket.  You can instantiate the class, set up your listeners for incoming connections, and bind to a specific IP address and port.  When you are ready to start handling connections, you call ServerSocket.listen().

The main event listener to be aware of at this point is the connection from a client.  This takes the form of ServerSocketConnectEvent.CONNECT.  The event object that comes along with that has a “socket” property that is a reference to the client.  Since you may want to send messages from the server to the client (the whole point of Web Sockets really), you probably want to keep track of those connections.  I push the reference into an Array called “connections”.

Getting a connection is one thing, but then you will want to handle incoming data.  In the case of Web Sockets, this incoming data might be messages from the client, or at the very beginning, the handshake that says the server accepts Web Socket connections in the first place.  Incoming data happens on an event called ProgressEvent.SOCKET_DATA.  The event that goes along with it carries the associated data being sent from the client.

Handshake

The Web Socket handshake starts off with an HTTP GET request.  This is different from how the subsequent data messages are handled, so it provides a good point to determine what it is that the client actually wants from the server.  I decided to handle this point of differentiation by reading the first byte and determining if it was the letter “H” or “76” as an integer.  If it is the letter “H” then the client is trying to establish the connection, and we can further the handshake process along.

While Hybi simplifies the headers needed to make the handshake, the headers themselves are still important.  At this point you can read in all the incoming data, and parse out the headers.  The specific header you are most interested in accessing is the “Sec-WebSocket-Key” header.  This header contains a randomly generated string.  Per the specification, you are required to append a specific GUID to that string, then perform a Base-64 SHA-1 hash on the resulting string.

Once you have this hashed value, you are required to return it as part of the HTTP response.  The first header in the HTTP response indicates that you want to switch protocols from standard HTTP.  The second header tells the client that you are switching to the Web Socket protocol.  The third header states that this is an upgrade action.  And finally, the “Sec-WebSocket-Accept” header sends the resulting hash from the previous operation.

Once you’ve sent the HTTP response, assuming you have hashed the incoming value correctly, a connection is established and the handshake process ends.  From here on out, incoming data takes the form of messages.  And of course you can send outgoing messages from the server as well.  We will dig into those details next.

Incoming Messages

Since we’ve established that only the handshake starts with “H” and that we’d not have incoming messages if the handshake had failed, we can assume new incoming data is messages.  Data messages can be a variety of data types, to permit clients that aren’t browser-based.  For example, there is an option to send binary messages.  Early work on binary support in JavaScript is happening, but for now I’m going to focus on text messages.

Messages are passed using a concept called “framing” which can commonly be found in other protocols.  In this case, the first four bits (yes, bits) tell the server if this is a single message, or the continuation of a longer message.  For this example, I’ll be sending single messages at a shot from the client to the server, so these bits will always be “1000” and I can move on to getting more information about the message itself.

The next bits of the incoming message data represent the data type for this message.  Since I’m looking for text messages, I’m looking for the bits “0001”.  You might be wondering how you get at bits if binary support isn’t part of JavaScript just yet.  While there’s more to this story that I’ll cover in a moment, the quick way to get at the bits is through string manipulation.  You can read the incoming data, treat it as a string with the conversion radix of 2 (binary) and then look at the second chunk of four characters.

Oddly enough the data type bits can also denote if the client wants to close the connection.  If that is the case, the bits of this second chunk of data will be “1000”.  In that case, we will use Array.splice() to pull that particular client from our array of monitored clients.  From there we will close that connection as well, before letting it be garbage collected down the road.

Data Masking

Continuing down the path of this being a text message, we will next want to know if the data was masked.  In the case of messages coming from the client, in the case of Web Sockets, that bit will always be “1” (true).  All messages from the client to the server get masked.  We will come back to this in a moment.

The next seven bits indicate the size of the data that is being sent along from the client.  Note that a message may be longer than what seven bits can handle (125 characters), and the specification accounts for this by using the value of “126” to indicate that these seven bits, and the next 16 bits are the payload size.  If you need longer still, you will get a value of “127” which means these seven bits and the next 64 bits.  For this example, all my messages will be less than 125 characters, so we take those seven bits to determine the size of the payload.

You might have noticed at this point that there’s some JavaScript syntax that you don’t normally see around handing bytes.  It turns out that AIR provides binary manipulation APIs for you to use in JavaScript.  This API may or may not reflect the ongoing JavaScript work around binary support, so take it with a grain of salt.

The next four bytes are the actual mask for the payload data itself.  And then the next bytes are the actual payload data itself, where the number of bytes to read comes from the previous operation.  If you didn’t already feel a little confused, this is where things can get a bit sticky.  Masking bytes are a way of shifting the payload data bytes around such that the message itself retains some security integrity.

The next operation then is to unmask the payload data.  To do this you essentially walk through the bytes of the payload data and shift their values using the bytes of the masking key.  For each byte of the payload data, you will increment the masking byte that you use.  When you’ve reached the fourth masking key byte, you start back at the first masking key byte, and so on until the payload data has been unmasked.  Now you have the actual message value and can figure out what the client wants from the server.

Outbound Messages

Sending messages also relies on data framing, but luckily messages from the server to the client do not have to be masked, which makes the process of sending a message much easier to handle.  From our previous walkthrough, we know that the first four bits of the framing are “1000” for a single message.  We also know that we will be sending a text message, so the next four bits are “0001”.  A byte consisting of “1000 0001” is the equivalent of “129”, so I send that byte right across.

Again, without the requirement of masking messages coming from the server, the next bits will be “0000”.  That is to say that there is no masking (zero on the first bit), and therefore no masking key is needed so zero from the remaining seven bits.  From there we can write a byte indicating how long our response message will be.  And then finally, the actual payload data bytes going back to the client.

Of course being able to construct a message is one thing, but knowing where to send that data is another.  That is why we kept track of the clients as they were connecting.  For this example, I am sending random numbers back to the client at a high rate (every 50 milliseconds).  Every time that interval hits, I iterate through the connected clients, and send along the randomly generated number.

Extras

Because I want to ensure that I only send messages along to the clients that are currently interested in getting them, I also keep an array of the various states of the connected clients.  Clients can stay connected and choose not to receive messages for the time being.  This also sets up the foundation to potentially send entirely different message to different clients.

Fellow Adobe Developer Evangelist, Andrew Trice, covers this situation very nicely in his write-up on the topic.  If this is a scenario you are interested in for your application, I highly suggest that you take a look at his example code.  Andrew also takes the next step on abstracting all the connection code and client management.  Definitely a great read for those interested in the topic.  Andrew has also posted his version on GitHub if you want to take a shot at the code yourself.

Conclusion

There you have it, a Web Socket server implemented with JavaScript on Adobe AIR.  While it is a fun exercise to truly understand the Web Socket specification, and while it could serve as the basis for your own server, there are many other great open source options out there.  I’ve posted this code on GitHub and will likely iterate over time, but I encourage you to check out the other options as well.

Historically, however, this has been a job of refreshing the data occasionally to see the latest.  This lag can introduce missed opportunities for the business – especially when the data being monitored relates to a single event (e.g. special sales).  With Web Sockets, this data can now become real-time information, and allow for more immediate decision making.

The subsequent question then becomes how to best visualize that data to provide the necessary information.  This is a whole area of research, but one thing I have found that always puts a smile on executives’ faces is animation.  Animating data is a fairly basic programming task once you know how to do it, but if you are new to this world of real-time data, you might dismiss it as an extra, when it is really a low-hanging fruit to a dazzling win.

Web Socket Connection

The first step to visualizing real-time data is understanding how to access the real-time data in the first place.  Luckily, web standards are here to save the day with Web Sockets.  This specification has been in a working state for years, but has recently moved on to the “request for comments” (RFC) stage.  This means it is unlikely to change significantly moving forward, and that you can start leveraging it in your projects.

And to be sure, the only parts that have changed at all in the past year have been around the server implementation and handshake details, that you the web developer don’t need to think about.  The client API you implement in JavaScript from the browser has been baked for some time.

From JavaScript, you will find a new class to use named WebSocket.  This is a first-class data type along the lines of String, Number, Math, etc.  When you instantiate the class via the “new” keyword, you must pass the IP and port to which the socket will connect.  Per the specification, the URI prefix of “ws” should be used (as opposed to “http”).  At the end of the day however, Web Sockets are an upgrade to the HTTP protocol that happens during the handshake.

Note that as soon as you instantiate the class, the process of connecting begin.  If you are interested in knowing when you are officially connected, the WebSocket class fires an “onopen” event, which you can map to a function.

There is also the corresponding “onclose” event for when the connection is closed.  Keep in mind here that unlike HTTP, for which the connection is terminated once all the data has been delivered, that Web Sockets are an open connection.  This connection can be closed on the client by calling the WebSocket.close() method, but it can also be closed by the server for any number of reasons (e.g. security concerns).

Web Socket Messages

Web Sockets have the ability to handle a variety of types of data in anticipation that connections may not always come from the browser.  For example, the specification allows for binary messages.  JavaScript is rapidly evolving however, and there is some hope for binary support in the language in the not too distant future.  For now you will be limited to text messages.

Regardless of the data type, now or in the future, sending a message is as easy as calling WebSocket.send() and passing along the data you want to go across the wire to the server.  As an example, this could be valuable for telling the server that you want to add additional data to be monitored, or that your application is in a state to really only be interested in a subset of a larger data feed.

I’ve been working with a fellow Adobe Developer Evangelist, Andrew Trice, on this topic and he has a great example of how this might work, when it might be important, and how to implement the details.

Getting messages is a matter of handling the incoming event “onmessage”, which gets passed an event object with many interesting properties.  While those properties still seem to vary slightly per implementation, the “data” property on that object is what we will be interested in accessing for the purposes of this example.

Some Charting Options

The area of canvas-based charting has seen explosive growth in the past year alone.  There are a number of great options that can cater to your specific needs.  One word of caution here is to find the charting abilities that best suit your needs, and that this may not be the biggest, baddest charting framework on the block.  Especially in the context of delivery to tablets, sometimes the closer you can get to the basic the better off you will be – especially in terms of performance.

A few years ago, when I start looking into charting options for my projects, I found that PlotKit worked wonderfully.  It has a great look and feel right out of the box, thus providing a great user experience with very little effort.  PlotKit however hasn’t been updated for a long time.

Another charting library I have used in the past, and that I will use for this example, is RGraph.  The RGraph API reminds me a lot of NET syntax, so it may be more approachable to programmers, but I’ve also found it harder to get a polished look and feel out of the available customization properties.

And if you are jQuery-inclined, you might look at jqPlot.  This library strikes a nice balance between features and customization, and in the classic jQuery approach, it gets you started with minimal effort and flexes its customization features by exposing tons of features after the fact.  Again, however, when you consider performance on mobile devices, any library that abstracts another should be tested thoroughly.

Animating Charts

In order to animate charts, you’re going to want to first figure out how much data you can reasonably display on the screen.  This could be adjusted by the user via the user interface down the road, but you will want to find a happy medium as a starting point.  For the purposes of this example, I will assume that we want to show 100 data points at any given time.

Keep in mind that when animating data, each element also represents how much history the user can view.  Sometimes more data isn’t necessarily better data.  The human mind needs to be able to digest what it is seeing.  That may be more or less than 100 data points for your use-case.

From a programming perspective, this means setting up an Array of 100 elements in a scope that can be accessed by other parts of your code.  When a new message arrives, get the data point(s) you are interested in visualizing, and then Array.splice( 0, 1 ) the first element off the array, and Array.push( event.data ) onto the end.  Then you want to redraw the data.

This is an interesting aspect of working with Canvas.  Once something has been rendered to the canvas, it becomes part of the overall bitmap data on the screen.  There are no discrete display objects to work with independently.  Even if your chosen library abstracts data points in a manner such that you can work with them directly and have the chart updated, chances are that it is redrawing the vast majority of the canvas space anyways.

Whether you are working with discrete points, or using the array method I show in the above code snippet, the important part is in moving the data down the chain.  You can’t just add onto the end.  You want to keep the same number of data points and change the values they reflect directly.  Over time, this will create the illusion of the data sliding in from the right to the left – also known as animation.  To move the chart the other way, put the new data in at the first element (zero) and splice off the end of the array.

Conclusion

This really just scratches the surface of the types of data visualizations that are possible with this technique.  Bar charts, lines, high-low points, and even pie charts render some visually impressive results with relative ease.  And again, keep in mind that the experience of the user matters.  This few extra lines of code, makes a big impact on the user, and in my experience, most marketers will love you for the effort over forcing them to refresh the data, or wait for updates of HTTP polling.

I should note up front that I have often included my daughter in my presentations – especially around multi-screen and physical computing. The original idea popped into my head when I needed an additional set of hands to interact with content, while also filming at the same time.  I work in a remote office with no other Adobe employees around, so it is not like I can just grab somebody from the next cube over.  My wife is notoriously camera shy, so that left one option, my daughter.

These days at conferences, I will often get questions around my content, as expected, but inevitably, somebody will ask about when I have new content coming out that includes my daughter.  She has become a bit of a celebrity in that respect, which is great because she loves helping her dad with work.

The Slides

I actually build the entire presentation before involving my daughter at all.  I work the content over and over until I have a cohesive presentation that won’t be changing much.  I’ll generally add to the sections all the way up until the presentation itself, but the section headers themselves will reach a point where they stop changing.  This is important, because the process of having my daughter draw the slides takes a considerable amount of time.  Changing major sections would be costly.

The Artwork

Once I have the presentation mostly refined, or at least refined enough to where the section headers won’t be changing, I pull out a sheet of 8.5” x 11” paper for each major heading.  Think of a sheet of paper as the screen for a specific header slide.  It’s not an exact representation of the aspect ratio, but it is close enough.  As they say in the video business “we will fix it in post”.  That is to say that we can massage the sizing once the artwork is finished.

First, layout the sheet of paper horizontally (long side across the top).  Then, using a ruler, measure out two lines on the paper roughly where you would normally put a slide title.  If you have a subtitle, you might adjust the lines accordingly.  Draw the lines very lightly – they are simply serving the purpose of helping you keep things level.  Then on those lines, in big letters, write the slide heading.  Again, be light here.  You are not interested in the lines any more than to provide a guide for your eager helper.

At this point, I turn it over to my daughter.  I tell her to trace the letters, and to do it somewhat sloppy (which she loves since to her staying in the lines is such a drag).  The sloppiness lends to better readability.  The thicker the lettering, the more legible the words will be on the screen in a formal presentation setting.  Once she has finished the letters, we think up a theme for the slide.  For example, since I was going to be in New York, NY for the presentation on “Exploring Canvas” I thought a New York skyline would be a good fit.  For another slide, since it was close to Halloween, my daughter wanted to draw witches and pumpkins.

Try to have your helper draw a variety of objects.  Don’t limit yourself to what you think will fit best on the slides.  Let them really go at it.  The more options you have the better.  I found that on any given slide, I would use maybe three or four out of the ten different things my daughter would draw.  Also, when they are drawing, try to have them stay clear of the letters of the slide heading.  This will make it easier to fit the content to the slide down the road.  I also found it helpful to have a kind of factory line.  My daughter would finish one slide, and while she was starting on the next slide, I would start digitizing the work.

Some Assembly Required

Once a given slide is complete, I scan it into the computer using a fairly high DPI setting (300 dpi or better).  This gives you more pixels to play with when it comes to sizing the content.  It also lets you clean things up easier at a high resolution, and then scale it down to fit with less artifacts from the cleaning process itself.  For example, if you are using crayon, there will inevitably be flakes of wax you don’t want.  Photoshop’s “Content Aware Fill” makes quick work of those.

I found that most of the time, despite being told to steer clear of the letters, that my daughter would inevitably get carried away and end up drawing into them.  Here a little work with the Photoshop “Clone” tool goes a long way.  I will set the original point on a blank piece of the paper, and make really soft edges on the clone area.  Then I can clone the paper over errant scribbles.  If you have scanned in the artwork at a high enough resolution, then when you scale it down to fit your slides, these fixes will be imperceptible.

Once the artwork has been cleaned up, I use the “Polygon Lasso Tool” to trace around the parts and pieces of the slide.  I keep it fairly random to emulate the look and feel of a child cutting out the words with clunky safety scissors.  I then paste the cut out objects into my slides.  From there, if I have scanned at high enough resolution, I can continue to scale, skew and rotate the artwork individually, without loss of quality of the artwork itself.  Before long the final product emerges.

Finishing Touches

For my purposes, I found that the artwork itself, when placed on a blank white slide, lost a lot of the character that I wanted.  There was something missing.  After thinking about it for a while, I realized that it was the texture of the paper itself that was missing.  The computer rendering was too perfect.  To solve this problem, I crumpled up a blank slide, er, a piece of paper, and scanned it.  From there a little color correction brought out the right one that I was trying to achieve.  Then I simply plopped that in as the background to each heading slide (again stretching and scaling to fit the aspect ratio).

When I did this, I found that the artwork became lost in the texture of the paper.  Now I had the inverse problem.  To bring the artwork back out of the textured paper, I applied a slight drop shadow to each object.  Now I had the final product.  Of course, once you have had your helper work so hard, it is important to show them the results of the work, so fire up the presentation and show them their handiwork inside the computer.  I found that my daughter would occasionally have recommendations as to pieces of her work that were missing that she wanted to include.  If at all possible, I tried to accommodate – she is, after all, the real star of the show.

Bond or Bono?

From the point of conceiving all four demonstration ideas, through development, and to the point of delivery, which included a trip from the United States to London, England, was four days.  Four applications in four days was an ambitious goal to be sure, but PhoneGap and web standards made it happen.

PhoneGap and web standards didn’t however, give me the boost in creative energy I need to finish off the second half of this application.  I never really could land on a look I liked for the buttons.  I tried caffeine, beer, cigars, and even walking around picturesque London for a few hours, but my creative juices were tapped.

I really wanted to fill the buttons with the texture of the handle from James Bond’s preferred weapon, the Walther PPK.  Unfortunately, I couldn’t find large enough pictures to accomplish that easily, and my Photoshop skills were letting me down in a big way after coming over the Pacific Ocean. Point being that while I like how most of the application looks, I can’t stand the buttons.

Device Camera Capture

The application presents two button for James to use.  The first button presents 007 with the opportunity to take a picture using the device camera.  When tapped, a call to “navigator.camera.getPicture()” will present the device UI for taking a picture.  The call takes a success function, a failure function, and options as arguments.

There are a number of options that you can provide, which can make using this part of the PhoneGap API a little tricky.  In my case, I wanted to get the image data itself back after the picture was taken.  Depending on the device, and the resolution of the camera, this might be more data than can easily be passed back from the device into the PhoneGap application.  I didn’t have a problem, but it is something to be aware of during development.

The alternative option then is to get a reference to a file on disk where the image is stored.  From there it is up to you to manage if that file gets a life longer than that of the application, where it lives, etc.  Once you’ve taken care of the details, you can change the “src” attribute of an IMG tag to show the image from disk, set the image as background to a DOM element using CSS, or even simply process the image bytes further for whatever additional data it is that you might be mining (e.g. Exif).

From there, I specified that the source was to be “Camera.PictureSourceType.CAMERA”, which is the notation for the device camera.  The other option would be “Camera.PictureSourceType.PHOTOLIBRARY”, which we will cover in a moment.  Along the way, you can tell the device to allow the user to edit the picture they’ve taken, should the device support image editing.

One of the nice things that PhoneGap does for you is image sizing.  This would otherwise be horribly pixelated if the full image was smashed down into a smaller version by force, or conversely take forever to process making a thumbnail directly with JavaScript.  PhoneGap allows you to specify the dimensions you’d like the returned file to fit in, and will even respect the aspect ratio (e.g. it won’t stretch or distort the image to fit the specified sizing).

When the picture has been taken, the success function you passed along will be called, and will contain the raw image data, Base-64 encoded.  This is actually pretty ideal because from there you can pop it right into a canvas element for further manipulation, or feed it into an IMG tag as the source.

Device Photo Album

The other button on the user interface allows Mr. Bond the opportunity to select a picture he has already taken.  The code is almost identical with the exception of the aforementioned change in source type, and the addition of a media type.  The media type option allows you to make sure that, in the heat of a fight with Oddjob or Jaws, James doesn’t accidentally select a video from his photo album.

Conclusion

Being able to take a picture of something from within an mobile application, is all but considered a given these days.  I went to play a new tower defense game on my iPad the other day, and even it wouldn’t let me install without a front-facing camera.  While web standards move forward to make that a possibility in the future, PhoneGap is here to help you today.  Even if James is otherwise preoccupied chatting with Miss Moneypenny, or getting his groove on with the ever-so-lovely Bond Girls.

Tardis Finder is really a simple example of using the device compass from PhoneGap.  The code is actually pretty short and sweet.  It is also very similar to using the accelerometer.  You make a call to “navigator.compass.watchHeading()” and get a numeric identifier in return.  You can use that identifier at some later point to stop watching the compass, so keep it in a variable that will be around to reference.

And of course you pass a success and error function to the “watchHeading()” call, along with an option of how often to poll the compass.  The default frequency for polling the compass is every 100 milliseconds.  When the success callback is executed, you will get an object with a variety of properties around magnetic heading, true north, and more.  Support for the options varies widely depending on operating system, so generally speaking you will want to simply use magnetic heading.

CSS3 Success and Failure

In this example, I use the heading value, which will be between 0 and 360 to rotate the compass image that many degrees.  This is done using the CSS3 transform “rotate()”, which despite being nearly 600×600 performs admirably well on my relatively dated Droid X.

You might notice that the compass has a slight drop shadow to it, and you might then assume that I use the CSS3 “box-shadow” attribute to apply that shadow.  And you’d be wrong.  It turns out that “box-shadow” works only on the containing box.  This would be fine if I wanted a drop shadow on a picture, but for the compass, which is round, it doesn’t come close to rendering the desired results.

To get around this, I separate the compass from its shadow – there’s one image for each, and I layer them on top of one another.  Positioned accurately, it looks like the compass has a nice, rounded, drop shadow.  I rotate the compass image, but not the shadow.  Thanks to transparent PNGs, this gives the desired result.

User Interface Considerations

You might notice that the compass doesn’t have a needle.  How do you know then what direction you are going?  Well, for one, if you are as smart as The Doctor, then you just know, but if you’re not, let me clue you in – the top of your phone, in the center, where the Tardis doors close, is the heading you are currently on.  Pretty intuitive right?  Maybe not, but maybe more than you think.

Once I had made the call to rotate the compass, I realized that if I had a needle, that it would essentially always be pointing towards the top of the application.  And to be fair, if I had the graphical skills to pull off a good looking needle, then I would have put it in there.  But the point remains that when it comes to compass heading you have two choices.

The first choice is to rotate the compass itself.  In which case, realistically, you should provide some fixed indicator (and if you come up with anything compelling, please send it over).  The second choice is to rotate the needle.  In this case, where the compass spills off of the screen, that wouldn’t work because you’d only know your heading about 180 degrees of the time.  So if you’re going this second route, size the user interface to include the entire compass on the screen.

You should also consider simply telling the user the heading value in a textual fashion.

I’m inclined to enjoy the second approach because to me, it more closely resembles how we actually use a compass.  You generally hold the compass fixed in front of you, with the top point directly perpendicular from your body.  The compass then is free floating and turns to always be pointing to the north.  Technically, you turn and the compass stays still, and that’s what happens in Tardis Finder.

Operating Systems and Sensors

The device I use to test my iOS applications is generally an iPod Touch.  The iPod Touch has no compass, so for this application, I targeted Android.  This brings up two interesting points.  The first is simply to check for the compass availability.  I haven’t covered the “error” blocks of most of these examples, but that’s where you’d catch that there is no compass sensor, and then take the appropriate alternative action.

The other interesting point is the viewport.  Despite the iPod Touch having a “retina” display of 640×960, as I’ve noted in other posts, working with graphics that large can still result in sub-par performance.  For this reason, I generally design for a 320×480 resolution, and let the operating system scale up the graphics.  And on iOS, this is done quite well with minimal, or altogether absent scaling artifacts.

With iOS, when targeting the smartphone form factor, I don’t even use a viewport.

Android on the other hand is nowhere near as forgiving, and it will try to scale up everything – even graphics sized for the exact resolution of a specific device.  This means that the “meta viewport” definition is really important.  Further, you can’t get away with just any viewport values either if you expect your graphics to fit the display precisely.  After a whole lot of trial and error, here is the viewport definition I used in Tardis Finder.

With this definition in place, I am free to expect that one pixel in my design will equal one pixel on the device.  In the case of Tardis Finder, my 480 pixels across the top fills the display of my Droid X exactly.  And luckily many Android devices have 480 pixels across the top … But not all of them.

And then there is the horizontal dimension to consider as well.  Early Android devices had 480×800 resolution displays.  The Droid X however has 480×854.  And a more modern device like the Motorola Atrix has a 540×960 resolution display.  This is clearly where CSS Media Queries would come into play.  I haven’t covered them here in the interest of sticking to PhoneGap features, but the bottom line is simply to test, test, test.

Conclusion

It never ceases to amaze me how something relatively simple can involve so much thought.  Here I’ve shown how to use the device compass via PhoneGap in a handful of lines of code.  But from there comes CSS considerations, UI consideration, device support considerations, resolution considerations and more.  Indeed a large percentage of the time of overall development for devices will ultimately be in testing.  Luckily, I’ve already done that footwork for the good Doctor, and now he can get back to saving the universe.

WARNING: There is some potentially offensive material in this tutorial.  If you find yourself sensitive to foul language, you may want to head on to somewhere else.  Continue reading at your own risk.

Request File System

What?  A tutorial on recording audio starts with the PhoneGap File API?  You bet!  It turns out that PhoneGap won’t record a file unless there is something already on the file system to record the audio into.  The file on the system doesn’t need to have any content to it, and must have a “wav” extension.

First up we will get a reference to the root of the file system.  This is done through calling the “requestFileSystem()” method, found on the “window” object.  We can tell the system that we want temporary or persistent storage.  Temporary content is removed when the application is closed.  We can also optionally tell the system just how much space we will need.  After that comes handlers for success and failure events.

Now that we have a reference to the file system, let’s get a file reference.  We do this by calling the “getFile()” method found on the root property of the file system object that is returned from the request call.  On this method call we tell the system the name of the file we are interested in getting.  Since we’ll be creating a file, name it whatever you like – just keep that name handy.  The options we will pass tell the system to create the file, and not to fail if the file does not exist.  Then, more callbacks for success and failure.

When we have successfully created the file, the callback gets a reference to the file entry itself.  Let’s store the full path of the file so we can easily access it later.

At this point we still haven’t told the file system what we intend on doing.  We have a reference to a file, and that’s about all it knows.  Next up then is to create a “file writer” by calling “createWriter()” on the file entry we got back from getting a file reference, from getting access to the file system.  Just like the rest of these calls, you pass success and failure callbacks to the “createWriter()” method call.

In the success callback of getting a file writer, you will get a reference to the writer itself – finally, we’ve made it.  Here let’s simply call “write( ‘ ‘ )” on that object.  Done.  And oh, by the way, you need to write at least something to the file in order for it to hang around.  In this case I’ve used a single space character.  A null space will not work.

If this seems like a lot to go through to write a file, I agree.  And I didn’t even mention the asynchronous calls that can result from the writing process itself.  The good news is that this isn’t PhoneGap obtuseness – it is by design.  Whose design?  As it turns out, like most of the PhoneGap APIs, this functionality maps to the W3C specification for file access.  The bad news then is that this is W3C obtuseness.

On the desktop, this asynchronous API is accompanied by a synchronous version, which is far more concise.  It turns out however, that PhoneGap proxies its calls to the device operating system.  Because you don’t want your user interface to hang while you’re waiting for the operating system to respond, these all pretty much have to be asynchronous, so that’s what PhoneGap gives us to use.

Recording Audio

Now that we have a file to record our audio to, the rest of this gets pretty easy.  The trickiest part here is first to make sure you grabbed that reference to the file we just created … Like I told you to do.  You did, didn’t you?  Cool.  Then the only other hard part, more time consuming than hard really, is in managing all the buttons you’re going to need.

You want to record, so you will need to provide a button for that.  However, once you’re recording, you probably want to let the user stop the recording as well.  That’s either another button, or a toggle version of the first button.  Once you’ve recorded the file, you’re probably going to want to let the user play it back to make sure you captured what they think you captured.  And once playing, you will want to stop the playback, and maybe even pause it.  That’s a few more buttons/states.  So like I said, it gets tedious.  The code to record and playback, however, is actually really easy.

PhoneGap provides a “Media” class for recording and playback using the native system resources.  As far as recording is concerned, I assume that if that object instance is null, then you want to record.  When the user hits the button to stop the recording, I do that for them, and then set the media instance back to null.

To get a Media object instance, use its constructor and pass that file reference from earlier.  As usual, you can also provide callbacks for success and failure.  The actual recording is done by calling “startRecording()” on your media object instance.  Conversely “stopRecord()” finishes the recording process.  In order to free up the resources consumed by the recording process, call the “release()” function on the Media object instance.

The way I’ve designed this block of code lets the user record repeatedly until they are satisfied with the fidelity of the audio to be translated.  To hear what they’ve recorded, I have provided a play button.  When that button is clicked, we head on back to that magic Media class.  This time however, we will want to use the success callback to know when the audio has finished playing.  From there we can free up the resources, and set the Media object instance back to null.

If the user wants to stop the playback before the end of the audio stream, that will be another button press.  I use a toggle here, so the audio is either ready to play back (stopped), or playing back.  If the audio is already playing back, then I assume the user wants to stop the playback if they tap the button again.  A call to “Media.stop()” does that, then we clean up after ourselves.

Translation

Okay, just so we’re on the level here, I’m not some crazy Ph D computer scientist.  I don’t actually know how to translate audio files.  I’m sure there’s some brain at Google that has that covered, but as for me, I’ll just play back some nice prerecorded audio files.  And each time you ask for a translation, the response seems to get more and more nice.  Eventually it gets downright gregarious, before finally just going off the edge.  You are warned (again).

I wanted to compare and contrast the PhoneGap Media object with the HTML “audio” tag, so that’s what we’ll use for playback of these “translations”.

The first part of that is to have an audio tag in your HTML.  The HTML audio tag is an interesting one because it actually takes several “source” tags inside of it.  The idea is to tell the browser where it can find the file with various audio encodings.  The browser looks at the source specified in the first tag, and if it can’t play it, tries the next, and the next until eventually falling back to whatever else is left inside the audio tag.

When the button to translate the audio recording is pressed, I empty out any previously placed “source” tags.  Then I create a new “source” tag with the “src” attribute pointing to the MP3 file I want to play this time around.  Note that not all browsers support MP3, and I’m not accounting for that.  This example works on iOS, but not Android.  I could add that support by having additional encodings, and inserting the additional “source” tags.

In a lot of the documentation around the audio tag, you will see to call the “load()” method, and then the “play()” method, one right after the other.  I found this approach to deliver very mixed results on my iPod Touch.  Perhaps the desktop is quick enough to load the audio file and then immediately turn around and play it, but the iPod is not.  To get around this, I listen to the “progress” event from the “audio” tag.  When the file is completely loaded, I go ahead and play the audio via the “play()” method.

The problem I had here is that the “progress” event fires while the content is loading, but then again once it is completely loaded.  That means you get “Hey, I’m 100% loaded.” called twice.  To manage this I keep a variable around for the loading progress outside the scope of the “progress” event itself.  Kind of clunky, really.

I was surprised to find that there’s no “isPlaying” attribute on the “audio” tag.  There is however a “stalled” event for when content has stopped loading before all the file has been loaded.  Apparently some browsers will also not let you play the audio programmatically unless you’ve turned on the “controls” attribute.  Note to self, “audio” seems to still be very much a work in progress.

Notification

I’m not entirely sure why I even put this in here, and you might be wondering the same thing yourself.  “Why are notifications even in PhoneGap?  JavaScript has the ‘alert()’ method, right?”  Well, yes and no.  When you use the JavaScript “alert()” method inside a PhoneGap application, the title on the dialog will be “index.html”.  That’s not really ideal for an application.  And what about presenting more than just an “Okay” and “Cancel” button?  Or vibrating the phone?  Or just beeping at the user?

All of those features are really easy to use with PhoneGap.  Like most PhoneGap functionality, you will find a “notification” property on the “navigator” object.  From there you can alert, confirm, beep and vibrate to your heart’s content.  In this application I use a “confirm()” call when the “Bob’s Your Uncle” button is pressed to show some options.  Now my native dialog looks like it’s coming from a native application.

Conclusion

Outside of all the asynchronous file work we have to do up front, working with the device audio via PhoneGap is really very easy.  It even provides the callbacks that you want the HTML audio tag to have, that it doesn’t.  And of course, the native audio functionality lets us record audio as well as play it back.  And if you’re wondering what “Bob’s your uncle” is translated to, it means “then it will be simple” just like getting started with PhoneGap.  What?  You haven’t started yet?  What are you waiting for?

Accelerometer

Accessing the accelerometer with PhoneGap is a relatively straightforward process.  The main function you will want to call is “navigator.accelerometer.watchAcceleration()”.  That sets the ball in motion to poll the device for accelerometer data at a given frequency.  The parameters you’ll want to pass to the function then include a function to call back when the interval has elapsed, a function to call back if there is an error, and a JavaScript object with a property named “frequency” that defines how often you want to get an update.

You can set the frequency interval to be as low as you want, but PhoneGap caps the update rate to a minimum of 40 milliseconds.  You can also set the frequency interval to be as high as you want.  If you set the value greater than one second, PhoneGap will still poll the device every second, but only make the callback when the interval you specified has elapsed.  In this game I fire up the accelerometer at 100 milliseconds, and record the values as a separate data point from the actual game play.  More on that later.

Relative Tilt

The accelerometer on my iPod Touch presents a value of “0” on the x-axis and y-axis when laying flat with the screen up.  Depending on the screen orientation, you will get a maximum value of “1” for a tilt of 90 degrees at one end, and a value of “-1” for a tilt of 90 degrees in the opposite direction.  From there you might choose to have some multiplication factor to translate accelerometer data into pixel movement.  Apply some CSS and you’re golden, right?  Well, not so fast.

There’s a good chance that your user doesn’t want to play a game with tilt controls laying flat on the table.  They might be seated, and holding the device at an angle that gives them the best view of the screen.  It is also likely that the user doesn’t want to have to tilt a full 90 degrees to get to the maximum acceleration.  If you don’t account for these tilt factors, you’re likely to present a frustrating user experience.

The trick then is to use an existing tilt as the zero mark, effectively creating a relative tilt.  From there, you want to map a smaller tilt range to the gauge of what represents 0 – 100% in your application.  This math took me some time to figure out.  In fact, I’d say it was the toughest part of the application.  And it doesn’t help when relative tilt is relative not only to the user, but also possibly to the containing HTML element.

The way I approached this problem was first to assume that the user would be holding the device at an angle comfortable to them at the very moment before the game started.  To be clear, I’m talking about the game play, not the launch of the application itself.  The user presses a start button, the game presents a countdown, and then 500 milliseconds before the game starts, I grab the latest accelerometer data, and use it as zero.

In my game, the captured accelerometer point is mapped to the half-way point of total tilt range.  I then limit the total range by 0.25 in both directions.  Why 0.25?  Mostly just because I played with a number of options and found that value presented the best experience for my game.  And I think that goes to a point you will hear from me often – get a device, get as many as you can, and test on all of them from an early point in development.

This is what I came up with to solve the relative tilt problem.  With the given relative minimum and maximum ranges, the first step is to get the accelerometer data.  In order to put that accelerometer data in the new range, I subtract the relative minimum tilt value, and divide by the total range of motion.  This gives me a percentage value of where the accelerometer sits relative to my total range.  Then I can multiply that percentage across the placement of the UI offsets.

CSS3 Transforms

I started using CSS3 transforms for much of the animation in this game.  The performance of using the transforms was notable over using animation techniques built into frameworks such as jQuery.  That being said, transforms and animations afforded by CSS3 were really quite cumbersome to tune.  A lot of “CSS, run, test, CSS, run, test” cycles for split second movements.

The biggest problem with CSS3 transforms and animations was a lack of callback when the action was completed.  It is common to want to fade something out, and then to trigger another action such as starting a timer, when that object is completely transparent – or better yet, to remove the transparent element once the animation has completed.

Without a callback I ended up having to keep a timer running, and hope that it was running in the same timing as the animations were actually being rendered.  And for the most part, the timing worked great.  Really strange though to have to keep a counter of what frame of the animation I’m on to be able to get a fine-tuned control on it, and to take actions after the effects were applied.

Decoupling Processes

I wasn’t quite sure what to call this section.  It’s a problem I’ve run into before with other experiments.  Essentially, when a timer is running at a regular interval, you have to be careful not to do more code in the callback than can reasonably be accomplished before the next interval.

For example, I wanted to get updates from the accelerometer every 100 milliseconds to make the game feel relatively responsive.  It’s likely you might even want to go lower.  Once you get a callback, you’ll be tempted to calculate placement of all the parts and pieces of the UI, and then make the DOM calls to update all the positions.  I’m here to tell you that you won’t be able to do all that in 100 milliseconds on a resource-limited device.

The solution then is to decouple the things you are doing.  Keeping with the accelerometer example, in my game I capture the values as they come in and update a variable that stores the latest value – and that’s it.  Then I have another process that controls the game play.  As it iterates, it checks the variable that has been updated.  Once the two are separate, there’s a notable increase in performance.  The UI is free to update, while PhoneGap is free to work with the device.

It should also be mentioned here that using PhoneGap to communicate with the device itself also takes time.  Depending on how much data you’re communicating, you may hang your user interface until the transaction is complete.

Conclusion

After all that talk of managing tilt, animation, performance, you’d think I’d have a result that I really liked.  In all honesty, I do not.  I still feel like the UI stutters too much.  I still don’t like how some of the animations play out.  And while I’m managing tilt effectively, it’s only for one orientation.  There’s a lot of work to do yet to make this a real game.  Along the way however, I’ve learned a lot about designing a mobile application with PhoneGap.  If you’re playing this game in the London Underground, just remember to look up from your phone every once in a while and “Mind the Gap”.

About a week before the trip, as I was reviewing the presentation, and updating to all the latest bits, it hit me.  “If you’re going to London, why not have a variety of London-themed examples?” I set to coding, and before long found myself with four new examples of basic PhoneGap functionality in action.  It was a lot of fun to build them all, and I plan on sharing them each over the next few posts.  In the meantime however, here is the rundown of what to expect.

Mind the Gap

If you have never been to London, you may or may not know that they have an extensive subway system.  Britons don’t call it the “subway” however, but rather the “Underground.”  At virtually all the Underground stops there is a warning you will find painted on the platform, between you and the train.  That warning reads “Mind the Gap.”    I thought to myself “Yeah, you should mind the gap – the PhoneGap!”  And the first example was born.

My “Mind the Gap” application is an example of using PhoneGap to access the accelerometer on the device.  As you tilt the device, you move around on the Underground platform.  If you touch the “the gap”, your game will be over – which you will know by the use of another PhoneGap feature – the vibration of the device.  The example also uses CSS3 transitions to control movement and animation, which keeps the performance respectable.

Blimey

Of course, if you are going to be presenting somewhere, it helps to know the language.  You might be thinking “Hey Kevin, it’s London, not China.  They speak English.”  To which I would largely disagree.  For example, in the United States if you want to squeeze by somebody standing in your way, you will say “Pardon me.”  In the United Kingdom, that translates to “I farted.”  So you would be pushing past people, telling them that you farted, not to get out of the way.  How rude!

I figured that a translator was needed for my presentation.  I could use PhoneGap to record the audio of somebody speaking a UK idiom, and translate it to English (yeah, I said it – English!).  Of course I wasn’t going to build a full translation system, so what you get out is limited to a set of random canned responses – an example of using PhoneGap to play audio.  No matter what you record, you’ll always get a nice, reaffirming, message in response.

There’s also an example of using PhoneGap to present native dialog boxes with custom buttons and labels.  Be warned though, that things get a little colorful on that side of the application.  It was an emergency feature added just in case the audience wasn’t responding to my jokes.

Tardis Finder

If you look around, you’ll find a number of applications that help you solve that age old problem of remembering where you parked.  Accessing the GPS in the device is usually the method used to solve this problem.  But GPS is very hard to show while presenting indoors, so I wanted an alternative.  Additionally, I didn’t want to show how you could accomplish the same old thing that dozens of other applications already do just fine.  I needed a new audience, and who better than that British icon than Doctor Who?

Think about it – there’s no parking application for Doctor Who.  There he is, traveling all about space and time, saving the universe from the evil Daleks, with nothing to reliably get him back to his trusty blue phone booth, er, Time And Relative Dimension In Space machine.  What if he gets lost?  Well thanks to PhoneGap, and its ability to access the compass, Doctor Who can now download the Tardis Finder application.

Since there’s only been ten (10) Doctors, I’m not expecting huge sales, but at least I’m doing my part to keep the universe safe.

iBond

So long as we’re talking about British icons, one would be remiss in their duties if they didn’t mention Ian Fleming’s 007: James Bond himself.  You know how all the Bond movies start, don’t you?  There’s Bond and his signature Walther PPK being tracked by a circle – as if somebody is spying on the best spy.  Sometimes there’s different chases that Bond takes part in, and of course, there’s always a woman.  I thought to myself “Why does Bond get to be the only one to have all the fun?” and the next application sprang to life.

iBond leverages PhoneGap to allow you to capture an image from the device camera, or to select an existing image from the device photo gallery.  From there it takes the picture, leverages CSS3 transforms to scale down the image, and then places the picture in the center of the classic circle used during the opening of the movies.  You are now James Bond.  Tap on the 007 logo to use PhoneGap’s access to the local file system, and some canvas magic, to save the entire circle, swirl and selected picture to disk as one composite image.

Luckily for you there are a variety of new services popping up on the horizon.  The details go a little something like this.  You know about the cloud.  You know you can spin up Amazon EC2 instances faster than you can toast a piece of bread.  Why is it then that create, read, update and delete, the same CRUD developers have been doing since the dawn of data processing, can’t be just as easy?  That’s exactly what these new services offer.  You’ve got your HTTP for the wire, REST for parity with CRUD, and JSON to represent the objects you want to store. They manage the server, your data, the scale, etc.  You are now comfortably back at home on the client.  Make a few web standards requests and badda-bing, badda-boom, you launch your application tomorrow.

I’ve had the good fortune to play with some of these cool services over the past few weeks, and I’ve got to say, as somebody who has seen more server than they care to ever see, I’m impressed!  My current favorite is Parse.  I didn’t think I would like it at first, having to define my own objects, but in the end, found the freedom quite liberating.  I’m not worried about Third Normal Form (3NF) or anything here, so there’s a lot of redundancy to be sure, but storage and processing cycles are cheap these days, no?  And it’s just that kind of freedom that gets me going.  They’ve also opted to keep the REST API very straightforward.  It’s like I have a Rails Jedi sitting next to me.  Oh, and my personal favorite – no OAuth – a client-side developers worst nightmare.

Ready to create your first object on somebody else’s infrastructure?  Let’s do this thing!

When you login to Parse, you will be prompted to set up an application.  You can have as many of these as you like, and for most purposes, you can think of it as roughly analogous to a database.  Along with that application you will get a unique identifier, and a master key.  You will use these as the user name and password in an HTTP Authentication header on your request.  Simply concatenate and Base64 encode the two.  I’m using a Base64 encoding class from Steven Webster here.  From there you set up your request, and since you are creating an object, you will use the HTTP POST method.

Note that the URL for the Parse API is used as the destination, and then appended to that is the name of the class you want to create.  Didn’t define it prior to making the request?  No worries, that’ll get done the first time you make the request.  The data we will send to that URL is a straight-up ActionScript Object instance.  You put whatever properties you want on it, encode it with JSON, and send it along as the data of the request.  When the result comes back, it’ll be a JSON object with the data/time stamp the row was created, and the unique identifier for the data you just stored.  Again, think of this as your primary key in database terms.

You my friend, are done!  There’s about twenty lines of working code there, and you never even mentioned the words server or database.

Don’t believe it can be that easy?  You can always go to the Parse data browser to check it out, work with the data, import some more data from a CSV file, or drop the whole thing outright.  If you are like me though, and want to see for yourself using a request of the same system, I’ve got your back.  It all follows the same pattern.  You set up the authentication header, but this time your request will be done using the GET method.  And notice that the URL is the base Parse API URL, plus the class name, plus the object identifier of the data you want.  Send that bad boy on over, and you’ll get yourself some JSON back representing the stored data.

And you can go on like this ad nauseam.   HTTP PUT for an update and HTTP for DELETE.  The same boiler code will do you.  There is even a fairly well thought out query syntax for when you want to start filtering on your requests.  Of course, if it seems like this boilerplate code would be all too easy to wrap up into a simple class for reuse, you are exactly right.  Up on my GitHub account, I’ve posted a simple set of classes for interacting with the Parse REST API.  There’s even a sample on how to use the class.  Feel free to do so.  If you want to contribute, I can accomodate that too.  All I ask for in return is a piece of that next best selling application you’re writing.  I kid!  I kid!  Now go on with your bad self, and enjoy you some server-free data storage.

Franklin Covey has historically been a mainstay in the realm of personal productivity.  Their journals, books, training and other media have saved countless people from information overload.  Back in the days of paper tracking, Covey journals had an important side bar for “priorities.”  Unless you had ever read Covey’s techniques, you’d probably never use this space for anything other than notes.  Or you may have jotted a few priorities down without having given any consideration as to why you are putting them down in the first place.

To understand the idea of this space, you first have to step back and understand who you are as a person, and what you are about.  This first level of priority setting, outside of the presence of technology or systems, is critically important.  It takes a degree of self introspection that isn’t always comfortable.  The outcome should be the “roles” you play in your life.  As an example, you might be an employee, husband, father, etc.  Once you’ve identified who you are, and the roles you play, setting priorities becomes markedly more approachable.

Next up would be to start the week by examining those roles and thinking about the priorities of what needs to get accomplished in the week ahead.  And it should go without saying that you should schedule time for this activity, each and every week.  From there you’d come up with five items that you need to get done in the week ahead across those roles.  You write them down in the sidebar of the journal, and stick with them.  Again, not forgetting to schedule time for those things.

As the week progresses, you cross those items off your list.  The following Monday (or whenever you decide to do this activity) you’d look at what you did not get done, and carry those forward to the next week.  Then again with some contemplation, consider how you round out that list with what lies in the week ahead.  As time goes on, you can look back at all that you have accomplished, and you may even choose to reward yourself when you’ve crossed a certain milestone.  Looking forward, if you stick to the plan, you will quickly come to realize just how productive you’ve become – and how much “other stuff” falls away because it simply doesn’t matter to who you are.

Sounds interesting?  Here’s is my abbreviated version for those just getting started.

At the start of the week (Monday for me), think about what you have to do in the week ahead.  Try to think holistically.  You don’t have to focus on roles just yet.  At the start, simply get some basic things you want to get done, and try to spread the items across more than just “work.”  I’d suggest just picking five items.  Keep it short and sweet.  Then go through the week and cross those items off as you go.  Wash, rinse and repeat for the next week.  Carry over what you didn’t get done, and then round it out with new items to total five priorities for the week.  Over time, the roles that are important to you will surface, and you can start focusing more specifically on those items.

The other important factor of this technique is to keep those priorities relevant in your mind.  For this, I suggest a small whiteboard that you keep on your desk.  Or if you are creatively inclined, make a fun wallpaper with those priorities.  Whatever works for you to keep your action items “mentally relevant” – always on your mind.  Of course this is but one technique, and not all personal productivity wisdom applies to everybody equally, so feel free to adapt this concept to whatever works for you.  In the end, you’ll discover a more productive “you” and the people around you will recognize it as well.

I’ve discovered that my approach to lining up presenters differs somewhat from others.  My first action is to head to Twitter and openly ask for topics and presenters.  From there I start working my professional network to reach out to suggested presenters, and see if they are interested.  I also review their past presentations from SlideShare, including comments both from there and from user group web sites.  And of course there’s an obligatory stop at their blogs.  Eventually, what settles out is a camp that is by the people, for the people.

These sessions have almost all sold out one time already at this point, with a month left to go until MAX starts, and most of the presenters have been able to sign on for another session.  So if you’re into web development, and are looking for awesome content, then don’t delay – head over to the MAX web site and register now.  If you’ve already made plans to attend, check your schedule and make sure you get to see these folks live and in person.  Without further ado then, the line-up for my camp this year is as follows.

How to Rapidly Build HTML5 Web Applications with Sencha Technologies

Aaron Conran, ExtJS Core Development Team Member

Join this session as we explore how to rapidly build HTML5 desktop and mobile applications using Sencha technologies. Ext JS and Sencha Touch are frameworks enabling development of pixel-perfect, cross-browser apps that look and feel like native applications. The frameworks are built on web standards (HTML5, JavaScript, and CSS), require no browser plug-ins, and can integrate with any server-side back end such as ColdFusion, PHP, or Java. Learn how to use Sencha Designer to create rich interfaces for the web in an easy-to-use visual environment.

Mobile Applications with jQuery, Dreamweaver and PhoneGap

Dave Johnson, Nitobi Cofounder

Steve Gill, PhoneGap Community Champion

In this session you’ll learn how to leverage native device functionality with HTML and JavaScript using PhoneGap. You’ll also see how Dreamweaver 5.5 makes it easy to integrate jQuery mobile and PhoneGap. This is a great session for anyone who wants to build cross-platform mobile applications with HTML, CSS, and JavaScript. The session will walk you through getting set up, creating a basic application, using jQuery mobile for UI, and using the PhoneGap APIs to hook into device-specific features like camera and GPS. By the end you’ll have all of the info you need to deploy and publish the application.

Building It with jQuery Mobile

Sidney Maestre, PayPal Developer Evangelist

Find out how jQuery Mobile takes the popular jQuery JavaScript library to the next level by providing a unified user interface system across all popular mobile device platforms. In this session, we’ll cover structuring content, touch events, helper methods, and working with remote data. We’ll build a mobile app using jQuery Mobile toolbars, buttons, form elements, and list components. You’ll leave with a solid foundation for future jQuery Mobile projects.

Real-Time Programming with Arduino Using WebSockets

Justin Mclean, Consultant, Developer and Trainer

Learn how you can communicate in real time with the physical world using Arduino, a low-cost, easy-to-program open source hardware and software platform. This session looks at how to interact with Arduino hardware directly from a web browser using the WebSockets protocol and the Socket.IO JavaScript library. We’ll start out by turning LEDs on and off and progress to creating graphs that react in real time to environmental sensors.

HTML5: The 2012 of the Web

Robert Nyman, Mozilla Technical Evangelist

Take an in-depth look at HTML5, a buzzword we’ve all heard, but few truly understand. We’ll explore HTML5 elements such as new form input and behavior, as well as APIs like video, canvas, Web Storage, History, and more. You’ll find out how these technologies can help you create better and richer websites for end users.

Mastering Media Queries

David Powers, Bestselling Author

Take a deep dive into using CSS3 media queries to create websites that look good and work well on desktops, tablets, and mobile phones regardless of screen size. In this session, bestselling author and trainer David Powers explores how to optimize style rules for each type of device depending on its features, such as width, height, aspect ratio, and orientation. You’ll also learn how to cope with older browsers that don’t support media queries and how to avoid wasting mobile users’ valuable data allowance by forcing them to download assets intended only for larger screen sizes.

HTML5 Semantic Web

Terry Ryan, Adobe Developer Evangelist

Learn how the real HTML5 can make your job much easier! Lost in all of the marketing about HTML5 are the real features that actually define it. These include new tags, new form fields, and new attributes on both new and old tags alike. This session will introduce you to these new semantic elements, explain them, and explore when you would use them. It will also show how you can use them to reduce divitis in your HTML and make your work faster to write and easier to maintain.

Building Interactive Content Using HTML5 Canvas

Grant Skinner, CEO GSkinner

Join Grant Skinner, veteran interactive developer and creator of EaselJS and Pirates Love Daisies, for this session on building interactive content using the HTML5 canvas element. The talk will feature a comparison of related technologies (Flash, CSS, SVG) and include tips and gotchas, the core API, and an examination of a number of canvas libraries, with a focus on EaselJS. Applied uses include games, infographics, data visualization, and advertising.

Building Cross-Platform Mobile Applications with HTML, CSS and JavaScript

Jonathan Stark, Bestselling Author

Join mobile application consultant Jonathan Stark on an up-close and personal tour of the mobile side of HTML, CSS, and JavaScript. With the mobile web still in its infancy, platform fragmentation is worse than ever, and maintaining separate codebases can be problematic. Fortunately, advances in HTML5 and related technologies are paving the way forward. Learn how to leverage a single codebase to deliver a compelling experience on mobile platforms, both online and off.

High-Performance JavaScript

Nicholas Zakas, Bestselling Author

Join the discussion as we dive into the complexities of JavaScript. For much of its existence, JavaScript has been slow, but no one complained until developers started creating complex web applications with thousands of lines of code. Although newer JavaScript engines have improved the situation, there’s still a lot to understand about what makes JavaScript slow and what you can do to speed up your code.

From the initial examination of the cigar, the dark cameroon wrapper was certainly easy on the eyes.  A silky smooth dark wrapper leaf that seemed to suggest a typical Patel medium to full body smoke.  I’ve read that cameroon wrappers are notoriously difficult to roll well, so I was eager to see if the construction of the stick held up to other Patel smokes.  Pre-light, the scent of the cigar wasn’t anything notable either on the wrapper or on the foot.

Upon lighting the cigar, it started off with a little more spice than I expect, but it is a formidable size stick at 6 inches and 58 ring gauge, so it took a bit to light it.  A hot cigar usually burns a bit more spicy, so this wasn’t entirely unexpected.  After letting the cigar cool, and getting down a couple of inches, the spice subsided and flavors exhibited were that of nuts, with a slight hint of dark cherry.  The smoke itself was smooth and enjoyable.

Then disaster struck, and the cigar suddenly emitted a bunch of unexpected smoke, and suddenly extinguished itself.  I examined the foot for any construction flaws, but found no holes or other problems.  I suspect that this surprise came from the leaf being a bit on the younger side – it is after all only eight (8) years old.  After cleaning the foot and relighting, the remainder of the cigar exhibited no further problems.  I smoked it all the way down to the cap.

Overall, this was an enjoyable cigar.  It was surprisingly mild for a Rocky Patel smoke.  It would make a great late afternoon, pre-dinner stick.  Something you could enjoy without having to worry about having anything in your stomach.  Given that the cigar went out on me, I’d suggest picking up a few sticks and stashing them in your humidor for a couple of years.  I imagine that the extra age would really bring out all the characteristics of this cigar.  Notably, I’d hope that the dark cherry I tasted would mature into a more dominant flavor.

Embassy Suites, La Vista, Nebraska, Room #609

La Vista, Nebraska is a suburb of Omaha, Nebraska on the far West side.  It’s so far West in fact, that I’m not even sure it’s proper to call it a suburb.  If you are driving West from Omaha to Denver, Colorado, along I-80, then it is pretty much the last civilized exit you will en counter before you enter the vast farm land between Omaha and Lincoln, Nebraska.  The main draw of the area is probably the Cabela’s sporting goods store, which is just across the street from the Embassy Suites.

The hotel itself is a relatively new property – maybe five years old at the most.  As such the furnishings are still pretty much free of the blemishes that come with patron wear and tear.  If you have never been to an Embassy Suites, they are part of the Hilton brand.  Each room has two rooms – a living room and a bedroom (hence the “suites”).  A breakfast buffet is served every morning and includes everything from custom made omelets to biscuits and gravy.  If you’re a member of the Hilton Honors frequency program, there’s also a nightly managers reception with free beer, wine and hors de vors.

Embassy Suites, La Vista is connected to a Marriott Courtyard by a small conference center.  The conference center has maybe a dozen presentation rooms, and a few ballrooms.  For a few years running, the Heartland Developer Conference has been hosted in the conference center, and it is that event that brings me to La Vista, Nebraska this time around.  More information, session notes, presentations and other content from that conference coming up in a subsequent post.

The thing I like about these events is that they are being organized by the community, for the community.  They focus not on web design, but on enterprise web application developers and architects.  I get to share the stage with esteemed industry thought leaders such as Christian Heilmann from Mozilla, Bruce Lawson from Opera, James Pearce from Sencha and more.  If you haven’t already registered, you owe it to yourself attend.  And the good news is that there’s still space available.

The organizers recently shot me a list of questions about my sessions, to share with attendees and those looking to attend.  So without further ado, here is my session description, and my answers.

Description

Learn about programming charts and graphs, animations, drawing applications and other early use-cases for the HTML5 canvas element.  Come explore the canvas API including shapes, styles, transformations, compositing, images and animation.  Along the way we’ll explore examples on both the frivolous and more practical sides of the scale.

Questions and Answers

Q. Tell us a little about what you will be talking about at HTML5 Live.

A. At a high level, I will be talking all about the canvas element, and the extensive API that goes along with it.  It’s that later part that can end up getting really deep, and indeed I think this talk will initially make attendees feel a bit like Alice falling down the rabbit hole.  Once there’s a foundation of knowledge to build on however, we will take off on new, more comprehensive adventures with a wide variety of more sophisticated examples.

Q. What will people who attend your talk learn?

A. At a baseline, they will learn the fundamentals of using canvas.  I also hope that they will learn what kinds of new opportunities are opened up by this fantastic set of new capabilities.  There’s a whole new world of creative expression that can be accomplished with canvas, and I want to open attendees minds to the possibilities.

Q. What will they take away that they can apply right away?

A. Attendees will walk away with confidence that they can use, and rely on canvas for their next project. Hopefully they will also be able see web development problems in a new light, and find solutions in canvas.

Q. In your opinion, why should people attend HTML5 Live?

A. I present at, and attend, more conferences per year than I care to admit.  In talking with the HTML5 Live event organizers however, it feels like there will be a real sense of education and community throughout the day.  Those are always the best conference environments.  When attendees can take time to interact with one another, and the speakers in an open dialog, magic happens.

Q. Why is HTML5 exciting for web developers? Architects?

A. So many new APIs! What’s not to be excited about there?  New APIs mean new feature possibilities, or easier solutions to historical complex problems.  Or even better yet, ways to solve problems that were previously just not possible to solve with web standards.  And the best developers are always learning, always pushing the boundaries of themselves, and the technology which they yield.  All those APIs gives us all new opportunities to grow.

Q. Anything else you’d like to talk about?

A. I think some might find it odd to have Adobe, the Flash company, presenting at an HTML and/or web standards conference.  It is important to remember that Adobe has a long and bountiful history with web standards.  Adobe is also an active contributor to web standards proper, as well as various JavaScript frameworks.  At the end of the day, Adobe is about “Changing the world through digital experiences.”  And not on our terms but on yours.  We make tools to help you build the best experience possible – regardless of Flash, HTML, in-browser, out-of-browser, desktop, mobile, tablet, television, or any other screen.

Q. What are some of your favorite cigars?

A. Yes, I know it’s social faux pas to smoke these days, but for me, nothing beats kicking back with a nice cigar and a pour of single malt scotch (neat please).  Of late I’m finding myself particularly fond of Nicaraguan blends, so as you might imagine most of the new stuff coming from Drew Estates is a big favorite.  An Ashton Maduro is always an exquisitely constructed stick with a great taste.  I like the Illusione line across the board as well.  And Fuente has recently started shipping a great stick with a split wrapper that I’ve grown rather fond of enjoying.  On my list to explore further is the new Xikar line, HC Series.  Or, you know, when I’m in London, it’ll be anything Cuban.

While at 360Flex in Denver, Colorado earlier this year, I had lunch with Paul Trani.  Among the many topics discussed was a concept of producing a stable of well-designed applications for each person on the team.  I specifically asked Paul to focus on his take on the child’s game of “Memory.”  You know, you pick two cards, and if they do not match, you turn them over and it is the other player’s turn?  This initiative eventually turned into a game that Paul called “Monster Match”.

Fast forward to this afternoon, and I spent some time “helping” Paul test out his creation.  Honestly, I think I was there more for moral support than anything else.  Paul had the game running on just about every mainstream device – from tablet to smartphone, from iOS to PlayBook – under the sun.  It leverages peer-assisted technology to be able to allow head-to-head play on the same wireless network.  We even got it playing on the Logitech Revue (Google TV) box.

Paul Trani shows off Monster Match

It was there where I learned this humiliating lesson of not playing a game with it’s designer.  Since Paul designed the characters and their corresponding animations, every facet of the cards were burned into his memory.  It took him no effort whatsoever to remember where he last saw a particular card.  Needless to say, I was thoroughly trounced.  While we have had some interest around the game from third parties, and are not in a position to put it into the various application markets, we do hope to have a video of this game in action in the coming week or two.  Stay tuned.