Multiple ways of generating objects.

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Multiple ways of generating objects.

João Fernandes
Recently we needed to improve our app when it comes to generate dynamic
views based on a descriptor. Currently I'm changing our engine to create
elements similar to what the compiler & SDK does. The problem is, it uses
different approaches based on the type of containers. If it's a MX
container it will use childDescriptors, if it's a SkinnableContainer it
will use mxmlContentFactory and if it's a regular Group it will generate
directly by using mxmlContent property. My question is, isn't there a
better way?



--

João Fernandes
Reply | Threaded
Open this post in threaded view
|

Re: Multiple ways of generating objects.

Alex Harui



On 8/7/12 7:23 AM, "João Fernandes" <[hidden email]>
wrote:

> Recently we needed to improve our app when it comes to generate dynamic
> views based on a descriptor. Currently I'm changing our engine to create
> elements similar to what the compiler & SDK does. The problem is, it uses
> different approaches based on the type of containers. If it's a MX
> container it will use childDescriptors, if it's a SkinnableContainer it
> will use mxmlContentFactory and if it's a regular Group it will generate
> directly by using mxmlContent property. My question is, isn't there a
> better way?
Not really, but childDescriptors are pretty inefficient.  You'd be better
off just doing addChild.  Are you trying to improve performance?  I think
the key is to make sure to parent the containers before adding their
children.  That's especially true in Spark, IIRC.

--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


Reply | Threaded
Open this post in threaded view
|

Re: Multiple ways of generating objects.

João Fernandes
On 7 August 2012 15:50, Alex Harui <[hidden email]> wrote:

>
>
> Not really, but childDescriptors are pretty inefficient.  You'd be better
> off just doing addChild.  Are you trying to improve performance?  I think
> the key is to make sure to parent the containers before adding their
> children.  That's especially true in Spark, IIRC.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Thanks Alex but currently what our builder was doing that using
AddChild/addElement but the problem is it wouldn't respect deferred content
creation (like tabnavigators/ viewstacks etc) and would create everything
in 1 pass which was a massive hit in performance.

BTW, you're saying that currently childDescriptors are inefficient ? why?
because they're added to the parentContainer even if the parentContainer
isn't parented yet?

--

João Fernandes
Reply | Threaded
Open this post in threaded view
|

Re: Multiple ways of generating objects.

Alex Harui



On 8/7/12 8:17 AM, "João Fernandes" <[hidden email]>
wrote:

>>
> Thanks Alex but currently what our builder was doing that using
> AddChild/addElement but the problem is it wouldn't respect deferred content
> creation (like tabnavigators/ viewstacks etc) and would create everything
> in 1 pass which was a massive hit in performance.
>
> BTW, you're saying that currently childDescriptors are inefficient ? why?
> because they're added to the parentContainer even if the parentContainer
> isn't parented yet?
The childDescriptors create child objects and functions that get used once.
Our tests show that you can add children faster via the generated functions
and mxmlContent than the childDescriptor code path.

But if your main issue is navigator deferred instantiation, then the
performance difference between the two won't matter nearly as much as
getting deferred instantiation to work.

--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


Reply | Threaded
Open this post in threaded view
|

Re: Multiple ways of generating objects.

João Fernandes
On 7 August 2012 16:23, Alex Harui <[hidden email]> wrote:

>
>
> But if your main issue is navigator deferred instantiation, then the
> performance difference between the two won't matter nearly as much as
> getting deferred instantiation to work.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Thanks Alex, so my next question is, would it be possible to change mx
containers to work similar to spark infrastructure? Or would it require too
much work?

--

João Fernandes
Reply | Threaded
Open this post in threaded view
|

Re: Multiple ways of generating objects.

Alex Harui



On 8/7/12 8:44 AM, "João Fernandes" <[hidden email]>
wrote:

> Thanks Alex, so my next question is, would it be possible to change mx
> containers to work similar to spark infrastructure? Or would it require too
> much work?
We could add another code path for generating children in containers.
Actually, I had prototyped exactly such a thing to go into the Falcon
compiler.  It did not use the Spark way either.  It was one way to unify
both worlds.  There's less need for it now since future FBs won't include an
MXML code model, but maybe we can put it in anyway.

--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui