Adaptive UI: Mobile vs Tablet

The screen size of a tablet device is much bigger than a smartphone one. It’s very close to a desktop one. If you plan to develop a mobile application and run it on smarphones and tablets, you need to adapt the UI (your views) for several reasons: user experience, performance and usability. Usually, you carry a smartphone with your left hand and interact with the fingers of your right-hand. Because of the size and the weight of tablets, you might design your screens differently to accept interactions on the left and on the right portions of the screen. Ideally, some users would just use their left and right thumbs to interact with your app. The shape of the BlackBerry PlayBook has been built to enable this “thumbs” experience. In this tutorial, I’ve just built a very simple application. It’s a gallery of pictures with two screens: the list of pictures view, and the full picture view. To enable the most efficient user experience, I defined three potential layouts:

The goal of this project is to handle these three layouts within one single project that will adapt its layout depending on the size and the orientation of the screen. I’ve been inspired by NJ’s presentation available on his blog. This video presents the final result on smartphones and tablets. As you can see, the performance of the application are excellent on Android, iOS and on the PlayBook.

States and groups

To adapt the UI, start with simple declarations of states. The use if stateGroups if necessary to reduce the size of your code creating two main families “screen sizes” (phone, tablet) and “orientation” (portrait,landscape).

<s:states>
	<s:State name="portraitPhone" stateGroups="phone,portrait"/>
	<s:State name="landscapePhone" stateGroups="landscape,phone"/>
	<s:State name="portraitTablet" stateGroups="portrait,tablet"/>
	<s:State name="landscapeTablet" stateGroups="landscape,tablet"/>
</s:states>

To switch from one state to another one, I’m just listening at Resize events.

protected function application1_resizeHandler(event:ResizeEvent):void
	{
 
		var isPortrait:Boolean = height > width;
		isTablet = height > 960 || width > 960;        
 
		currentState = (isPortrait ? "portrait" : "landscape") + (isTablet ? "Tablet" : "Phone");
	}

ViewNavigator x 2

Then I’m adding two ViewNavigator comps to my main <s:Application>. In this case, I’m building a Flex Mobile Project, but I’m not using the ViewNavigatorApplication architecture as a shell. Notice that the coordinates, the dimensions and the visibility of the viewNavigator components depend on the states (and on the state groups).

<!--TABLETS CENTERED VIEW-->
	<s:ViewNavigator includeIn="tablet"
		id="tabletPictureNavigator"
	        width.landscapeTablet="{this.width - phoneViewNavigator.width}"
		height.landscapeTablet="{this.height}"
		x.landscapeTablet="270"
		y.landscapeTablet="0"
		height="100%"
		width.portraitTablet="100%"
		x.portraitTablet="0"
		y.portraitTablet="400"
		height.portraitTablet="{this.height - phoneViewNavigator.height}"
 
	/>
	<!--PHONES-->
	<s:ViewNavigator
		width.phone="100%"
		height.phone="100%"
		width.portraitTablet="100%"
		height.portraitTablet="400"
		width.landscapeTablet="270"
		height.landscapeTablet="100%"
		id="phoneViewNavigator"
		backgroundColor="0xffff01"
 
		x="0" y="0"
		firstView="views.ListView"/>

The Hardware Back Button

The Flex 4.5 framework handles by default the Back Hardware Key on Android phones. It works perfectly with the classic ViewNavigatorApplication. In this case, as I’m using a <s:Application> shell architecture containing two ViewNavigator components, there is no stack of navigation at a root level and the application is lost when it receives a Back command. Here is the code that disable the classic behavior. I’ve added it within the view that displays the picture in full size.

protected function view1_initializeHandler(event:FlexEvent):void
			{
				// TODO Auto-generated method stub
				systemManager.stage.addEventListener(KeyboardEvent.KEY_DOWN, deviceKeyDownHandler);
				systemManager.stage.addEventListener(KeyboardEvent.KEY_UP, deviceKeyUpHandler);
			}
 
			protected function deviceKeyDownHandler(event:KeyboardEvent):void
			{
				// TODO Auto-generated method stub
				if(event.keyCode == Keyboard.BACK && navigator.length > 1){
					event.preventDefault();
				}
			}
 
			protected function deviceKeyUpHandler(event:KeyboardEvent):void
			{
				// TODO Auto-generated method stub
				if(event.keyCode == Keyboard.BACK && navigator.length > 1){
					navigator.popView();
				}
			}
 
			protected function view1_viewDeactivateHandler(event:ViewNavigatorEvent):void
			{
				// TODO Auto-generated method stub
				systemManager.stage.removeEventListener(KeyboardEvent.KEY_DOWN, deviceKeyDownHandler);
				systemManager.stage.removeEventListener(KeyboardEvent.KEY_UP, deviceKeyUpHandler);
			}

You can download the source code of this application and check the tricks introduced within my code.

Link to the source code application: http://riagora.com/pvt_content/android/DynamicLayout.fxp

I’ve also published the demo app on the Android Marketplace: https://market.android.com/details?id=air.com.riagora.dynamiclayout&feature=search_result