Adobe AIR Development

[tensioncore]

I've got the code working from the following thread:
http://supportforums.blackberry.com/t5/Adobe-AIR-Development/BB10-Beta4-ActionBar-issues/td-p/201530...

I understand RIM is moving away from AIR, but why have the functionality there for a new OS when there are no samples and What information out there is very scarce and basic?

I'm really just looking for any more docs on how I can use this feature to built a decent app.

How to use it would be a nice place to start. I've read the SDK reference over and over, but I just can't seem to figure out how to use this code effeciently, and what does what? I might just need a better explanation... 

...what's the difference between Action and TabAction?

...How can I use the ActionBar with a multiple page app and have the "actions" in the ActionBar change the current page?

... How can I imlement an app Menu?

...Can I use SWIPE events like with the PlayBook to open the "IN_OVERFLOW" menu of the ActionBar?

[jtegen]

RIM is not moving away from AIR.  Their focus is on Cascades, but that does not equate dropping AIR.  AIR 3.4 will be coming this spring and they just release support for FlashBuilder 4.7.

As of documentation.  All the environments are playing catch up.  The API is there, but how to use is still a little weak.

To answer some of your questions:

•  A tab action is suppose to change the state of the view, where actions are to perform some kind of action.
• You could have a single action page that pages the views.  Most will have an aciton bar on each page and the actions are based on the content of the page.  When an action is selected, it calls an event listener and you respond to that (see sample below)
• Swipes for BB10 for the app menu is no different then PlayBook app bar/buttons.  There are a lot of threads on this.  If you need more, I can probably post some code.

I use a "Page" class and an "ActionPage" class that encapsulate some of the action bar features.  This assumes that an action bar has been added as a child and the updateDisplayList updates its position and width.

Add actions to bar:

this.actionbar.showTabsFirstOnBar( false );
this.actionbar.backButton = new Action( 'Back', null, {id:'back'} );
this.actionbar.addAction( new TabAction( 'Search', null, {id:'search'} ) );
this.actionbar.addAction( new TabAction( 'POI', null, {id:'poi'} ) );
this.actionbar.addEventListener( ActionEvent.ACTION_SELECTED, ActionSelected );

 The nulls can be replaced to show an image.  Do not have to do that for the back button unless you want your own back image.

List for actions:

////////////////////////////////////////////////////////////////////////
private function ActionSelected( event : ActionEvent ) : void
{
	switch( event.action.data.id )
	{
		case 'back'           : this.Back(); break;
		case 'options'        : this.showSettings(); break;
		case 'poi'            : this.shared_data.locateOnMap(); break;
		case 'details'        : this.showDetails(); break;
		case 'directions'     : this.showDirectionsTo( ); break;
		case 'clear'          : this.DoClear( null ); break;
		case 'search'         : this.DoSearch( null ); break;
		case 'share'          : this.Share(); break;
	}
}

 You can use the same ActionSelected listener for context menu selections.

Hope this helps.

[tensioncore]

That was pretty great, as per usual for your posts.

Right now I have been looking at the idea of using Containers and Alphas to dynamically change content.

I was thinking I could use the top part of the screen (everything above the ActionBar) as a Container, everything that I need having Alpha = 1; and everything else (things on different "pages") with an alpha = 0;

You mentioned having a Page Class, would you use this to the same result as I described with the alphas? - Dynamically Add/remove content based on button presses? Is this the same Page class I recall seeing for the playbook? - PageViewStack?

I should be fine without code examples, I really just need the concepts to be explained a little more thoroughly, I definitely see what you mean about the catch-up game that non-Native SDKs are playing.

I've already submitted/had approved my first BB10 app (using coding styles I used for the PlayBook) - now I am most curious about developing apps with a Native Look/Feel.

[Innovatology]

Don't use alpha, it is not an efficient way of doing this. All your controls will be created,  measured, rendered even if their alphas are 0. On mobile, keep the display list as simple as possible and create your controls on demand.

[tensioncore]

In looking at the API Ref for Action and TabAction they seem to be identical with the exception of name and intended purpose. Odd

I just don't see what adding an Action to do something is different then adding a TabAction to do something? Don't they both appear in the ActionBar/Overflow?

[jtegen · Accepted solution]

