⎋
 
 

AIR

Thursday, November 06, 2008

The Funkatron.com PHPMAX 2008 US Tour

The Funkatron.com PHPMAX 2008 US Tour

The coming weeks are gonna be a little hectic for me, as I fly to Atlanta on the 12th to attend php|works / PyWorks 2008. I’ll be doing the following talks:

I’m pretty excited about php|works / PyWorks 2008, especially because we can interact with the Python community and learn more about each other’s tech. Cross-pollination is a Good Thing.

I’m flying back to IND on the 15th, but then I’m leaving again on the 16th for San Francisco and the Adobe MAX 2008 conference. I’m giving the following talk:

Originally this talk was going to be given by John Resig, creator of the jQuery library, but he ran into some time constraints and thoughtfully suggested me. Of course, the description still mentions his name, which likely means I’ll be tarred and feathered by the audience. This also looks like it may be the largest audience I’ve ever given a talk before: there are currently about 70 folks listed as attending, with ~300 capacity. So if I wet myself on stage, please forgive me.

, , , , , , , , , , ,
Posted in AIR, JavaScript, jQuery, Python, PHP by funkatron on 11/06 at 06:29 PM
(2) Comments

Wednesday, October 15, 2008

Safely parsing JSON in JavaScript

Wear safety shoes

I love me some JSON. It saves me tons of parsing headaches when exchanging data between web services because it maps so well to concepts shared among most common programming languages. It’s super easy to take a PHP object, convert it to JSON, and then push it to a Javascript (or a Ruby, or a Python) app.

Because JSON is valid JavaScript code, the most common method for converting it into native JS objects is to just eval the JSON. This is an extremely bad idea, because it opens your app up to all sorts of code injection attacks. Even with “trusted” sources, a security failure on your source’s end, or just a disgruntled employee, could wreak havoc on your apps and your users. I’d recommend reading Douglas Crockford’s “JSON and Browser Security”. Go ahead; I’ll wait. Rockford is impatient

jQuery, which we’ll use for all our examples because it’s awesome, will in many cases automatically parse JSON responses for you. This, as we learned above, is a Bad Thing. The following Ajax methods will automatically parse JSON in jQ (as of 1.2):

  • jQuery.getJSON() – always
  • jQuery.ajax() – if type is ‘json’
  • jQuery.get() – if type is ‘json’
  • jQuery.post() – if type is ‘json’

So my rules of thumbs are:

  1. never, ever use $.getJSON()
  2. never, ever set the type option to ‘json.’

To force the issue, I set my type to ‘text’ in my ajax calls. For example:

<script type="text/javascript" charset="utf-8" src="/js/jquery.js"></script>
<script type="text/javascript" charset="utf-8">
    $.ajax('http://twitter.com/statuses/public_timeline.json', function(data, textStatus) {
        alert('Status is '+textStatus);
        alert('JSON data string is: '+data);
    }, 'text');     
</script>

In the example above, we’re including the jquery library with the first <script> tag, and then calling the jQuery.ajax() method in the second. We’re passing three parameters:

  1. the URL we’re pulling the JSON string from. In this case, it’s the Twitter public timeline
  2. an anonymous function that’s called when the request is successful
  3. the type of data we’re getting, as a string. Using ‘text’ ensures no extra processing is done on the response string

So this is great, but all we’ve got is a string of serialized data, which isn’t terribly useful. Thankfully, there’s a handy library at JSON.org that takes care of parsing JSON without using eval without using eval on non-JSON code1. The library gives us two methods: JSON.parse() for turning a JSON string into a JS object, and JSON.stringify() for turning a JS object into a JSON string. So let’s utilize JSON.parse() in our code, and actually do something with that data:

In the modified example above, the second script tag loads the JSON2 library. We then use the JSON.parse() method to turn the data string into a JavaScript object – in this case, and array of Twitter message objects. Then we iterate over the array, building a string of HTML for each entry and prepending it to the <body> tag (so the newest item is on top).

