code zen » Flash

My FlashCampPhilly presentation: Some interesting libraries to consider for your next app

arpit — Mon, 16 Nov 2009 20:27:06 +0000

Last Saturday, Philadelphia was host to its first ever FlashCamp event. The event brought together some of the biggest names in Flash and Flex in the neighborhood and beyond (special kudos to Rob Hall for organizing the event from vision to a lot of very hard work). I did have one session at the event as well, as I walked through some of the libraries I have started using in a lot of my projects, including the soon to be alpha-ed Espresso Reader. These libraries included:

The CIM logging framework including LogBook
Drew Cummins’ Green Threading library
Performance measurement libraries like gskinner’s performance testing harness
Some miscellaneous classes that I have written for AIR apps

Anyway, the entire presentation is embedded below for posterity. My favorite lib is the green threading one which is saving me a lot of headaches in terms of keeping my application performant even while doing a lot of data processing. I’ll probably have a separate post up soon with a good example on that.

Flashcamp

View more presentations from arpitmathur.

Thoughts on Commercial Ecosystem for the Flash Platform

arpit — Wed, 30 Sep 2009 02:02:54 +0000

This post is in response to Grant Skinners post on a thriving commercial ecosystem for the Flash Platform. For those who are just getting caught up with the conversation, it all began with Adobe labs releasing Squiggly, a spelling library for Flash apps which may compete directly with Grant’s own Spelling Plus Library which prompted quite a few people (including Grant himself) to talk about how Adobe may be competing with developers who build on their platform. This conversation isn’t new, quite a few people said the same thing when Adobe came out with Photoshop.com which competed with services like Picnik. As Adobe starts eying the services market with apps like Share, Buzzword, etc, developers may (justifiably) feel that it may be a matter of time before Adobe competes with them should their product seem lucrative. Considering they own the platform, ie the Flash Player, they may very well put features in that give them the advantage. For example, Adobe Connect already leverages the screen sharing capability that gets enabled on the Flash Player with the Connect plugin (yes a plugin for the browser plugin), something that non-adobe developers cannot access.

Can Adobe navigate these waters carefully enough to not alienate its developers remains to be seen, but this post is more regarding Grant’s follow up post on what Adobe can do to create a vibrant commercial ecosystem for the Flash Platform.

Actually there is a slight difference in the title of Grant’s post: “How Can Adobe Encourage a Commercial Ecosystem?” and what he writes about: “… lack the high-quality, well-supported, production-ready components that a commercial marketplace can provide.” While both are in similar vein, I feel a thriving commercial ecosystem on the Flash Platform doesnt have to be based around production ready components. There will be a few, like SPL that make a decent amount of money but those are going to be the exception and not the rule.

Adam Lehman, ColdFusion Product Manager made the point on one of the comments on that post which I most agree with: The Free Open Source marketplace which is pretty thriving on the Flash Platform does tend to kill the commercial component marketplace.

A Commercial Ecosystem on the Flash Platform is different from a commercial ecosystem on the Flash Platform based around commercial components. Grant’s own SPL is only viable till an open source version came out that may even be half as good as the SPL. The Flash developer community has become used to the Open Source way: find something out there that fills your need, if not and you find a fledgeling open source project that may have those ambitions, see if you can contribute, else build it yourself. My personal opinion is that the market for commercial components is pretty small no matter what Adobe does, and I dont think too many people miss it (except maybe a few folk coming from the Microsoft side of the world who are used to paying for components they use).

Flash Platform’s own commercial ecosystem would/should probably be around full products, embeddable widgets, AIR applications, Flash lite/mobile AIR apps etc. The best thing Adobe could do is keep powering the platform even more, add more capabilities to the runtimes, create distribution and monetization channels for the developers and make sure the developers dont feel threatened. And the developer services products on Adobe devnet seems to be a step in the right direction.

When things go wrong: Communicating error and gathering information for client side code

arpit — Fri, 10 Jul 2009 00:24:43 +0000

Having developed client side applications for the last few years in a variety of languages (Java, Flash, AIR, Javascript and recent forays into Objective C for the IPhone), its funny that some discussions appear cyclically and are discussed as though for the first time in every new project. Communicating errors in your application seems to be one of them, and I wanted to pen a few thoughts on that.

Serverside developers have it easy!
Well, no . But there are paradigms that have become the norm now. If something bad happens and you get a 404 or a 500 error on a webpage, its pretty likely that its been logged and if its on a major product, alarms have been raised. Client side code, especially in the languages I have worked in the last couple of years, have been less…communicative. I would like to focus on AIR and Flash here since those are the technologies I work with most often. The problem becomes more critical in AIR where you have much more things that can go wrong since you are interacting with items on the user’s machine which is not a controlled environment.

