Archive for the ‘Flex 4.0’ Category

Spark: DataNavigators – Elements instead of ItemRenderers

Friday, March 12th, 2010

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):

    (more…)

    Spark: DataNavigators

    Tuesday, March 9th, 2010

    At the last LFPUG I did a presentation on Flex 4 where I went through what I thought were the fundamental changes, and they showed some custom stuff I’d been working on. The plan was to then do a post on each slide explaining in a little more detail (which is still the plan), but there’s a few posts that talk about Navigators in Flex 4, and for anyone who visits this blog often you’ll be well aware of how much I use navigators.

    With this in mind I thought I start posting some examples and open sourcing the code I’ve been working on, so today I thought I’d start with DataNavigators.

    There are 3 components to talk about here. They all support virtualLayouts as long as the layout supports it. In building these I’ve ask a lot or questions of what others expected and try to implement the re-usability that is inherent in the spark framework.

    —————————————————————-

    DataNavigator

    You can think of this to much like a DataGroup with 2 exceptions…

  • the layout must implement INavigatorLayout (a custom interface I’ll cover another day).
  • it implements ISelectableList
  • —————————————————————-

    SkinnableDataNavigator

    You can think of this much like a SkinnableDataGroup, with 3 exceptions…

  • the layout must implement INavigatorLayout (a custom interface I’ll cover another day).
  • it implements ISelectableList
  • the SkinPart it uses for displaying content has to be a DataNavigator
  • —————————————————————-

    BorderDataNavigator

    BorderDataNavigator extends SkinnableDataNavigator adding a border, in the same way as BorderContainer extends SkinnableContainer.

    —————————————————————-

    Here’s an example of the 3 of them in action using itemRenderers:

    (more…)

    AnimateTransitionShader

    Monday, January 11th, 2010

    A couple of days ago Corey Lucier posted a couple of nice examples of the new Flex 4 AnimateTransitionShader.

    Like Flex 3, the new effects don’t handle being interrupted well. They jump abruptly to the end of the current IEffectInstance, then start a new one. The abruptness is what your trying to get away from when you decide implement an effect, opting for a smooth transition.

    With a bit of tweaking about it was fairly easy to hack around this. Here’s what i changed

  • When an effect instance is interrupted it takes a snapshot of the view, and passes this a a bit of other info to the effect factory.
  • The effect instance then stops the final value being applied.
  • When creating an effect instance the effect factory looks inside itself for any interrupted effects that have the same target. If it finds one it passes the data through to the instance.
  • The effect instance then uses the snapshot to transition from.
  • In the examples below I’ve added a couple of more states and a ButtonBar to navigate. I’ve also removed the easing to make it a little simpler to see. If you click around a bit you should see the difference.

    (more…)

    Using Spark Containers in MX Navigators

    Wednesday, December 30th, 2009

    I love mx Navigators (ViewStack, TabNavigator etc.) yet when adding spark containers to them you get the error…

    The children of Halo navigators must implement INavigatorContent.

    If you want to use the new spark containers you need to wrap them in, or just use spark.components.NavigatorContent (not easily found unless your using design view). NavigatorContent itself extends spark.components.SkinnableContainer so you can use it much like a Group and set a custom layout.

    <?xml version="1.0" encoding="utf-8"?>
    <s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" 
    	       xmlns:s="library://ns.adobe.com/flex/spark" 
    	       xmlns:mx="library://ns.adobe.com/flex/mx"
    	       minWidth="955" minHeight="600">
     
    	<s:layout>
    		<s:VerticalLayout/>
    	</s:layout>
     
    	<mx:ViewStack id="vs" width="400" height="200">
     
    		<s:NavigatorContent width="100%" height="100%" backgroundColor="0xFF0000">
    			<s:layout>
    				<s:VerticalLayout/>
    			</s:layout>
    			<s:Button label="vertical button 1"/>
    			<s:Button label="vertical button 2"/>
    			<s:Button label="vertical button 3"/>
    		</s:NavigatorContent>
     
    		<s:NavigatorContent width="100%" height="100%" backgroundColor="0x0000FF">
    			<s:layout>
    				<s:HorizontalLayout/>
    			</s:layout>
    			<s:Button label="horizontal button 1"/>
    			<s:Button label="horizontal button 2"/>
    			<s:Button label="horizontal button 3"/>
    		</s:NavigatorContent>
     
    	</mx:ViewStack>
     
    	<mx:ToggleButtonBar dataProvider="{vs}"/>
     
    </s:Application>

    Flex Community Feedback Forum

    Wednesday, January 28th, 2009

    Apparently the Flex SDK team had disappointing turns outs for their session at Max, although personally I wouldn’t read to much into that. Max is expensive, and if you are there, it’s highly likely there’s other sessions you might be interested in.

    This evening at 6pm GMT the Flex SDK team with be holding a community feed back forum via Adobe connect.

    Come speak with the Flex SDK team to voice your interests and concerns. This session will be an opportunity for the community to talk about the Flex SDK
    itself and discuss our management of the SDK open source project. Please bring your questions and feedback as the session will primarily be led by you (and could be short if there’s not a lot of input).

    http://adobedev.adobe.acrobat.com/techweds
    ** enter the room as a Oguest¹ using your First and Last name **

    Announcement

    Orientation Class

    Thursday, July 24th, 2008

    In the Flex framework we have the following classes…

    BoxDirection
    FormItemDirection
    TileDirection
    TileBaseDirection
    ScrollBarDirection
    ScrollEventDirection
    SliderDirection.

    All for the purpose of setting the orientation of a component (defined as direction), each class has the following 2 public static constants…

    HORIZONTAL : String = “horizontal”
    VERTICAL : String = “vertical”

    Do we seriously need all those classes for those 2 options?

    I logged a request on this a while ago suggesting they all get replaced with a class called Orientation. This for me would seem a more useable/consistent approach, and also would give me a class to use in my own components that required an orientation property set on them.

    https://bugs.adobe.com/jira/browse/SDK-15859

    This issue is now assigned to ‘community’ and I get the feeling that means its just lost and ignored, which is why I thought I resurrect it with a post here.

    As I noted in the request, direction isn’t the greatest name for the property on the components that use the above classes as direction also implies, up, down etc… Personally i think the a property called orientation is much more fitting. If change it would mean the following…

    [as]myComponent.orientation = Orientation.HORIZONTAL;
    myComponent.orientation = Orientation.VERTICAL;[/as]

    … which to me looks much tidier.

    On a side note does anyone look through the community issues regularly to vote?

    Flash, Flex & AIR Package Names

    Monday, April 28th, 2008

    flash = Flash Player & AIR
    fl = Flash
    mx = Flex & AIR
    air = AIR

    Make any sense? Explicit for new users? Does anyone know why the legacy mx is still around?

    A while back I suggested the following, and it was brought up in conversation again the other day…

    player = Flash Player
    flash = Flash
    flex = Flex
    air = AIR

    To be honest I thought the feature request would get quashed straight away, but it’s still there and open. Want to see package names cleaned up for future releases? It’s up to us!

    Flex 4.0

    Monday, February 25th, 2008

    Now Flex 3.0 is officially released, I guess a lot or you like me will be waiting to get your hands on Flex 4.0. You can keep an eye on what’s going on with Flex 4.0 here.