Note: If you’re using this code on a remotely-hosted html page (or loading it as a local file under Firefox 3), it won’t work, and if you check in your error console you’ll probably see a security warning. That’s because our $.get() call directly accesses the Twitter API hosted on Twitter.com, which is almost certainly not the domain your files are hosted on. When we try to do so, it violates the same-origin policy enforced by browsers. The only workaround that I think is safe is to set up some sort of proxy on your domain to pass requests – other approaches like JSONP rely on eval()ing the result, which is what we’re trying to avoid here. I’ll try to cover setting up a local domain proxy in a future post.

By handling JSON with a parser rather than just using eval(), we mitigate the risk of code injection. This helps us protect both our application and our users.

  1. Basically, JSON.parse() runs a regex search for code that appears to be defining a function or redefining prototypes or other kinds of stuff beyond simple data transmission, and guts those parts.

    ↩

, , , , , , , , ,
Posted in AIR, JavaScript, jQuery, InfoSec by funkatron on 10/15 at 11:24 AM
(2) Comments

Friday, September 19, 2008

Slides and code from my ZendCon08 talk on AIR+PHP

The Doom Beer

Update: Audio is now available, thanks to Kevin Hoyt.

ZendCon was pretty fun, although I was feeling under the weather most of the time. Still, I was able to offend lots of folks with my DearZend project, which was also the source for one of my three examples in my talk. You can get the code for my examples, and the slides in PDF, from here or from SlideShare:

You can also get the code for the DearZend client app and server app on GitHub. For those curious, I wrote the server app in CodeIgniter.

Building Desktop RIAs with PHP, HTML & Javascript in AIR
View SlideShare presentation or Upload your own. (tags: air css)
, , , , ,
Posted in AIR, JavaScript, jQuery, PHP by funkatron on 09/19 at 05:09 PM
(1) Comments

Friday, August 22, 2008

The ugly side of developing AIR HTML apps

i will take over the world.

I’ve been developing with AIR for over a year now. It’s all been HTML/JavaScript apps, but the complexity of most of them has been pretty low. Spaz, the Twitter client I created, definitely isn’t simple, though – mostly because I’m kind of a crappy coder, but also because it just does a lot of stuff.

Lately I’ve been getting a little bummed about AIR, because I’m starting to bump into limitations of the platform more and more. What’s particularly frustrating is that some of these limitations are specific to HTML AIR app dev. So what follows is a couple of issues that have been particularly troublesome when developing Spaz and other HTML/JS AIR apps.

AIR gets greedy under OS X

Julien Viet, who has contributed significantly to Spaz, made a post recently about the base resources used by the AIR runtime. In it he finds that the basic “Hello World” sample app provided by Adobe used about 20MB of RAM, and hovered at about 2% CPU usage even when idling. I replicated these tests on my Macbook (2.2Ghz, 4GB) under OS X 10.5.4 and WinXP SP2, and had similar results:

AIR HTML app - Base CPU and memory usage (WinXP SP2) AIR HTML app - Base CPU and memory usage

I also created a Flex-based “Hello World” application to compare base usage if the Webkit renderer isn’t being used. Memory usage was slightly lower, but otherwise it was comparable to the HTML app.

AIR Flex app - Base CPU and memory usage (WinXP) AIR Flex app - Base CPU and memory usage

The constant CPU usage seems to be specific to OS X: WinXP will jump back and forth between 0% and 2%. This is consistent with my observations of CPU usage in Spaz as well: in OS X, we get 10-15% CPU usage constantly, but under XP and Vista, CPU usage is 0% while idling. Initial memory usage is also about 30% higher with Spaz under OS X than it is under Windows. Something is goofy with AIR on OS X.

That aside, I don’t think the memory and CPU usage of AIR are surprising, considering the technology. AIR is a full Flash runtime, and HTML apps add a Webkit renderer on top of that. The memory and CPU usage is in line — or a bit lower — than most SSBs. Using traditional browser tech to build a desktop app is going to be a tradeoff in terms of memory and CPU usage, just like many other technologies that make development easier. But for one reason or another, the expectation seems to be that AIR is a lightweight technology, and it’s really not.

AIR HTML apps are leaky