Why communicate the error?
Very few client side web apps I have worked with, including my own, have ever seemed to have handled error correctly. Most of the time, the app has been scoped with time allocated against the features and error states have never been considered. Occasionally, a developer will put in an Alert window or something similar just as a precaution (I know I have). In Flash/AIR there doesnt seem to be a good library that I can integrate into my application that encapsulates best practicess. Heck, I dont even know what the best practices are, which is what prompted me to write this post.

What would you include in the error window?
While you may want to include app specific information in the error window, I think there are a few things that make most sense:

An error description: What happened ? Corrupt file? Cannot connect to server? Something readable. For bonus points, can the user do anything about this, like restart the application?
An error code: This makes sense and if you include a support system, like a bug tracker or a 1-800 number, it would make the conversation a lot more meaningful
The detailed stack trace: A good paradigm I have seen here is a toggleable details state that shows/hides the detailed error stack trace, would go a long way in figuring out the source of the error
Extra points: email API integration, or some other way for the user to send the error description with as little pain as possible

The last point is kind of interesting, cause you might want to send more than just the stack trace of the error. You might want to set the whole application state. If you have application logging enabled, say with something like the CIM logging framework, the whole log file might be of interest. Again, the developer must ensure that he is only logging non-personal information there.

Of course there are situations when the error might cause the entire app to blow up, without giving it enough time to react to the error. Would it make sense to log and end of session event and allow users to send the application log to the server if the end of session was not successfully logged for a prior session?

Prior Art:

I started looking at some Google results for Error dialogs and crash reporters. Here are some screenshots:

First is the JXErrorPane, a Java class part of SwingX project. This seems to be the most familiar UI for reporting errors(link to API docs)

The usage is pretty simple:


 try {

          //do stuff.... something throws an exception in here

      } catch (Exception e) {

          JXErrorPane.showDialog(e);

      }

A step up would be the UI from crash reporters which would perhaps be overkill for a web app, but would make a lot of sense for desktop apps, especially in the beta stages. Here is a screenshot from something called Bug Buddy.

Whats kind of interesting here is that it adds a field that allows user to add information about the context of the crash, as well as an email address that may be used to contact him or something.

The last screenshot is from an open source library called JRFeedbackProvider someone presented at the Philadelphia Cocoa Users Group.

. This has the features of the previous crash reporters but also adds a “request a feature” tab which is great if you are running an alpha version of your application and are looking for more than bug reports.

If you have seen any other error UI that seem to do a good job, please add a comment here.

New Adobe toys this week: Flash Builder 4, Flex 4 SDK, Flash Catalyst, BrowserLab

arpit — Thu, 04 Jun 2009 04:27:02 +0000

An exciting week for Flash Platform Developers as Adobe released a number of Beta versions on the Adobe Labs site. I have just started playing with a couple of them but its definitely worth the shout out.

Flash Builder 4:
Flash Builder 4 is the next version of the Eclipse based IDE formerly known as Flex Builder. The renaming is more than just a re-branding exercise, as FB4 seems to have added features that make it a lot easier to work with other frameworks besides Flex. This is really exciting for me personally as this means it will be a lot easier to work with OpenPyro in FB4. In fact Greg even created a simple project with AS3 only classes that could be exposed as MXML tags. The resultant file size is minute.

Besides that, the my favorite extension to the IDE has been the inclusion of FlexUnit, the unit testing framework for Flex. While FlexUnit itself has been available as a library for a while, inclusion into the IDE will make unit testing a lot easier and hopefully a lot more prevalent.

There is also a network monitor built right into the IDE. While I have used Firebug with success for Flash apps on the web, doing the same for AIR apps has been a challenge (though Charles has been really good, though a requires a bit of a context-switch when coding). The network monitor is going to make a lot of lives a lot easier.

Integration of ASDocs is another great feature, as well as code generation for integrating with serverside code.

[Update] There are also a bunch of improvements to the Debugger on FB4 which you can read more about here.

Flash Catalyst:
Flash Catalyst is a new tool that Adobe is releasing with the promise of truthfully translating designer interactions to stub code that a developer can add functionality to. Basically Catalyst can import any Photoshop, Fireworks or Illustration file, and then can allow the design to assign behaviors to the different parts. For example the designer can select four graphics and mark tham as the four parts of a Scrollbar. The interactions are written out as Flex4 tags that can be compiled into a swf with complete interactivity.

The video below shows how Catalyst can be used:

Flex 4:
The two releases of course directly depend on the Flex 4 SDK, Adobe’s Open Source framework for building Rich Internet Applications. The new release of the SDK introduces a new component architecture called Spark. The core difference between the Spark and the earlier Halo architecture is the favor of the composition as a design pattern over inheritance. What this translates into in everyday development is a leap in productivity as complex UI components can be created a lot easier than before and not requiring things to be subclassed as often. This also makes skinning a lot easier, since all the skin parts can be swapped pretty easily. Another new thing in Flex 4 is the introduction of a new graphics interchange format called FXG, an xml format for graphics that can be understood even by the CS4 products like Photoshop and Fireworks. Matt Chotin’s post on changes in Flex is a lot more comprehensive.

