Tag Archives: javascript

PhoneGap for Flex Developers: Debugging PhoneGap Applications on Android

Posted on by
5

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

Posted on by
3

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.

HTML5 and jQuery for Flex Developers
View more presentations from Ryan Stewart

WebSocket Charting Demo with HTML5 and JavaScript

Posted on by
9

One of the PHP demos that goes over pretty well is my Flex socket demo. It used to be that Flex/Flash was really the only way to take advantage of WebSockets but with browser vendors implementing bleeding edge support for HTML5, developers can now use the WebSocket API in JavaScript. I wanted to combine that with the Canvas API and try to recreate a basic example of my Flex socket demo in HTML5/JavaScript. It mostly works (demo embedded at the bottom).

Code

  • socket.html – HTML/JS file for connecting to the socket server
  • socket.php – PHP file that creates the socket server

Who Can Run This

It’s been kind of cool to see the browser vendors really move forward to implement support for various bits of HTML5 and CSS3 without a defined spec. That can be problematic because the spec is still changing, causing code to break in new versions of browsers, but in general it means that web developers can live on the cutting edge for most browsers. Currently, the WebSocket API (and this example) should work in the latest version of Chrome and the Firefox 4 beta.

Differences in WebSockets with Flash and HTML5

Overall the WebSocket API is pretty easy to use. I took my existing PHP socket server code that works in Flash and tried to use it for the HTML5 version but all I was getting was the “close” event. The problem was that I wasn’t thinking about the handshake. Flash uses a policy file to determine whether or not it can connect, but the WebSocket API uses a handshake. I was able to grab some example code, change my PHP server to add the handshake then everything basically worked. The only other small change I had to make was to add a character (chr 0 and chr 255) to either end of the message I was sending through the socket_write method. I’m still not entirely sure why this is, but my onmessage event wouldn’t fire until I added those.

Charting with Canvas

I’m very excited about the Canvas API in HTML5. If you’re a Flash developer who has been working with the Flash drawing API, you’re going to be able to do some very cool stuff. The APIs are fairly similar with some syntax changes that you have to be aware of. The biggest pain I found was that once something is on the canvas, it’s on the canvas. You can’t reference specific drawn elements like you can in ActionScript. That makes doing things like the hover effect on specific charting points basically impossible.

Partly because of that, and because I’m still getting used to JavaScript I went with a very scaled down version of the chart. All this chart does is draw some grid lines and then plot the points as it gets them from the socket server. When you get to the end, the points are drawn off the page. I also couldn’t really figure out how to add to a path in a function call so I just went with the points instead of making it an actual line graph. I’m fairly sure that most of these are due to my JavaScript incompetence and not a limitation of Canvas.

Conclusion

It was both a lot of fun and very painful to go back to JavaScript. It’s an incredibly powerful language but if you come from Flash, you’ll find yourself banging your head against the wall because of subtle differences. The one thing that keeps tripping me up is figuring out how the DOM works compared to Flash. Another sticking point is the tooling. We have very good tooling on the Flash side compared to JavaScript. Chrome’s developer tools and Firebug both help a lot, but there’s no tool out there that provides code completion for the Canvas drawing API. When you don’t know the API that well, it means a lot of Googling, and a lot of the examples are pretty basic. I think a tool with basic code completion for Canvas would make it a lot easier to start creating complex content in.

It’s definitely rough to go from Flash to JavaScript but hopefully I’ll be playing around with the new stuff in HTML5 more, especially as Dreamweaver gets more support baked in.

Talking to Chris Brichford about HTML and JavaScript in AIR

Posted on by
Reply

For Tech Talk with Ryan Stewart I sat down with Chris Brichford who works on the HTML side of the AIR Runtime. We talk about some of the history behind HTML support in AIR and some of the history on the team. It’s just a bit over 6 minutes but there’s some cool background on how decisions were made around HTML and Adobe AIR as well as how Adobe is working with the HTML and WebKit communities.

The “War” Between Flash and HTML/Ajax

Posted on by
3

