Posted by Doug Hays on the 15th of June, 2007 at 11:34 pm under Flex.    This post has no comments.

In building a PositiveWare Project Tree for the Time Card, I found some great articles/posts on how to keep the open nodes of a tree after a dataProvider change:

 http://lordbron.wordpress.com/2006/07/28/flex-20-reopening-a-tree-after-updating-the-dataprovider/

http://www.adobe.com/devnet/flex/quickstart/working_with_tree/

 I tried out the solution and it worked very well for me… until the Time Card was released into the wild.

 First of all, here’s the setup.  It’s a Tree, inside of a HDividiedBox which is all popped up in a TitleWindow.  The user navigates through the Project Tree, finding the right Project or Task to track time against, enters the data and clicks save.

Now, the user wants to add a second entry and pops up the Add Time Card Entry window. 

 Two issues crept up:

  • A tree that initially is small enough to be completely visible, is expanded outside of the visible space,  and scroll bars appear.  The next time the tree is popped-up, the scroll bars don’t appear until a new node is opened or closed
  • A tree that is, when fully collapsed, larger than the visible space, will lose portions of the tree when popped up the second time.  For example, in a tree of states and their cities,  Ohio through Wyoming may not show up the second time… until you open, shut and scroll around a bit.

I wrangled with this oddity for an hour or so and right before packing it in for the night, I had the what-the-heck-lets-try-one-more-thing idea.

 Instead of:

SampleTree.openItems = open;

 I’m iterating through the items in open and calling expand:

 

if (open != null) { 

     for each(var obj : Object in open) {        

          expandItem(obj, true);   

       }

 }  

And all is well again in the Project Tree.

 

Posted by Doug Hays on the 11th of June, 2007 at 9:31 pm under Apple.    This post has no comments.

It’s amazing what losing an entire blog posting will do for brevity of your next (replacement) post.

 I had several thoughts on Windows for Safari before IE helped me get rid of them.  So, instead of well-formed thoughts, I’m bringing out the bullets:

  • I get it.  I understand why Apple decided to do this
  • It has to with the user experience for Safari users.  The more people (like QA people and web developers) that can get their hands on Safari the fewer incompatibilities that will exist.
  • Apple is about to add 4 million Safari users (who knows how long this will take, but that’s how many iPhones are being made in the first push).
  • Safari is the iPhone’s gateway to the world.  The better a website works in Safari, the more pleasant the iPhone experience
  • Safari is the iPhones software platform for 3rd parties.  This isn’t as important to me (as it relates to releasing Windows Safari).  3rd Party iPhone developers would have found a way to develop for Safari.  There will be far fewer 3rd Party apps that are as important to iPhone users as there are websites that are important to iPhone users.  These are websites that these (lucky) people use every day and will expect to run well on their iPhone

So, that’s nice and all, but how well does it work?

 Really, very, super fast.  I didn’t try many sites, in fact, I only tried PositiveWare.  But there is a lot of AJAX going on in PositiveWare and there are cases where I’m waiting for IE to run the JavaScript.

 In browsing to the Project Manager for one of PositiveWare’s best clients, here are my click-to-load times (using an iPod):

  • Windows Safari: 3.48s, 3.47s
  • Windows IE: 21.1s, 20.8s

In the Project Manager still, clicking Contract All and then Expand All on the same Project Tree used in the previous test

  • Windows Safari: 3.6s, 3.34s
  • Windows IE: 14.7s, 14.32s

Tests were run on a Mac Mini, running XP via Boot Camp. 

Can’t wait to try Safari 3 in Mac OS X!

Posted by Doug Hays on the 9th of June, 2007 at 6:29 am under Flex.    This post has 94 comments.

I’ve been writing Flex apps since I was 31. And now, when I look back on how dumb I was back then, it’s shocking. Writing my own date comparison methods and creating clone/copy methods by hand. Was I bored?

Well, I wish someone had noticed my stupidity and told me about mx.utils.ObjectUtil. What a fantastic collection of static functions. If you (who is even reading this?) aren’t using ObjectUtil in your Flex code, you should be.

My favorite functions:

  • compare – will compare the properties of two objects (even recursively) – this is great for trying to decide the equality of two objects that were returned from a web service or remote object call
  • copy – simple way to create a copy of an object. I’ve found this useful for purposefully breaking a data binding.
  • dateCompare – self-explanitory
  • toString – this is perhaps the greatest of all of them… for logging purposes, throw an Object at ObjectUtil.toString() and it’ll pretty-print the Object’s innards. It’s the var_dump of ActionScript

Enjoy,
Doug.