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.

Slides and Code from 360Flex Denver

360Flex Denver360|Flex Denver was an absolutely fantastic event. I was at the first 360 and have watched the event grow and mature over the years. It’s always been the best Flex conference out there, but there was something about those first few 360′s that had so much energy and got the community excited. This event felt like that. I’d rank it as one of the best 360′s I’ve ever been to. The attendees were enthusiastic and great to talk to, the keynotes were awesome and inspiring, and John and Nicole were at the top of their game as far as hosting went. It might have been all of the mobile stuff, it might have been the announcement on day 2 of Project Spoon, but this 360Flex was just all around great.

So of course, I made a bit of a misstep with my talk. At what was one of the greatest Flex conferences of the past 5 years, I go and give an HTML5/jQuery talk. But hopefully it was still fun. And to be honest, as I dove into HTML5 and jQuery for this talk, I learned that we have it very, very good as Flex developers. There are a lot of great things about HTML5 and especially jQuery, but if you’re building complex RIAs and applications, Flex has solved a ton of problems that the HTML5/JS world hasn’t yet. I definitely think they will, and the community around JS and jQuery is great, but as a Flex developer, you’ve got the best of both worlds and you’re going to be able to jump over to jQuery/HTML5 projects and bring some very valuable knowledge about building complex apps.

Thanks to everyone who attended the talk. My slides can be found here (and embedded below) and you can grab the demos from my GitHub repository here.

Building a jQuery Mobile Application with the PlayBook WebWorks SDK

I remain really impressed with the PlayBook as a device. It’s a great size, has fantastic specs, and the user experience that the QNX team has built is fun to use. Primarily I’ve been using the Flash-based AIR SDK for my tests and applications. I think that’s the best way to build PlayBook apps and when I’ve talked to people I’ve gushed that it’s the best mobile Flash development experience we have. But there are also a lot of JS/HTML developers who will want to deploy PlayBook content and RIM has included a WebWorks SDK to make that possible. So I took it for a spin, porting my landmark finder to the device.

Getting Started

The first thing you have to do is grab all of the required files. You first need to make sure you have the AIR 2.5 SDK (which, since we’ve moved to 2.6, can be found here). Then you can grab the WebWorks SDK and the simulator files from the BlackBerry developer site. By default the WebWorks SDK installs to your user directory, so if you can’t find it, look for a folder called bbwp.

Building the Application

There really isn’t any special trick to getting jQuery Mobile working on the PlayBook. It works perfectly and it performs really well. My application just took the core jQuery Mobile framework and included two different screens; one for getting the location and another for a list of landmarks that are close to you. It uses the GPS coordinates from the device and then goes out to Geonames to find a list of landmarks in the area. Selecting one of the landmarks takes you to Wikipedia so you can find out more about it.

The code (above) doesn’t have anything particularly tricky, which is a testament to how easy it use to use the WebWorks SDK if you’re an HTML/JS developer. I was even able to use the standard HTML5 Geolocation AP. RIM hasn’t announced any plans for geolocation on the device so I’m not sure what the final status or experience will be. Today on the simulator you can get a geolocation object but you can’t get position, so I just default to using the lat/lng from my neighborhood here in Seattle.

Creating the Config.xml File

The PlayBook uses a manifest file, config.xml, to control the title, icon, and features on the device. The config.xml file is pretty straightforward and if you’re familiar with app manifest files you should have no issues. There is also some decent documentation here. Mine is below.

There were a couple of gotchas I ran into when I dove into the config.xml file. The first was the access attribute. Instead of asking for blanket access to the web, you have to specify which domains your application will access. In my case it was just the Geonames API. But if you’re pulling down remote source files (say from jQuery) you’ll also need to include that domain.

Compiling the Application

Compiling and deploying the application was a bit tougher. Right now the only tools I could find are command line tools for the compiling, packaging, and deployment of WebWorks applications. The first thing you have to do is zip up all of the files you want to include in the application. The packager tool converts a .zip file into a .bar file, the native file format of the PlayBook. So I selected my config.xml file, my index.html file, and then all of the css and js files from jQuery to create geonames.zip. The tool you use to do that is in the bbwp directory in the root of the WebWorks SDK directory. Here’s the command. You can also specify an output directory with a -o switch. By default it creates a bin directory in the directory you’re in and puts the .bar file there (my WebWorks SDK is in an SDKs folder in my Library).

/Library/SDKs/com.blackberry.dev/bbwp/bbwp geonames.zip

That will build a geonames.bar file in the bin directory of your project.