There is a pretty good rundown of the RIA space and HTML versus Flash/Silverlight on CNet today. If you read through the comments a lot of people trash the article for arguing Apples and Oranges which I think is an encouraging sign that we’ve come a long way. No matter how you slice it, HTML/Ajax and Flash are competitors in a sense. They do very different things but the “5 year convergence” for the technologies looks very similar I think. Frankly, companies like Google and the browsers that have bought into Ajax and HTML must be feeling a little bit frustrated at the speed of innovation that a company like Adobe can achieve with Flash. So there’s tension there. But I hope that we don’t ever get to the point where we have a “winner”.

Flash can do some great, great stuff as a platform. It goes beyond animation because from our platform we’ve built up an ecosystem of servers, tools, and services that enable things like real-time collaboration, powerful video streaming, and system integration. We’ve been able to do that because the Flash Player allows us to do some very, very cool stuff. I hope our direction as a company is to figure out how to get that to merge more into the HTML/JS world.

The first comment on Digg nails it on the head (aside from the last few sentances):

Firstly, HTML has to be in any of these regardless. HTML is the building blocks of any web page, regardless of the other technologies it uses.

We need to bring Flash and HTML/Ajax closer together. You absolutely should be able to reach inside of the Flash Player as a JavaScript developer and pull out some of the good bits that make the Flash experience so great. We shouldn’t force the “1 pixel SWF” or a sand-boxed Flex application. With AIR you get a glimpse of what that’s like. To me, that’s win-win for everyone. You get to use Flash for things at which it excels. You can tap into Adobe’s services, tools, and infrastructure, and we enhance the entire web – including the HTML/JS side.

Come Learn JavaScript and HTML on the On AIR Tour Europe

Posted on by
1

In a couple of weeks we’ll be back in Europe for the on AIR Tour. This time we’re hitting northern and eastern Europe, a part of the country that I’ve never been in that part of the continent before so I’m pretty excited. We’re also going to be bringing some new goodies that should appeal to HTML and JavaScript developers. You’ll get a copy of our AIR for JavaScript developers pocket guide at every stop.

In order to add to the local flare, I wanted to provide some encouragement in the local languages. I got every stop except for Prague. If you know any Czech, let me know:

Stockholm – “Vi ser verkligen fram emot att komma till Stockholm med on AIR tour. Om du är HTML- eller Flash-/Flexutvecklare så är detta ett utmärkt tillfälle att lära dig utveckla desktopapplikationer och träffa andra utvecklare. Vi är också mycket intresserade av att höra dina åsikter om du redan har använt AIR.” – Thanks to Nisse Bryngfors for the translation.

Berlin and Munich – “Die Adobe AIR Tour kommt am 4. Juni nach Berlin und am 11. Juni nach München. Du bist ein HTML- oder Flash/Flex Entwickler? Dann ist dies eine großartige Gelegenheit zu lernen, wie Du mit AIR Desktop-Anwendungen entwickeln kannst und Dich mit anderen Entwicklern auszutauschen. Uns interessiert auch Dein Meinung zu AIR falls Du damit bereits Anwendungen entwickelst.” – Thanks to Craig Cmehil and Gregor Wolf for the translation.

Warsaw – “”Naprawd? czekamy z niecierpliwo?ci? na on AIR Tour w Warszawie. Je?eli jeste? develorepem HTML lub Flash/Flex, b?dzie to ?wietny sposób, aby nauczy? si? wi?cej o budowaniu aplikacji i porozmawia? z innymi developerami. Oczywi?cie my te? jeste?my zainteresowani Twoj? opini?, je?eli ju? u?ywasz AIR.”" – Thanks to Lukasz from the Flex Adobe User Group in Poland.

Prague – ???

 

 

Milan – “Siamo davvero lieti di poter essere a Milano con l’onAIR Tour. Se sviluppi in HTML o in Flash/Flex questa è una grande occasione per imparare come creare applicazioni desktop e scambiare quattro chiacchiere con i colleghi. Siamo anche interessati a sentire il tuo parere ed avere il tuo feedback se già stai utilizzando AIR.” – Thanks to Marco Casario for the translation

Flags from 3DFlags.com

.