PhoneGap for Flex Developers: Debugging PhoneGap Applications on Android

I’ve been spending a bit of time this weekend trying to dig into PhoneGap for obvious reasons. I’ve done a couple of basic PhoneGap apps prior to this but I wanted to get the full workflow down. Coming from a Flex/Flash background, I think I got a little spoiled. From what I’ve been able to tell, there’s almost nothing in the HTML/JS stack that can replicate what Flex/Flash Builder do. For this particular challenge I wanted to be able to debug my code on the device. Brian Leroux pointed me in some great directions but during the process I found myself a bit frustrated. There is a lot of “grab this github project, get this dependency, get this github project”, etc. That’s not to say it’s bad, it just wasn’t in a centralized place, which is what I’m used to. Simeon Bateman made an interesting comment to me over IM that I was from the “heavy, all-inclusive camp” whereas JavaScript developers came from the “lightweight, use-as-needed camp”. That’s something I need to get used to.

So here’s some general info I found while going through this process. Big disclaimer: This is more of a brain dump than anything, so it isn’t meant to be all that informative, but I wanted to jot it down for my own memory. Comments are welcome.

Aardwolf

The first thing I tried was Aardwolf, which seems really, really awesome. It’s essentially a remote debugger written in JavaScript. You open up the HTML page, which has a JavaScript console, and then load your application up on the device. It uses Node.js, which I thought was pretty slick, and by dropping a script into your page you can set breakpoints in the JavaScript console to test code. Sadly, I couldn’t get it to work. My main issue was that I had a hell of a time figuring out how to get the Node.js server exposed outside of my Mac correctly. I think I got close, but it stumped me. That’s not necessarily a knock on Aardwolf, because it looks really, really slick, I just didn’t have the Apache knowledge to pull it off. I’m going to revisit this one later.

Weinre

Weinre ended up being the winner for me. It seems like an absolutely perfect solution for the PhoneGap world because as long as you’ve exposed your Mac to web sharing, you can use the Mac client and with a simple line of code, you have access to everything about your application you’d expect from something like the Chrome Developer Tools. I think I’ll try to do a more in-depth blog post on this in the near future, but for now, here’s my rough setup:

I downloaded the Mac client from this page. I had web sharing on my Mac set up for the IP address 10.1.0.4. When it starts up, the Weinre client creates a ~/.weinre/ directory but if you want to customize the app at all you need to create a server.properties file in that directory. With this you can specify the host that the Weinre debugger will connect to. Mine was this:

boundHost:    10.1.0.4
httpPort:     8080
reuseAddr:    true
readTimeout:  1
deathTimeout: 5

Now the Weinre debugger is using the same IP address that any other devices use to connect to my Mac when they share the same network. When I read through the Weinre documentation, the examples focused on browser-apps that would be able to load a URL from that 10.1.0.4 URL. So at first I was kind of confused where PhoneGap fit in. But then I had my “duh” moment: one of the beautiful things with PhoneGap is that we’re just dealing with a web view instance in a native app. So all I had to do was take the script block that the “default” page creates for you and put that in my PhoneGap code. I started with the default PhoneGap template from Dreamweaver so I just added that line to my app:

<html>
<head>
<meta charset="UTF-8">
<title>Beer Inventory</title>
<link href="jquery-mobile/jquery.mobile-1.0a3.min.css" rel="stylesheet" type="text/css"/>
<script src="http://10.1.0.4:8080/target/target-script-min.js#anonymous"></script>
<script src="jquery-mobile/jquery-1.5.min.js" type="text/javascript"></script>
<script src="jquery-mobile/jquery.mobile-1.0a3.min.js" type="text/javascript"></script>
<!-- This reference to phonegap.js will allow for code hints as long as the current site has been configured as a mobile application.
      To configure the site as a mobile application, go to Site -> Mobile Applications -> Configure Application Framework... -->
<script src="/phonegap.js" type="text/javascript"></script>
<script src="scripts/test.js" type="text/javascript"></script>
</head>

It’s that first script block that gives me access to the Weinre debugger. Then I built that app and packaged it into an .apk file and installed it on my phone.

Voila! I automatically had access to all of the Weinre features for my PhoneGap app!

Fantastic!….err…..sort of

Being able to inspect elements and change them on the fly is awesome, but then I wanted to debug some JavaScript code. Turns out you can’t do that with Weinre (yet). This is one of the things that Aardwolf is really great at, but it has to tie into Node.js to get the breakpoints to work. Plus you have to manually enter an array of breakpoints in the JavaScript console to get it to work. I wasn’t able to get past the step of making Aardwolf and my local Node.js server accessible to my device, so I wasn’t able to test it. Plus I’m not totally sure how Aardwolf would work with PhoneGap, but I *think* it should. My plan this week is to try and get Aardwolf and my app running on Heroku so I don’t have to worry about making my local Node.js server accessible but I wasn’t able to do that tonight.

Welcome to the edge

As far as I can tell, we’re getting into some edgy territory here. Even the Google searches are pretty sparse. So if you’re coming from the Flash/Flex world, I think there will be some learning curves.

