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.

JavaScript Templating – Kind of Like ItemRenderers or Binding from Flex

One of the things I’ve been struggling with on the HTML/JS app I’ve been working on is how to get binding-like functionality. It seems like there are a few ways to do it, but the ones I looked at didn’t seem to fit with the general pattern of JavaScript and I wanted something a bit more elegant. Luckily, I just didn’t know what to look for, and once I came across templates, I realized I had found exactly what I wanted. Templates in JavaScript act like ItemRenderers but in my example I was able to use them to create a page, and then dynamically change the data on that page almost like I would if I were binding an object to a form in Flex.

And that’s almost exactly what templating lets you do. Here’s my example. I’m creating a list of beers, and when I click on one of those beers, I want to load a bunch of information about that beer in a form so I can make changes to it and save those changes to my database. With Flex Mobile I was able to do that pretty robustly because I can pass data between views very easily and bind elements in the second view to my data. With jQuery mobile, there’s nothing quite that fancy, so I had to rely on templates.

It turns out there are a ton of JavaScript templating libraries out there. Underscore.js includes a templating feature and looks interesting but I tried Mustache.js off the bat and found it pretty simple to use.

I started off with the template itself. In my case, it was a basic form that I called beer_detail.mustache

    <form action="#" method="post">
<div id="beername" data-role="fieldcontain">
            <span id="beerlabel">{{ beername }}</span>
            </div>
        <div id="brewername">{{ brewername }}</div>
        <div id="brewerlocation">{{ brewerlocation }}</div>
        <div id="beerstyle">{{ beerstyle }}</div>
<hr>
        <div id="quantity" data-role="fieldcontain">
<label for="quantityslider">Quantity: {{quantity}} </label>
<input type="range" name="quantityslider" id="quantityslider" value="{{ quantity }}" min="0" max="25"  />
</div>
        <div id="purchasedate" data-role="fieldcontain">
        <label for="purchasedatefield">Purchase Date:</label>
                <input type="date" name="purchasedatefield" id="purchasedatefield" value="{{ purchasedate }}"  />
</div>
        <div id="price" data-role="fieldcontain"><input type="text" value="{{ price }}"></div>
        <div id="cellardate" data-role="fieldcontain">
        <input type="date" name="cellarfield" id="cellardatefield" value="{{ cellardate }}"  />
</div>
        <div id="cellartemp">Cellar Temperature: {{ cellarTemperature }}</div>
        <div id="brewdate" data-role="fieldcontain">
        <input type="date" name="brewdatefield" id="brewdatefield" value="{{ brewdate }}"  />
        </div>
<a href="#pintley">This beer on Pintely</a>
        <button type="submit" data-theme="a">Submit</button>
        </form>

The double brackets {{ }} are all of the variable names that the template looks for so those will be replaced with actual data when the template gets rendered. I liked the similarity to Flex’s binding syntax.

One of the things you can do in jQuery Mobile is pass url variables, so for the first part of my application, I use a list of the beer names with a link to a page named beer_details.html that includes an id parameter that I use to look up the beer. In this example I’m using a Lawnchair database called “beers” and just calling the all() method to get all of the beers in the database. Then I iterate through those and build the 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 = '<a href="beer_details.html?id='+arrBeers[i].key+'">'+arrBeers[i].value.beername+'</a>';              
               $('#beer_list').append(listdiv);    
          }
          $('#beer_list').listview("refresh");
     });

The beer_details.html page itself just contains some skeleton code for jQuery mobile. The code will inject the template into the div id="content" tag. This way, all of the jQuery functionality stays with the application so it can use the back button, has the header/footer, etc and plays the transitions back and forth. So it’s pretty bare bones:

<div data-role="page" id="beerdetail" style="type-inline">
     <div data-role="header">
          <h1>Your Beers</h1>
     </div>
     <div id="content" data-role="content" align="center">
 
     </div>
     <div data-role="footer" data-id="foo1" data-position="fixed">
          <div data-role="navbar">
               <ul>
                    <li><a href="beers.html">Beers</a></li>
                    <li><a href="styles.html">Styles</a></li>
                    <li><a href="scan.html">Scan Barcode</a></li>
                    <li><a href="locations.html">Locations</a></li>                   
               </ul>
          </div>
     </div>
</div>

So now that the structure is set up, we can use Mustache to populate our template with data and inject the resulting HTML into the DOM. The first step is to set up the data object. In this code I parse the URL to figure out the ID of the beer, then use Lawnchair to retrieve that data. I’m listening for the pagebeforeshow method, but I’m not sure if that’s the best one. But it allowed me to get the data and change the DOM before the page showed, which is important for being able to render the template.

     $('#beerdetail').live('pagebeforeshow',function(e) {
          var beerID;
          beerData = {};
 
 
          var hashes = window.location.href.slice(window.location.href.indexOf('?') + 1).split('&');    
 
          for(var i = 0; i < hashes.length; i++)
          {
            hash = hashes[i].split('=');
            if(hash[0] == "id")
            {
                 beerID = hash[1];
            }
          }                 
 
     });

Once I have the beerID, I can use LawnChair to grab the information. Then I can use that object and pass it to Mustache to build the template. The Mustache library uses a .to_html() method that takes a reference to the template and the object that holds the data, in this case beerData. In the example below, there’s a bit of chaining going on. First I have to get the data, then when that is returned, it calls a function that will go out and load my .mustache template using Ajax, and finally, when that page is retrieved, I call Mustache.to_html() to get the HTML and then inject that HTML into the content so it will render correctly. This code goes inside the pagebeforeshow event handler.

          beers.get(beerID,function(obj){
               beerData = obj.value;
               $.get('templates/beer_detail.mustache',
                    function(data){
                         template = data;    
                         var renderedhtml = Mustache.to_html( template,beerData);
                         $("#content").html(renderedhtml);    
                    });
          });

And voila! Now when we click on a beer from the list, the data gets inserted into the template and when we move back and forth the data will update as we click on new beers.

This is much, much easier than trying to go through the DOM and insert/modify the form variables and also lets us potentially use different templates depending on the beer I choose. So far I’ve found templates to be helpful for getting around concepts like binding in HTML/JS.

I’ve gone ahead and put this project up on GitHub. It’s kind of a disaster at this point, since it’s basically my learning project, but you can see how this was done.

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.

Why I’m Doing PhoneGap

I’ve started to see some general questions and fielded a few emails from people asking about why the big push around PhoneGap on the Adobe side. In general, everyone knows the basic answer: we acquired Nitobi (the company behind PhoneGap), so now as Adobe evangelists, it makes a lot of sense for us to know it and be able to talk about it. And I think we’ve done a pretty good job of that. Christophe has a demo app (with source code) up, Greg has a couple of really good posts on it (especially this one that talks about how PhoneGap affects Flex evangelism). So at a general level, it shouldn’t be a huge surprise, but for me it’s quite a bit deeper than that and I wanted to provide a bit of context.

My desire to learn PhoneGap (and by extension get a lot better at HTML/JS) comes from two places. One, if you aren’t learning new technology, you’re not adapting as a developer. Two, as I’ve been looking around and trying to get my head around PhoneGap/HTML, I’ve found some rougher edges. Since I work at a tools company, I want to know where those edges are so that as Adobe builds out tools for this technology stack, I can provide good feedback to the product teams.

New Technology

I’ll say this a thousand times: I think AIR and Flex are the best way to build cross-platform mobile applications. I think they’re arguably the best way to build mobile apps in general for specific types of apps. And with AIR 3.0, AIR has never been more powerful. Stage3D is coming, we have native extensions and captive runtime so as a developer you can really blur the line between your AIR app and native functionality. But as great as I think native extensions are for our developer community, I’m not personally that excited by spending a lot of time writing them. I love the web. What got me so excited about RIAs back in the day was that you could build desktop-like apps with web technologies. I fully believe that Flash is part of the web, and I always will. Java and Objective C are decidedly not web technologies. And I’m not really that interested in spending a bunch of time learning Java/Objective C code. I don’t think that many AIR developers will have to roll their own native extensions, but it is one of the cool new parts of the platform, so a lot of the Adobe evangelists will be spending time getting up to speed on how to build them. That just doesn’t get me excited. Same goes for Stage3D. The stuff you can do with 3D in Flash Player is mind-blowing. I’m just not a 3D developer or a game developer. Luckily the Flash Platform is evolving beyond that as well. The stuff coming up with concurrency and potential enhancements to ActionScript both fall into what I’d call the “web world” and I’m excited to dive into those and get to know them as they get closer.

But, while I’m waiting, it turns out we now have a pretty cool HTML/JS mobile story with PhoneGap. I’ve been dabbling for a little while in jQuery mobile and HTML/JS and I’d consider myself an average JS developer. But you’ve always got to be learning, and if you love the web, you can’t not be good at JavaScript. I’m kind of ashamed that I’m not better, but this is a great opening for me to dive in, dedicate a ton of time and energy to getting better, and coming out a more holistic web developer. One of the things I love about the HTML/JS community is just how varied it is. There are JS developers of all stripes creating their own frameworks, own solutions to architecture problems, their own server solutions, and hell, even their own languages that eventually end up as JavaScript. The raw creativity of the web ecosystem is on full display when it comes to HTML/JS. And there is a certain zen to the chaos that I find intoxicating. I desperately want to be a part of that and the fact that I’m behind the curve is kind of depressing.

Helping Adobe

