Hoping for a Web App Future

If I think back to 2006/2007 I was very happy with how things were shaking out. The web was on the upswing and we were moving away from native applications. All of the great things about the web–its ubiquity, its freedom, its openness–were being harnessed to create native-like experiences that, I hoped at the time, would see us all do away with native apps. At the time, there wasn’t much (I thought) that web apps couldn’t do that we needed native apps for. How wrong I was. With the introduction of the iPhone, and subsequent smartphone releases, we’ve seen a huge shift back to native applications. Part of that is performance, right now native apps just feel better than mobile web apps, but it also came about because of just how many things native mobile apps could do. Geolocation, accelerometers, contact info–the smartphone showed how many things “apps” needed access to and for the most part those features have been exclusive to native applications. So just as the web was starting to really take off, we’ve slid back into native application territory.

It bummed me out, and still does. I thought AIR was an okay solution to the problem, but by the time AIR came around it was pretty clear that “the web” had come to mean HTML/JS, and I’m fine with that. So as PhoneGap started getting traction, and then Adobe took a major interest in the project, I was excited about the prospect of working on it as an Adobe evangelist, and more importantly, working with the teams behind it to see what else they had up their sleeves as the web moves forward.

But another side benefit is that it’s put me on what I’d consider the “right” side of the web argument. Two things got me thinking more about this. One was a very good post by a VC named Mark Suster, who while not telling his companies to focus exclusively on the web, has told them to make it a big part of what they do. So many startups nowadays are thinking completely mobile-first while ignoring the web, I’d say at their peril. When I think of my own usage, I’m still using a lot of native apps (for reasons I can’t quite figure out) but the ones I enjoy most have a web component that is well done and part of the overall experience. Yelp comes to mind. Another is Untappd. I can do almost anything I need to on the website version of Untappd so it’s not as though I’m getting a watered down experience. It more easily lets me move between contexts and devices while still using the service. I contrast that to something like Foursquare or Path. Both are mobile-centric, and with Foursquare I can’t check in because it wants to be sure that I am where I say I am (using GPS) but it still makes the web side of it less useful for me. Path is unusable when you’re not on a mobile device as far as I can tell. When I log in all I get is “download the app”. Which I hate. Mobile is clearly important but the web can’t be ignored.

Path Login

If this is what I see when I log into your site, you're too mobile-first.

The second thing that got me thinking more about this was something Brian Leroux pointed to on the Cordova mailing list, a post by Tim Berners-Lee about Installable Web Apps. This is a model I would love to see take hold. As Tim notes, there are a few things that users need to have when they’re installing web apps, and some trust/permissions issues that need to be figured out. Right now, I think PhoneGap is closest to this model, but a huge, huge, part of me wishes PhoneGap didn’t need to exist. If we could somehow skip the native shim and just take for granted that every platform supported, and at its core used, installable web apps. Maybe something like the WebOS model. But we’re not there yet. So for now, I’m glad I get to work with PhoneGap and build apps with web technologies. Eventually though I think PhoneGap can be used as inspiration for installable web apps. This is kind of how the standards world moves, as more and more people adopt something, people find ways to bring that something back into the standards. I think some of PhoneGap’s APIs and methodologies would make a great start at the idea of installable web apps. And I think the guys behind PhoneGap will be at the forefront of making those things happen, which means Adobe is going to be a really cool place to be over the next few years. It feels like there is a lot of potential to change the world and while I miss spending time with Flash, I feel like the HTML/JS/CSS work I’ve been doing and that Adobe is investing in, will make a similar impact on the web down the road.

Dealing with Binary Data from a Canvas Object using JavaScript TypedArrays

I’m not sure how helpful this will be for anyone, but during the process of doing a binary WebSocket demo I found myself learning a lot about JavaScript typed arrays and how that translates into binary data. The demo I wrote took Canvas image data and sent it over a binary WebSocket connection. The WebSocket server took that data and sent it out to all of the connected clients, who would then render the Canvas data as a PNG. It’s kind of a niche use case but I wanted to specifically create a binary WebSocket demo. It also was a more efficient way to send image data than doing something like base64 encoding it. First off, the Mozilla documentation was REALLY helpful. Major props to them.

Translating Canvas Data Into a Binary Format