BrowserLab
BrowserLab, a project formerly known as Meer Meer, is a new service being released by Adobe that targets HTML developers. BrowserLab allows developers to preview any URL as rendered by different browsers. The service is in limited beta, but I was able to get an account before it was capped, and I can tell you its pretty impressive. It would be interesting to see how Adobe can integrate this with Dreamweaver, although its supposed to remain open to mortals like myself who still prefer TextMate

So a lot of toys on the labs site. Take em out for a spin and let me know what you think

AS3 weirdness with URLVariables for HTTP POST

arpit — Tue, 05 Aug 2008 03:02:46 +0000

Two+ hours wasted today on dealing with this. Apparently when using URLVariables to pass variables to the server using HTTP Post, using the square bracket syntax ( vars[varname] = varvalue ) sets the contentType of the URLRequest to text/html. However setting the same variables using the dot syntax (vars.varname = varvalue) sets it to text/xml. I couldn’t set the contentType to text/xml using the [] notation no matter how I tried, whether using the URLRequest.contentType property or appending a custom “Content-Type”,”text/xml” URLRequestHeader.

Hope this helps someone.

LogBook and Application Performance

arpit — Fri, 30 May 2008 03:14:48 +0000

Its exciting to see LogBook, Comcast Interactive Media’s first open source project get some traction. There is talk of LogBook being included in other open source projects as well as people have started submitting patches and suggestions to the project.

One issue that was submitted a few days back was around the Logging implementation dispatching all logging events out of the application across the LocalConnection. Here is a quote from the issue:

Logging could add significant overhead to an application, due to
log message construction, and sending messages to LogBook.

It is good practice to minimize logging overhead, with code like:

if (Log.isInfo()) {
LOG.info(”version: {0}”, version);
}

The current implementation of class LocalConnectionTarget always
sets the log level to ALL and the log filter to “*”. This means
that all logging methods are executed, which is undesirable.

You can see the details of the issue here.

I just wanted to elaborate a little on why the LocalConnectionTarget class does not use any kind of filtering to reduce the number of LogMessages being constructed.

One of the reason we went with LogBook as an AIR application as opposed to a web application was because as far as I know, the Flash Player process on the web is independent from that in AIR. This means that LogBook could become a very elaborate application on its own but it will not impact the performance of the application using LogBook based logging. Also when we pass objects across LocalConnection, these objects do not accumulate in the application’s memory. Here is a screenshot from a quick experiment where I ran an endless loop that created a custom LogDispatcher object, had it send a log message across the LocalConnection and then get garbage collected. The memory profile of the application can be seen below:

Here is also the live objects screen capture:

As you can see, over 600 objects were constructed but all of them could be garbage collected with no overhead in terms of memory used.

So your take away from this discussion is: using LogBook has virtually no memory overhead in your application. The idea of broadcasting all messages to LogBook is to allow you to filter the data on the client at the moment of debugging or after, rather than configuring it at some pre-launch time.

Now LogBook itself is another story. Another bug submitted by the same developer who reported this also talked about LogBook’s performance when over 1000 messages were collected, and yes, I have verified that at that point, the application becomes pretty sluggish. So for the next version of the LogBook, I am considering leveraging the SQLite database that AIR comes packaged with.

More on LogBook 2.0 soon. We are already on it and it will be good . If you would like to participate in defining the functionality in 2.0 or better yet, help us develop it, join the conversation on the LogBook user group here.

Can PicLens be done in just Flash and Papervision3d ? Here ya go !

arpit — Thu, 13 Mar 2008 00:22:07 +0000

PicLens has been one of the new interfaces that has wowed quite a bit of people I know (including myself). But the application is written in native code and needs to be installed on your computer as a plugin to be usable. Off late I have been playing with Papervision3D a bit and I figured it was possible to kind of get the functionality just by using that. Here is the result of my experiments so far. (warning: this demo requires a good internet connection since I am loading a lot of images)

Update: Uploaded a video for users on poorer connections:

Click on the input text field, enter a search term and hit enter:

The code is built on top of the Paged – data classes I had talked about in my last post. So basically new photos are loaded from Flickr as you reach the edge of the currently loaded data set. The code is pretty awful right now since I had to revisit my basic algorithm a couple of times so if you scroll around quite a bit, it may begin to spike your memory or act all weird. I need to implement some recycling of renderers strategy which seems to be advised strongly for such applications. Also I am not completely happy with the tilting algorithm I have right now (to get it really right I need to change the algorithm to do a little more math, right now the transition from tilt to normal is a little jarring). Ah well, that happens later. Right now, I am just stoked this works .

