Adaptive UI: Mobile vs Tablet
Join the DZone community and get the full member experience.
Join For FreeThe 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
Published at DZone with permission of Michael Chaize, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Reducing Network Latency and Improving Read Performance With CockroachDB and PolyScale.ai
-
Fun Is the Glue That Makes Everything Stick, Also the OCP
-
Conditional Breakpoints: A Guide to Effective Debugging
-
Google Becomes A Java Developer's Best Friend: Instantiations Developer Tools Relaunched For Free
Comments