Spark: DataNavigators – Elements instead of ItemRenderers

In the previous post I gave an example of our DataNavigators in action as you would expect them to be used, with a dataProvider and ItemRenderer but you may well be asking…

I want navigators where all the elements can be different, not driven by data all using the same ItemRenderer.

This is the obvious usage of navigators as we know them (ViewStack, TabNavigator).

Well DataGroup has a sneaky little secret. It isn’t just capable or reusing ItemRenderers, its also capable of achieving deferred instantiation on elements defined inside it (thanks to Ryan Frishberg for this info).

To do this you set the itemRenderer property to null, the add your elements inside an ArrayList. Using this method its only when the element is required to be displayed that it is created.

Unfortunately this isn’t a complete solution as it isn’t capable of handling FXG as an element, it has to be wrapped inside another container.

I developed a DeferredGroup class to get over this limitation, but its success is dependent on changes to the SDK. I have 2 items in the Flex Bugbase referring to this, so if you would like to DeferredGroup (a Group that supports deferred instantiation and FXG), please go and vote on them…

  • Make it easier to extend Group
  • Don’t not hard code GraphicElement to Group
  • The components used in the following example are the same as the example in the previous post, but instead of using an ItemRenderer and setting a dataProvider the elements that need to be displayed are specified (check the numElements count, compared to the previous examples numRenderers count):

    (right click for source).

    The source for the code can be downloaded from our Google Code repository

    12 Responses to “Spark: DataNavigators – Elements instead of ItemRenderers”

    1. polyGeek says:

      Very nice discovery. I voted for both. Unfortunately I think the SDK is locked for the 4.0 release. We’ll probably have to wait for the first update to the SDK to get your suggestions in.

    2. Dan Orlando says:

      Great post Tink! That’s a sweet little discovery.

    3. Dan Orlando says:

      …wow, too bad the second of those two bugs got deferred. I agree with you completely on that. Nonetheless, I voted for both to be fixed (even the second is technically marked “closed”, which is sucky). I really like what you’re doing here… there is a lot that can be learned from this post!

    4. mico says:

      Hey Tink
      I was trying to use this example using the library from google code, but deffered instantiation is not enabled. Everything is created immediately.

      DataNavigator was populated with two groups and both were created at the very beginning.

      Can you share the classes which were used in this sample ?

    5. Tink says:

      Hi mico

      Can you show me an example of what you are doing and enable view source.

      • Tink says:

        This is because the default value for the property useVirtualLayout on ws.tink.spark.layouts.StackLayout is now false.

        <st:controls:layout>
        	<st:layouts:StackLayout useVirtualLayout="true"/>
        </st:controls:layout>

        As mentioned previously in a reply, if your adding elements instead of using an ItemRenderer and dataProvider I’d recommend looking was Navigator and NavigatorGroup.

    6. mico says:

      Great, that worked! Also, I build that using NavigatorGroup as you recommended. Got some errors related to skins first when Navigator was used .

      Thanks a lot!

    7. [...] Spark: DataNavigators Spark: DataNavigators – Elements instead of ItemRenderers [...]

    8. Kevin says:

      At risk of this being a “dumb” question… What is the advantage to this approach instead of using states and state transitions? Also, can your efflex effect be used with this naviagtors?

    9. Tink says:

      Hi Kevin

      I would use states when there complex changes within a view, for instance if you still show the same item, but ad another, I would use a navigator when I just want a simple change from one view to another.

      Navigators are simple to hook up to other controls (ButtonBars or ScrollBars), that can then get updated dynamically and control the current view.

      Navigators also allow you to affect how the view is handled very easily by changing the layout. The navigators all require an INavagatorLayoutBase, which among other things have a selectedIndex property. The default is a used in these navigators are a StackLayout, but this could be replaced with a SemiCarouselLayout, CoverFlowLayout, TimeMachineLayout, RolodexLayout (any layout which has a item that has the main focus of of many).

      Efflex cannot be used with them at the moment and generally Efflex hooks into the flex 3 navigator mx:ViewStack. Off hand I can’t remember what version of the StackLayout is public, but I have experimented with an effect property and a custom effect for Efflex, I just haven’t had the time to complete it and talk about it (although if your interested in trying it and maybe doing some work on it I can send you the code).

    Leave a Reply