Which brings me to the second reason I’m planning to dedicate a ton of time to the PhoneGap stack. There are quite a few areas where the workflow is downright broken. My recent foray into on-device debugging is one example. Some of that is just that I don’t know enough, but there are also some real gaps in tooling, services, etc. We’ve got some smart people at Adobe who know the JS/HTML world pretty well. But we can always have more and if we want to provide value to developers in the space, that’s going to require knowing where the gaps are, knowing where to spend our time, and what kind of solutions will be helpful. I want to be able to provide that feedback and the best way to do that is to really know it. The hope is that I’ll be able to contribute in a small way to what Adobe will contribute to the open web ecosystem for developers.

Viva Flash!

So for me this particular foray goes beyond just learning PhoneGap to get up to speed. I think it’s a really cool time to be an Adobe evangelist and I came away from MAX a lot more invigorated than I’ve felt in a long time. Part of that is the Flash side (this session on the roadmap was excellent). But a big part of that was definitely that I think Adobe is going to make a positive impact in the HTML/JS space. The Nitobi guys are all insanely talented and I think that with them we’ve got a vision for mobile apps rooted in web technologies. I’m ready to contribute to that vision.

Update: And Ray pointed out he’s got a ton of stuff up as well.

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.

Success Window fix in Facebook ActionScript API

Facebook ActionScript APII just added a fix to an issue with the Facebook ActionScript API I ran into where after logging into Facebook on Android, the success event listener would never get called, the login window would never disappear, and you’d be left with a white StageWebView window with the word “Success” in it. It had something to do with a change in how AIR for Mobile handles StageWebView events.

I also noticed that when you would pass in a custom viewport for StageWebView in the initial window, the code would overwrite any settings and make it full screen. I didn’t think that was the expected behavior so I patched some code in FacebookMobile to make sure that if the login function has a viewPort specified, that one gets used instead of creating a new one.

I’m working on getting it added to the release SWC but I can’t tell exactly how the project has that process set up, so for now if you want the fix you’ll have to check out the source directly.

I’m spending some time with the Facebook API recently so if you have any issues, let me know.

AIR for Android Application – 100 Days of Exercise

100 Days of Exercise

100 Days of Exercise

Part of the evangelism team has been spending the past few weeks diving in and creating AIR mobile applications. We didn’t want them to look like just any other app so we hired the folks at The1stMovement and had them come up with some very cool designs across a few different application ideas. They gave us the PSD files and then we went to work developing them. It has been a great experience and I think it touches on something that AIR and Flex do really well; expressive, beautiful applications. This is an area where HTML/JS can’t quite cut it and that is pretty tough to do with native toolkits on iOS or Android. But it’s exactly the kind of thing that Flex and Flash excel at. Plus with AIR these apps can be taken and deployed to other platforms (you’ll see a version of all of these on the Apple App Store before too long). The apps themselves are awesome. Terry Ryan built a helpful item-finder called Finicky which incorporates a very cool grunge design. Renaun Erickson built the best looking Caltrain app on the market for finding train schedules and the closest stop to you based on GPS. Both are really spectacular.

Profile Screen

Profile Creation Screen

My contribution is 100 Days of Exercise, an app that will help track exercise progress over 100 days. Evidence has shown that if you do something 100 days in a row, it becomes a habit, and this app helps track that. It’s also supposed to help redefine what exercise means. For a lot of people, they think it means 3 hours at the gym, or an hour run, but it doesn’t have to. Just commit to something small for as long as you feel like you can do it. The goal is to get to the end of 100 days, not to throw yourself into a completely new lifestyle.

Wheel of Death

The Date Selector

One of the things I’m most proud of is the date picker. This is going to be an application for both Android and iOS and those platforms do date pickers very differently. Android has the buttons for up and down and iOS has the scroller. I wanted something that was very high design that would translate across both platforms. They came up with the “wheel of death” as a way to represent the month and date. So I took some of Evtim’s wheel layout code and created a custom Flex list layout that did what I wanted. It looks nice, is unique, performs well, and translates across any platform.

It’s been a fun project and I’m looking forward to adding a few things down the road. If you have any feedback, definitely drop me an email and let me know.

Dismissing a Flex Mobile PopUp With the Back Button

In an application I’m building for Android I use a lot of pop up windows (because that’s how Android does combo boxes) and I was having a tough time figuring out how to get them to close when the user pushes the back button. By default, the framework will call navigator.popView() whenever the back button gets pushed and the only way to override that is by doing it at the application level, which isn’t really ideal.

So here’s what I came up with.

Basically I intercept the removing event on the view, which is the last event that gets called before the view goes away. Using that event I check to see if any of my PopUps are on the screen using the isPopUp property and if they are, I use event.preventDefault() to stop the view from being removed and instead just remove the PopUp.

protected function view1_removingHandler(event:ViewNavigatorEvent):void
{
     if(exerciseList.isPopUp)
     {
          PopUpManager.removePopUp(exerciseList);
          event.preventDefault();
     }
 
     if(timeList.isPopUp)
     {
          PopUpManager.removePopUp(timeList);
          event.preventDefault();
     }
}

I’m not sure if this is really the best way to solve this issue, so if anyone has something that they’ve done I’d love to hear about it in the comments.