But I set out to do this with Android. For iOS, arguably the platform that is the most important, it’s way easy because the tools are much better. Since all PhoneGap projects are native projects, you can use the exact same debugging/deployment workflow as other iOS apps. That means you can leverage the power of Xcode to help out. I haven’t spent a ton of time in Xcode, so I’ll be spending some cycles on that this week as well, but it looks much, much nicer.

I’m really excited to spend a lot more time on PhoneGap. I think building apps with HTML/JS is kind of fun, even if there are some rough edges. Based on my experiments so far, the Flex/Flash story with AIR is way, way, WAY better than anything on the HTML/JS side for building mobile apps, including PhoneGap. But the world is embracing HTML and JavaScript and by learning JavaScript, as a developer, you will never be more versatile. So in that respect, PhoneGap is a great way to start bridging the gap between Flex/Flash and the HTML/JS ecosystem. So far I’m having fun.

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.

Adobe SXSW Roundup

If you haven’t been to SXSW, as a geek, you need to go at least once. The badge is pretty cheap for what you get, and the experience is unreal. As I’ve gone to SXSW I find myself going to fewer and fewer panels, but there is always very good content. And the subject matter is incredibly diverse so you can geek out on everything from development to food. But the best part is connecting with people. One of the best things about SXSW is that everyone there is happy to talk to you about anything. There are always a few people who came to pitch their stuff, but even they’re fun to talk about and the enthusiasm they have is infectious. We held some Adobe events at breakfast and lunch and I got to meet some really fun people who were jazzed about what Adobe is doing.

We also had our crack video team at the event and they did a ton of video. To get a feel for what it was like at SXSW, check out the videos below. And hopefully we’ll see you there next year. Big thanks to the Edge team, and the CS marketing team for putting on some great Adobe events at SXSW this year.

There’s a cool video about the Interactive Web Awards, which we sponsor and some of the winners and how they use Adobe tools. Some of the finalists for these awards are amazingly impressive.

We also snuck some of the next-gen features in Flash Professional and Dreamweaver and did a couple of videos of feedback from the people that came to the session. You can find Part 1 here and Part 2 here.

Flash Builder for Dreamweaver CS5 Users

Thanks to everyone who stuck out the preso on Flash Builder for Dreamweaver CS5 users. Clearly this isn’t my month for demos. I’ve uploaded the slides as well as the (working) source code. There are two directories: the Flex directory, which includes the source code for the Flex projects, and the html directory, which includes the HTML code.

It’s got examples for using ExternalInterface, the Flex/AJAX Bridge, and FlashVars. You can grab it here.

Adobe and RIM Collaborating on Tool Support for BlackBerry Devices

At the developer conference in San Francisco today, RIM and Adobe announced a collaboration around creating content for BlackBerry devices and Adobe’s Creative Suite tools. This builds off of the momentum we started with RIM when they announced they were joining the Open Screen Project and dedicated to bringing Flash Player to BlackBerry. There are some good links on Techmeme that cover the announcement pretty well.

rim_adobe_announcement

Creating Content with Adobe Tools

Adobe is known for first class design and development tools and today’s announcement means that you’ll be able to use those tools to target RIM’s devices. There are going to be multiple points of integration. One of the critical pieces of creating mobile content is to make sure it is optimized for the smaller screens and often less bandwidth. In Creative Suite 5 we’re going to support optimized graphic and video content from Adobe Photoshop, Adobe After Effects, and Adobe Illustrator. We’re also supporting a seamless workflow between those design tools and BlackBerry’s developer tools including the BlackBerry Web Plug-in for Eclipse and the BlackBerry Java Plug-in for Eclipse.

More interestingly for developers, we’re going to be working closely with RIM to enable full support for BlackBerry devices in Creative Suite Design Central, Dreamweaver, and Fireworks. You’ll be able to use those three tools to test and create content for BlackBerry’s mobile browser as well as to create widgets directly on the BlackBerry device. Device Central is a fantastic way to test both HTML and Flash content for specific mobile devices. It lets you tweak battery settings, screen sizes, and other phone-specific functionality. Now we’ll have support for most of the BlackBerry phones so you never have to leave Creative Suite to see exactly how something will look on the phone.

Lastly, on the application front, Adobe is to be working on applications for BlackBerry that will let users take rich media and image content from the phone and quickly and easily bring it into tools like Photoshop Elements and Photoshop.com so it can be edited and modified.

BlackBerry Momentum

My colleague Mark Doherty has some great stats on what the BlackBerry market looks like and what this collaboration will mean for people who want to use their existing skills with Adobe’s tools to create mobile content for BlackBerry. Seeing the level of cooperation between Adobe and RIM is an exciting thing for designers and developers. Unlike some companies, I think RIM sees the value in partnerships, and with the breadth of Adobe tools it means they’re able to leverage our community for all kinds of different content- not just Flash.

Next year is going to be incredibly exciting for Adobe developers and designers. We’ve already talked a lot about Flash Player being available for smart phones next year, you’ll undoubtedly be hearing more about AIR, and hopefully we’ll continue to see deeper mobile integration across all of our tools just like you’re seeing with RIM here today. For more information you can check out the BlackBerry portal on Adobe’s site to get the scoop on the details and see some of the workflows in action.