|
|
Sermon Ohakwe (@admin) |
Android applications have direct hardware access, can be distributed independently, and are built on an open source platform featuring open communication, so it’s not particularly surprising that security is a big concern.
For the most part, users will take responsibility for what applications they install and what permissions they grant them. The Android security model restricts access to certain services and functionality by forcing applications to request permission before using them. During installation, users then decide if the application should be granted the permissions requested. You can learn more about Android’s secu-rity model in Chapter 11 and at http://code.google.com/android/devel/security.html.
This doesn’t get you off the hook. You not only need to make sure your application is secure for its own sake, but you also need to ensure that it can’t be hijacked to compromise the device. You can use several techniques to help maintain device security, and they’ll be covered in more detail as you learn the tech-nologies involved. In particular, you should:
❑Consider requiring permissions for any services you create or broadcasts you transmit.
❑Take special care when accepting input to your application from external sources such as the Internet, SMS messages, or instant messaging (IM). You can find out more about using IM and SMS for application messaging in Chapter 9.
❑Be cautious when your application may expose access to lower-level hardware.
For reasons of clarity and simplicity, many of the examples in this book take a fairly relaxed approach to security. When creating your own applications, particularly ones you plan to distribute, this is an area that should not be overlooked. You can find out more about Android security in Chapter 11.
The idea of a seamless user experience is an important, if somewhat nebulous, concept. What do we mean by seamless? The goal is a consistent user experience where applications start, stop, and transition instantly and without noticeable delays or jarring transitions.
The speed and responsiveness of a mobile device shouldn’t degrade the longer it’s on. Android’s pro-cess management helps by acting as a silent assassin, killing background applications to free resources as required. Knowing this, your applications should always present a consistent interface, regardless of whether they’re being restarted or resumed.
With an Android device typically running several third-party applications written by different devel-opers, it’s particularly important that these applications interact seamlessly.
Use a consistent and intuitive approach to usability. You can still create applications that are revolution-ary and unfamiliar, but even they should integrate cleanly with the wider Android environment.
Persist data between sessions, and suspend tasks that use processor cycles, network bandwidth, or bat-tery life when the application isn’t visible. If your application has processes that need to continue run-ning while your activity is out of sight, use a Service, but hide these implementation decisions from your users.
When your application is brought back to the front, or restarted, it should seamlessly return to its last visible state. As far as your users are concerned, each application should be sitting silently ready to be used but just out of sight.
You should also follow the best-practice guidelines for using Notifications and use generic UI elements and themes to maintain consistency between applications.
There are many other techniques you can use to ensure a seamless user experience, and you’ll be intro-duced to some of them as you discover more of the possibilities available in Android in the coming chapters.
In this example, you’ll be creating a new Android application from scratch. This simple example cre-ates a new to-do list application using native Android View controls. It’s designed to illustrate the basic steps involved in starting a new project.
Don’t worry if you don’t understand everything that happens in this example. Some of the features used to create this application, including ArrayAdapters, ListViews, and KeyListeners, won’t be introduced properly until later chapters, where they’re explained in detail. You’ll also return to this example later to add new functionality as you learn more about Android.
Start by creating a new Android project. Within Eclipse, select File ➪ New ➪ Project …, then choose Android (as shown in Figure 2-9) before clicking Next.
In the dialog box that appears (shown in Figure 2-10), enter the details for your new project. The “Application name” is the friendly name of your application, and the “Activity name” is the name of your Activity subclass. With the details entered, click Finish to create your new project.
Take this opportunity to set up debug and run configurations by selecting Run ➪ Open Debug Dialog … and then Run ➪ Open Run Dialog …, creating a new configuration for each, speci-fying the Todo_List project. You can leave the launch actions as Launch Default Activity or explicitly set them to launch the new ToDoList Activity, as shown in Figure 2-11.
Now decide what you want to show the users and what actions they’ll need to perform. Design a user interface that will make this as intuitive as possible.
In this example, we want to present users with a list of to-do items and a text entry box to add new ones. There’s both a list and a text entry control (View) available from the Android libraries. You’ll learn more about the Views available in Android and how to create new ones in Chapter 4.
The preferred method for laying out your UI is using a layout resource file. Open the main.xml layout file in the res/layout project folder, as shown in Figure 2-12.
Modify the main layout to include a ListView and an EditText within a LinearLayout. It’s important to give both the EditText and ListView controls IDs so you can get references to them in code.
<?xml version=”1.0” encoding=”utf-8”?>
<LinearLayout xmlns:android=”http://schemas.android.com/apk/res/android”
android:orientation=”vertical”
android:layout_width=”fill_parent”
android:layout_height=”fill_parent”>
<EditText
android:id=”@+id/myEditText”
android:layout_width=”fill_parent”
android:layout_height=”wrap_content”
android:text=”New To Do Item”
/>
<ListView
android:id=”@+id/myListView”
android:layout_width=”fill_parent”
android:layout_height=”wrap_content”
/>
</LinearLayout>With your user interface defined, open the ToDoList.java Activity class from your proj-ect’s source folder. In this example, you’ll make all your changes by overriding the onCreate method. Start by inflating your UI using setContentView and then get references to the ListView and EditText using findViewById.
public void onCreate(Bundle icicle) {
Inflate your view setContentView(R.layout.main);Get references to UI widgets
ListView myListView = (ListView)findViewById(R.id.myListView); final EditText myEditText = (EditText)findViewById(R.id.myEditText);
}Still within onCreate, define an ArrayList of Strings to store each to-do list item. You can bind a ListView to an ArrayList using an ArrayAdapter, so create a new ArrayAdapter instance to bind the to-do item array to the ListView. We’ll return to ArrayAdapters in Chapter 5.
public void onCreate(Bundle icicle) {
setContentView(R.layout.main);
ListView myListView = (ListView)findViewById(R.id.myListView); final EditText myEditText = (EditText)findViewById(R.id.myEditText);
// Create the array list of to do items
final ArrayList<String> todoItems = new ArrayList<String>();
Create the array adapter to bind the array to the listview final ArrayAdapter<String> aa;
aa = new ArrayAdapter<String>(this,
android.R.layout.simple_list_item_1,
todoItems);
Bind the array adapter to the listview. myListView.setAdapter(aa);
}The final step to make this to-do list functional is to let users add new to-do items. Add an onKeyListener to the EditText that listens for a “D-pad center button” click before adding the contents of the EditText to the to-do list array and notifying the ArrayAdapter of the change. Then clear the EditText to prepare for another item.
public void onCreate(Bundle icicle) {
setContentView(R.layout.main);
ListView myListView = (ListView)findViewById(R.id.myListView); final EditText myEditText = (EditText)findViewById(R.id.myEditText);
final ArrayList<String> todoItems = new ArrayList<String>(); final ArrayAdapter<String> aa;
aa = new ArrayAdapter<String>(this, android.R.layout.simple_list_item_1,
todoItems);
myListView.setAdapter(aa);
myEditText.setOnKeyListener(new OnKeyListener() {
public boolean onKey(View v, int keyCode, KeyEvent event) { if (event.getAction() == KeyEvent.ACTION_DOWN)
if (keyCode == KeyEvent.KEYCODE_DPAD_CENTER)
{
todoItems.add(0, myEditText.getText().toString());
aa.notifyDataSetChanged();
myEditText.setText(“”);
return true;
}
return false;
}
});
}Run or debug the application, and you’ll see a text entry box above a list, as shown in Figure 2-13.
You’ve now finished your first “real” Android application. Try adding breakpoints to the code to test the debugger and experiment with the DDMS perspective.
As it stands, this to-do list application isn’t spectacularly useful. It doesn’t save to-do list items between sessions, you can’t edit or remove an item from the list, and typical task list items like due dates and task priority aren’t recorded or displayed. On balance, it fails most of the criteria laid out so far for a good mobile application design.
You’ll rectify some of these deficiencies when you return to this example in later chapters.