Canvas has a getImageData() method that gives you an ImageData object. Within that ImageData object is a data property, which has the actual array data of the image. Normally I would have been able to stop right there because that would (in theory) have the information I needed. But what I had to get at was the ArrayBuffer. The way the spec has been implemented you can’t do anything with the ArrayBuffer. Instead you have to use an ArrayBufferView, which takes the form of TypedArrays in JavaScript. Luckily, to get the actual buffer you can just call the buffer property on any of the typed arrays and do what you want with it. But Canvas (at least in Chrome) is slightly different. The object you get from the ArrayBuffer of ImageData.data is something called CanvasPixelArray. Currently CanvasPixelArray doesn’t behave like a regular typed array, it looks like it will become a Uint8ClampedArray but the way it works in Chrome right now the CanvasPixelArray doesn’t provide access to a buffer property so you can’t send/access the ArrayBuffer data. Luckily getting that data into a Uint8Array, which you can get the buffer data from is pretty easy:

     imagedata = context.getImageData(0, 0, imagewidth,imageheight);
 
     var canvaspixelarray = imagedata.data;
 
 
     var canvaspixellen = canvaspixelarray.length;
     var bytearray = new Uint8Array(canvaspixellen);
 
     for (var i=0;i<canvaspixellen;++i) {
          bytearray[i] = canvaspixelarray[i];
     }

With that new Uint8Array all that we have to do is grab the buffer property and we can send it across the wire (beyond this post, but I’m planning on writing up the binary WebSocket info).

Reassembling the pieces

Now what I wanted to do was take that binary data from my Canvas and render it as a PNG file on the screen. The first step is to use a Canvas object to render out a PNG. But before that we have to get the data into a Canvas. In theory, you should be able to just do what happened above in reverse. But it’s not quite that simple. Once you get back the binary data from somewhere (WebSocket say), you’ve got an ArrayBuffer that you have to deal with. There is a putImageData() that takes an ImageData object, and we can create an ImageData object a few different ways, but you can’t set the data property of it. It’s read only. So we can’t take our data from the ArrayBuffer and just put it into our Canvas. We have to manually loop through the data property and line-by-line change the data.

          var bytearray = new Uint8Array(event.data);
 
 
          var tempcanvas = document.createElement('canvas');
               tempcanvas.height = imageheight;
               tempcanvas.width = imagewidth;
          var tempcontext = tempcanvas.getContext('2d');
 
          var imgdata = tempcontext.getImageData(0,0,imagewidth,imageheight);
 
          var imgdatalen = imgdata.data.length;
 
          for(var i=8;i<imgdatalen;i++)
          {
               imgdata.data[i] = bytearray[i];
          }
 
          tempcontext.putImageData(imgdata,0,0);

If the above isn’t clear, basically I’m just creating a new Uint8Array with the data from the server, then creating the temporary Canvas so I can get image data from it, and when I have that, I’m looping through the data property and inserting my own data from the Uint8Array.

Rendering it as a PNG

So now we have a Canvas (not being displayed) that has all of the data from our server, so it’s an exact graphical copy of the info we received. Turning that into a PNG is actually pretty easy because HTML is awesome. Canvas has a toDataURL() method that will take whatever is in the Canvas and create a string that can be put into the src property of an image. Then putting that image somewhere on the DOM will display the data as an image.

          var img = document.createElement('img');
               img.height = imageheight;
               img.width = imagewidth;
               img.src = tempcanvas.toDataURL();

Fin

Now that I’ve gotten my head around binary data a lot more, I’m kind of excited about JavaScript typed arrays. Looking through the list it looks like the typed arrays will help a lot with byte manipulation because of the different types. It also looks like they’re pretty fast (at least the fastest option at the time of that post).

HTML/JS/CSS and Tooling

I enjoyed this post by Grant Skinner that walks through his view of the evolution of technology and where/how/when tooling starts to come in. Adobe makes tools for web professionals. That’s what we’ve always done and that’s what we’ll do for a long time. You could even paint a broader brush that we make tools for creative people to share their creations. Watching our own evolution over the past year or so with regards to HTML tooling has been very interesting. We got some flack for not moving in earlier, but as Grant rightly points out, tools are a major investment and only once you have stability can you make that investment. It was never a matter of momentum around HTML or a focus on Flash, it was just the fact that things weren’t quite ready for tools.