Deploying to the Simulator

I won’t get into how to set up and configure the simulator because that’s been covered in other places. But once you have the simulator set up, you can test and deploy your application. Within the bbwp directory you’ll find a blackberry-tablet-sdk/tools directory, which has a bunch of libs for deploying and signing your application. To test it on the simulator you’ll use blackberry-deploy. To deploy it you have to have the simulator in development mode and know the IP address of the simulator and the password on the device. With that info you can deploy your .bar file to the simulator with this command.

blackberry-deploy -installApp -device  -package "bin/geonames.bar" -password 

And now you should be all set!.

Word of Caution

This particular example isn’t fantastic for the simulator because it uses the geolocation APIs, which aren’t supported currently on the simulator. But if you’re building a straight jQuery Mobile app (or any HTML/JS app) then these steps will get you compiled and on the device. The next step is to make sure your application is signed and then you can submit it to RIM’s App World and it’ll be ready to use when the PlayBook launches.

Adobe Refresh – Australia, Seoul, Hong Kong and Singapore

I’m really excited to be joining up with the crew for Adobe Refresh, which will cover some of the latest and greatest features for the Flash Platform as well as show off Adobe’s HTML story over a couple of weeks in March. We’re hitting a total of 6 cities in Australia, Hong Kong, Seoul, and Singapore. I’ll be tagging along with Richard Galvan, Paul Burnett, and Michael Stoddart.

The sessions are going to cover Flash Pro, HTML5, Flex/Flash Builder, Digital Publishing, and a Q&A for answering any questions you might have about the Adobe stack. Plus we’ll be showing off some things that most people won’t have seen live yet, so if you come, you’ll get a first crack at seeing some very cool stuff coming up from Adobe.

Here’s the full list of cities:

I’m looking forward to being able to see all of the community members in those countries as well as getting to show off the latest and greatest with the Flash Platform. I’ll be talking about multiscreen development with Flex and Flash Builder and there is some VERY good stuff for developers on the horizon when it comes to building apps across devices. This will be a great event to see it all come together.

Getting Started With jQuery Mobile

I’ve been spending a lot of time recently getting my JavaScript and HTML chops up because I think that Adobe is going to have a lot of impact in the HTML5/JS/CSS3 world next year and as a web developer, HTML and JavaScript have become incredibly interesting (and fun) with the rise of frameworks and the mobile landscape. As part of that experiment I’ve been digging into jQuery mobile. I’m obviously not a jQuery pro but after playing with both Flex “Hero” for mobile applications and now jQuery mobile, I thought it would be helpful to do a quick getting started post on jQuery mobile and talk about some of the UI paradigms it uses while walking through a basic application. jQuery mobile is in alpha2 right now, so it’s a little rough around the edges, but still very capable of providing a basis to create mobile applications.

jQuery Mobile divides the world up into pages, which are essentially just screens. Each page has three areas for content; the header, the main content, and the footer. Those are each defined by setting the data-role attribute within the div tag to specify “header”, “content”, or “footer”. The data-role attribute is also used to set up pages by setting it to the “page” value. With jQuery mobile the pages can be set up in different HTML files or all in one file. For this example I’m going to build a two-screen application. The first screen has a button that the user clicks to enable the use of the Geolocation APIs and the second screen is going to be a list of Wikipedia entries that are close to the coordinates. So I have two pages each with the three content types set using data-role.

 
<div>
 
<div>
 
<h1>Find Location</h1>
</div>
 
 
<div>
 
This application will use the <a href="http://geonames.org">Geonames</a> API and your location to bring back a list of Wikipedia articles about features that are near you. To get started, click the button below and allow the application to read your geolocation information.
 
        <input id="getLocation" type="button" value="Get My Location" /></div>
 
 
<div>
 
<h4>By <a href="http://blog.digitalbackcountry.com">Ryan Stewart</a></h4>
</div>
</div>
 
 
<div id="dashboard">
 
<div>
 
<h1>Data List</h1>
</div>
 
 
<div>
 
<ul id="wikiList">
</ul>
</div>
 
 
<div>
 
<h4>By <a href="http://blog.digitalbackcountry.com">Ryan Stewart</a></h4>
</div>
</div>

With my structure set up I can now start adding jQuery-mobile specific interactions. As soon as I add the jQuery mobile libraries to my application it knows how to parse the data-role attributes and themes the application accordingly. What you get is something like on the right. Notice how it automatically styles the header and footer sections as well as providing a nice, big, touchable button and some styling on the footer link to indicate that it can be tapped.