Photowall: Scroll based data prefetch

arpit — Wed, 12 Mar 2008 03:53:53 +0000

Photowall is part 1 of a secret project I am working on (secret only since I am not sure part 2 will work, so I’d rather not declare yet what its about ). This component on its own is an exercise in data-prefetch. The idea is to load data as the user scrolls to the end of the current set rather than ask the user to click on a “more photos” link. In this case, the component is feeding off Flickr data.

Type in a search word inside the text input and hit enter. Once the first set of data has loaded in, use the scrubber below the photos to scrub through the photos. Note: Data prefetch is triggered on mouse-up rather than mouse-move, I need to implement that in the final version.

Under the hood, I have a class called PagedDataService that computes which page of the remote data the user is on (Flickr apis support paged data, with each call out asking for a certain number of photos and a page offset, so page 1 has 0 to 1 x pagesize photos, page has 2 x pagesize, etc. Right now my pagesize is 60. ). The code also uses a PagePolicy class that the container looks at to see when the more data should be fetched. For example, in this case, I have asked the container to get more photos when the user is about 18 photos (6 columns) away from the last photo in the set.

There is no optimization of the code here yet, so I am not managing the photo renderers that aren’t visible to the user (which would free up memory). Another optimization would be to reuse renderers rather than create new ones like I do for every photo. Finally, a priority queue for the load requests would be great here.

So much for part 1, on to part 2. Stay tuned .

E4X parsing caveat: Watchout for the Firefox-hidden Namespaces

arpit — Wed, 06 Feb 2008 02:01:46 +0000

A friend of mine was having issues with parsing an xml file using E4X today. We were trying parsing an XML file generated by a webservice and for all he tried, the nodes were completely inaccessible to his code. Viewing the XML in Firefox didn't give any clues and everything should have worked. I have debugged exactly the same thing before so I was able to help but since I have seen developers do this more than a couple of times, I thought I should mention this: Loading an XML file within Firefox hides all Namespace declarations. To actually see the document as its coming in, view source on the document and all namespaces will be seen there.
The document he was parsing turned out to have a default namespace declaration in the root tag which means all the nodes were in that Namespace. The root tag of the xml document looked like:

PLAIN TEXT

XML:

status="0" xmlns="some:ns:declaration">

Here is the code to actually parse such a document:

PLAIN TEXT

Actionscript:

var u:URLLoader = new URLLoader();
u.addEventListener(Event.COMPLETE, onLoadComplete);
u.load(new URLRequest("document.xml"));
function onLoadComplete(event:Event):void{
XML.ignoreWhitespace = true;
var x:XML = XML(event.target.data);
var ns = x.namespace();
trace("node value: "+x.ns::node1.ns::node2);
}

Note the 'ns:: ... ' prefix to the node-names you are trying to reach.

Hope this helps .

More links on E4X and Flash:
Referencing ActionScript Reserved Words in E4X
Parse a document with namespaced nodes and a variable to be evaluated

Be careful with the new Flash Player 9.0.115.0 security changes.

arpit — Mon, 14 Jan 2008 01:43:34 +0000

I am surprised this isn't talked about more in the blogosphere. The only reason I got to this was because a couple of my Flash applications broke this weekend and it took a lot of digging by quite a few of us on my team before we got to the root of the problem. So here is the deal: With all the goodies that have come with the latest Flash Player, one of the features that seems to have arrived is a stricter security model. There is a complete article on the updated security model can be found here on the Adobe Devnet site. A more bite sized sum-up of the article can be found here. As you see, the 2 big changes is the move to XML schemas rather than DTDs and a new site-control tag for meta-policies on crossdomain access.

Ah, so that's breaking my app.

Well, not really. Before we updated our crossdomain.xml files, I just wanted to confirm that that was indeed the problem. So I enabled logging on my Flash Player (to see how to do that check the logging section on the article here). The log though surprised me. Here is what I saw (I have edited the site names where I was seeing the issues):

Error: [strict] Ignoring policy file at http://[site name]/crossdomain.xml due to missing Content-Type. See http://www.adobe.com/go/strict_policy_files to fix this problem. Error: Request for resource at http://[site name] by requestor from http://[swf url] is denied due to lack of policy file permissions.

Yikes. So seems the problem was that our server was not sending Content-Type headers for the xml files and the new Flash Player is a lot more strict about that, rejecting such crossdomain.xml files.

Hopefully this helps someone out there. If you do load data across domains, do verify they work on the new Flash Player.

[Update] Also check out the changes to authorization headers support for basic HTTP Auth:
http://kb.adobe.com/selfservice/viewContent.do?externalId=kb403184&sliceId=1