What is particularly problematic is that there seem to be memory leaks within the Webkit engine as used in AIR – or at very least, it’s pretty easy to leak memory. Apps like Spaz run into this problem because it’s constantly pulling in large amounts of new data and images, and is often left running for hours or days on end.

Some of this is almost certainly because you can get away with that kind of thing on a web site, where users are unlikely to leave a single page open for days on end. Even if a web site does causes a big leakage, the browser almost always gets blamed. The libraries and tools available for HTML/JS devs, being browser-focused, typically don’t pay much attention to long-term performance issues.

Essential tools, like profilers and step debuggers, are non-existent

But memory leaks are a problem for most desktop app developers. That’s why memory profiling tools are common in desktop frameworks. And Adobe certainly understands this to be the case with Flex, as it’s FlexBuilder 3 IDE ships with memory and peformance profiling tools, as well as a full-featured debugger with breakpoints et al. That’s perfect if I was writing something in Flex, but it is completely useless for HTML/JavaScript AIR apps. I was able to get Spaz to run from within Flex Builder with a tiny bit of hackery, but the profiler gets no information about what’s going on within Webkit.

Other common choices for debugging web apps aren’t available either: Firebug is Mozilla-specifc, and the Drosera debugger and Web Inspector tools can’t hook into AIR’s Webkit instances. The information on Drosera does say:

In WebKit there is a WebScriptDebugServer which is started when WebKit starts and listens for a DCOM connection. Once a connection is made it will begin to interact with Drosera via Drosera’s ServerConnection class. WebScriptDebugServer informs Drosera about every line of JavaScript executed.

I would assume that WebScriptDebugServer exists inside AIR’s Webkit, but AFAIK this has not been utilized in any way. Adobe does have a nice AIR-specific tool called the AIR Introspector in the SDK, and it does offer some very useful functionality, but it too lacks step debugging and profiling capabilities.

That leaves us with good old console logging as our only option for debugging AIR HTML apps. That’s okay for simpler stuff, but tracking down execution bugs in more complex applications becomes extremely tedious. And console logging is basically useless for memory profiling, as there’s no insight into the underlying operations of Webkit.

I’m proud of the work I’ve done on Spaz, but as the application has grown in complexity, I’ve found the limitations of HTML app dev in AIR more and more problematic. Adobe has consistently stated that the HTML dev side of AIR is as important as the Flash/Flex side. To quote Mike Chambers:

Adobe AIR is as much about JavaScript, HTML, CSS, etc… as it is about Flash / Flex. #

If that truly is the case, Adobe needs to commit to providing a toolset for HTML/JS developers comparable to what Flex developers have. Until that’s changes, Mozilla’s XULRunner and Prism platforms are looking more and more appealing.

Posted in AIR, Development, JavaScript, OS X, Spaz, XULRunner by funkatron on 08/22 at 04:10 PM
(7) Comments

Tuesday, August 19, 2008

Spaz gets Twitpic, Ping.fm, Identi.ca support

PUREX ! NEW STREAMLINED BOTTLE "PUREX ! NEW STREAMLINED BOTTLE"

It’s been many months since I’ve posted about Spaz here, but I’ve actually still been working on it quite a bit. Spaz recently had its 1 year anniversary, which is a pretty good milestone for one of my projects – I usually lose interest well before this. Not only is Spaz one of the oldest Twitter desktop clients still under development, but it’s also one of the few FOSS clients. I also believe Spaz is one of the most sophisticated AIR HTML apps out there, and is a good example of what can be done with HTML and JavaScript on the desktop.

The newest release of Spaz, which came out a couple days ago, adds some significant new features:

  • Image uploading via Twitpic.com
  • Crossposting support via Ping.fm. Try beta code “vivalaping”
  • Support for microblogging services with Twitter-compatible APIs, including Identi.ca
  • A Dock icon badge with the unread message count. This is probably less significant if you are not running OS X.

You can read the whole fat list of what’s new. Also, if you want to talk to other users or help with development, here are some resources:

Posted in AIR, My Projects, Development, JavaScript, jQuery, Spaz by funkatron on 08/19 at 07:22 PM
(0) Comments
Page 1 of 1 pages