The look of the button is different. Tab buttons have a selected state. Just like normal "tab" views, one tab is selected to show which view is currently being shown. Actions are more like a button that performs a "momentary" action in that view.

If you have tab buttons, you cannot have a "back" action button. So if you are allowing a person to go back to the previous page from a back action, then you cannot use tabs.

There is a lot to the action items that we do not have examples and why one whould be used over another. Personally, I have not had a lot of time to play with it. I know you can take the back button and make it draggable to expose a view underneath. Once there are more BB10 apps, I might get better ideas in how to improve the UX on BB10, but right now, I just use basic Actions, no tabs.

[jtegen]

Yes, dont use alphas,
I have a Page class that extends UIComponent. My ActionPage extends Page that includes an action bar. In my old page view class that I enhanced some for BB10, I basically tween a page on and off and at the end of the tween, add or remove a new (or old page) from the display list. the entire page is self contained and does not rely on other pages for content. This makes it a lot easier to code and understand the state of a single page.

The base app just governs the pages. If your app just has one view, in my world, that is still a single page.

I will post the code for this in case it does help someone. Even for ideas.

[jtegen]

Page transition:  If this helps someone and if any has ideas to improve it:

//////////////////////////////////////////////////////////////////
public function setPageIndex( pg : int, direction : String ) : void
{
	//trace( 'setPageIndex ' + pg + ' ' + this._current_index + ' ' + this._switching );
	if( this._current_index == pg || this._switching )return;
			
	var page :UIComponent = this._pages[ pg ] as UIComponent;
         page.setActualSize( this._parent.stage.stageWidth, this._parent.stage.stageHeight );
	
	this._switching = true;
			
	this._current_index = pg;
			

	if( direction == RIGHT_LEFT )
	{
              page.setPosition( this._parent.stage.stageWidth, 0 );
	    this._parent.addChild( page );
	}
	else if( direction == LEFT_RIGHT )
	{
              page.setPosition( 0, 0 );
	    this._parent.addChildAt( page, this._parent.numChildren - 2 );
	}
	else if( direction == TOP_BOTTOM )
	{
              page.setPosition( 0, -this._parent.stage.stageHeight );
	     this._parent.addChild( page );
	}
	else if( direction == BOTTOM_TOP )
	{
              page.setPosition( 0, this._parent.stage.stageHeight );
	     this._parent.addChildAt( page, this._parent.numChildren - 2 );
	}
            
            

	if( direction == RIGHT_LEFT )
	{
		Tweener.addTween( page, {x:0,time:this.time,onComplete:DonePage,onCompleteParams:[page],transition:'linear'} );
	}
	else if( direction == LEFT_RIGHT )
	{
		Tweener.addTween( this._current_page, {x:this._parent.stage.stageWidth,time:this.time,onComplete:DonePage,onCompleteParams:[page],transition:'linear'} );
	}
	else if( direction == TOP_BOTTOM )
	{
		Tweener.addTween( page, {y:0,time:this.time,onComplete:DonePage,onCompleteParams:[page],transition:'linear'} );
	}
	else if( direction == BOTTOM_TOP )
	{
		Tweener.addTween( this._current_page, {y:-this._parent.stage.stageHeight,time:this.time,onComplete:DonePage,onCompleteParams:[page],transition:'linear'} );
	}
}
		
////////////////////////////////////////////////////////////////////////
private function DonePage( page : Page ) : void
{
	this._switching = false;

	this._parent.removeChild( this._current_page );
	this._current_page = page;
}

[tensioncore]

Thanks!

My understanding is much better now, and I've got some good ideas on how to build a nice looking/feeling BB10 app now!

I see in the Weather Guesser app, the extra options come out on the left side, whereas the normal "overflow" comes out on the right... Is there any reason to have one or the other in AIR?

I can see using the left for "peek" type options (tabs- usually, no?) and left for Actions Overflow.....MAN they are giving us a lot of options for menus....

[jtegen]

There is probably some doc on the UX side of this. From what I've seen, new page come in from the right and when done, depart to the right. Thinks peek underneath still moves the page to the right. Cards seem to come from the bottom. I am fully prepared once we see more BB10 apps in action, that some of the metaphors will need to be adjusted.