Reflex Application Initialization Questions

[Jesse Freeman]

Hi guys, not on my iPad so I have a serious question ;-)

Ok so I have been working on getting pre init code to run on an
extension of the current application class for the past 2 days. Going
through the chain of inheritance and trying to wrap my head around it.
Here are my issues:

1) I need a way to preload content into the application. As of now if
I extend Application directly there are not hooks to inject code
before all the Component -> Container logic fires. This is not so bad
but if my Main class is MXML (extending my implementation of
Application) my configuration logic fires after any components get
instantiated. So this is a little bit of a problem since Component is
not set up in a modular enough way to inject "preinit" code and
manually resume the built in initialization process. If this does
exists I am missing it somewhere.

2) There is no hook for when the application is ready. I have added my
own which ties into my own configuration logic but there is currently
no way to do this in any MXML class similar to how you can in Flex.

3) I am fine with not making my main class MXML (since I can't force
my own configuration files to load in first) so is this the intended
solution? I am still wrapping my head around best practices for Reflex
and MXML classes since my exposure to Flex has been very little.

4) Finally going through the chain of inheritance of Application ->
Component -> Container I found it extends MovieClip? Why not make
this extend Sprite? I don't see any advantages we would gain over
using MovieClip but if I am wrong I would love to know why.

Thanks for listing,
Jesse

[Tyler Wright]

Jesse,

Because of the way MXML is compiled in the FlexSDK all of the objects are created in one pass. This means we can only delay instantiation where children are assigned dynamically, such as with a skin-lookup via the CSS. It would be possible to have a pre-init hook fire before children are added to the display-list, possibly before the children are even created, but no way to halt the process and then manually resume later.

There's another option where you could load pre-initialization stuff before the Application class is instantiated. We plan on taking full advantage of the [Frame] meta-tag that allows 2 or more frames to load the application in pieces (Flex uses a two-frame system). I finally got my hands dirty with the system and would love to write up an article on modularity in Reflex, but don't have the time to fully document it at the moment.

If you describe the kind of pre-init things you're trying to accomplish it would help determine if there's another approach that would be a better fit.

Tyler

--
To unsubscribe, reply using "remove me" as the subject.

[Tyler Wright]

Extending MovieClip was a design choice made back when there was a general consensus that Reflex would fully support Flash CS. It costs significantly less by way of performance and memory footprint than is generally perceived, but still more (if only slightly) than Sprite. It also adds API that is irrelevant to a Flex-like workflow. It may change.

Tyler

On Wed, Apr 7, 2010 at 10:05 AM, Jesse Freeman <jessef...@gmail.com> wrote:

[Jacob Wright]

We could add a preInit event to be dispatched in the constructor of Application. This would make it easy to add stuff in MXML to that event. There is also currently an init method which can be overridden when a component is added to the stage (creationComplete) and I believe an init event is fired then too. This is also when the application is complete.

If this doesn't work for your situation we could talk about what you're trying to accomplish and figure out what we need to add to support situations like it.

Jacob

[Mrinal Wadhwa]

Tyler,

Would love to know more about how modularity is implemented in Reflex,

>> We plan on taking full advantage of the [Frame] meta-tag that allows 2 or more frames to load the application in pieces (Flex uses a two-frame system)

I recently spent some time understanding the [Frame] meta tag and implemented a preloader here

But, turns out the -frame compiler option works much better since it doesn't force a dependency on IFlexModuleFactory and results in much cleaner code.

_

Mrinal

[Tyler Wright]

We could add a preInit event to be dispatched in the constructor of Application. This would make it easy to add stuff in MXML to that event. There is also currently an init method which can be overridden when a component is added to the stage (creationComplete) and I believe an init event is fired then too. This is also when the application is complete.

It doesn't make sense to dispatch events in the constructor of an object because it will always be too late by the time a listener is added.

[Tyler Wright]

I recently spent some time understanding the [Frame] meta tag and implemented a preloader here

But, turns out the -frame compiler option works much better since it doesn't force a dependency on IFlexModuleFactory and results in much cleaner code.

Interesting, I assumed they would have been the same. That would be a great approach to look into, particularly if it's something that can be added into the SWC.

I'll try and get something posted about modularity, probably after we have component-filled UI's to be modular with. ;)

Tyler 

[Paul Taylor]