In fact, I’d argue they still aren’t. But we’ve taken that as something that comes with the web. It’s always evolving, always moving, and while things will start to coalesce more and more, in the end, you have to get in and be ready to move. That’s kind of the approach we’ve taken with Adobe Edge. We just released Preview 4 of Edge which incorporates a lot of features that people have been asking for. Some of it I’m not even sure if it was on the original roadmap. But the Edge team made a conscious decision to be very agile, to build Edge in such a way that it could incorporate customer feedback quickly, and then getting product management on board to do lots of versions very quickly. I think it’s worked out very well and despite being on the earlier side of Grant’s curves, I think Edge will be a very helpful tool for a lot of people because of it.

Developer tools are a bit of a different story in terms of both ecosystem and readiness in my mind. There isn’t one, big, HTML IDE that people seem to like (akin to Flash Builder, Eclipse or Visual Studio). Instead people seem to be using a lot of different things and experimenting. What actually seems to be most popular right now are the basic text editors like TextMate or Sublime (my favorite). These seem to be focused on helping smart people work faster. Lots of shortcuts, lots of snippets, but not a lot in terms of helping along the learning process. And I think that’s just where we are now as far as HTML/JS/CSS tooling. But I’m excited to see that evolution as well and see what happens when frameworks get a bit more standardized and more general web developers start jumping into JS more and more. Will those people need a more robust HTML/CSS/JS editor that’s still developer centric? And I think the answer is yes, but I think it’s also tough to really see what that would look like until the JS/HTML/CSS stack is a bit more solid. But I’m excited to watch it and find out. And from what I’ve seen of Adobe’s HTML tooling side, we’re taking a good approach and I’m excited to see what people think as the PMs share more and more of it.

Slides for my PhoneGap Presentation

I had the chance to present to the Seattle Web App Developers Group (formerly the Flex UG) and here are the slides from that presentation. Thanks a ton to everyone who came out. It was a lot of fun and it was exciting to see so many people interested in PhoneGap.

Building a Mobile-Themed Slider without jQuery Mobile

I’m generally a big fan of jQuery mobile. I think it’s an ambitious project and it’s got some areas that could be improved, but I’m glad we’re contributing and think it’s going to be a huge boon for mobile web applications as they get bigger and bigger. But building PhoneGap applications with jQuery Mobile is a bit problematic partly because the goal for the project is “Delivering top-of-the-line JavaScript and a unified User Interface across the most-used smartphone web browsers…” and partly because jQuery Mobile can be tough to really customize if you want a specific look and feel. One of the things I wanted for something I’m working on is a slider that is a bit more boxy than the traditional slider used with jQuery Mobile. Some of this might have been possible with customizing the jQuery Mobile theme but I wanted to see what it would take to build my own from scratch.

This example is part of an app that’s using Backbone.js so I won’t post a working example because the Backbone.js infrastructure makes it kind of tough to strip out just the toggle button part. I’ll post the whole thing later, but wanted to show the general process.

The Look and Feel

To set it up I wrapped a div tag around a select tag with a couple of options. The div tag provided the border so it ended up being the track that the sider went along. This makes it pretty easy to customize the look and feel while still being very nicely degraded into a regular HTML select box.

                         <div id="toggle" class="toggleoff">
                         <select name="activetoggle" id="activetoggle" class="selectoff">
                              <option value="all">All</option>
                              <option value="active">Active</option>
                         </select>
                         </div>

Initially both the div and the select start with “off” classes. At this point the CSS starts to take over and create a more slider-looking button. There is a cool -webkit-appearance property that can be used on the slider to give it some instantaneous look/feel. But for the most part I rely on -webkit-border-image to customize the look and feel of the slider button. The CSS for the toggle button itself, the div tag, and the off states give us a basic looking toggle with no real toggle functionality because it behaves just like a regular HTML select box.

Toggle button off state

select {
     -webkit-appearance: push-button;
     margin-top: 0px;
     margin-bottom: 0px;
     height: 50px;
     width: 155px;
     border-style: solid;
     border-color: #cdcdcd;
     border-width: 1px;
     color: #555;
       font-size: 25px;
       overflow: hidden;
     padding-top: 2px;
       padding-bottom: 1px;
     white-space: nowrap;
     text-align: center;
 
}
 
.selectoff {
     -webkit-border-image: url( ../assets/button.up.png ) 4 4 4 4 stretch stretch;
     padding-left: 60px;
 
}
 
#toggle {
     margin-left: 5px;
     margin-right: 5px;
     margin-top: 5px;
     height: 50px;
     width: 312px;
     -webkit-border-radius: 2px;
     -webkit-box-shadow: 0px 1px 3px rgba(0, 0, 0, 0.1);    
     border: 2px solid #cdcdcd;    
}
 
