http://www.tink.ws/examples/apache-flex/

http://svn.apache.org/viewvc/incubator/flex/whiteboard/tink/

Navigators

Navigator Example - source

TabNavigator Example - source

DataNavigator Example - source

Accordion Example - source

DataAccordion Example - source

I use navigators all the time, they are at the core of applications I build. Spark was released without any navigators, so some time ago I set about building some navigators following the spark architecture. They set includes element and data driven navigators as well as low level group navigators and skinnable navigators.

The core functionality that makes these navigators are the fact that they implement ISelectableList and can therefore be used with other controls that require and IList/ISelectableList as their dataProvider, namely s:ButtonBar and st:MenuBar (see below).

These navigators all require their layouts to implement INavigatorLayout.

Flex Navigators Presentation

Navigator Layouts

AccordionLayout Examples - source

CarouselLayout Examples - source

CoverflowLayout Examples - source

RolodexLayout Examples - source

TimeMachineLayout Examples - source

All the layouts implement INavigatorLayout for use with navigators, but the layouts can also be used with spark control/containers that expose a layout property.

I'm have some other navigator layouts in the pipeline.

Navigator Controls

MenuBar Examples - source

The MenuBar control can be used with IList objects, meaning it can also be used with navigators. If the IList's are nested it will create sub menus.

The MenuBar is basically a s:ButtonBar that uses s:DropDownLists for it's item renderers. The s:DropDownLists in turn use s:DropDownLists for it's item renderers and so on.

InlineScroller Examples - source

Users should not be prevented from setting custom layouts on spark controls as it removed flexibility from the framework. A good example of this is Scroller.

Time and time again I've come across UI's that require the increase and decrease buttons only when paging or scrolling and developers build it over and over again. If we could set layouts on a Scroller we would be able to use its built in functionality to take care of this for use. I don't propose we add an InlineScroller component, but allow uses to set layouts on the Scroller and add some new skins and an InlineScrollerLayout.

IView

ApacheIView Examples (apk)

It seemed strange to me that Adobe choose to extend SkinnableContainer for the View class for the following reasons.

1. You create instances of containers, and add elements to them. With mobile navigators, they create the instance, so 99% of people are extending view, it might as well be a Group, as you won't be using Skin Parts.

2. If you are using Skin Parts, you'd want a SkinnableComponent, not a container.

Both these reduce the DisplayObjects required. I just don't see a user case for the heaviest option, a container, that no-one uses as a container, and is what your stuck with as there is no interface.

With that in mind I put the necessary classes together for this. I have an IView interface implemented throughout, although there is a need here and there to cast to UIComponent for access to properties and methods behing the mx_inernal namespace.

So I have a custom
org.apache.spark.components.supportClasses.NavigatorStack.as
org.apache.spark.components.supportClasses.ViewDescriptor.as
org.apache.spark.components.supportClasses.ViewNavigatorBase.as
org.apache.spark.skins.mobile.ViewNavigatorSkin.as
org.apache.spark.transitions.SlideViewTransition.as
org.apache.spark.transitions.ViewTransitionBase.as

and added:
org.apache.spark.components.IView.as org.apache.spark.components.ViewGroup.as
org.apache.spark.components.ViewNavigator.as
org.apache.spark.components.ViewSkinnableComponent.as
org.apache.spark.components.ViewSkinnableContainer.as

Mobile DropDownList

MobileDropDownList Example (apk)

On desktop the item is selected on mouse down and the drop down closed. This doesn't work on mobile as the user may be scrolling the list, and therefore the committing of the selected index doesn't happen until mouse up.

I propose that in the override item_mouseDownHandler and we check the interactionMode. If it's "touch" we don't set userProposedSelectedIndex and we DON'T CLOSE the dropDown, not not touch it carries on as normal, hopefully not introducing any new bugs.

We add an override for, setSelectedIndex call super then check the interactionMode. If it's touch, set userProposedSelectedIndex and we CLOSE the dropDown.