2009
08.19
the Flex 4, aka Gumbo, Open Iteration Meeting (recording here) dealt primarily with the work Adobe plans to do to bring parity (or near parity) between new Flex 4 components and the old Flex 3 components and the transition from Flex 3 to Flex 4.
Just to review, the new component and skinning architecture has been dubbed Spark. Halo, now referred to as MX, is the current Flex architecture and will eventually fade into the sunset (or Flex 5). That doesn’t mean Halo will go away, just that the goal is to transition new users and applications to Spark. They also emphasized that with Flex 4, you may not be able to create a pure Spark application due to lack of Spark components. With Flex 5 being the targeted release for the ability to replace all the MX system with the Spark components. Thus Flex 4 will be a boundary release, allowing a user to mix in Spark components alongside the existing MX components.
The primary driver of Spark will be Flash Builder 4 & Catalyst. In the meeting we were told that Flash Builder 4 will offer a new choice when creating a Flex project. Whether to use Spark/Halo or Just Halo. This will alter the auto-complete and code hinting suggestions. The user can still use one or both, but this will allow Adobe to shape the experience toward Spark. Thus allowing a more natural feeling transition without an forced choice that will lock a user down. Catalyst will require Spark for the output it creates.
There will also be a separation of the theme and the components themselves. There will be both Spark and MX components, and they will be named separately from the TBD (“Spark”) theme and the Halo theme. So the look & feel will be separated from the functionality. No name exists for the “Spark” theme, but after the suggestion of “Fire” or “Smoke” by Simeon Bateman, Matt Chotin replies “but we were thinking along those lines 
”
Along with this news, the presentation went through a good bit of Spark components. Adobe is working on better Spark/MX container compatibility. That may mean adjusting some MX components as well to unify them using Interfaces rather than hard classes. Each Spark component had a nice “what we’re fixing” list as well. The end goal is not to clone a MX component’s functionality but to work out the most features while keeping things simple. One example was that instead of having border styles of many components, a border container was created that would allow a border to be created around a single or many components.
Currently Flex 4 is targeted Early 2010 with a Late 2009 second beta.
Other handy links:
Differences between Flex 3 and Flex 4
What’s new in Flex 4 beta
Related Posts (generated):
2009
08.18
Today, Aug 18th, there is a Open Iteration Meeting from 10am – 11am PDT. That’s noon – 1pm local time for me, but I’ll be there, lurking in the background.
The official link is here but if you miss the meeting, there will be a summary at the Gumbo Opensource Site.
Related Posts (generated):
2009
08.11
Flex SDK bug SDK-16241 was interesting for two reasons. It was claimed then abandoned (it shouldn’t take 4 months to patch) and the “Expected Result” was actually incorrect. Lots of bugs are claimed the abandoned. I admit I did it at the BugQuash when I realized I was over my head and should move on rather than flail around for the rest of the day. The expected result threw me though.
The problem lies with Scientific Notation and it’s formatting when converted to string using NumberFormatter, which doesn’t take into account the altered decimal position. Since we’re dealing with strings in the function itself, flex doesn’t have to worry about the size of the number, so I simply built the number up to full size and send it down the line. The same problem was in the NumberBase class when adding the thousands separator via formatThousands since it converts the Object->Number->String which returns my fancy long string to scientific notation. Since I’d already solved the problem, I just copied some code over. Both places needed to be fixed because only the numbers to the right of the decimal are sent to the formatThousands function.
I also learned that when talking precision, flex means number of decimal places, not significant digits. A major distinction mentioned in the NumberBase reference.
So what about the “expected result”? Well the value being formatted is -2.34444444444434e+21 which expands out to -2,344,444,444,444,340,000,000. The expected result is listed as -2,344,444,440,000,000,000,000 for some reason. I assume it’s someone’s calculator rounding off to a numerical precision of 9 since the actual value of 235345-242+99209323-2344444444444444444444 is -2344444444444345000018 which also tells me that flex’s default numerical precision is 15.
My patch is SDK-22643 if you’re interested.
Related Posts (generated):
2009
08.06
Throwing out the laser and scalpel, and pulling out the bone saw this time. Flex SDK Patch 2 (SDK-22552) was rejected. That means it’s time for part 5 of my 3 part series (1,2,3,4) on bug quashing. Once again Ryan gives a solid reason:
Patches are getting better, but I’m still rejecting this one for performance reasons. This ends up creating 2 new Dictionaries at every single internalCompare between two objects. This is quite a lot of memory and garbage collection thrashing.
Which is a valid concern, but I wasn’t sure where else to go. Of course, Ryan had an idea though (probably sensing my lack of algorithmic knowledge)
If I’m thinking about it correctly (I hope I am), I would stick with the one dictionary approach, and in there, I would map objects to objects you’ve already detected as equal objects. The way I would actually represent this would be similar to the Union Find Algorithm and associated data structure. Check out: http://www.users.csbsju.edu/~lziegler/CS162/UnionFind.html (there’s also plenty of info on google). It’s a little more complicated but should be much faster and use less space.
I knew the problem was that you couldn’t know an object’s value unless you traversed the object, but if the object was it’s own child (as you traversed the tree) you ran into the loop before you got a result. The previous patch tracked parents, and created generic object numbers, in this patch I ignored objects (and arrays and lists) in determining the equality of objects. That doesn’t mean I threw them out, I just noted that when an object has the same concrete data and the same types of nestable objects, we’ll call it even. Then we can dig in to each object, list, or array with our new references ready to go.
Related Posts (generated):
2009
08.04
It turns out my contact form was broken, so if you tried to send me an e-mail that way, it never got through. It’s fixed now.
Related Posts (generated):