Jesse, if you're using Tyler's fork, there's a class that is similar
to Flex's SystemManager. If you just need need to preload classes, one
way to do it is to create a SWC and add it to your project's build
path as an external resource. The ReflexApplicationLoader (aka
Reflex's SystemManager) will load it on frame 1 for you, and you will
have the content available by the time your Application's constructor
is called.

Though, this does bring up a point I neglected to mention previously
about the ReflexApplicationLoader:
We could support the [Mixin] tag, (more here:
http://nondocs.blogspot.com/2007/04/metadatamixin.html ). Basically if
you write a class with [Mixin] metadata, create a static init function
which accepts the root MC as its only parameter, we can do some static
initialization before the Application is created and added to the
stage. FlashBuilder generates a list of "mixins" (classes it knows
about with the [Mixin] metadata tag) that the Flex SystemManager calls
the init method on them before it creates the Application. Here's the
code that we could change in the RAL: http://gist.github.com/359366

Let me know if it's something that interests you guys.

Paul

[Tyler Wright]

I think exposing the system manager (or frame-1 class) as a public and extendable class is the way to go, rather than the hidden magic of Flex. The mixin tag might have some merit too, but to support customization of your loading and initialization process might be enough.

By the way Paul, great work with the [Frame] implementation - I have a few suggestions we could talk about sometime. Specifically refactoring to a factory base-class that could work on a 1st, 2nd, 3rd frame and so on. Extending this class with an exposed continue() API or something would make it easy to create custom initialization frames where any type of asynchronous initialization would be possible. I got a little carried away daisy-chaining factory classes when I was playing with it last, it's kinda fun. :)

Tyler

[Jesse Freeman]

Sorry to start the tread and not follow up but i have been busy trying to implement my idea. I finally reached a working poc but am calling it a night. Will throw up some examples of what I did tomorrow. 

Sent from my iPad

[Paul Taylor]

> But, turns out the -frame compiler option works much better since it doesn't
> force a dependency on IFlexModuleFactory and results in much cleaner code.

The only thing is that FlashBuilder already works with and generates
code for the IFlexModuleFactory. We'd need an interface that did the
same thing anyway, so why not use it?

> I have a few
> suggestions we could talk about sometime. Specifically refactoring to a
> factory base-class that could work on a 1st, 2nd, 3rd frame and so on.

True that, it could be totally useful.

> Extending this class with an exposed continue() API or something would make
> it easy to create custom initialization frames where any type of
> asynchronous initialization would be possible. I got a little carried away
> daisy-chaining factory classes

A few things I'm not sure about is 1. the order in which the frames
are placed, and 2. who will be set as the root mc.
The Frame metadata on the [Reflex] Application class does something
very different than Frame metadata on your actual (mxml or AS) App's
Application class. If it's on the Reflex Application, FB generates/
compiles in the "SystemManager" for you. If it's on your App's
application class, I know it doesn't generate a subclass, instead it
uses the actual implementation you specify, but it does compile it in
on a frame... just not sure of the order.

> The mixin tag might have some merit too

I could see a mixin class that initializes styles on the root before
the Application is created/added, and possibly inherit them when he's
added to the stage. Not too familiar with Jac's styles implementation
yet, but it's possible. What about applying Layouts to the root MC
this way? I'm sure there are some legitimate uses for it.

Paul

> >http://nondocs.blogspot.com/2007/04/metadatamixin.html). Basically if

[RickB]

Tyler, aren't there cases of deferred/lazy instantiation in certain
containers? I was under the impression that containers such as the
Tab-* components behaved this way, thus the reason for the
creationPolicy property.

Rick

On Apr 7, 2:50 pm, Tyler Wright <xty...@gmail.com> wrote:
> Jesse,
>

> Because of the way MXML is compiled in the FlexSDK *all* of the objects are

> created in one pass. This means we can only delay instantiation where
> children are assigned dynamically, such as with a skin-lookup via the CSS.
> It would be possible to have a pre-init hook fire before children are added
> to the display-list, possibly before the children are even created, but no
> way to halt the process and then manually resume later.
>
> There's another option where you could load pre-initialization stuff before
> the Application class is instantiated. We plan on taking full advantage of
> the [Frame] meta-tag that allows 2 or more frames to load the application in
> pieces (Flex uses a two-frame system). I finally got my hands dirty with the
> system and would love to write up an article on modularity in Reflex, but
> don't have the time to fully document it at the moment.
>
> If you describe the kind of pre-init things you're trying to accomplish it
> would help determine if there's another approach that would be a better fit.
>
> Tyler
>

> > To unsubscribe, reply using "remove me" as the subject.- Hide quoted text -
>
> - Show quoted text -

[Tyler Wright]

Tyler, aren't there cases of deferred/lazy instantiation in certain
containers?  I was under the impression that containers such as the
Tab-* components behaved this way, thus the reason for the
creationPolicy property.

Yes, but unfortunately we have to tie very closely into UIComponent and the Flex Framework to support this. So we have to be smart in other areas to compensate and roll our own deferred instantiation. There are a few approaches we might try but nothing implemented yet.

Tyler

[Ben Stucki]

Agreed. It's probably going to be a few versions in before we get to this one, but right now I'm expecting deferred instantiation to be tied into the new state system as opposed to the containers themselves. Paul's already started some early work on the state system, but I'm not sure if it's ready to be merged in yet.

[Paul Taylor]

> Paul's already
> started some early work on the state system, but I'm not sure if it's ready
> to be merged in yet.

Sorry, I've been slacking on this the last two weeks, deadlines have
reared their ugly heads. In addition to the SetProperty functionality,
I've got the includeIn and excludeFrom working locally and I should be
posting it in the next week or so.

Paul

[RickB]

Or, make the component instantiation so mind bendingly fast and
lightweight that there's no need for deferred instantiation...hey, a
boy can dream, can't he?

[Tyler Wright]

I think that's where Flex has trained us to assume UI's are intrinsically heavy by nature. There are some pretty complex Flash animations that are handled beautifully by the Flash Player. Why shouldn't our UI's be the same?