Blog

*** Update 7.14.2006: Got an official update.

(mt) Media Temple currently has plans for turn-key hosted Flex Data Services solutions. Although we don’t have a confirmed timeline for the rollout of these products please be assured they are in our pipeline and will be prioritized based on customer demand.

*** Update 7.12.2006: Been shooting emails back and forth with David Feinberg, a Product Manager at Mediatemple. He says they DO have plans, and are working on getting FDS setup. w00t! ***

I just asked Mediatemple sales and got a response. More specifically:

…To answer your questions specifically; at this time we don’t have any immediate plans to upgrade. Please check with our site or with me at a later time. …

Anyone know of any hosting companies that plan on doing Flex Data Services hosting?

When creating custom components, a lot of times it’s just easier to extend existing controls. For example, creating an auto-complete text field isn’t so hard; if you extend mx.controls.TextInput, the only code you have to write is for handling creation of the popup, and handling keyboard events.

The problem is validation. It’s an extremely complex process that works in many passes. In Flash MX 2004 and 8, it was constructor, init, createChildren, draw, and size. There were other minor, but integral functions in that process, but basically it comes down to create it, set it’s default properties, and render the mofo. This strong arm approach didn’t scale to Enterprise apps very well.

Enter the Flex framework. They further fine tuned the invalidation routines. Not only could you defer sizing and drawing to the next redraw event in the Flash Player, but all kinds of properties and styles. If you’re a seasoned Flash Developer, you know if stuff appears “not ready” you just wait a frame… or two. In Flex 1.5, things are no different. Typically, you can use a doLater (or 8) with simpler recursions for a lazy approach, or you can find what properties in particular start the process as most are pretty blatant (anything that calls invalidate).

I may sound like I’m bashing it, and I am, but it truly is valuable. Drawing once per redraw is better than attempting to draw 300 times a second when you can only draw 30 times a second. This is before refactoring and optimization of course. It’s just it’s extremely confusing the nuances of how those affect those extending the framework classes. You shouldn’t use Composition over Inheritance because you’re afraid of extending a class, instead feeling more secure by wrapping your own proxy methods around it as a safety net.

As a component developer, you may think you can take advantage of this, and you can. All the plumbing is held mostly in mx.core.UIObject and all his CSS and LayoutManager friends have hooks nicely integreated. The problem is mixing methods that redraw your GUI immediately vs. later. So, if you write methods that draw your GUI, and mix invoking them elsewhere with doLater’s, you can get unexpected results. The reason for this is that doLater’s are added to an array, and dealt with next screen redraw. After they are dealt with, they no longer exist.

I ran into a situation today where I was calling doLater in a class that extended TextInput, and they’d disappear off into the ether. The reason was, the method I was calling before was setting the “text” property. This is a getter / setter that actually causes invalidation. I’m doing the exact same thing in 2 places; calling a method that causes invalidation and then immediately calling a doLater after it. The only reason the second one fails is because the onEnterFrame spins off into the ether. The cause? Not sure. The first method is called when the internal component fires the enter key presseed event. The latter, broken, method is called in response of a List control being created in a popup being clicked on.

My guess is, the List emitting an event, and immediately being destroyed via a call from a Delegate scoped function somehow ticks off the internal guts of the UIObject, confusing it’s scope, and thus refusing to deal with the methodTable. Meaning doLaterDispatcher is apparently never fired even though onEnterFrame is happily chugging away, 21 times a second, doing nothing useful, eating CPU cyles.

My fix? Make all methods excluding the invalidation causing one to use doLater. Since there is no operator, similiar to public and private that goes something like “causesinvalidation”, I’ll just have to be extra mindful when extending controls that if I’m doing something that will cause multiple invalidations, I’ll have to provide a better conduit, such as a funnel method (you wanna redraw, you call me), or some other proxy.

Bottom line, if you doLater’s are failing to fire, try converting all functions to a doLater and/or indentifying what property you are setting / method you are calling that is causing the invalidation and tread around it.

…or build your own invalidation. Make a movieclip, make it’s onEnterFrame call your function via closure, and then immediately have it remove itself. This has worked flawlessly since Flash 4.

Flex 1.5 (and Flex 1, and Flash 8, and Flash MX 2004) have a class called mx.managers.PopUpManager that allows you to create modal windows. You don’t have to make them modal, but modality ensures that users handle the interface you’ve provided for them first and prevent them from doing anything else until they have.

The problem is when you open multiple popups that are modal and have the same parent. A preferences form for example could be opened in a modal popup window which in turn launches another modal popup. It uses very low-level ActionScript to create a “mouse shield” that prevents user mouse clicks from activating anything behind the popup. This ensures that the user can only click on whatever is in front of the shield. Others have found that some keyboard presses can get through, but it’s rare enough to not be a problem.

The problem here, however, is if you have a component in the 2nd popup that utilizes it’s own non-modal popup. Since some components, namely Panel’s and TitleWindow’s use a shadow that’s actually created in 1 depth below them in their parent’s drawing stack (timeline), the PopUpManager’s modal code compensate’s for this and moves the modal mouse shield 2 depths lower to give it breathing room. For some reason I can’t pin down, nor care to at this point, additional non-modal popups are put behind this lastest shield. So, in the case of a ComboBox for example, the popup list will appear behind your form AND the modality (mouse shield).

My hack, after it creates the custom List component in a popup (think auto-complete field), is to have the component check if the parentDocument’s deletePopUp method is not undefined. If it’s not undefined, it’s a popup. If it’s a popup, I need to move my newly created List popup up 2 depths higher than the parentDocument that houses it. This works like a charm, but is a hack, breaks encapsulation, and might not work if she’s deeply nested in more than 1 level of popups.

If you’re popups start appearing behind the modality, and you’ve ensured you’ve positioned them correctly, try swapping their depths to something at least 2 higher than their parentDocument.