In this chapter we will look at the different UI components of android screen. This chapter also covers the tips to make a better UI design and also explains how to design a UI.
UI screen components
A typical user interface of an android application consists of action bar and the application content area.
Main Action Bar
View Control
Content Area
Split Action Bar
These components have also been shown in the image below −
Understanding Screen Components
The basic unit of android application is the activity. A UI is defined in an xml file. During compilation, each element in the XML is compiled into equivalent Android GUI class with attributes represented by methods.
View and ViewGroups
An activity is consist of views. A view is just a widget that appears on the screen. It could be button e.t.c. One or more views can be grouped together into one GroupView. Example of ViewGroup includes layouts.
Types of layout
There are many types of layout. Some of which are listed below −
Linear Layout
Absolute Layout
Table Layout
Frame Layout
Relative Layout
Linear Layout
Linear layout is further divided into horizontal and vertical layout. It means it can arrange views in a single column or in a single row. Here is the code of linear layout(vertical) that includes a text view.
AbsoluteLayout
The AbsoluteLayout enables you to specify the exact location of its children. It can be declared like this.
TableLayout
The TableLayout groups views into rows and columns. It can be declared like this.
RelativeLayout
The RelativeLayout enables you to specify how child views are positioned relative to each other.It can be declared like this.
FrameLayout
The FrameLayout is a placeholder on screen that you can use to display a single view. It can be declared like this.
Apart form these attributes, there are other attributes that are common in all views and ViewGroups. They are listed below −
Sr.No
View & description
1
Specifies the width of the View or ViewGroup
Specifies the height of the View or ViewGroup
Specifies extra space on the top side of the View or ViewGroup
Specifies extra space on the bottom side of the View or ViewGroup
Specifies extra space on the left side of the View or ViewGroup
Specifies extra space on the right side of the View or ViewGroup
Specifies how child Views are positioned
Specifies how much of the extra space in the layout should be allocated to the View
Units of Measurement
When you are specifying the size of an element on an Android UI, you should remember the following units of measurement.
Sr.No
Unit & description
1
Density-independent pixel. 1 dp is equivalent to one pixel on a 160 dpi screen.
Scale-independent pixel. This is similar to dp and is recommended for specifying font sizes
Point. A point is defined to be 1/72 of an inch, based on the physical screen size.
Pixel. Corresponds to actual pixels on the screen
Screen Densities
Low density (ldpi)
Medium density (mdpi)
High density (hdpi)
Extra High density (xhdpi)
Optimizing layouts
Here are some of the guidelines for creating efficient layouts.
Avoid unnecessary nesting
Avoid using too many Views
Avoid deep nesting
Источник
Android User Interface Design: Building Application Preference Screens
Many applications can benefit from Shared Preferences – the Android platform’s answer to the persistent storage of application settings. There are many ways to create user interfaces for collecting and displaying persistent settings for users. The easiest way is to use the PreferencesActivity, which provides a consistent look-and-feel with the rest of the platform, including the device system preferences. Learn how to use PreferencesActivity in this tutorial.
Our simple Mobiletuts tutorial feed reader application, which doesn’t have an official name yet (we’ve been referring to it as TutList), needs better user control over the background updating process. Therefore, we’ll add a single preference to help control the background updating.
This tutorial builds upon previous tutorials, including Android Essentials: Application Preferences and the continued series on our TutList activity with the most recent tutorial, Android Fundamentals: Scheduling Recurring Tasks. If you have trouble keeping up, feel free to post questions in the comment section — many folks read and respond, including ourselves. Also, don’t forget about the Android SDK reference. The final sample code that accompanies this tutorial is available for download as open-source from the Google code hosting.
Step 0: Getting Started
This tutorial assumes you will start where the previous tutorial in the series, Android Fundamentals: Scheduling Recurring Tasks, left off. You can download that code and work from there or you can download the code for this tutorial and follow along. Either way, get ready by downloading one or the other project and importing it into Eclipse.
Step 1: Adding a Shared Preferences Helper
Shared preferences are often used throughout an application. The definitions of the names of the individual settings and the name of the preferences group must be stored for use throughout an application. There are several ways to solve this problem. The solution we’ll use involves a helper class for consistent access to specific settings values, with the preferences keys stored in as resources strings for access from code and other resource files.
Let’s start with the helper class code:
In this class, we’ve defined a public constant to identify the name of the preferences group or set, called PREFS_NAME. We’ve also used a resource string, called pref_key_flag_background_update, to specify the specific preference name definition. You should add a string to your resources so this identifier is defined. We set its value to «background_update_flag» but what matters is that the value used is the same everywhere.
Although we’ve added a setBackgroundUpdateFlag() method for completeness, we will not be using this method. Read on to see why.
Finally, we added this Java class to the com.mamlambo.tutorial.tutlist.data package as that seems most relevant.
Step 2: Adding a Preferences Screen Activity
The Android SDK includes a consistent means of presenting settings to users: the PreferenceActivity. In conjunction with a preference resource file, this specialized Activity class makes it very easy for developers to configure and display most types of application settings in a consistent fashion. The consistency with other application and system preference screens also makes these screens familiar and easy for users, too.
To add a PreferenceActivity to the “TutList” application, start by adding a new activity call TutListPreferencesActivity and have it extend PreferenceActivity (we added it to the main package). Since we’re not using the default preference name, we need to set the preference name this PreferenceActivity will use. In addition, we need to tell it which preference resource file to use. This will tell it how to display the preferences, as well as which ones this screen displays and modifies.
Within the onCreate() method of this activity, use the setSharedPreferencesName() method with the preference group constant defined in the preferences helper class we defined in the previous step. Then make a call to the addPreferencesFromResource() method. We’ll define this resource in the next step.
Right now, this entire class looks like this:
We’ll enhance this class throughout the tutorial. But first, let’s create the referenced XML resource called prefs.
Step 3: Defining a Preferences Screen Resource
Add a new XML file called prefs.xml to the application resources. You can use the new Android XML file wizard and fill out the fields as shown in the following image. This will also create the XML file in the correct location, the /res/xml directory.
A preferences activity resource file consists of a
This demonstrates one of best reasons to store the key strings as a resource: they can be used directly in the XML file as well as loaded into Java.
Step 4: Launching the Preferences Screen
Next, we’ll add a menu item on the list fragment to launch the preferences screen. While doing this, we’ll also update the refresh menu item to no longer start the scheduled update.
To do this, first edit the /res/menu/options_menu.xml resource file to add a new menu item:
You’ll also need to add the corresponding resource string for the item title (@string/settings) and add an appropriate icon (@drawable/ic_menu_preferences). We used the standard preferences icon from the Android SDK, which will be familiar to users.
Next, edit the onCreateOptionsMenu() method to provide the correct Intent for the new menu item:
Now, update the onOptionsItemSelected() method. Since there is more than one menu item, it now makes sense to use a switch statement. Within the switch statement, we can use the constant identifiers assigned for each menu item to differentiate the user selections.
Finally, don’t forget to add the new activity to the Android manifest file:
You can now run the application and see the new menu item.
The preferences activity can be launched and store and retrieve the background update preference. It should look like the following:
It looks great, but it doesn’t do anything real yet. Although the flag is updated within the preferences, there isn’t yet a place where the value is checked to see if the background updating should start or not..
Step 5: Starting and Stopping the Alarm
In the last step, calls to the setRecurringAlarm() helper method were removed. In fact, this method won’t be needed in the TutListFragment class any longer. Instead, move it to the TutListPreferencesActivity class. Then add a second helper, called cancelRecurringAlarm():
Finally, override the onPause() method of the TutListPreferencesActivity class to set or cancel the recurring alarm as appropriate. Within this method, you can check the value of preferences — updated values using the helper method getBackgroundUpdateFlag() and call the appropriate method:
Now, whenever the settings are checked, the alarm is updated based on the current value. With a default value of “off”, the user must go in to the settings to enable background downloading.
About PreferenceFragment
You may have wondered why we didn’t use the new PreferenceFragment class. The reason is simple: it is not yet supported in the compatibility library. Since we want to keep the TutList application compatible with more than just Android 3.0 devices, we can’t yet use it. Hopefully the compatibility library will continue to be enhanced.
Conclusion
In this tutorial, you have learned how to use the PreferencesScreen resource file with a PreferencesActivity to quickly and easily create a functional activity that for managing application preference data. In addition, you provided the user with a method to control the background updating of the TutList application. As always, we look forward to your feedback.
Источник
Android User Interface Design: Layout Basics
Understanding layouts is important for good Android application design. In this tutorial, we provide an overview of how layouts fit into the Android application architecture. We also explore some of the specific layout controls available for organizing application screen content in a variety of interesting ways.
What Is A Layout?
Android developers use the term layout to mean one of two things. Both definitions apply to this tutorial, and are, unfortunately used interchangeably in the Android development community. The two definitions of layout are:
A type of resource that defines what is drawn on the screen. Layout resources are stored as XML files in the /res/layout resource directory for the application. A layout resource is simply a template for a user interface screen, or portion of a screen, and contain.
A type of View class whose primary purpose is to organize other controls. These layout classes (LinearLayout, RelativeLayout, TableLayout, etc. ) are used to display child controls, such as text controls or buttons or images on the screen.
Android user interfaces can be defined as layout resources in XML or created programmatically.
Using Eclipse to Design Layout Resources
The Android Development Plug-in for Eclipse includes a handy layout resource designer for designing and previewing layout resources. The tool includes two tab views: the Layout view allows you to preview how the controls will appear on various screens and for each orientation and the XML view shows you the XML definition of the resource. The layout resource designer is shown in this figure:
Here are some tips for working with the layout resource designer in Eclipse:
Use the Outline pane to Add and Remove controls to your layout resource.
Select a specific control (either in the Preview or the Outline) and use the Property pane to adjust a specific control’s attributes.
Use the XML tab to edit the XML definition directly.
It’s important to remember that the Eclipse layout resource designer preview can’t replicate exactly how the layout will appear to end users. For this, you must test your application on a properly configured emulator and, more importantly, on your target devices. Also, certain “complex” controls, including tabs or video viewers, cannot be previewed within Eclipse.
Defining an XML Layout Resource
The most convenient and maintainable way to design application user interfaces is by creating XML layout resources. This method greatly simplifies the UI design process, moving much of the static creation and layout of user interface controls and definition of control attributes, to the XML, instead of littering the code. It creates a potential distinction between UI designers (who concern themselves more with layout) and developers (who know Java and implement application functionality). Developers can still alter the content of a screen programmatically when necessary. Complex controls, like ListView or GridView, are usually populated with data programmatically.
XML layout resources must be stored in the /res/layout project directory (or, in the case of alternative resources, in a specially named sub-directory). It’s common practice to create an XML layout resource for each screen in your application (closely tied to a specific Activity), but this is not required. You could, in theory, create an XML layout resource and use it for different activities, supplying different data on the screen. You can also componentized your layout resources and include them within one another, if needed.
The following is a simple XML layout resource, a template with a LinearLayout containing a TextView and an ImageView, defined in XML:
This layout represents a simple screen with two controls: first some text and then an image below it. These controls are organized within a vertically oriented LinearLayout. The following two figures show what this layout might look like on a device in both portrait and landscape modes:
Within the Activity, only a single line of code within the onCreate() method is necessary to load and display a layout resource on the screen. If the layout resource was stored in the /res/layout/main.xml file, that would be:
Defining a Layout Programmatically
You can also programmatically create user interface components. For organization and maintainability, this is best left for the odd case rather than the norm. Instead of loading a layout resource directly using the setContentView() method, you must instead build up the screen contents and then supply a parent layout object which contains all the control contents to display as child views to the setContentView() method.
For example, the following code illustrates how to programmatically have an Activity instantiate a LinearLayout view and place two TextView objects within it. No resources whatsoever are used.
As you can see, the code can rapidly grow in size as more controls are added to the screen, making screen contents more difficult to maintain or reuse.
Exploring Various Layout Types
Now let’s turn our attention to those helpful layout controls that organize other controls. The most commonly used layout classes are:
FrameLayout — designed to display a stack of child View controls. Multiple view controls can be added to this layout. This can be used to show multiple controls within the same screen space.
LinearLayout — designed to display child View controls in a single row or column. This is a very handy layout method for creating forms.
RelativeLayout — designed to display child View controls in relation to each other. For instance, you can set a control to be positioned “above” or “below” or “to the left of” or “to the right of” another control, referred to by its unique identifier. You can also align child View controls relative to the parent edges.
TableLayout — designed to organize child View controls into rows and columns. Individual View controls are added within each row of the table using a TableRow layout View (which is basically a horizontally oriented LinearLayout) for each row of the table.
Combining Layouts To Organize Controls
A layout (LinearLayout, TableLayout, RelativeLayout, etc.) is a control like any other. This means that layout controls can be nested. For example, you might use a RelativeLayout within a LinearLayout, or vice-versa, in order to organize controls on a screen. The following figure shows a screen with a LinearLayout (parent), a TableLayout (top child)_and a FrameLayout (bottom child).
But beware! Keep your screens relatively simple; complex layouts load slowly and cause performance issues.
Providing Alternative Layout Resources
Consider device differences when designing your application layout resources. It is often possible to design flexible layouts that look fine on a variety of different devices, in both portrait and landscape modes. When necessary, you can include alternative layout resources to handle special cases. For example, you could provide different layouts to load depending upon the orientation of the device or whether or not the device has a large screen (e.g. an internet tablet).
For more information on how to use alternative resources, see the Android SDK documentation on Android Resources.
Layout Tools and Optimization
The Android SDK includes several tools that can help design, debug and optimize layout resources. In addition to the layout resource designer built into the Android plug-in for Eclipse, you can use the Hierarchy Viewer and layoutopt tools provided with the Android SDK. These tools are available in the /tools directory of your Android SDK.
You can use the Hierarchy Viewer to inspect layout details at run-time. Find out more about the Hierarchy Viewer on the Android Developer website.
You can use the layoutopt command-line tool to optimize your layout files. Optimizing layouts is important because complicated layout files are slow to load. The layoutopt tool simply scans XML layout files and identifies unnecessary controls. Find out more about the layoutopt tool on the Android Developer website.
Conclusion
Android application user interfaces are defined using layouts. There are a number of different types of layout types that can be used to organize controls on a screen, or portion of a screen. Layouts can be defined using XML resources, or programmatically at run-time in Java. Alternative layouts can be loaded under special circumstances, such as to provide an alternative user interface in portrait versus landscape mode. Finally, designing good layouts is important for application performance; use Android SDK tools like the Hierarchy Viewer and layoutopt to debug and optimize your application layouts.