With the external jQuery and jQuery mobile files included I can move on to adding interactivity. I start by adding a click handler to my button, which will go out and grab the geolocation information if it’s available. It’s just using the HTML5 geolocation API, which is supported by most modern browsers. When the user clicks the button, it will get the current position and then call onSuccess or onError depending on whether or not the API call worked.

$(document).ready(function(){
     // Add a click listener on the button to get the location data
     $('#getLocation').click(function(){
          if (navigator.geolocation) {
               navigator.geolocation.getCurrentPosition(onSuccess, onError);
          } else {
               // If location is not supported on this platform, disable it
               $('#getLocation').value = "Geolocation not supported";
               $('#getLocation').unbind('click');
          }
     });
 
});

Next I set up a namespace for the geonames information. It has variables for the baseURL and then a search function with the getJSON function that goes out and calls the Geonames API. The function loops through each one of the results and then creates an <li> tag and appends the data we want to show to it, including the title of the Wikipedia article, the distance, and a summary. This is all straight jQuery. But after that we get into a couple of jQuery mobile-specific parts.

// create the geonames namespace for calling the API
var geonames = {};
     geonames.baseURL = "http://ws.geonames.org/";
     geonames.method = "findNearbyWikipediaJSON";
     geonames.search = function(lat,lng){
 
     // get the data in JSON format from Geonames
     $.getJSON(geonames.baseURL + geonames.method + '?formatted=true&amp;lat=' + lat + '&amp;lng=' + lng + '&amp;style=full&amp;radius=10&amp;maxRows=25',function(data){
          // Loop through each item in the result and add it to the DOM
          $.each(data.geonames, function() {
               $('
 
 
')
               .hide()
               .append('<a href="http://'+this.wikipediaUrl+'">
 
<h2>'+this.title+'</h2>
 
 
</a>
 
'+ this.summary + '
 
<span class="ui-li-aside">
 
<h5>'+this.distance+' (km)</h5>
 
 
</span>')
               .appendTo('#wikiList')
               .show();
          });
          // Once the data is added to the DOM, make the transition
          $.mobile.changePage('#dashboard',"slide",false,true);
 
          // refresh the list to make sure the theme applies properly
          $('#wikiList').listview('refresh');
     });
};

The page model in jQuery mobile gives you a lot of control over how those pages are displayed. By default, when you set up an anchor tag it will play a default transition and go to the page you want. If that page is an external page it will load that external page in the browser. If it’s an internal, local link (with a hash), then jQuery will perform a slide transition and then swap out the old page content with the new one. It also updates the URL by default so you can use the back button that’s included in the header or the back button on your device/browser and go back to the original page. Pretty slick that this all happens by default. However, if you want more control you can use the $.mobile.changePage method, which is what I’m using because I wanted to only change the page after I had parsed the data from Geonames. With mobile.changePage I specify the URL, which in this case is just the id of the new div tag, the transition I want, whether I want the animation to be reversed, and finally whether I want to change the URL so the user can go back to the first screen. By default when you use mobile.changePage the last attribute is set to false so it won’t update the URL in the navbar. In this case I want them to be able to update their location when they move so I set the property to true.

The last thing I have to do is refresh the list to make sure the styles are applied to the new data. Lists are incredibly sick in jQuery an jQuery mobile. By using the data-role attribute and the data-theme attribute you can create some very powerful lists. In this case, I’m just using the default list so my <ul> tag has an id of wikiList, and a data-role of “listview”. That means any <li> tags I add to it will become jQuery mobile list items. And that’s exactly what happens in my Geonames callback function when I iterate through each item. It’s creating <li> elements with my data and appending them to my wikiList <ul> tag. Then when I call .listview('refresh') on my wikiList, it styles them appropriately. One cool feature of jQuery mobile lists is that there are a few different properties I can set to add some stylistic touch. For example, to show distance I’m using a span tag with the class set to ui-li-aside. That class will right-justify the content so my distance shows up on the right side.

And that’s pretty much all there is to it. The last bit of code I have is just the onSuccess and onError functions that handle the geolocation API.

// Success function for Geolocation call
function onSuccess(position)
{
     geonames.search(position.coords.latitude,position.coords.longitude);
}
 
// Error function for Geolocation call
function onError(msg)
{
     alert(msg);
}

You can check out the full application here and see it in action. This is just scratching the surface of what you can do with jQuery mobile but hopefully you got a sense of the page model and how to move back and forth between screens. In some later posts I’ll hopefully cover the new gestures, the new components, and some of the ways to lay out content.