.toggleoff {
     padding-left: 158px;
     background-image: -webkit-linear-gradient(#ffffff, #e7e7e7);
}

I have the benefit of using absolute positioning because I’m building this for an iPhone, but the CSS is pretty straightforward. I’ve got some padding-left properties so I can control how the text looks and where the actual toggle button appears within the div tag. This is why this particular strategy works. When I move between states I’m just going to change the position of the toggle button, I’m not actually doing anything with the select object itself other than changing how it looks and where it is. Here are the “on” classes.

 
.selecton {
     -webkit-border-image: url(../assets/button.down.png) 4 4 4 4 stretch stretch;
     padding-left: 30px;
}
 
.toggleon {
     padding-left: 0px;
     background-image:-webkit-linear-gradient(#bccead, #cbdfba);
}

Just a couple of small changes to gradients and backgrounds so that when our button is on or active, it looks like this:

Toggle button on state

Functionality

Now that the CSS classes are set up I used jQuery to first add/remove the classes I wanted and finally set the value of the select box programatically. As I mentioned, this is using Backbone.js so the code may look a bit odd.

          onMouseDown:function(event){
               event.preventDefault();
               if(this.displayingAll) {
                    $("#activetoggle").removeClass("selectoff");
                    $("#activetoggle").addClass("selecton");
                    $("#toggle").removeClass("toggleoff");
                    $("#toggle").addClass("toggleon");
                    $("#activetoggle").val("active");         
               } else {
                    $("#activetoggle").removeClass("selecton");
                    $("#activetoggle").addClass("selectoff");
                    $("#toggle").removeClass("toggleon");
                    $("#toggle").addClass("toggleoff");    
                    $("#activetoggle").val("all");                             
               }

My Backbone view has a variable, displayingAll, which I set to either true or false depending on what is currently visible. It helps track which classes need to be added/removed. But the first, and probably most important thing, is that I’m capturing the event and keeping it from doing anything. I don’t want the default select behavior at all so I can trap it and make sure it doesn’t keep doing the rest of its work. That means no pop up where the user can select values. Instead I go through and swap out the on/off classes to change the look of my button. Finally I use the val() method to set the value of the select so that what the screen is showing is the actual value of the select input.

So now the slider is working but we haven’t done any animation. So right now the slider just jumps back and forth. It works but it isn’t all that pretty. Luckily CSS3 is pretty awesome and we can leverage the very powerful -webkit-transition to help us out.

Animation

Animation for this example is insanely simple. Using the -webkit-transition CSS property we can listen for changes in the DOM on a specific property and whenever that property changes we can play a specific transition. The way I have set this up is that I’m changing the padding-left property between on/off classes so that’s the one we have to listen for.

Quick sidenote: I struggled with this for a bit. At first I was using the align property of the div to move the toggle button back and forth. That had the benefit of being able to scale better for multiple pixel-widths. The button would move back and forth just fine but there wasn’t a way to animate the align property that I found, which makes sense. So to do animation I had to use a value that could be animated and padding-left ended up being a decent option.

In order to get the animation to trigger we have to add a single CSS property to the #toggle div tag:

     -webkit-transition: padding-left 250ms ease-out;

So whenever the padding-left property changes (on a Webkit browser) a quarter of a second ease-out transition will play and move the toggle button back and forth. Under the hood we’re changing the value of the select so that if we have to rely on that value it’s all in sync while still creating a very specific look-and-feel for our toggle button.

I realize this isn’t entirely helpful without a working demo and I’ll work on getting a jsFiddle or something up to show it but I’m working on some other bits of the project and want to be able to share the whole thing when it’s done. One of the main things I learned: CSS3 transitions aren’t entirely intuitive when coming from the Flash world, but they’re very powerful.

Passing Data Between Pages in jQuery Mobile

Coming from Flex one of the things I’ve struggled a bit with is passing data between views in my jQuery Mobile applications. The template approach with Mustache worked really well, but it also had a lot of overhead. In fiddling around today I found a more hacky way that seems to work pretty well (though I think the Mustache route is still better). It relies on the fact that the pagebeforeshow method provides a prevPage property as part of its data object. That prevPage property is just a representation of everything in DOM of the previous page. That means it’s relatively easy to use selectors and that object to pass data to the new page.

The setup of my pages is as follows. My first page has a list of breweries, and each brewery page has a list of the beers that brewery uses. When you click on any of the beers, it goes to a form that can be used to rate the beers and provide some extra information about them. My goal was to prepopulate some of those forms with the beer data I already had. For instance I know the beer name, brewery, and style of each beer, so I should be able to prepopulate those, but they change for every beer so it has to be dynamic.

Within each page I defined a hidden div with two span elements with ids that represent the brewery name and brewery location (since they’re the same for every beer). Then within the beer list I have a hidden div that contains the beer name and the beer style. Here’s an example:

<div data-role="page" id="aleasylum" data-theme="e" data-add-back-btn="true">
     <div data-role="header">
          <h1>Ale Asylum</h1>
     </div>
     <div style="display:none">
          <span id="brewernameinfo">Ale Asylum</span>
          <span id="brewerlocationinfo">Madison, WI</span>
     </div>    
     <div data-role="content">    
          <ul data-role="listview">
               <li data-role="list-divider">Year Round Beers</li>
               <li>
                    <a href="#beerdetails">
                         <img src="images/hopalicious-thumb.gif" />
                         <h3>Hopalicious</h3>
                         <p>5.8% abv. Eleven separate additions of cascade hops give this American pale ale its lush citrus aroma and bold hop flavor without crazy bitterness. Hopalicious is available year round in six packs and on tap throughout the Madison and Milwaukee regions.</p>
                         <div style="display:none">
                              <span id="beernameinfo">Hopalicious</span>
                              <span id="beerstyleinfo">IPA</span>
                         </div>
                    </a>
               </li>
               <li>
                    <a href="#beerdetails">
                         <img src="images/madtown-nutbrown-thumb.gif" />
                         <h3>Madtown Nutbrown</h3>
                         <p>5.5% abv. Our nutbrown ale is velvety smooth with a rich caramel aroma. We blend seven different malts for just the right touch of sweetness and a creamy finish youÔøΩll really dig. Madtown Nutbrown is available year round in six packs and on tap throughout the Madison and Milwaukee regions.</p>
                         <div id="info" style="display:none">
                              <span id="beernameinfo">Madtown Nutbrown</span>
                              <span id="beerstyle">IPA</span>
                         </div>                        
                    </a>
               </li>

So in order to grab that, I just added an event listener to the pagebeforeshow method that uses selectors to grab the data. One of the critical parts is that jQuery selectors have an optional context property that can be set so that jQuery only selects from that context. In this case, since my pages are all using the same id names for the values, I need to set the context so that the selectors are only pulling from the previous page and not the entire document.

 $('#beerdetails').on('pagebeforeshow',function(e,data){
     var beername = $('.ui-btn-hover-e #beernameinfo',data.prevPage).text();
     var brewername = $('#brewernameinfo',data.prevPage).text();
     var brewerlocation = $('#brewerlocationinfo',data.prevPage).text();
     var beerstyle = $('.ui-btn-hover-e #beerstyleinfo',data.prevPage).text();
     $('#beername').val(beername);
     $('#brewername').val(brewername);
     $('#brewerlocation').val(brewerlocation);
     $('#beerstyle').val(beerstyle);
 });

The code above executes before anything gets displayed on the new page, grabs the values from the first page with the hidden div tags, and then sets some of the form fields to those new values.

It strikes me as a bit odd that there isn’t an easier way to do this, so it could be that I’m just not googling the correct thing and jQuery Mobile has something built-in to help with this issue. It does seem like this can be done by using URL variables, but what I like about this approach is that it’s a bit more semantic and there’s no required parsing of the URL string.

Flex Mobile European Tour 2011

Next week I’m going to be hitting the road with my colleague Mihai Corlan to spread the news about what Adobe has been up to the past few months. The primary reason for the trip is to show off the work the product teams have done with Flex on devices. Mihai and I are going to be doing some hands-on sessions showing just how easy it is to build great looking applications for iOS and Android. Bring your laptop, a copy of Flash Builder, and a device and we’ll walk you through all the steps you need to go through to start building and deploying mobile applications.

The other part of these events is providing some firsthand demos of some of the things we showed off at MAX. I think MAX was a major turning point for Adobe and Mihai and I will be showing off the touch tooling, talking about the creative cloud, and showing all of the things Adobe is up to in the world of HTML5. Plus we’ll give you some sneak peaks of the next generation of the Flash Platform. So there’s a ton of info and you’ll have the chance to ask questions firsthand. 2012 is going to be a great ride for the Adobe community so we want to make sure you have all the info you need to be successful.

Here are the cities we’re hitting:

Update: For those of you in the UK, there is an event on Monday, the 7th. I couldn’t make it out in time for that, but Mihai will be there covering everything.

November 9th

November 10th

November 11th

November 14th

November 15th

November 17th

November 19th

Can’t wait to see you and talk about application development and Adobe’s 2012.

Using Lawnchair for Data Storage in PhoneGap

I’ve been looking around for good ways to store information for a PhoneGap application I’m working on. I think that the PhoneGap SQL APIs may still be the best bet but I also wanted to check out some of the more unique storage options. One of the options I came across was Lawnchair, by Brian Leroux. One of the beautiful things about Lawnchair is that it’s incredibly simple. It does persistent JSON storage, has adapters for different storage options (localstorage, webSQL, etc) and is very lightweight. One of the not-fun things about Lawnchair is that it’s incredibly simple. While I found it easy to use (mostly) there were some areas that didn’t work. I think part of the issue is that I don’t have a lot of experience with NoSQL solutions like CouchDB (where Lawnchair draws a lot of its inspiration) so I think a lot of the issue lies with me.

That said, I found it to be a powerful, if basic way to store data and I think it’s worth knowing about. This isn’t going to be helpful for people who know JavaScript pretty well or who have used Lawnchair a lot, but I figured jotting downs some of my thoughts and the basics of it would be helpful for my learning process. So here it is.

Quick Info Up Front

One of the first things I ran into was that Lawnchair will behave slightly differently depending on the adapter you end up using. For instance, I started out using the default ‘dom’ adapter, which just ties into the localStorage API and uses key/value pairs. So when you call the save() method, you pass in a key with values. But upon switching to the webkit-sqlite adapter, which relies on databases, I found that the old key/value pair code didn’t seem to work because of the way that the webkit-sqlite adapter assigns ids. The key is still stored, but it doesn’t seem to work as a selector. I think this might have something to do with the fact that I’m using ints as my key and not strings, but haven’t done enough research.

This post will use the webkit-sqlite adapter so keep that in mind as you’re looking at the code.

Getting Started

Getting started with Lawnchair is a beautiful thing. Simply drop the Lawnchair.js file and whatever adapter you want to use, then just start using the Lawnchair class. I found it’s helpful to assign it to a variable so that you can access it easily from other functions. It also requires a callback function. Normally, when you set the callback, you can use the this scope to perform operations on the database, but in my example I’m just tracing out that we connected.

     var beers = Lawnchair({name:'beers'},function(e){
          console.log('storage open');
     });

So beers is now the reference to my data storage and I can call the Lawnchair APIs using that variable.

Saving Data

While at first I was a little bit confused about how to treat Lawnchair as a way to store more complex data types, storing objects is incredibly easy. Just wrap whatever you want in a JavaScript object and then call the save method.

          var obj = {beername:"Wet Hop",brewername:"Deschuttes",brewerlocation:"Bend, OR"
                         ,beerstyle:"IPA",quantity:1,purchasedate:"12/11/2011",price:"9.00"
                         ,cellardate:"9/11/2011",cellartemp:40,brewdate:"8/10/2011"};
          beers.save({key:"1",value:obj});

In this case, I assigned a key of “1″, which makes sure it’s a string. If you just use integers, it ends up translating to the database as 1.0. This actually becomes kind of a pain later on as you’ll see, so it’s important to keep it in mind. If you use a string as your key, it will just make the ID that string, so it’s a little bit simpler to use. Below is what the data storage looks like when you don’t use a string.

By using strings I found it makes the retrieve operations a lot more simple. In fact, I couldn’t figure out how to use the get operation using the webkit-sqlite adapter and a number for the key. Getting 1 didn’t work and getting 1.0 didn’t work, so I just ended up using a string. I think that’s more a limitation of my JS knowledge than anything, but it was something that I struggled with.

One cool feature of modifying data in Lawnchair is that when you save() something, if you pass in a key that already exists, it will just overwrite that existing key. No having to worry about update versus insert, Lawnchair just figures it out and saves the data correctly.

Getting Data

There are a couple of good ways to get data; the first is the get() method. Pretty straightforward: You pass in a key, and it will return the value associated with that key.

             beers.get("1",function(obj){
                  console.log(obj);
             });

The object that comes back includes a key property and a value property, which is where the data is stored. So in my example object above, I can reference obj.value.beername to get the name of the beer.

Another helpful retrieve method is the all() method, which just dumps every object from the storage area in an array. Every function in Lawnchair can use a callback function and in this one it’s especially helpful. In my app I use the all() method to loop through the beers and display them in a list.

     beers.all(function(arrBeers){
          for(var i = 0; i<arrBeers.length;i++)
          {
               console.log(arrBeers.length);
               var listdiv = document.createElement('li');
                 listdiv.setAttribute('id','listdiv');
                 listdiv.innerHTML = arrBeers[i].value.beername;              
               $('#beer_list').append(listdiv);    
          }
          $('#beer_list').listview("refresh");
     });

Modifying Data

As I mentioned above, the way Lawnchair works is that when you save an object with the same key, it just overwrites it. So the key to modifying data is just grabbing it using the get() method, adjusting the data on the object, and calling save() with the same key.

          beers.get("1",function(thisobj){
               console.log(thisobj);
               var obj = {};
                    obj = thisobj.value;
                    obj.beername = "Not Wet Hop";
               beers.save({key:thisobj.key,value:obj});
          });

I found it kind of helpful to use the existing key on my retrieved object to save since that’s a good way to make sure you’re saving the object you want and not overwriting another one or creating a new one. Key management becomes kind of important with Lawnchair but it’s not tough to do.

Beyond

One of the things I found helpful after digging in was checking out the Lawnchair plugins. The couple that I downloaded were the query plugin and the callback plugin. The query plugin just lets you use some basic query syntax to pull out information. The callback plugin lets you specify callbacks for before and after events so you can make your code do specific things based on when you’re accessing the data.

It’s also really important to take a look at the adapters because that’s critical to making sure the application will work across devices. In general the adapters should be hot-swappable in that you should be able to just move adapters in and out without having to change the code. I had some trouble getting the latest DOM adapter to work, so I can’t totally verify that, but as I understand it that’s the way it’s supposed to work.

Conclusion

After messing with it, I think Lawnchair is one of the most straightforward ways to store data for a basic PhoneGap application. It’s not going to hold up to all of the use cases that a complex application needs, but for something where you’re storing some simple data, Lawnchair is perfect. It leverages existing web storage options and using adapters you can make sure it’s cross platform.

Full Code

I posted the full code snippet here. Keep in mind I’m a JavaScript newbie so if you see things I’m doing wrong I’d be grateful to hear about them.

MAX Reflections

I’m sitting down with some tea while my little girl is taking a nap feeling the big exhale from MAX. The energy of the past few days has been largely fantastic and I always find MAX to be rejuvenating both from a professional standpoint and a personal standpoint. Getting to connect with the community and my colleagues at Adobe has been great. In the contrast to the buzzing of MAX, the current deep quiet of my house leaves me reflecting a bit on the week.

This will go down as a very transformational MAX. The announcement of the Creative Cloud and the fact that it will include all of Creative Suite Master Collection as well as the touch tools and services (including TypeKit) is one of the biggest things I’ve seen from Adobe in a long time. And it feels like we’re jumping in with both feet and getting back to the core of what Adobe does: empowering designers to create with great tools. I thought the news about the single edition of the Digital Publishing suite was a perfect example of that. It makes the blossoming world of digital publishing accessible to more people.

The PhoneGap announcement was, for me, the most significant announcement of the week. By acquiring Nitobi (fantastic guys) and contributing the PhoneGap project to the Apache Foundation, Adobe took a huge, huge step into the world of HTML5. It was a perfect way to start a day 2 keynote that focused on the things Adobe is doing to be a part of the HTML5 ecosystem.

Based on the Twitter stream there seemed to be a feeling that the lack of traditional Flash indicated that Adobe is giving up on it. I think that misses the big picture. With the Nitobi acquisition and the embracing of PhoneGap, Adobe is making a significant and meaningful bet on the web and cross-platform mobile applications. This can’t be overstated. For Flash developers we have AIR, which will let you build cross-platform mobile applications. For HTML developers we have PhoneGap, which will let you create cross-platform mobile applications. Both are web technologies that don’t require developers to be locked into a specific operating system or type of device. You see the same thing with our digital publishing suite; it doesn’t matter if you want to deploy on iOS, Android, or PlayBook, you can. And that’s possible largely because of the web formats that go into creating the DPS apps.

This isn’t about Flash versus HTML, this is about supporting creative and interactive content across the broadest platform in the world: the web. Whether it’s mobile apps or browser content; animations, interactive web applications, or 3D gaming experiences, Adobe genuinely believes that the web is the best way for our customers to deliver their creations. By making PhoneGap a cornerstone of our story, I think we’ve proven our commitment to that mission.

I’m glad I was at MAX to see all of this in person.

Edit: This is a great piece by Daryl Taft of eWeek that talks about Flash and HTML. And it’s great to see that the “and not or” message is getting picked up. But what I like about this particular message is that when you follow it upstream a bit more, it just means we love the web. And if that’s the case (and I feel like it is) then the technology becomes secondary to the goals of helping people create cross-os and cross-device content with web technologies.

Flash Player 11, AIR 3, and Flex/Flash Builder 4.6

Today is a pretty big day for Adobe developers. We’re officially announcing Flash Player 11, AIR 3, and Flex 4.6 and Flash Builder 4.6. The bits will be available in early October, but we’re announcing things today to help provide developers with information on what’s coming. I’ve been at Adobe for 4 years now and it’s been a very interesting 4 years as the landscape has evolved. It’s definitely been an up and down ride for Adobe developers, but the world has never been a better place for interactive developers, and these set of releases provide a ton of functionality aimed at helping Adobe developers create content in the most cutting edge places.

Gaming

We’ve been doing a lot of work to help enable console-esque games on top of the Flash Platform. Flash Player 11 includes Stage3D, which is going to open up a whole new world for game developers. Zombie Tycoon and Tanki are initial examples of what can be done and I can’t wait to see what comes of it. I’m reminded very much of the early days of Flash where a bunch of creative people were given a technology that was pretty open-ended and poked and prodded to create a bunch of very cool things. I think we’ll see that kind of revolution with Stage3D because of the ubiquity of Flash and the creativity of our developer community. Also in the gaming bucket is a framework we’re working on called Starling, which leverages Stage3D to create a super-fast way of doing parts of 2D games. It’s a great merger between the underlying technology/performance benefits of Stage3D and the kinds of things people want to do in 2D games. I think it’s also going to see some traction beyond games as agencies start to use it to enhance 2D content.

Mobile Applications

Flex and AIR have really found a great place in mobile applications. The performance enhancements in 2.7 made building native-experiences with AIR possible and we’ve seen some great examples of that in action including Machinarium and Caltrain Times. I’ve been impressed with performance on my 100 Days of Exercise application on iOS. I’m incredibly, incredibly excited by what this means for Flash. There’s a definite need to create mobile apps that can be deployed to multiple application stores. The Flash Platform provides a way to create great looking, high-design applications with near-native performance that can run on multiple devices. That’s a big deal.

And this release of AIR 3 goes where we haven’t gone before on the Flash Platform with native extensions. Now if there are features that aren’t included in AIR, like access to a credit card reader, you can build those extensions in native code and then link them to your AIR applications and leverage those libraries. It’s a great mix of native for specific use cases and AIR/Flash for fantastic user interfaces. It’s a big, big, big deal to be able to extend the platform and it’s a huge step.

I also think we have one of the best mobile-tool chains out there. Flash Builder 4.6 is going to help with creating those native extensions while also enabling the use of captive runtime in AIR so your applications don’t need to rely on the external AIR runtime on Android. Combine that with the enhancements that are coming in Flex 4.6 and it adds up to a world class mobile development platform that lets you reach more devices that matter. Flex 4.6 is especially exciting because of the new components that have been added. Flex and AIR are far and away the best toolset for interactive developers or any mobile developer who needs to create content for multiple devices. The apps you can build with Flex and AIR are going to stand out from the boring, standard apps that have started to litter app stores. Creativity will win the day and creativity is at the core of Flex/AIR.

Beyond

So this is a huge release, and I’m excited. But I’m also excited about the future of Adobe and how we are responding and will continue to respond to the evolving marketplace. As Danny Winokur, VP and GM of the Flash Platform, said recently:

“We’re not so concerned about what the right technology is for that as long as we’ll be able to deliver those experiences. We’re working with Microsoft and other members of the HTML community including Google, Apple, and others to enable rich experiences on HTML5.”

This is not a technology war. Adobe is about enabling developers to build the best possible experiences with the technology they want. We want to build tools and services that cater to that ethos. That takes the form of cutting-edge gaming features like Stage3D and world-class mobile app features with Flex, AIR and Flash Builder. But HTML5 is exciting for a lot of reasons, and Adobe will help developers there as well. If you’re an interactive developer, the future is very, very bright for you.

So you better get a good pair of sunglasses.