IT

Email on your USB flash drive

2014-05-30T22:32:00.000-07:00

previous How to get more space on your hard drive

Mozilla are the creators of the widely popular browser, Firefox. They have also developed an email client called Thunderbird. Thunderbird is a robust and reliable email client, with many advanced features and it can be used on the move from a USB flash drive! Here's how.

You can download the portable version of Thunderbird from the portable apps website.

To install Thunderbird Portable on your USB flash drive, double-click the downloaded installer file and select your USB flash drive as the location to install the application and click ‘Install’.

This will create a Portable Thunderbird directory and associated files on your flash drive.

Double click the .exe file to get started.

In an earlier article we discussed the portable apps suite, which has a huge list of goodies that can be used on USB flash drives. The PortableApps.com Suite includes Mozilla Thunderbird by default.

Portable Thunderbird simply works like any application on your hard drive. With the portable edition of Mozilla Thunderbird, your email, address book and account settings are always available to you on your USB flash drive. Thunderbird supports email services such as Yahoo, Hotmail, MailDotCom, Gmail, Libero, and AOL.

You can manage multiple e-mail, newsgroup and RSS accounts and identities with Thunderbird. If you wish to upgrade Thunderbird, you only need to install a new copy over the existing one. This will preserve your data. Thunderbird will also work from a write-protected USB flash drive. [Note: Thunderbird will not automatically save addresses to the address book].

The advantage of using Thunderbird Portable from a USB drive is that it does not leave any data behind on your netbook or notebook. All the data remains on the USB flash drive. You can easily access your emails from any server provider (like Hotmail, Yahoo, Lycos, mail.com, Gmail, and AOL) both online and offline with Thunderbird Portable. Although an offline version of Gmail is available, it is in experimental stages and could still have a lot bugs. In addition to this, accessing Gmail offline requires the installation of Google Gears on your netbook or notebook. Offline Gmail running from a USB drive is not available yet. However, in the case of Thunderbird Portable, the software is installed on the USB flash drive and does not require the installation of any software on your notebook.

Please note that it is important to change the default Thunderbird settings from “download and remove your mail from the server” to “keep a copy of all emails in the server” so that all emails will be available online and for downloading on other computers. Make sure that this is done before you download your emails to Thunderbird Portable.

Android SDK Features

2014-05-30T11:14:00.001-07:00

previous Professional Android Application Development- Reto Meier

The true appeal of Android as a development environment lies in the APIs it provides.

As an application-neutral platform, Android gives you the opportunity to create applications that are as much a part of the phone as anything provided out of the box. The following list highlights some of the most noteworthy Android features:

No licensing, distribution, or development fees
Wi-Fi hardware access
GSM, EDGE, and 3G networks for telephony or data transfer, allowing you to make or receive calls or SMS messages, or to send and retrieve data across mobile networks
Comprehensive APIs for location-based services such as GPS
Full multimedia hardware control including playback and recording using the camera and microphone
APIs for accelerometer and compass hardware
IPC message passing
Shared data stores
An integrated open source WebKit-based browser
Full support for applications that integrate Map controls as part of their user interface
Peer-to-peer (P2P) support using Google Talk
Mobile-optimized hardware-accelerated graphics including a path-based 2D graphics library and support for 3D graphics using OpenGL ES
Media libraries for playing and recording a variety of audio/video or still image formats
An application framework that encourages reuse of application components and the replacement of native applications

Access to Hardware including Camera, GPS, and Accelerometer

Android includes API libraries to simplify development involving the device hardware. These ensure that you don’t need to create specific implementations of your software for different devices, so you can create Android applications that work as expected on any device that supports the Android software stack.

The Android SDK includes APIs for location-based hardware (such as GPS), camera, network connections, Wi-Fi, Bluetooth, accelerometers, touch screen, and power management. You can explore the possibilities of some of Android’s hardware APIs in more detail later in this blog.

Native Google Maps, Geocoding, and Location-Based Services

Native map support lets you create a range of map-based applications that leverage the mobility of Android devices. Android lets you create activities that include interactive Google Maps as part of your user interface with full access to maps that you can control programmatically and annotate using Android’s rich graphics library.

Android’s location-based services manage technologies like GPS and Google’s GSM cell-based location technology to determine the device’s current position. These services enforce an abstraction from specific location-detecting technology and let you specify minimum requirements (e.g., accuracy or cost) rather than choosing a particular technology. It also means that your location-based applications will work no matter what technology the host handset supports.

To combine maps with locations, Android includes an API for forward and reverse geocoding that lets you fi nd map coordinates for an address, and the address of a map position.

You’ll learn the details of using maps, the geocoder, and location-based services later in this blog.

Background Services
Android supports applications and services designed to run invisibly in the background.

Modern mobiles are by nature multifunction devices; however, their limited screen size means that generally only one interactive application can be visible at any time. Platforms that don’t support background execution limit the viability of applications that don’t need your constant attention.

Background services make it possible to create invisible application components that perform automatic processing without direct user action. Background execution allows your applications to become eventdriven and to support regular updates, which is perfect for monitoring game scores or market prices, generating location-based alerts, or prioritizing and pre-screening incoming calls and SMS messages.

SQLite Database for Data Storage and Retrieval
Rapid and efficient data storage and retrieval are essential for a device whose storage capacity is limited by its compact nature.

Android provides a lightweight relational database for each application using SQLite. Your applications can take advantage of the managed relational database engine to store data securely and efficiently.

By default, each application database is sandboxed — its content is available only to the application that created it — but Content Providers supply a mechanism for the managed sharing of these application databases.

Shared Data and Interapplication Communication

Android includes three techniques for transmitting information from your applications for use elsewhere: Notifications, Intents, and Content Providers.

Notifications are the standard ways in which a mobile device traditionally alerts users. Using the API, you can trigger audible alerts, cause vibration, and flash the device’s LED, as well as control status bar notification icons.

Intents provide a mechanism for message passing within and between applications. Using Intents, you can broadcast a desired action (such as dialing the phone or editing a contact) system-wide for other applications to handle. Intents are an important core component of Android.

Finally, Content Providers are a way to give managed access to your application’s private database. The data stores for native applications, such as the Contact Manager, are exposed as Content Providers so you can create your own applications that read or modify these data stores.

P2P Services with Google Talk

Based on earlier SDK versions, it’s expected that in later releases you will once again be able to send structured messages from your application to any other Android mobile using Android’s peer-to-peer (P2P) communications service.

The Android P2P service uses a specialized version of XMPP (Extensible Messaging and Presence Protocol). Based on Google’s Google Talk instant messaging service, it creates a persistent socket connection between your device and any other online Android handset that ensures communication with low latency and rapid response times.

When made available, you’ll be able to use the Google Talk service for conventional instant messaging, or an interface to send data between application instances on separate devices. This is strong sauce for creating interactive applications that involve multiple users, such as real-time multiplayer games or social applications.

The P2P service also offers presence notification, which is used to see if a contact is online. While the P2P service is very attractive in itself, it also plays very well with other Android features. Imagine a background service that transmits locations between friends and a corresponding mapping application that displays these locations or alerts you when friends are nearby.

Owing to security concerns, sending data messages with Google Talk isn’t possible in Android 1.0. An instant messaging client is available, and it’s expected that XMPP-compatible IM and data messaging will be made available to developers in a future SDK release.

Extensive Media Support and 2D/3D Graphics

Bigger screens and brighter, higher-resolution displays have helped make mobiles multimedia devices. To make the most of the hardware available, Android provides graphics libraries for 2D canvas drawing and 3D graphics with OpenGL.

Android also offers comprehensive libraries for handling still images, video, and audio fi les including the MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, and GIF formats.

Optimized Memory and Process Management

Android’s process and memory management is a little unusual. Like Java and .NET, Android uses its own run time and virtual machine to manage application memory. Unlike either of these frameworks, the Android run time also manages the process lifetimes. Android ensures application responsiveness by stopping and killing processes as necessary to free resources for higher-priority applications.

In this context, priority is determined depending on the application with which the user is interacting. Ensuring that your applications are prepared for a swift death but are still able to remain responsive and update or restart in the background if necessary, is an important consideration in an environment that does not allow applications to control their own lifetimes.

next Introducing the Open Hands set Alliance

Professional Android Application Development- Reto Meier

2014-05-30T11:08:00.001-07:00

Whether you’re an experienced mobile engineer, a desktop or web developer, or a complete programming novice, Android represents an exciting new opportunity to write innovative applications for mobile devices.

Despite the name, Android will not help you create an unstoppable army of emotionless robot warriors on a relentless quest to cleanse the earth of the scourge of humanity. Instead, Android is an open source software stack that includes the operating system, middleware, and key applications along with a set of API libraries for writing mobile applications that can shape the look, feel, and function of mobile handsets.

Small, stylish, and versatile, modern mobile phones have become powerful tools that incorporate cameras, media players, GPS systems, and touch screens. As technology has evolved, mobile devices have become about more than simply making calls, but their software and development platforms have struggled to keep pace.

Until recently, mobile phones were largely closed environments built on proprietary operating systems that required proprietary development tools. The phones themselves often prioritized native applications over those written by third parties. This has introduced an artificial barrier for developers hoping to build on increasingly powerful mobile hardware.

In Android, native and third-party applications are written using the same APIs and executed on the same run time. These APIs feature hardware access, location-based services, support for background services, map-based activities, relational databases, interdevice peer-to-peer messaging, and 2D and 3D graphics.

Using this series of articles, you will learn how to use these APIs to create your own Android applications. In this chapter, you’ll learn some mobile development guidelines and be introduced to the features available from the Android development platform.

Android has powerful APIs, excellent documentation, a thriving developer community, and no development or distribution costs. As mobile devices continue to increase in popularity, this is an exciting opportunity to create innovative mobile phone applications no matter what your development background.

A Little Bac kground

In the days before Twitter and Facebook, when Google was still a twinkle in its founders’ eyes and dinosaurs roamed the earth, mobile phones were just that — portable phones small enough to fit inside a briefcase, featuring batteries that could last up to several hours; they offered the freedom to make calls without being physically connected to a landline.

Increasingly small, stylish, and powerful mobile phones are now as ubiquitous as they are indispensable. Hardware advancements have made mobiles smaller and more efficient while including an increasing number of peripherals.

Beginning with cameras and media players, mobiles now include GPS systems, accelerometers, and touch screens. While these hardware innovations should prove fertile ground for software development, the applications available for mobile phones have generally lagged behind the hardware.

The Not So Distant Past

Historically, developers, generally coding in low-level C or C++, have needed to understand the specific hardware they were coding for, generally a single device or possibly a range of devices from a single manufacturer. As hardware technology has advanced, this closed approach has struggled to keep pace.

More recently, platforms like Symbian have been created to provide developers a wider target audience. These systems have proved more successful in encouraging mobile developers to provide rich applications that better leverage the hardware available.

These platforms offer some access to the device hardware, but require writing complex C/C++ code and making heavy use of proprietary APIs that are notoriously difficult to use. This difficulty is amplified when developing applications that must work on different hardware implementations and is particularly true when developing for a particular hardware feature like GPS.

In recent years, the biggest advance in mobile phone development has been the introduction of Javahosted MIDlets. MIDlets are executed on a Java virtual machine, abstracting the underlying hardware and letting developers create applications that run on the wide variety of hardware that supports the Java run time. Unfortunately, this convenience comes at the price of restricted access to the device hardware.

In mobile development, it’s considered normal for third-party applications to receive different hardware access and execution rights compared to native applications written by the phone manufacturers, with MIDlets often receiving few of either.

The introduction of Java MIDlets has expanded developers’ audiences, but the lack of low-level hardware access and sandboxed execution have meant that most mobile applications are desktop programs designed to run on a smaller screen rather than take advantage of the inherent mobility of the handheld platform.

The Future

Android sits alongside a new wave of mobile operating systems designed for increasingly powerful mobile hardware. Windows Mobile and Apple’s iPhone now provide a richer, simplified development environment for mobile applications. However, unlike Android, they’re built on proprietary operating systems that often prioritize native applications over those created by third parties and restrict communication among applications and native phone data. Android offers new possibilities for mobile applications by offering an open development environment built on an open source Linux kernel. Hardware access is available to all applications through a series of API libraries, and application interaction, while carefully controlled, is fully supported.

In Android, all applications have equal standing. Third-party and native Android applications are written using the same APIs and are executed on the same run time. Users can remove and replace any native application with a third-party developer alternative; even the dialer and home screens can be replaced.

What It Is n’t

As a disruptive addition to a mature field, it’s not hard to see why there has been some confusion about what exactly Android is. Android is not:

A Java ME implementation Android applications are written using the Java language, but they are not run within a Java ME virtual machine, and Java-compiled classes and executables will not run natively in Android.
Part of the Linux Phone Standards Forum (LiPS) or the Open Mobile Alliance (OMA) Android runs on an open source Linux kernel, but, while their goals are similar, Android’s complete software stack approach goes further than the focus of these standards defining organizations.
Simply an application layer (like UIQ or S60) While it does include an application layer, “Android” also describes the entire software stack encompassing the underlying operating system, API libraries, and the applications themselves.
A mobile phone handset Android includes a reference design for mobile handset manufacturers, but unlike the iPhone, there is no single “Android Phone.” Instead, Android has been designed to support many alternative hardware devices.
Google’s answer to the iPhone The iPhone is a fully proprietary hardware and software platform released by a single company (Apple), while Android is an open source software stack produced and supported by the Open Handset Alliance and designed to operate on any handset that meets the requirements. There’s been a lot of speculation regarding a Google-branded Android phone, but even should Google produce one, it will be just one company’s hardware implementation of the Android platform.

An Open Platform for Mobile Development

Google describes Android as:

The first truly open and comprehensive platform for mobile devices, all of the software to run a mobile hone but without the proprietary obstacles that have hindered mobile innovation.
http://googleblog.blogspot.com/2007/11/wheres-my-gphone.html

Android is made up of several necessary and dependent parts including the following:

A hardware reference design that describes the capabilities required of a mobile device in order to support the software stack
A Linux operating system kernel that provides the low-level interface with the hardware, memory management, and process control, all optimized for mobile devices
Open source libraries for application development including SQLite, WebKit, OpenGL, and a media manager A run time used to execute and host Android applications, including the Dalvik virtual machine and the core libraries that provide Android specific c functionality. The run time is designed to be small and effi cient for use on mobile devices.
An application framework that agnostically exposes system services to the application layer, including the window manager, content providers, location manager, telephony, and peer-to-peer services
A user interface framework used to host and launch applications
Preinstalled applications shipped as part of the stack
A software development kit used to create applications, including the tools, plug-ins, and documentation

At this stage, not all of the Android stack has been released as open source, although this is expected to happen by the time phones are released to market. It’s also worth noting that the applications you develop for Android do not have to be open source.

What really makes Android compelling is its open philosophy, which ensures that any deficiencies in user interface or native application design can be fixed by writing an extension or replacement. Android provides you, as a developer, the opportunity to create mobile phone interfaces and applications designed to look, feel, and function exactly as you image them.

Native Android Applications
Android phones will normally come with a suite of preinstalled applications including, but not limited to:

An e-mail client compatible with Gmail but not limited to it
An SMS management application
A full PIM (personal information management) suite including a calendar and contacts list, both tightly integrated with Google’s online services
A fully featured mobile Google Maps application including StreetView, business finder, driving directions, satellite view, and traffic conditions
A WebKit-based web browser
An Instant Messaging Client
A music player and picture viewer
The Android Marketplace client for downloading third-party Android applications.
The Amazon MP3 store client for purchasing DRM free music.

All the native applications are written in Java using the Android SDK and are run on Dalvik.

The data stored and used by the native applications — like contact details — are also available to third-party applications. Similarly, your applications can handle events such as an incoming call or a new SMS message.

The exact makeup of the applications available on new Android phones is likely to vary based on the hardware manufacturer and/or the phone carrier or distributor. This is especially true in the United States, where carriers have significant influence on the software included on shipped devices.

next Android SDK Features

The Android Platform

2014-05-12T13:15:00.000-07:00

Mobile phone applications require s oftware one of which is the Android software which is widely used in developing the applications of a mobile phone. If you are asking what Android is, the answer is that it consists of an operating system with middleware and some key applications. The Android platform can be used along with its tools and APIs which have been produced with the Java programming language.
There is a fixed application in the form of maps, calendar, browser, email client, contacts and other such basic features of a cell phone and these applications have all been created with the help of the Java programming language.
The biggest advantage in using the Android application framework is that it provides an open development platform so that the developers can create a rich and novel application. Developers can optimize the device hardware and attain information regarding location. They can set alarms, put in other additional services and personalize the status bar and do so much more. The developers can use the same APIs that are used for the core applications. The components can be reused ina simple manner so that if one application publishes its capabilities then another application can make use of it and components can be replaced by the customer.
Those interested in knowing what Android is should know that it has certain functionalities such as Views for helping to create grids, buttons and list. There are Content providers which enable the user to get data from other applications and transfer it to his mobile device. This could be in the form of contacts and he can even share data with another application. A Resource Manager is present in the Android system which assists the developer to gain access to graphics and layout files which are non-code resources. The Notification Manager enables all created applications to show custom alerts in the mobile phone status bar. The working of the Applications is completely controlled with the help of an Activity Manager which provides one common backstack to the mobile device.
The Android software has various libraries and helps to provide the resources in creating the basic functionalities of the mobile device. These consist of the Media Libraries, the System C Library, and SGL for LibWEBCore and 3D libraries. The 2.6 Linux version has been incorporated for enabling processing, memory, network, security and other features.

IBM-PC Parallel Printer Port Programming Considerations

2012-12-07T21:07:00.001-08:00

The printer adapter responds to five I/O instructions: two output and three input. The output instructions transfer data into two latches whose outputs are presented on the pins of a 25-pin D-type female connector.

Two of the three input instructions allow the processor to read back the contents of the two latches. The third allows the processor to read the realtime status of a group of pins on the connector.

A description of each instruction follows

Output to address 278/378/3BC Hex

Bit 7 6 5 4 3 2 1 0

Pin 9 8 7 6 5 4 3 2

The instruction captures data from the data bus and is present on the respective pins. These pins are each capable of sourcing 2.6 mA and sinking 24 mA. It is essential that the external device not try to pull these lines to ground.

Output to address 27A/37A/3BE Hex

Bit 7 6 5 4 ~3 2 ~1 ~0

Pin - - - IRQ 17 16 14 1

enable

This instruction causes the latch to capture the least significant bits of the data bus. The four least significant bits present their outputs, or inverted versions of their outputs, to the respective pins shown above. If bit 4 is written as 1, the card will interrupt the processor on the condition that pin 10 transitions high to low.

These pins are driven by open collector drivers pulled to +5 Vdc through 4.7 k-ohm resistors. They can each sink approximately 7 mA and maintain 0.8 volts down-level.

Input from address 278/378/3BC Hex

This command presents the processor with data present on the pins associated with the corresponding output address. This should normally reflect the exact value that was last written. If an external device should be driving data on these pins (in violation of usage groundrules) at the time of an input, this data will be ORed with the latch contents.

Input from address 279/379/3BD Hex

This command presents realtime status to the processor from the pins as follows.

Bit 7 6 5 4 3 2 1 0

Pin 11 10 12 13 15 - - -

Input from address 27A/37A/3BE Hex

This instruction causes the data present on pins 1, 14, 16, 17 and the IRQ bit to be read by the processor. In the absence of external drive applied to these pins, data read by the processor will exactly match data last written to the corresponding output address in the same bit positions. Note that data bits 0-2 are not included. If external drivers are dotted to these pins, that data will be ORed with data applied to the pins by the output latch.

Bit 7 6 5 4 3 2 1 0

Pin - - - IRQ ~17 16 ~14 ~1

enable

state assumed after processor reset

0 1 0 1 1

IBM-PC Parallel Printer Port

2012-12-07T11:22:00.001-08:00

Registers & Pinouts

Registers (- unavailable)

Pinouts

Signal Name Bit Pin Direction

=========== ======== ===== =========

-Strobe ¬C0 1 Output

+Data Bit 0 D0 2 Output

+Data Bit 1 D1 3 Output

+Data Bit 2 D2 4 Output

+Data Bit 3 D3 5 Output

+Data Bit 4 D4 6 Output

+Data Bit 5 D5 7 Output

+Data Bit 6 D6 8 Output

+Data Bit 7 D7 9 Output

-Acknowledge S6 10 Input

+Busy ¬S7 11 Input

+Paper End S5 12 Input

+Select In S4 13 Input

-Auto Feed ¬C1 14 Output

-Error S3 15 Input

-Initialize C2 16 Output

-Select ¬C3 17 Output

Ground - 18-25 -

(Note again that the S7, C0, C1 & C3 signals are inverted)

IBM-PC Parallel Printer Port Female DB-25 Socket external Pin layout

______________________________________________________

/ \

\ 13 12 11 10 9 8 7 6 5 4 3 2 1 /

\ /

\ 25 24 23 22 21 20 19 18 17 16 15 14 /

\________________________________________________/

So it's also the Pin layout on the solder side of the Male DB-25 Cable Connector that plugs into it.

I/O Port Access in Microsoft Visual C++

2012-12-07T11:13:00.001-08:00

Microsoft Visual C/C++ provides access to the I/O ports on the 80x86 CPU via the predefined functions _inp / _inpw and _outp / _outpw.

int _inp(unsigned portid); /* returns a byte read from the I/O port portid */

unsigned _inpw(unsigned portid); /* returns a word read from the I/O port portid */

int _outp(unsigned portid, /* writes the byte value to the I/O port portid */

int value); /* returns the data actually written */

unsigned _outpw(unsigned portid, /* writes the word value to the I/O port portid */

unsigned value); /* returns the data actually written */

portid can be any unsigned integer in the range 0-65535

#include /* required only for function declarations */

#define Data 0x378

#define Status 0x379

#define Control 0x37a

int Bits, /* 0 <= Bits <= 255 */

Dummy;

Dummy = _outp(Data,Bits); /* output data */

Bits = _inp(Status); /* input data */

The Android Application Life Cycle

2012-05-25T08:44:00.000-07:00

previous Creating Applications and Activities

Unlike most traditional environments, Android applications have no control over their own life cycles Instead, application components must listen for changes in the application state and react accordingly, taking particular care to be prepared for untimely termination.

As mentioned before, by default, each Android application is run in its own process that’s running a separate instance of Dalvik. Memory and process management of each application is handled exclusively by the run time.

While uncommon, it’s possible to force application components within the same application to run in different processes or to have multiple applications share the same process using the android:process attribute on the affected component nodes within the manifest.

Android aggressively manages its resources, doing whatever it takes to ensure that the device remains responsive. This means that processes (and their hosted applications) will be killed, without warning if necessary, to free resources for higher-priority applications — generally those that are interacting directly with the user at the time. The prioritization process is discussed in the next section.

Understanding Application Priority and Process States

The order in which processes are killed to reclaim resources is determined by the priority of the hosted applications. An application’s priority is equal to its highest-priority component.

Where two applications have the same priority, the process that has been at a lower priority longest will be killed first. Process priority is also affected by interprocess dependencies; if an application has a dependency on a Service or Content Provider supplied by a second application, the secondary application will have at least as high a priority as the application it supports.

All Android applications will remain running and in memory until the system needs its resources for other applications.

Figure 3-3 shows the priority tree used to determine the order of application termination.

It’s important to structure your application correctly to ensure that its priority is appropriate for the work it’s doing. If you don’t, your application could be killed while it’s in the middle of something important.

The following list details each of the application states shown in Figure 3-3, explaining how the state is determined by the application components comprising it:

Active Processes Active (foreground) processes are those hosting applications with components currently interacting with the user. These are the processes Android is trying to keep responsive by reclaiming resources. There are generally very few of these processes, and they will be killed only as a last resort.

Active processes include:
- Activities in an “active” state; that is, they are in the foreground and responding to user events. You will explore Activity states in greater detail later in this chapter.
- Activities, Services, or Broadcast Receivers that are currently executing an onReceive event handler.
- Services that are executing an onStart, onCreate, or onDestroy event handler.
Visible Processes Visible, but inactive processes are those hosting “visible” Activities. As the name suggests, visible Activities are visible, but they aren’t in the foreground or responding to user events. This happens when an Activity is only partially obscured (by a non-full-screen or transparent Activity). There are generally very few visible processes, and they’ll only be killed in extreme circumstances to allow active processes to continue.
Started Service Processes Processes hosting Services that have been started. Services support ongoing processing that should continue without a visible interface. Because Services don’t interact directly with the user, they receive a slightly lower priority than visible Activities. They are still considered to be foreground processes and won’t be killed unless resources are needed for active or visible processes.
Background Processes Processes hosting Activities that aren’t visible and that don’t have any Services that have been started are considered background processes. There will generally be a large number of background processes that Android will kill using a last-seen-first-killed pattern to obtain resources for foreground processes.
Empty Processes To improve overall system performance, Android often retains applications in memory after they have reached the end of their lifetimes. Android maintains this cache to improve the start-up time of applications when they’re re-launched. These processes are routinely killed as required.

Externalizing Resources

No matter what your development environment, it’s always good practice to keep non-code resources like images and string constants external to your code. Android supports the externalization of resources ranging from simple values such as strings and colors to more complex resources like images (drawables), animations, and themes. Perhaps the most powerful resources available for externalization are layouts.

By externalizing resources, they become easier to maintain, update, and manage. This also lets you easily define alternative resource values to support different hardware and internationalization.

Among other things, this lets you change the layout based on the screen size and orientation and customize text prompts based on language and country.

Creating Resources

Application resources are stored under the res/ folder of your project hierarchy. In this folder, each of the available resource types can have a subfolder containing its resources.

If you start a project using the ADT wizard, it will create a res folder that contains subfolders for the values, drawable, and layout resources that contain the default layout, application icon, and string resource definitions, respectively, as shown in Figure 3-4.

There are seven primary resource types that have different folders: simple values, drawables, layouts, animations, XML, styles, and raw resources. When your application is built, these resources will be compiled as efficiently as possible and included in your application package.

This process also creates an R class fi le that contains references to each of the resources you include in your project. This lets you reference the resources in your code, with the advantage of design time syntax checking.

The following sections describe the specific resource types available within these categories and how to create them for your applications.

In all cases, the resource filenames should contain only lowercase letters, numbers, and the period (.) and underscore (_) symbols.

Creating Simple Values

Supported simple values include strings, colors, dimensions, and string or integer arrays. All simple values are stored within XML fi les in the res/values folder.

Within each XML fi le, you indicate the type of value being stored using tags as shown in the sample XML fi le below:

<?xml version=”1.0” encoding=”utf-8”?>
<resources>
<string name=”app_name”>To Do List</string>
<color name=”app_background”>#FF0000FF</color>
<dimen name=”default_border”>5px</dimen>
<array name=”string_array”>
<item>Item 1</item>
<item>Item 2</item>
<item>Item 3</item>
</array>
<array name=”integer_array”>
<item>3</item>
<item>2</item>
<item>1</item>
</array>
</resources>

This example includes all of the simple value types. By convention, resources are separated into separate files for each type; for example, res/values/strings.xml would contain only string resources.

The following sections detail the options for defining simple resources.
Strings
Externalizing your strings helps maintain consistency within your application and makes it much easier to create localized versions.
String resources are specified using the string tag as shown in the following XML snippet:
<string name=”stop_message”>Stop.</string>

Android supports simple text styling, so you can use the HTML tags <b>, <i>, and <u> to apply bold, italics, or underlining to parts of your text strings as shown in the example below:

You can use resource strings as input parameters for the String.format method. However, String.format does not support the text styling described above. To apply styling to a format string, you have to escape the HTML tags when creating your resource, as shown below:

Within your code, use the Html.fromHtml method to convert this back into a styled character sequence:

String rString = getString(R.string.stop_message);
String fString = String.format(rString, “Collaborate and listen.”);
CharSequence styledString = Html.fromHtml(fString);

Colors

Use the color tag to define a new color resource. Specify the color value using a # symbol followed by the (optional) alpha channel, then the red, green, and blue values using one or two hexadecimal numbers with any of the following notations:

#RGB
#RRGGBB
#ARGB
#ARRGGBB

The following example shows how to specify a fully opaque blue and a partially transparent green:

Dimensions

Dimensions are most commonly referenced within style and layout resources. They’re useful for creating layout constants such as borders and font heights.

To specify a dimension resource, use the dimen tag, specifying the dimension value, followed by an identifier describing the scale of your dimension:

px Screen pixels
in Physical inches
pt Physical points
mm Physical millimeters
dp Density-independent pixels relative to a 160-dpi screen
sp Scale-independent pixels

These alternatives let you define a dimension not only in absolute terms, but also using relative scales that account for different screen resolutions and densities to simplify scaling on different hardware.

The following XML snippet shows how to specify dimension values for a large font size and a standard border:

Styles and Themes

Style resources let your applications maintain a consistent look and feel by specifying the attribute values used by Views. The most common use of themes and styles is to store the colors and fonts for an application.

To create a style, use a style tag that includes a name attribute, and contains one or more item tags. Each item tag should include a name attribute used to specify the attribute (such as font size or color) being defined. The tag itself should then contain the value, as shown in the skeleton code below:

<?xml version=”1.0” encoding=”utf-8”?>
<resources>
<style name=”StyleName”>
<item name=”attributeName”>value</item>
</style>
</resources>

Styles support inheritance using the parent attribute on the style tag, making it easy to create simple variations.

The following example shows two styles that can also be used as a theme; a base style that sets several text properties and a second style that modifies the first to specify a smaller font.

<?xml version=”1.0” encoding=”utf-8”?>
<resources>
<style name=”BaseText”>
<item name=”android:textSize”>14sp</item>
<item name=”android:textColor”>#111</item>
</style>
<style name=”SmallText” parent=”BaseText”>
<item name=”android:textSize”>8sp</item>
</style>
</resources>

Drawables

Drawable resources include bitmaps and NinePatch (stretchable PNG) images. They are stored as individual files in the res/drawable folder.

The resource identifier for a bitmap resource is the lowercase filename without an extension.

The preferred format for a bitmap resource is PNG, although JPG and GIF fi les are also supported.

NinePatch (or stretchable) images are PNG fi les that mark the parts of an image that can be stretched. NinePatch images must be properly defi ned PNG files that end in .9.png. The resource identifier for NinePatches is the filename without the trailing .9.png.

A NinePatch is a variation of a PNG image that uses a 1-pixel border to defi ne the area of the image that can be stretched if the image is enlarged. To create a NinePatch, draw single-pixel black lines that represent stretchable areas along the left and top borders of your image. The unmarked sections won’t be resized, and the relative size of each of the marked sections will remain the same as the image size changes.

NinePatches are a powerful technique for creating images for the backgrounds of Views or Activities that may have a variable size; for example, Android uses NinePatches for creating button backgrounds.

Layouts

Layout resources let you decouple your presentation layer by designing user-interface layouts in XML rather than constructing them in code.

The most common use of a layout is to define the user interface for an Activity. Once defined in XML, the layout is “inflated” within an Activity using setContentView, usually within the onCreate method.

You can also reference layouts from within other layout resources, such as layouts for each row in a List View.

Using layouts to create your screens is best-practice UI design in Android. The decoupling of the layout from the code lets you create optimized layouts for different hardware configurations, such as varying screen sizes, orientation, or the presence of keyboards and touch screens.

Each layout definition is stored in a separate fi le, each containing a single layout, in the res/layout folder. The filename then becomes the resource identifier.

A thorough explanation of layout containers and View elements is included in the next chapter, but as an example, the following code snippet shows the layout created by the New Project Wizard. It uses a LinearLayout as a layout container for a TextView that displays the “Hello World” greeting.

<?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”>
<TextView
android:layout_width=”fill_parent”
android:layout_height=”wrap_content”
android:text=”Hello World!”
/>
</LinearLayout>

Animations

Android supports two types of animation. Tweened animations can be used to rotate, move, stretch, and fade a View; or you can create frame-by-frame animations to display a sequence of drawable images.

Defining animations as external resources allows you to reuse the same sequence in multiple places and provides you with the opportunity to present an alternative animation based on device hardware or orientation.

Tweened Animations

Each tweened animation is stored in a separate XML fi le in the project’s res/anim folder. As with layouts and drawable resources, the animation’s filename is used as its resource identifier.

An animation can be defined for changes in alpha (fading), scale (scaling), translate (moving), or rotate (rotating).

Each of these animation types supports attributes to define what the sequence will do:

Alpha	fromAlpha and toAlpha	Float from 0 to 1
Scale	fromXScale/toXScale fromYScale/toYScale pivotX/pivotY	Float from 0 to 1 Float from 0 to 1 String of the percentage of graphic width/height from 0% to 100%
Translate	fromX/toX fromY/toY	Float from 0 to 1 Float from 0 to 1
Rotate	fromDegrees/toDegrees pivotX/pivotY	Float from 0 to 360 String of the percentage of graphic width/height from 0% to 100%

You can create a combination of animations using the set tag. An animation set contains one or more animation transformations and supports various additional tags and attributes to customize when and how each animation within the set is run.

The following list shows some of the set tags available:

duration Duration of the animation in milliseconds.
startOffset Millisecond delay before starting this animation.
fillBefore True to apply the animation transformation before it begins.
fillAfter True to apply the animation transformation after it begins.
interpolator Interpolator to set how the speed of this effect varies over time. To specify an interpolator, reference the system animation resources at android:anim/interpolatorName.

If you do not use the startOffset tag, all the animation effects within a set will execute simultaneously.

The following example shows an animation set that spins the target 360 degrees while it shrinks and fades out:

<?xml version=”1.0” encoding=”utf-8”?>
<set xmlns:android=”http://schemas.android.com/apk/res/android”
android:interpolator=”@android:anim/accelerate_interpolator”>
<rotate
android:fromDegrees=”0”
android:toDegrees=”360”
android:pivotX=”50%”
android:pivotY=”50%”
android:startOffset=”500”
android:duration=”1000” />
<scale
android:fromXScale=”1.0”
android:toXScale=”0.0”
android:fromYScale=”1.0”
android:toYScale=”0.0”
android:pivotX=”50%”
android:pivotY=”50%”
android:startOffset=”500”
android:duration=”500” />
<alpha
android:fromAlpha=”1.0”
android:toAlpha=”0.0”
android:startOffset=”500”
android:duration=”500” />
</set>

Frame-by-Frame Animations

Frame-by-frame animations let you create a sequence of drawables, each of which will be displayed for a specified duration, on the background of a View.

Because frame-by-frame animations represent animated drawables, they are stored in the res/drawble folder, rather than with the tweened animations, and use their filenames (without the xml extension) as their resource IDs.

The following XML snippet shows a simple animation that cycles through a series of bitmap resources, displaying each one for half a second. In order to use this snippet, you will need to create new image resources rocket1 through rocket3.

<animation-list
xmlns:android=”http://schemas.android.com/apk/res/android”
android:oneshot=”false”>
<item android:drawable=”@drawable/rocket1” android:duration=”500” />
<item android:drawable=”@drawable/rocket2” android:duration=”500” />
<item android:drawable=”@drawable/rocket3” android:duration=”500” />
</animation-list>

Using Resources

As well as the resources you create, Android supplies several system resources that you can use in your applications. The resources can be used directly from your application code and can also be referenced from within other resources (e.g., a dimension resource might be referenced in a layout definition).

It’s important to note that when using resources you cannot choose a particular specialized version. Android will automatically select the most appropriate value for a given resource identifier based on the current hardware and device settings.

Using Resources in Code

You access resources in code using the static R class. R is a generated class based on your external resources and created by compiling your project. The R class contains static subclasses for each of the resource types for which you’ve defined at least one resource. For example, the default new project includes the R.string and R.drawable subclasses.

If you are using the ADT plug-in in Eclipse, the R class will be created automatically when you make any change to an external resource fi le or folder. If you are not using the plug-in, use the AAPT tool to compile your project and generate the R class. R is a compiler-generated class, so don’t make any manual modifications to it as they will be lost when the fi le is regenerated.

Each of the subclasses within R exposes its associated resources as variables, with the variable names matching the resource identifiers — for example, R.string.app_name or R.drawable.icon.

The value of these variables is a reference to the corresponding resource’s location in the resource table, not an instance of the resource itself.

Where a constructor or method, such as setContentView, accepts a resource identifier, you can pass in the resource variable, as shown in the code snippet below:

// Inflate a layout resource.
setContentView(R.layout.main);
// Display a transient dialog box that displays the
// error message string resource.
Toast.makeText(this, R.string.app_error, Toast.LENGTH_LONG).show();

When you need an instance of the resource itself, you’ll need to use helper methods to extract them from the resource table, represented by an instance of the Resources class.

Because these methods perform lookups on the application’s resource table, these helper methods can’t be static. Use the getResources method on your application context as shown in the snippet below to access your application’s Resource instance:

Resources myResources = getResources();

The Resources class includes getters for each of the available resource types and generally works by passing in the resource ID you’d like an instance of. The following code snippet shows an example of using the helper methods to return a selection of resource values:

Resources myResources = getResources();
CharSequence styledText = myResources.getText(R.string.stop_message);
Drawable icon = myResources.getDrawable(R.drawable.app_icon);
int opaqueBlue = myResources.getColor(R.color.opaque_blue);
float borderWidth = myResources.getDimension(R.dimen.standard_border);
Animation tranOut;
tranOut = AnimationUtils.loadAnimation(this, R.anim.spin_shrink_fade);
String[] stringArray;
stringArray = myResources.getStringArray(R.array.string_array);
int[] intArray = myResources.getIntArray(R.array.integer_array);

Frame-by-frame animated resources are infl ated into AnimationResources. You can return the value using getDrawable and casting the return value as shown below:

AnimationDrawable rocket;
rocket = (AnimationDrawable)myResources.getDrawable(R.drawable.frame_by_frame);

At the time of going to print, there is a bug in the AnimationDrawable class. Currently, AnimationDrawable resources are not properly loaded until some time after an Activity’s onCreate method has completed. Current work-arounds use timers to force a delay before loading a frame-by-frame resource.

to be continued . . . . . .

Creating Applications and Activities

2012-05-24T08:31:00.000-07:00

previous Android Development Tools

Before you start writing Android applications, it’s important to understand how they’re constructed and have an understanding of the Android application life cycle. In this chapter, you’ll be introduced to the loosely coupled components that make up Android applications (and how they’re bound together using the Android manifest). Next you’ll see how and why you should use external resources, before getting an introduction to the Activity component.

In recent years, there’s been a move toward development frameworks featuring managed code, such as the Java virtual machine and the .NET Common Language Runtime.

Mobile devices now come in many shapes and sizes and are used internationally. In this chapter, you’ll learn how to give your applications the flexibility to run seamlessly on different hardware, in different countries, and using multiple languages by externalizing resources.

Next you’ll examine the Activity component. Arguably the most important of the Android building blocks, the Activity class forms the basis for all your user interface screens. You’ll learn how to create new Activities and gain an understanding of their life cycles and how they affect the application lifetime.

Finally, you’ll be introduced to some of the Activity subclasses that wrap up resource management for some common user interface components such as maps and lists.

What Makes an Android Application?

Android applications consist of loosely coupled components, bound using a project manifest that describes each component and how they interact.

There are six components that provide the building blocks for your applications:

Activities Your application’s presentation layer. Every screen in your application will be an extension of the Activity class. Activities use Views to form graphical user interfaces that display information and respond to user actions. In terms of desktop development, an Activity is equivalent to a Form.
Services The invisible workers of your application. Service components run invisibly, updating your data sources and visible Activities and triggering Notifications. They’re used to perform regular processing that needs to continue even when your application’s Activities aren’t active or visible.
Content Providers A shareable data store. Content Providers are used to manage and share application databases. Content Providers are the preferred way of sharing data across application boundaries. This means that you can configure your own Content Providers to permit access from other applications and use Content Providers exposed by others to access their stored data. Android devices include several native Content Providers that expose useful databases like contact information.
Intents A simple message-passing framework. Using Intents, you can broadcast messages system- wide or to a target Activity or Service, stating your intention to have an action performed. The system will then determine the target(s) that will perform any actions as appropriate.
Broadcast Receivers Intent broadcast consumers. By creating and registering a Broadcast Receiver, your application can listen for broadcast Intents that match specific filter criteria. Broadcast Receivers will automatically start your application to respond to an incoming Intent, making them ideal for event-driven applications.
Notifications A user notification framework. Notifications let you signal users without stealing focus or interrupting their current Activities. They’re the preferred technique for getting a user’s attention from within a Service or Broadcast Receiver. For example, when a device receives a text message or an incoming call, it alerts you by flashing lights, making sounds, displaying icons, or showing dialog messages. You can trigger these same events from your own applications using Notifications.

By decoupling the dependencies between application components, you can share and interchange individual pieces, such as Content Providers or Services, with other applications — both your own and those of third parties.

Introducing the Application Manifest

Each Android project includes a manifest fi le, AndroidManifest.xml, stored in the root of the project hierarchy. The manifest lets you define the structure and metadata of your application and its components.

It includes nodes for each of the components (Activities, Services, Content Providers, and Broadcast Receivers) that make up your application and, using Intent Filters and Permissions, determines how they interact with each other and other applications.

It also offers attributes to specify application metadata (like its icon or theme), and additional top-level nodes can be used for security settings and unit tests as described below.

The manifest is made up of a root manifest tag with a package attribute set to the project’s package. It usually includes an xmlns:android attribute that supplies several system attributes used within the file. A typical manifest node is shown in the XML snippet below:

<manifest xmlns:android=http://schemas.android.com/apk/res/android
package=”com.my_domain.my_app”>
[ ... manifest nodes ... ]
</manifest>

The manifest tag includes nodes that define the application components, security settings, and test classes that make up your application. The following list gives a summary of the available manifest node tags, and an XML snippet demonstrating how each one is used:

application A manifest can contain only one application node. It uses attributes to specify the metadata for your application (including its title, icon, and theme). It also acts as a container that includes the Activity, Service, Content Provider, and Broadcast Receiver tags used to specify the application components.
<application android:icon=”@drawable/icon”
android:theme=”@style/my_theme”>
[ ... application nodes ... ]
</application>
activity An activity tag is required for every Activity displayed by your application, using the android:name attribute to specify the class name. This must include the main launch Activity and any other screen or dialogs that can be displayed. Trying to start an Activity that’s not defi ned in the manifest will throw a runtime exception. Each Activity node supports intent-filter child tags that specify which Intents launch the Activity.
<activity android:name=”.MyActivity” android:label=”@string/app_name”>
<intent-filter>
<action android:name=”android.intent.action.MAIN” />
<category android:name=”android.intent.category.LAUNCHER” />
</intent-filter>
</activity>
service As with the activity tag, create a new service tag for each Service class used in your application. Service tags also support intent-filter child tags to allow late runtime binding.
<service android:enabled=”true” android:name=”.MyService”></service>
provider Provider tags are used for each of your application’s Content Providers. Content Providers are used to manage database access and sharing within and between applications.
<provider android:permission=”com.paad.MY_PERMISSION”
android:name=”.MyContentProvider”
android:enabled=”true”
android:authorities=”com.paad.myapp.MyContentProvider”>
</provider>
receiver By adding a receiver tag, you can register a Broadcast Receiver without having to launch your application first. As you’ll see in Chapter 5, Broadcast Receivers are like global event listeners that, once registered, will execute whenever a matching Intent is broadcast by an application. By registering a Broadcast Receiver in the manifest, you can make this process entirely autonomous. If a matching Intent is broadcast, your application will be started automatically and the registered Broadcast Receiver will be run.
<receiver android:enabled=”true”
android:label=”My Broadcast Receiver”
android:name=”.MyBroadcastReceiver”>
</receiver>
uses-permission As part of the security model, uses-permission tags declare the permissions you’ve determined that your application needs for it to operate properly. The permissions you include will be presented to the user, to grant or deny, during installation. Permissions are required for many of the native Android services, particularly those with a cost or security implication (such as dialing, receiving SMS, or using the location-based services). As shown in the item below, third-party applications, including your own, can also specify permissions before providing access to shared application components.
<uses-permission android:name=”android.permission.ACCESS_LOCATION”>
</uses-permission>
permission Before you can restrict access to an application component, you need to define a permission in the manifest. Use the permission tag to create these permission definitions. Application components can then require them by adding the android:permission attribute. Other applications will then need to include a uses-permission tag in their manifests (and have it granted) before they can use these protected components.

Within the permission tag, you can specify the level of access the permission will permit (normal, dangerous, signature, signature Or System), a label, and an external resource containing the description that explain the risks of granting this permission.
<permission android:name=”com.paad.DETONATE_DEVICE”
android:protectionLevel=”dangerous”
android:label=”Self Destruct”
android:description=”@string/detonate_description”>
</permission>
instrumentation Instrumentation classes provide a framework for running tests on your Activities and Services at run time. They provide hooks to monitor your application and its interaction with the system resources. Create a new node for each of the test classes you’ve created for your application.
<instrumentation android:label=”My Test”
android:name=”.MyTestClass”
android:targetPackage=”com.paad.aPackage”>
</instrumentation>

A more detailed description of the manifest and each of these nodes can be found at
http://code.google.com/android/devel/bblocks-manifest.html
The ADT New Project Wizard automatically creates a new manifest fi le when it creates a new project.
You’ll return to the manifest as each of the application components is introduced.

Using the Manifest Editor

The ADT plug-in includes a visual Manifest Editor to manage your manifest, rather than your having to manipulate the underlying XML directly.

To use the Manifest Editor in Eclipse, right-click the AndroidManifest.xml fi le in your project folder, and select Open With ➪ Android Manifest Editor. This presents the Android Manifest Overview screen, as shown in Figure 3-1. This gives you a high-level view of your application structure and provides shortcut links to the Application, Permissions, Instrumentation, and raw XML screens.

Each of the next three tabs contains a visual interface for managing the application, security, and instrumentation (testing) settings, while the last tag (using the manifest’s fi lename) gives access to the raw XML.

Of particular interest is the Application tab, shown in Figure 3-2. Use it to manage the application node and the application component hierarchy, where you specify the application components.

You can specify an application’s attributes — including its Icon, Label, and Theme — in the Application Attributes panel. The Application Nodes tree beneath it lets you manage the application components, including their attributes and any associated Intent Filter subnodes.

next The Android Application Life Cycle

Android Development Tools

2012-05-21T10:16:00.000-07:00

previous Developing for Android

The Android SDK includes several tools and utilities to help you create, test, and debug your projects. A detailed examination of each developer tool is outside the scope of this book, but it’s worth briefly reviewing what’s available. For more detail than is included here, check out the Android documentation at:

http://code.google.com/android/intro/tools.html

As mentioned earlier, the ADT plug-in conveniently incorporates most of these tools into the Eclipse IDE, where you can access them from the DDMS perspective, including:

The Android Emulator An implementation of the Android virtual machine designed to run on your development computer. You can use the emulator to test and debug your android applications.
Dalvik Debug Monitoring Service (DDMS) Use the DDMS perspective to monitor and control the Dalvik virtual machines on which you’re debugging your applications.
Android Asset Packaging Tool (AAPT) Constructs the distributable Android package fi les (.apk).
Android Debug Bridge (ADB) The ADB is a client-server application that provides a link to a running emulator. It lets you copy fi les, install compiled application packages (.apk), and run shell commands.

The following additional tools are also available:

SQLite3 A database tool that you can use to access the SQLite database fi les created and used by Android
Traceview Graphical analysis tool for viewing the trace logs from your Android application
MkSDCard Creates an SDCard disk image that can be used by the emulator to simulate an external storage card.
dx Converts Java .class bytecode into Android .dex bytecode.
activityCreator Script that builds Ant build fi les that you can then use to compile your Android applications without the ADT plug-in

Let’s take a look at some of the more important tools in more detail.

The Android Emulator

The emulator is the perfect tool for testing and debugging your applications, particularly if you don’t have a real device (or don’t want to risk it) for experimentation.

The emulator is an implementation of the Dalvik virtual machine, making it as valid a platform for running Android applications as any Android phone. Because it’s decoupled from any particular hardware, it’s an excellent baseline to use for testing your applications.

A number of alternative user interfaces are available to represent different hardware configurations, each with different screen sizes, resolutions, orientations, and hardware features to simulate a variety of mobile device types.

Full network connectivity is provided along with the ability to tweak the Internet connection speed and latency while debugging your applications. You can also simulate placing and receiving voice calls and SMS messages.

The ADT plug-in integrates the emulator into Eclipse so that it’s launched automatically when you run or debug your projects. If you aren’t using the plug-in or want to use the emulator outside of Eclipse, you can telnet into the emulator and control it from its console. For more details on controlling the emulator, check the documentation at http://code.google.com/android/reference/emulator.html.

At this stage, the emulator doesn’t implement all the mobile hardware features supported by Android, including the camera, vibration, LEDs, actual phone calls, the accelerometer, USB connections, Bluetooth, audio capture, battery charge level, and SD card insertion/ejection.

Dalvik Debug Monitor Service (DDMS)

The emulator lets you see how your application will look, behave, and interact, but to really see what’s happening under the surface, you need the DDMS. The Dalvik Debug Monitoring Service is a powerful debugging tool that lets you interrogate active processes, view the stack and heap, watch and pause active threads, and explore the filesystem of any active emulator.

The DDMS perspective in Eclipse also provides simplified access to screen captures of the emulator and the logs generated by LogCat.

If you’re using the ADT plug-in, the DDMS is fully integrated into Eclipse and is available from the DDMS perspective. If you aren’t using the plug-in or Eclipse, you can run DDMS from the command line, and it will automatically connect to any emulator that’s running.

The Android Debug Bridge (ADB)

The Android debug bridge (ADB) is a client-service application that lets you connect with an Android Emulator or device. It’s made up of three components: a daemon running on the emulator, a service that runs on your development hardware, and client applications (like the DDMS) that communicate with the daemon through the service.

As a communications conduit between your development hardware and the Android device/emulator, the ADB lets you install applications, push and pull fi les, and run shell commands on the target device. Using the device shell, you can change logging settings, and query or modify SQLite databases available on the device.

The ADT tool automates and simplifies a lot of the usual interaction with the ADB, including application installation and update, log fi les, and fi le transfer (through the DDMS perspective).

next Creating Applications and Activities

Developing for Android

2012-05-21T08:45:00.000-07:00

previous Understanding Hello World

Nothing covered so far is specific to Android; the design considerations above are just as important when developing applications for any mobile. In addition to these general guidelines, Android has some particular considerations.

To start with, it’s worth taking a few minutes to read Google’s Android design philosophy at http://code.google.com/android/toolbox/philosophy.html.

The Android design philosophy demands that applications be:

Fast
Responsive
Secure
Seamless

Being Fast and Efficient

In a resource-constrained environment, being fast means being efficient. A lot of what you already know about writing efficient code will be just as effective in Android, but the limitations of embedded systems and the use of the Dalvik VM mean you can’t take things for granted.

The smart bet for advice is to go to the source. The Android team has published some specific guidance on writing efficient code for Android, so rather than rehash their advice, I suggest you visit http://code.google.com/android/toolbox/performance.html and take note of their suggestions.

You may find that some of these performance suggestions contradict established design practices — for example, avoiding the use of internal setters and getters or preferring virtual over interface. When writing software for resource-constrained systems like embedded devices, there’s often a compromise between conventional design principles and the demand for greater efficiency.

One of the keys to writing efficient Android code is to not carry over assumptions from desktop and server environments to embedded devices.

At a time when 2 to 4 GB of memory is standard for most desktop and server rigs, even advanced smartphones are lucky to feature 32 MB of RAM. With memory such a scarce commodity, you need to take special care to use it efficiently. This means thinking about how you use the stack and heap, limiting object creation, and being aware of how variable scope affects memory use.

Being Responsive

Android takes responsiveness very seriously.

Android enforces responsiveness with the Activity Manager and Window Manager. If either service detects an unresponsive application, it will display the unambiguous Application unresponsive (AUR) message, as shown in Figure 2-8.

This alert is modal, steals focus, and won’t go away until you hit a button or your application starts responding — it’s pretty much the last thing you ever want to confront a user with.

Android monitors two conditions to determine responsiveness:

An application must respond to any user action, such as a key press or screen touch, within 5 seconds.
A Broadcast Receiver must return from its onReceive handler within 10 seconds.

The most likely culprits for causing unresponsiveness are network lookups, complex processing (such as calculating game moves), and fi le I/O. There are a number of ways to ensure that these actions don’t exceed the responsiveness conditions, in particular, using services and worker threads.

The AUR dialog is a last resort of usability; the generous 5-second limit is a worst-case scenario, not a benchmark to aim for. Users will notice a regular pause of anything more than half a second between key press and action. Happily, a side effect of the efficient code you’re already writing will be faster, more responsive applications.

Developing Secure Applications

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.

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 technologies 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).
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.

Ensuring a Seamless User Experience

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 process 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 developers, it’s particularly important that these applications interact seamlessly.

Use a consistent and intuitive approach to usability. You can still create applications that are revolutionary 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 battery life when the application isn’t visible. If your application has processes that need to continue running 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.

To -Do List Example

In this example, you’ll be creating a new Android application from scratch. This simple example creates 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, specifying 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. The preferred method for laying out your UI is using a layout resource fi le. 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” />
With your user interface defined, open the ToDoList.java Activity class from your project’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, defi ne 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.
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.

next Android Development Tools

Understanding Hello World

2012-05-20T10:32:00.000-07:00

previous Creating Your First Android Activity

With that confirmed, let’s take a step back and have a real look at your first Android application.

Activity is the base class for the visual, interactive components of your application; it is roughly equivalent to a Form in traditional desktop development. The following snippet shows the skeleton code for an Activity-based class; note that it extends Activity, overriding the onCreate method.

package com.paad.helloworld;

import android.app.Activity;
import android.os.Bundle;

public class HelloWorld extends Activity {

/** Called when the activity is first created. */
@Override
public void onCreate(Bundle icicle) {
super.onCreate(icicle);
}
}

What’s missing from this template is the layout of the visual interface. In Android, visual components are called Views, which are similar to controls in traditional desktop development.

In the Hello World template created by the wizard, the onCreate method is overridden to call setContentView, which lays out the user interface by inflating a layout resource, as highlighted below:

@Override
public void onCreate(Bundle icicle) {
super.onCreate(icicle);
setContentView(R.layout.main);
}

The resources for an Android project are stored in the res folder of your project hierarchy, which includes drawable, layout, and values subfolders. The ADT plug-in interprets these XML resources to provide design time access to them through the R variable.

The following code snippet shows the UI layout defined in the main.xml fi le created by the Android project template:

Defining your UI in XML and inflating it is the preferred way of implementing your user interfaces, as it neatly decouples your application logic from your UI design.

To get access to your UI elements in code, you add identifier attributes to them in the XML definition. You can then use the findViewById method to return a reference to each named item. The following XML snippet shows an ID attribute added to the TextView widget in the Hello World template:

And the following snippet shows how to get access to it in code:

TextView myTextView = (TextView)findViewById(R.id.myTextView);

Alternatively (although it’s not considered good practice), if you need to, you can create your layout directly in code as shown below:

public void onCreate(Bundle icicle) {
super.onCreate(icicle);

LinearLayout.LayoutParams lp;

lp = new LinearLayout.LayoutParams(LayoutParams.FILL_PARENT,
LayoutParams.FILL_PARENT);

LinearLayout.LayoutParams textViewLP;
textViewLP = new LinearLayout.LayoutParams(LayoutParams.FILL_PARENT,
LayoutParams.WRAP_CONTENT);

LinearLayout ll = new LinearLayout(this);
ll.setOrientation(LinearLayout.VERTICAL);
TextView myTextView = new TextView(this);
myTextView.setText(“Hello World, HelloWorld”);
ll.addView(myTextView, textViewLP);
this.addContentView(ll, lp);
}

All the properties available in code can be set with attributes in the XML layout. As well as allowing easier substitution of layout designs and individual UI elements, keeping the visual design decoupled from the application code helps keep the code more concise.

The Android web site (http://code.google.com/android/documentation.html) includes several excellent step-by-step guides that demonstrate many of the features and good practices you will be using as an Android developer. They’re easy to follow and give a good idea of how Android applications fi t together.

Types of Android Applications

Most of the applications you create in Android will fall into one of the following categories:

Foreground Activity An application that’s only useful when it’s in the foreground and is effectively suspended when it’s not visible. Games and map mashups are common examples.
Background Service An application with limited interaction that, apart from when being configured, spends most of its lifetime hidden. Examples of this include call screening applications or SMS auto-responders.
Intermittent Activity Expects some interactivity but does most of its work in the background. Often these applications will be set up and then run silently, notifying users when appropriate. A common example would be a media player.

Complex applications are difficult to pigeonhole into a single category and include elements of all three. When creating your application, you need to consider how it’s likely to be used and then design it accordingly. Let’s look more closely at some of the design considerations for each application type described above.

Foreground Activities

When creating foreground applications, you need to consider the Activity life cycle carefully so that the Activity switches seamlessly between the foreground and the background.

Applications have no control over their life cycles, and a backgrounded application, with no Services, is a prime candidate for cleanup by Android’s resource management. This means that you need to save the state of the application when the Activity becomes invisible, and present the exact same state when it returns to the foreground.

It’s also particularly important for foreground Activities to present a slick and intuitive user experience.

Background Services

These applications run silently in the background with very little user input. They often listen for messages or actions caused by the hardware, system, or other applications, rather than rely on user interaction.

It’s possible to create completely invisible services, but in practice, it’s better form to provide at least some sort of user control. At a minimum, you should let users confirm that the service is running and let them configure, pause, or terminate it as needed.

Intermittent Activities

Often you’ll want to create an application that reacts to user input but is still useful when it’s not the active foreground Activity. These applications are generally a union of a visible controller Activity with an invisible background Service.

These applications need to be aware of their state when interacting with the user. This might mean updating the Activity UI when it’s visible and sending notifications to keep the user updated when it’s in the background.

Developing for Mobile Devices

Android does a lot to simplify mobile-device software development, but it’s still important to understand the reasons behind the conventions. There are several factors to account for when writing software for mobile and embedded devices, and when developing for Android, in particular.

Hardware-Imposed Design Considerations

Small and portable, mobile devices offer exciting opportunities for software development. Their limited screen size and reduced memory, storage, and processor power are far less exciting, and instead present some unique challenges.

Compared to desktop or notebook computers, mobile devices have relatively:

Low processing power
Limited RAM
Limited permanent storage capacity
Small screens with low resolution
Higher costs associated with data transfer
Slower data transfer rates with higher latency
Less reliable data connections
Limited battery life

It’s important to keep these restrictions in mind when creating new applications.

Be Efficient

Manufacturers of embedded devices, particularly mobile devices, value small size and long battery life over potential improvements in processor speed. For developers, that means losing the head start traditionally afforded thanks to Moore’s law. The yearly performance improvements you’ll see in desktop and server hardware usually translate into smaller, more power-efficient mobiles without much improvement in processor power.

In practice, this means that you always need to optimize your code so that it runs quickly and responsively, assuming that hardware improvements over the lifetime of your software are unlikely to do you any favors.

Since code efficiency is a big topic in software engineering, I’m not going to try and capture it here. This chapter covers some Android-specific efficiency tips below, but for now, just note that efficiency is particularly important for resource-constrained environments like mobile devices.

Expect Limited Capacity

Advances in flash memory and solid-state disks have led to a dramatic increase in mobile-device storage capacities (although people’s MP3 collections tend to expand to fill the available space). In practice, most devices still offer relatively limited storage space for your applications. While the compiled size of your application is a consideration, more important is ensuring that your application is polite in its use of system resources.

You should carefully consider how you store your application data. To make life easier, you can use the Android databases and Content Providers to persist, reuse, and share large quantities of data. For smaller data storage, such as preferences or state settings, Android provides an optimized framework.

Of course, these mechanisms won’t stop you from writing directly to the file system when you want or need to, but in those circumstances, always consider how you’re structuring these files, and ensure that yours is an efficient solution.

Part of being polite is cleaning up after yourself. Techniques like caching are useful for limiting repetitive network lookups, but don’t leave fi les on the file system or records in a database when they’re no longer needed.

Design for Small Screens

The small size and portability of mobiles are a challenge for creating good interfaces, particularly when users are demanding an increasingly striking and information-rich graphical user experience.

Write your applications knowing that users will often only glance at the (small) screen. Make your applications intuitive and easy to use by reducing the number of controls and putting the most important information front and center.

Graphical controls are an excellent way to convey dense information in an easy-to-understand way. Rather than a screen full of text with lots of buttons and text entry boxes, use colors, shapes, and graphics to display information.

If you’re planning to include touch-screen support (and if you’re not, you should be), you’ll need to consider how touch input is going to affect your interface design. The time of the stylus has passed; now it’s all about finger input, so make sure your Views are big enough to support interaction using a finger on the screen.

Of course, mobile-phone resolutions and screen sizes are increasing, so it’s smart to design for small screens, but also make sure your UIs scale.

Expect Low Speeds, High Latency

The mobile Web unfortunately isn’t as fast, reliable, or readily available as we’d often like, so when you’re developing your Internet-based applications, it’s best to assume that the network connection will be slow, intermittent, and expensive. With unlimited 3G data plans and city-wide Wi-Fi, this is changing, but designing for the worst case ensures that you always deliver a high-standard user experience.

This also means making sure that your applications can handle losing (or not finding) a data connection.

The Android Emulator lets you control the speed and latency of your network connection when setting up an Eclipse launch configuration. Figure 2-7 shows the emulator’s network connection speed and latency set up to simulate a distinctly suboptimal EDGE connection.

Experiment to ensure responsiveness no matter what the speed, latency, and availability of network access. You might find that in some circumstances, it’s better to limit the functionality of your application or reduce network lookups to cached bursts, based on the network connection(s) available.

At What Cost?

If you’re a mobile owner, you know all too well that some of the more powerful features on your mobile can literally come at a price. Services like SMS, GPS, and data transfer often incur an additional tariff from your service provider.

It’s obvious why it’s important that any costs associated with functionality in your applications are minimized, and that users are aware when an action they perform might result in them being charged.

It’s a good approach to assume that there’s a cost associated with any action involving an interaction with the outside world. Minimize interaction costs by the following:

Transferring as little data as possible
Caching data and GPS results to eliminate redundant or repetitive lookups
Stopping all data transfers and GPS updates when your activity is not visible in the foreground if they’re only being used to update the UI
Keeping the refresh/update rates for data transfers (and location lookups) as low as practicable
Scheduling big updates or transfers at “off peak” times using alarms

Often the best solution is to use a lower-quality option that comes at a lower cost.

When using the location-based services, you can select a location provider based on whether there is an associated cost. Within your location-based applications, consider giving users the choice of lower cost or greater accuracy.

In some circumstances, costs are hard to define, or they’re different for different users. Charges for services vary between service providers and user plans. While some people will have free unlimited data transfers, others will have free SMS.

Rather than enforcing a particular technique based on which seems cheaper, consider letting your users choose. For example, when downloading data from the Internet, you could ask users if they want to use any network available or limit their transfers to only when they’re connected via Wi-Fi.

Considering the Users’ Environment

You can’t assume that your users will think of your application as the most important feature of their phones.

Generally, a mobile is first and foremost a phone, secondly an SMS and e-mail communicator, thirdly a camera, and fourthly an MP3 player. The applications you write will most likely be in a fifth category of “useful mobile tools.”

That’s not a bad thing — it’s in good company with others including Google Maps and the web browser. That said, each user’s usage model will be different; some people will never use their mobiles to listen to music, and some phones don’t include a camera, but the multitasking principle inherent in a device as ubiquitous as it is indispensable is an important consideration for usability design.

It’s also important to consider when and how your users will use your applications. People use their mobiles all the time — on the train, walking down the street, or even while driving their cars. You can’t make people use their phones appropriately, but you can make sure that your applications don’t distract them any more than necessary.

What does this mean in terms of software design? Make sure that your application:

Is well behaved Start by ensuring that your Activities suspend when they’re not in the foreground. Android triggers event handlers when your Activity is suspended or resumed so you can pause UI updates and network lookups when your application isn’t visible — there’s no point updating your UI if no one can see it. If you need to continue updating or processing in the background, Android provides a Service class designed to run in the background without the UI overheads.
Switches seamlessly from the background to the foreground With the multitasking nature of mobile devices, it’s very likely that your applications will regularly switch into and out of the background. When this happens, it’s important that they “come to life” quickly and seamlessly. Android’s nondeterministic process management means that if your application is in the background, there’s every chance it will get killed to free up resources. This should be invisible to the user. You can ensure this by saving the application state and queuing updates so that your users don’t notice a difference between restarting and resuming your application. Switching back to it should be seamless with users being shown the exact UI and application state they last saw.
Is polite Your application should never steal focus or interrupt a user’s current activity. Use Notifications and Toasts (detailed in Chapter 8) instead to inform or remind users that their attention is requested if your application isn’t in the foreground. There are several ways for mobile devices to alert users. For example, when a call is coming in, your phone rings; when you have unread messages, the LED flashes; and when you have new voice mail, a small “mail” icon appears in your status bar. All these techniques and more are available through the notification mechanism.
Presents a consistent user interface Your application is likely to be one of several in use at any time, so it’s important that the UI you present is easy to use. Don’t force users to interpret and relearn your application every time they load it. Using it should be simple, easy, and obvious— particularly given the limited screen space and distracting user
Is responsive Responsiveness is one of the most important design considerations on a mobile device. You’ve no doubt experienced the frustration of a “frozen” piece of software; the multifunction nature of a mobile makes it even more annoying. With possible delays due to slow and unreliable data connections, it’s important that your application use worker threads and background services to keep your activities responsive and, more importantly, stop them from preventing other applications from responding in a timely manner.

next Developing for Android

Creating Your First Android Activity

2012-05-18T22:58:00.000-07:00

previous Getting Started with Android

You’ve downloaded the SDK, installed Eclipse, and plugged in the plug-in. You’re now ready to start programming for Android. Start by creating a new project and setting up your Eclipse run and debug configurations.

Starting a New Android Project
To create a new Android project using the Android New Project Wizard:

Select File ➪ New ➪ Project.
Select the Android Project application type from the Android folder, and click Finish.
In the dialog that appears (shown in Figure 2-4), enter the details for your new project. The “Project name” is the name of your project fi le; the “Package name” specifies its package; the “Activity name” is the name of the class that is your initial Activity; and the “Application name” is the friendly name for your application.
When you’ve entered the details, click Finish.

The ADT plug-in then creates a new project that includes a new class that extends Activity. Rather than being completely empty, the default template implements “Hello World.” Before modifying the project, take this opportunity to configure run and debug launch configurations.

Creating a Launch Configuration

Launch configurations let you specify runtime options for running and debugging applications. Using a launch configuration you can specify the following:

The Project and Activity to launch
The emulator options to use
Input/output settings (including console defaults)

You can specify different launch configurations for Run and Debug modes. The following steps show how to create a launch configuration for an Android application:

Select Run ➪ Open Run Dialog … (or Run ➪ Open Debug Dialog …).
Right-click Android Application on the project type list, and select New.
Enter a name for the configuration. You can create multiple configurations for each project, so create a descriptive title that will help you identify this particular setup.
Now choose your start-up options. The first (Android) tab lets you select the project and Activity that you want to start when you run (or debug) the application. Figure 2-5 shows the settings for the project you created earlier.
Use the Target tab to configure the emulator. There are options to choose the screen size, device skin, and network connection settings. You can also optionally wipe the user data on the emulator and enable or disable the start-up animation. Using the command-line textbox, you can specify additional emulator start-up options if needed.
Finally, set any additional properties in the Common tab.
Click Apply, and your launch configuration will be saved.

Running and Debugging Your Android Applications

You’ve created your first project and created the run and debug configurations for it. Before making any changes, test your installation and configurations by running and debugging the Hello World project.

From the Run menu, select Run or Debug to launch the most recently selected configuration, or select Open Run Dialog … or Open Debug Dialog … to select a configuration to use.

If you’re using the ADT plug-in, running or debugging your application:

Compiles the current project and converts it to an Android executable (.dex).
Packages the executable and external resources into an Android package (.apk).
Starts the emulator (if it’s not already running).
Installs your application onto the emulator.
Starts your application.

If you’re debugging, the Eclipse debugger will then be attached, allowing you to set breakpoints and debug your code.

If everything is working correctly, you’ll see a new Activity running in the emulator, as shown in Figure 2-6.

next Understanding Hello World

Getting Started with Android

2012-05-17T11:35:00.000-07:00

previous The Dalvik Virtual Machine

All you need to start writing your own Android applications is a copy of the Android SDK and the Java development kit. Unless you’re a masochist, you’ll probably want a Java IDE — Eclipse is particularly well supported — to make development a little easier.

Versions of the SDK, Java, and Eclipse are available for Windows, Mac OS, and Linux, so you can explore Android from the comfort of whatever OS you favor. The SDK includes an emulator for all three OS environments, and because Android applications are run on a virtual machine, there’s no advantage to developing from any particular operating system.

Android code is written using Java syntax, and the core Android libraries include most of the features from the core Java APIs. Before they can be run, though, your projects are first translated into Dalvik byte code. As a result, you get the benefits of using Java, while your applications have the advantage of running on a virtual machine optimized for Android devices.

The SDK download includes all the Android libraries, full documentation, and excellent sample applications. It also includes tools to help you write and debug your applications, like the Android Emulator to run your projects and the Dalvik Debug Monitoring Service (DDMS) to help debug them.

By the end of this chapter, you’ll have downloaded the Android SDK, set up your development environment, completed two new applications, and run and debugged them using the emulator and DDMS.

If you’ve developed for mobile devices before, you already know that their small-form factor, limited power, and restricted memory create some unique design challenges. Even if you’re new to the game, it’s obvious that some of the things you can take for granted on the desktop or the Web aren’t going to work on a mobile.

As well as the hardware limitations, the user environment brings its own challenges. Mobile devices are used on the move and are often a distraction rather than the focus of attention, so your applications need to be fast, responsive, and easy to use.

Developing for Android

The Android SDK includes all the tools and APIs you need to write compelling and powerful mobile applications. The biggest challenge with Android, as with any new development toolkit, is learning the features and limitations of its APIs.

If you have experience in Java development, you’ll find that the techniques, syntax, and grammar you’ve been using will translate directly into Android, although some of the specific optimization techniques may seem counterintuitive.

If you don’t have experience with Java but have used other object-oriented languages (such as C#), you should find the transition straightforward. The power of Android comes from its APIs, not from Java, so being unfamiliar with all the Java specific classes won’t be a big disadvantage.

What You Need to Begin

Because Android applications run within the Dalvik virtual machine, you can write them on any platform that supports the developer tools. This currently includes the following:

Microsoft Windows (XP or Vista)
Mac OS X 10.4.8 or later (Intel chips only)
Linux

To get started, you’ll need to download and install the following:

The Android SDK
Java Development Kit (JDK) 5 or 6

You can download the latest JDK from Sun at

http://java.sun.com/javase/downloads/index.jsp

If you already have a JDK installed, make sure that it meets the version requirements listed above, and note that the Java runtime environment (JRE) is not sufficient.

Downloading and Installing the SDK

The Android SDK is completely open. There’s no cost to download and use the API, and Google doesn’t charge to allow distribution of your finished programs. You can download the latest version of the SDK for your development platform from the Android development home page at
http://code.google.com/android/download.html

Unless otherwise noted, the version of the Android SDK used for writing this book was version 1.0 r1.

The SDK is presented as a ZIP fi le containing the API libraries, developer tools, documentation, and several sample applications and API demos that highlight the use of particular API features. Install it by unzipping the SDK into a new folder. (Take note of this location, as you’ll need it later.)

The examples and step-by-step instructions provided are targeted at developers using Eclipse with the Android Developer Tool (ADT) plug-in. Neither is required, though — you can use any text editor or Java IDE you’re comfortable with and use the developer tools in the SDK to compile, test, and debug the code snippets and sample applications.

The examples included in the SDK are well documented and are an excellent source for full, working examples of applications written for Android. Once you’ve finished setting up your development environment, it’s worth going through them.

Developing with Eclipse

Using Eclipse with the ADT plug-in for your Android development offers some significant advantages.

Eclipse is an open source IDE (integrated development environment) particularly popular for Java development. It’s available to download for each of the development platforms supported by Android (Windows, Mac OS, and Linux) from the Eclipse foundation homepage:

www.eclipse.org/downloads/

There are many variations available when selecting your Eclipse download; the following is the recommended configuration for Android:

Eclipse 3.3, 3.4 (Ganymede)
- Eclipse JDT plug-in
- WST

WST and the JDT plug-in are included in most Eclipse IDE packages.

Installing Eclipse consists of uncompressing the download into a new folder. When that’s done, run the Eclipse executable. When it starts for the first time, create a new workspace for your Android development.

Using the Eclipse Plug-in

The ADT plug-in for Eclipse simplifies your Android development by integrating the developer tools, including the emulator and .class-to-.dex converter, directly into the IDE. While you don’t have to use the ADT plug-in, it does make creating, testing, and debugging your applications faster and easier.

The ADT plug-in integrates the following into Eclipse:

An Android Project Wizard that simplifies creating new projects and includes a basic application template
Forms-based manifest, layout, and resource editors to help create, edit, and validate your XML resources
Automated building of Android projects, conversion to Android executables (.dex), packaging to package fi les (.apk), and installation of packages onto Dalvik virtual machines
The Android Emulator, including control of the emulator’s appearance, network connection settings, and the ability to simulate incoming calls and SMS messages
The Dalvik Debug Monitoring Service (DDMS), which includes port forwarding; stack, heap, and thread viewing; process details; and screen capture facilities
Access to the device or emulator’s filesystem, allowing you to navigate the folder tree and transfer files
Runtime debugging, so you can set breakpoints and view call stacks
All Android/Dalvik log and console outputs

Figure 2-1 shows the DDMS perspective within Eclipse with the ADT plug-in installed.

Installing the ADT Plug-in

Install the developer tools plug-in by the following steps:

Select Help ➪ Software Updates ➪ Find and Install … from within Eclipse.
In the resulting dialog box, choose Search for new features to install.
Select New Remote Site, and enter the following address into the dialog box, as shown in Figure 2-2: https://dl-ssl.google.com/android/eclipse/
The new site you entered should now be checked. Click Finish.
Eclipse will now download the plug-in. When it’s fi nished, select Android Plugin ➪ Developer Tools from the resulting Search Results dialog box, and click Next.
Read and then Accept the terms of the license agreement, and click Next and then Finish. As the ADT plug-in is not signed, you’ll be prompted before the installation continues.
When complete, you’ll have to restart Eclipse and update the ADT preferences. Restart and select Window ➪ Preferences … (or Eclipse ➪ Preferences for the Mac OS).
Then select Android from the left panel.
Click Browse …, and navigate to the folder into which you unzipped the Android SDK, as shown in Figure 2-3; then click Apply and OK.

If you download a new version of the SDK and place it in a different location, you will need to update this preference to reflect the SDK with which the ADT should be building.

Updating the Plug-in

As the Android SDK matures, there are likely to be frequent updates to the ADT plug-in. In most cases, to update your plug-in, you simply:

Navigate to Help ➪ Software Updates ➪ Find and Install …
Select Search for updates of the currently installed features, and click Finish …
If there are any ADT updates available, they will be presented. Simply select them and choose Install.

Sometimes a plug-in upgrade is so significant that the dynamic update mechanism can’t be used. In those cases, you may have to remove the previous plug-in completely before installing the newer version as described in the previous section.

next Creating Your First Android Activity

The Dalvik Virtual Machine

2012-05-17T08:29:00.000-07:00

previous Introducing the Open Hands set Alliance

One of the key elements of Android is the Dalvik virtual machine. Rather than use a traditional Java virtual machine (VM) such as Java ME (Java Mobile Edition), Android uses its own custom VM designed to ensure that multiple instances run efficiently on a single device.

The Dalvik VM uses the device’s underlying Linux kernel to handle low-level functionality including security, threading, and process and memory management. It’s also possible to write C/C++ applications that run directly on the underlying Linux OS. While you can do this, in most cases there’s no reason you should need to.

This book focuses exclusively on writing applications that run within Dalvik. If your inclinations run toward exploring the Linux kernel and C/C++ underbelly of Android, modifying Dalvik, or otherwise tinkering with things under the hood, check out the Android Internals Google Group at

http://groups.google.com/group/android-internals

All Android hardware and system service access is managed using Dalvik as a middle tier. By using a VM to host application execution, developers have an abstraction layer that ensures they never have to worry about a particular hardware implementation.

The Dalvik VM executes Dalvik executable fi les, a format optimized to ensure minimal memory footprint. The .dex executables are created by transforming Java language compiled classes using the tools supplied within the SDK.

Android Application Architecture

Android’s architecture encourages the concept of component reuse, allowing you to publish and share activities, services, and data with other applications with access managed by the security restrictions you put in place.

The same mechanism that lets you produce a replacement contact manager or phone dialer can let you expose your application components to let other developers create new UI front ends and functionality extensions, or otherwise build on them.

Android Libraries

Android offers a number of APIs for developing your applications. The following list of core APIs should provide an insight into what’s available; all Android devices will offer support for at least these APIs:

android.util: The core utility package contains low-level classes like specialized containers, string formatters, and XML parsing utilities.
android.os: The operating system package provides access to basic operating system services like message passing, interprocess communication, clock functions, and debugging.
android.graphics: The graphics API supplies the low-level graphics classes that support canvases, colors, and drawing primitives, and lets you draw on canvases.
android.text: The text processing tools for displaying and parsing text.
android.database: Supplies the low-level classes required for handling cursors when working with databases.
android.content: The content API is used to manage data access and publishing by providing services for dealing with resources, content providers, and packages.
android.view: Views are the core user interface class. All user interface elements are constructed using a series of Views to provide the user interaction components.
android.widget: Built on the View package, the widget classes are the “here’s one we created earlier” user-interface elements for you to use in your applications. They include lists, buttons, and layouts.
com.google.android.maps: A high-level API that provides access to native map controls that you can use within your application. Includes the MapView control as well as the Overlay and MapController classes used to annotate and control your embedded maps.
android.app: A high-level package that provides access to the application model. The application package includes the Activity and Service APIs that form the basis for all your Android applications.
android.provider: To ease developer access to certain standard Content Providers (such as the contacts database), the Provider package offers classes to provide access to standard databases included in all Android distributions.
android.telephony: The telephony APIs give you the ability to directly interact with the device’s phone stack, letting you make, receive, and monitor phone calls, phone status, and SMS messages.
android.webkit: The WebKit package features APIs for working with Web-based content, including a WebView control for embedding browsers in your activities and a cookie manager.

In addition to the Android APIs, the Android stack includes a set of C/C++ libraries that are exposed through the application framework. These libraries include:

OpenGL: The library used to support 3D graphics based on the Open GL ES 1.0 API
FreeType: Support for bitmap and vector font rendering
SGL: The core library used to provide a 2D graphics engine
libc: The standard C library optimized for Linux-based embedded devices
SQLite: The lightweight relation database engine used to store application data
SSL: Support for using the Secure Sockets Layer cryptographic protocol for secure Internet communications

Advanced Android Libraries

The core libraries provide all the functionality you need to start creating applications for Android, but it won’t be long before you’re ready to delve into the advanced APIs that offer the really exciting functionality.

Android hopes to target a wide range of mobile hardware, so be aware that the suitability and implementation of the following APIs will vary depending on the device upon which they are implemented.

android.location: The location-based services API gives your applications access to the device’s current physical location. Location-based services provide generic access to location information using whatever position-fixing hardware or technology is available on the device.
android.media: The media APIs provide support for playback and recording of audio and video media fi les, including streamed media.
android.opengl: Android offers a powerful 3D rendering engine using the OpenGL ES API that you can use to create dynamic 3D user interfaces for your applications.
android.hardware: Where available, the hardware API exposes sensor hardware including the camera, accelerometer, and compass sensors.
android.bluetooth, android.net.wifi , and android.telephony: Android also provides low-level access to the hardware platform, including Bluetooth, Wi-Fi, and telephony hardware.

next Getting Started with Android

Introducing the Open Hands set Alliance

2012-05-17T07:50:00.000-07:00

previous Android SDK Features

The Open Handset Alliance (OHA) is a collection of more than 30 technology companies including hardware manufacturers, mobile carriers, and software developers. Of particular note are the prominent mobile technology companies Motorola, HTC, T-Mobile, and Qualcomm. In their own words, the OHA represents:

A commitment to openness, a shared vision for the future, and concrete plans to make the vision a reality. To accelerate innovation in mobile and offer consumers a richer, less expensive, and better mobile experience.

http://www.openhandsetalliance.com/oha_faq.html

The OHA hopes to deliver a better mobile software experience for consumers by providing the platform needed for innovative mobile development at a faster rate and a higher quality without licensing fees for software developers or handset manufacturers.

Ultimately the success of Android as a mobile platform will depend largely on the success of OHA partners in releasing desirable handsets and mobile services that encourage the widespread adoption of Android phones. Developers meanwhile have the opportunity to create innovative new mobile applications for Android to encourage more mobile technology companies to become part of the OHA.

What Does Android Run On ?

The first Android mobile handset, the T-Mobile G1, was released in the US in October 2008 and in the UK in November 2008. The Open Handset Alliance has further committed to deploying additional handsets and services that support Android early in 2009.

Rather than a mobile OS created for a single hardware implementation, Android is designed to support a large variety of hardware platforms, from touch-screen phones to devices with no screens at all.

Beyond that, with no licensing fees or proprietary software, the cost to handset manufacturers for providing Android-compatible variations of their handsets is comparatively low. It’s hoped that once demand for hardware capable of running popular Android applications reaches a critical mass, more device manufacturers will produce increasingly tailored hardware to meet that demand.

Why Develop for Android?

If you have a background in mobile application development, this is meaningless to ask:

A lot of what you can do with Android is already possible.
But doing it is painful.

Android represents a clean break, a mobile framework based on the reality of modern mobile devices.

With a simple and powerful SDK, no licensing fees, excellent documentation, and a thriving developer community, Android is an excellent opportunity to create software that changes how and why people use their mobile phones.

Android is backed by more than 30 OHA members and is surrounded by significant industry buzz.

In market terms, the growth in portable devices is a worldwide phenomenon, with mobile-phone ownership outstripping computer ownership in many countries. The increasing popularity of smartphones — multifunction devices including a phone but featuring cameras, Internet access, media players, Wi-Fi, and GPS services — combined with the increasing availability of mobile broadband and Wi-Fi has created a growth market for advanced mobile applications.

What Will Drive Android Adoption?

Android is targeted primarily at developers, with Google and the OHA betting that the way to deliver better mobile software to consumers is by making it easier for developers to write it themselves.

As a development platform, Android is powerful and intuitive, letting developers who have never programmed for mobile devices create useful applications quickly and easily. It’s easy to see how innovative Android applications could create demand for the devices necessary to run them, particularly if developers write applications for Android because they can’t write them for other platforms.

Open access to the nuts and bolts of the underlying system is what’s always driven software development and platform adoption. The Internet’s inherent openness and neutrality have seen it become the platform for a multi-billion-dollar industry within 10 years of its inception. Before that, it was open systems like Linux and the powerful APIs provided as part of the Windows operating system that enabled the explosion in personal computers and the movement of computer programming from the arcane to the mainstream.

This openness and power ensure that anyone with the inclination can bring a vision to life at minimal cost. So far, that’s not been the case for mobile phones, and that’s why there are so few good mobile phone applications and fewer still available for free.

Corporations will also be attracted to Android for the level of control it offers. By using a popular enterprise programming language in Java, no licensing fees, and offering the level of access and control users demand, Android offers an excellent enterprise platform.

What Does It Have That Others Don’t?

Many of the features listed previously, such as 3D graphics and native database support, are also available in other mobile SDKs. Here are some of the unique features that set Android apart:

Google Map Applications: Google Maps for Mobile has been hugely popular, and Android offers a Google Map as an atomic, reusable control for use in your applications. The MapView widget lets you display, manipulate, and annotate a Google Map within your Activities to build map-based applications using the familiar Google Maps interface.
Background Services and Applications: Background services let you create applications that use an event-driven model, working silently while other applications are being used or while your mobile sits ignored until it rings, flashes, or vibrates to get your attention. Maybe it’s an application that tracks the stock market, alerting you to significant changes in your portfolio, or a service that changes your ring tone or volume depending on your current location, the time of day, and the identity of the caller.
Shared Data and Interprocess Communication: Using Intents and Content Providers, Android lets your applications exchange messages, perform processing, and share data. You can also use these mechanisms to leverage the data and functionality provided by the native Android applications. To mitigate the risks of such an open strategy, each application’s process, data storage, and files are private unless explicitly shared with other applications using a full permission-based security mechanism.
All Applications Are Created Equal Android doesn’t differentiate between native applications and those developed by third parties. This gives consumers unprecedented power to change the look and feel of their devices by letting them completely replace every native application with a third-party alternative that has access to the same underlying data and hardware. Every rule needs an exception and this one has two. The “unlock” and “in-call experience” screens can not be replaced in the initial SDK release.
P2P Interdevice Application Messaging: Android offers peer-to-peer messaging that supports presence, instant messaging, and interdevice/interapplication communication.

Changing the Mobile Development Landscape

Existing mobile development platforms have created an aura of exclusivity around mobile development. Whether by design or as a side-effect of the cost or complexity involved in developing native applications, most mobile phones will remain nearly identical to what they were when first unwrapped.

In contrast, Android allows, even encourages, radical change. As consumer devices, Android handsets ship with a core set of standard applications that consumers demand on a new phone, but the real power lies in the ability for users to completely change how their device looks, feels, and functions.

Android gives developers a great opportunity. All Android applications are a native part of the phone, not just software that’s run in a sandbox on top of it. Rather than writing small-screen versions of software that can be run on low-power devices, you can now write mobile applications that change the way people use their phones.

While Android will still have to compete with existing and future mobile development platforms as an open source developer framework, the strength of use of the development environment is strongly in its favor. Certainly its free and open approach to mobile application development, with total access to the phone’s resources, is a giant step in the right direction.

Introducing the Development Framework

With the PR job done, it’s time to look at how you can start developing applications for Android. Android applications are written using Java as a programming language but are executed using a custom virtual machine called Dalvik rather than a traditional Java VM.

Each Android application runs in a separate process within its own Dalvik instance, relinquishing all responsibility for memory and process management to the Android run time, which stops and kills processes as necessary to manage resources.

Dalvik and the Android run time sit on top of a Linux kernel that handles low-level hardware interaction including drivers and memory management, while a set of APIs provides access to all of the underlying services, features, and hardware.

What Comes in the Box

The Android software development kit (SDK) includes everything you need to start developing, testing, and debugging Android applications. Included in the SDK download are:

The Android APIs: The core of the SDK is the Android API libraries that provide developer access to the Android stack. These are the same libraries used at Google to create native Android applications.
Development Tools: To turn Android source code into executable Android applications, the SDK includes several development tools that let you compile and debug your applications.
The Android Emulator: The Android Emulator is a fully interactive Android device emulator featuring several alternative skins. Using the emulator, you can see how your applications will look and behave on a real Android device. All Android applications run within the Dalvik VM so that the software emulator is an excellent environment — in fact, as it is hardware-neutral, it provides a better independent test environment than any single hardware implementation.
Full Documentation: The SDK includes extensive code-level reference information detailing exactly what’s included in each package and class and how to use them. In addition to the code documentation, Android’s reference documentation explains how to get started and gives detailed explanations of the fundamentals behind Android development.
Sample Code: The Android SDK includes a selection of sample applications that demonstrate some of the possibilities available using Android, as well as simple programs that highlight how to use individual API features.
Online Support Despite its relative youth, Android has generated a vibrant developer community. The Google Groups at http://code.google.com/android/groups are active forums of Android developers with regular input from the Android development team at Google.

For those using the popular Eclipse IDE, Android has released a special plug-in that simplifies project creation and tightly integrates Eclipse with the Android Emulator and debugging tools.

Understanding the Android Software Stack

The Android software stack is composed of the elements shown in Figure 1-1 and described in further detail below it. Put simply, a Linux kernel and a collection of C/C++ libraries are exposed through an application framework that provides services for, and management of, the run time and applications.

Linux Kernel: Core services (including hardware drivers, process and memory management, security, network, and power management) are handled by a Linux 2.6 kernel. The kernel also provides an abstraction layer between the hardware and the remainder of the stack.
Libraries: Running on top of the kernel, Android includes various C/C++ core libraries such as libc and SSL, as well as:

A media library for playback of audio and video media
A Surface manager to provide display management
Graphics libraries that include SGL and OpenGL for 2D and 3D graphics
SQLite for native database support
SSL and WebKit for integrated web browser and Internet security

Android Run Time: What makes an Android phone an Android phone rather than a mobile Linux implementation is the Android run time. Including the core libraries and the Dalvik virtual machine, the Android run time is the engine that powers your applications and, along with the libraries, forms the basis for the application framework.

Core Libraries: While Android development is done in Java, Dalvik is not a Java VM. The core Android libraries provide most of the functionality available in the core Java libraries as well as the Android-specific libraries.
Dalvik Virtual Machine: Dalvik is a register-based virtual machine that’s been optimized to ensure that a device can run multiple instances efficiently. It relies on the Linux kernel for threading and low-level memory management.

Application Framework: The application framework provides the classes used to create Android applications. It also provides a generic abstraction for hardware access and manages the user interface and application resources.
Application Layer: All applications, both native and third party, are built on the application layer using the same API libraries. The application layer runs within the Android run time using the classes and services made available from the application framework.

next The Dalvik Virtual Machine

How to get more space on your hard drive

2012-05-13T07:02:00.000-07:00

previous Your customized desktop on a flash drive

There are a lot of disk cleaning software utilities available for analyzing disk usage and cleaning up folders. Making more space available on your hard drive helps to get the best performance out of your computer. Part of the process is to analyze how much space you have and which files or applications are using up your precious hard drive space. WinDirStart does all this and also cleans up your drive. Best of all it’s a portable app for Windows which can run straight from a USB flash drive.

You can download the free application from portableapps.com.

Previous article in this blog gives an overview of the Portableapps.com suite. If you already have the portableApps.com suite on your USB flash drive, click 'Options' on the PortableApps.com Menu and select 'Install a New App' to add WinDirStart to your suite.

Select the downloaded portable .paf.exe file you just downloaded. WinDirStart will be automatically added to the menu.

You can also install it separately, as a standalone app that’s not part of the suite. Now you can browse all of the folders on your computer and see what is really taking up all the space.

You'll be surprised to find unnecessary files and applications which are otherwise hidden. It actually breaks down the results of the analysis in a colorful, easy to understand manner. You can track almost all files.

Clicking 'Options' on the menu allows you to check out free space, see the file types, and a lot more. You can also view the files in Directory list, Treemap and Extension list.

The 'Clean up' option offers you various options to remove unwanted and unused files.

Little apps like WinDirStart on your USB flash drive, make flash drives more than just portable storage devices.

next Email on your USB flash drive

Your customized desktop on a flash drive

2012-05-13T04:59:00.000-07:00

previous How to run portable apps from USB flash drives

When you work between a desktop and a notebook, or between an office PC and a PC at home, don’t you wish you could be working with the same desktop, setup just the way you like it? That is now possible with MojoPac.
MojoPac is not a remote access or desktop sharing software, it’s virtualization software which lets you carry a customized version of your desktop on your USB flash drive so that you can view it on multiple systems.

The virtualization software, from RingCube technologies, creates an extra desktop on a USB flash drive. You can load most of your favorite apps on a virtual desktop and enjoy them by just plugging in the flash drive to multiple systems.

MojoPac software can be downloaded from the MojoPac website; the setup file is 21.6MB. During the installation process, select your USB flash drive as the location to install MojoPac.

After the installation process, a virtual XP desktop will be created on the USB flash drive. By default it will include Internet Explorer, Outlook Express and Windows Messenger, along with My Documents, My Pictures and My Music.

Next, register at the MojoPac website and create a username and password for the MojoPac desktop.

The whole interface is fantastic and can be easily customized to suite your needs and style. It has a task bar, start menu, icons, and desktop shortcuts, all very familiar to an XP powered computer.

Software, desktop apps, and files can be uploaded directly from the host computer. When you plug in your USB flash drive with MojoPac installed there will be two desktops and two ‘My Computer’ sections. Similarly, there will be two kinds of drives, those on the host computer drive and those setup as the MojoPac drives. A person working on the desktop of the host computer can access all the drives of MojoPac desktop, but someone working on the MojoPac desktop from a USB flash drive can only access limited drives of the host computer via the MojoPac desktop.

You can customize the desktop wallpaper and other settings, just like any other desktop. Music, video, and games can be uploaded to the MojoPac desktop. You can also upload software like RealPlayer, games, Firefox and web messengers.

Another benefit is that the USB flash drive is not blocked and can be still used for data transfer. But the best part is that the host computer is not stalled; it is easy to swap between host computer and the MojoPac desktop at anytime; there is a switch button near the top. The only disadvantage is that it’s a bit slow since the whole interface is operating from a USB flash drive.

MojoPac is a great way of carrying around a customized and familiar desktop so that you can use it on any PC. There is a lot of advanced virtualization software available in the market like Ceedo and VMware, but they have certain limitations. Ceedo requires you to purchase another product, Argo, to run a targeted application without modification. VMware is the best virtualization software out there, with many advanced features and support for different operating systems, but it is also a very expensive product costing nearly USD 6000. MojoPac is a great portable desktop option as it supports most popular software and replicates an entire desktop—plus, it’s free!

next How to get more space on your hard drive

How to run portable apps from USB flash drives

2012-05-13T04:49:00.000-07:00

previous How to set up an MP3 player on your USB drive

Life becomes a lot simpler when you can travel light with your little netbook or notebook and a USB flash drive, which can literally carry your entire digital world. The PortableApps.com Suite allows you to run applications directly from your USB flash drive, without the need for installation. Here's what this suite has to offer.

The PortableApps.com Suite offers a collection of portable apps, which are preconfigured to work from portable devices such as USB flash drives. The suite includes portable versions of Mozilla Firefox for web browser, Mozilla Thunderbird for email client, office suite, Mozilla Sunbird for calendar/scheduler, Pidgin for instant messaging, Clamwin for antivirus, CoolPlayer for audio player, Sudoku game, KeePass Password Safe for password manager, Sumatra PDF for PDF reader, minesweeper clone, backup utility and integrated menu.

You can install the PortableApps.com Suite and Platform from its homepage here http://portableapps.com/

Clicking the download button gives you the option of installing only the platform or one of the two suites, Suite Light and Suite Standard.

Suite Light replaces OpenOffice with AbiWord Portable. Suite Light can be installed on a 256MB+ devices and Suite Standard requires 512MB+ devices. You can download a suite of your choice. You need only to add the apps of your choice.

Install the suite in the root directory of your USB flash drive.

Now you can simply plug in your USB flash drive to launch the apps when you need to, and unplug it when you are through. It's that simple.
You can use the apps and delete those you don't need.
next Your customized desktop on a flash drive

How to set up an MP3 player on your USB drive

2012-05-09T21:39:00.000-07:00

previous How to keep your USB flash drive virus free

Winamp is a very mature free media player and with it and an Ontop USB flash drive, you can create a portable media player with your collection of MP3s that can then be used hassle free between computers.

The Winamp Media Player program is only 10.3MB, so it’s easily stored on a 4GB (or larger) USB flash drive. Winamp music doesn’t require a lot of memory and it plays all widely used audio and video file formats. To install the Winamp Media Player on your USB flash drive, download the free software to the hard drive of your computer. I used Winamp Media Player version 5.47

Install to the default folder c:\Program Files\Winamp on the computer

Plug your Ontop USB flash drive into the USB port of your computer.
Go to the c:\Program Files\Winamp location on your computer and copy the Winamp folder to USB flash drive.

Next you have to create a Winamp.cmd file inside the Winamp folder on the USB flash drive. To create a Winamp.cmd file, open a new Notepad file and type in the following text:
start Winamp.exe /inidir=ini

In Notepad, select File > Save As and save the file using the name winamp.cmd. To do this you will need to change the default file extension .txt to .cmd. You can now close Notepad.

Now double-click on the winamp.cmd file you’ve just created. This will open the Winamp Setup window.

On the step 2 of the Winamp Setup window, uncheck all of the file types that can be associated with Winamp.

Uncheck all of the file types

In the last step of the Winamp Setup window make sure you uncheck the ‘Yes, allow anonymous usage statistics (recommended)’. If you leave it checked Winamp will be sending periodical reports of the application to you via email.

After you click Finish, the Winamp Portal pops up with a message at the centre Add Media to Library. You can close the message and then copy your Playlist from your personal computer to your USB flash drive.

Close the Add Media to Library window

After doing all of this, every time you want to listen to your favourite songs on different computers, go to your Winamp folder on your USB flash drive and double click the Winamp icon to open the Winamp portal.

Double click on the Winamp file

Go to File > Play File and then select or queue the media files on your portable Winamp player to play your music files.

Click Play file or press L on the keyboard

Select the audio files from the USB flash drive

Winamp’s interface showing the song names, etc
By loading the portable version of Winamp Media Player with audio files onto an USB flash drive, you can carry your own music library with you and listen to them on any computer without having to worry about whether or not that computer has a media player installed.
next How to run portable apps from USB flash drives

How to keep your USB flash drive virus free

2012-05-09T04:33:00.000-07:00

previous How to format a drive with the NTFS file system

USB flash drives are the most convenient devices to use to carry and transfer data. While they are really useful, they are also prone to viruses. There are a few choices of major antivirus programs available, unfortunately, many of them don’t detect viruses on removable drives and may not permanently remove the viruses. USB Virus Scan is an USB virus cleaner, one of the best available.

The best part of USB Virus Scan is that it scans the USB drive, memory card and any storage media as soon as the USB drive is connected. If Virus Scan finds any virus, Trojan or any other kinds of threats, it cleans them immediately. The program scans the following areas:

Operating memory
Local drives
Removable media

USB Virus Scan is developed by USB Virus Scan International Inc and you can download a trial copy from their website usb-virus-scan.software.informer.com/2.3/download/?go. The trial copy will scan all the sectors of your computer including removable media, but to remove it, you’ll need to register the software. Registration costs $25.95 and it’s just a onetime cost unlike other antivirus programs. You don’t need to pay any renewal fee.

To install the program, double click the downloaded exe file and follow these steps:

Click ‘Next’

Select the ‘I accept the agreement’ radio button and click ‘Next’.

Use the ‘Browse’ button to select a different destination location other than the default location (if required) and click ‘Next’.

Click ‘Next’.

Click ‘Finish’ to complete the set up.

USB Virus Scan will then launch.
Its interface is compact and simple unlike other antivirus programs like AVG.

When you launch the program for the first time, it is advisable to perform a full scan of your system, including operating memory, all local drives and any removable media. If the scan detects any virus, clean the infected files immediately.

From the next time onwards you won’t need to scan the removal drives manually, as USB Virus Scan will automatically scan your removable drives as soon as you connect them to your computer. This will mean that you’ll be able to plug in a USB flash drive of a friend or colleague without worrying about whether or not it contains a virus. If it does, USB Virus Scan will find it and deal with it immediately.

next How to set up an MP3 player on your USB drive

How to format a drive with the NTFS file system

2012-05-09T03:24:00.000-07:00

previous Counteracting known risks

The most recent variants of Microsoft’s operating systems support NTFS, an advanced file system. Here’s a way to format your USB flash drive to the NTFS file system when it’s plugged into a PC running Windows XP. By doing so you’ll enjoy better encryption and a boost in performance of your USB flash drive.

Microsoft introduced NTFS, an advanced file system, with the Windows NT operating system and continued using it in Windows 2000, XP and Vista. NTFS is a standard file system that supports high performance, a self healing mechanism and file encryption. It also offers file compression and auditing, thereby providing larger volumes of storage than the older FAT file systems.

If you format a USB flash drive with the NTFS file system, it will increase the storage space by compressing the files. NTFS allows you to encrypt data on files and folders with the help of Windows XP’s integrated file encryption feature. The NTFS file system also allows you to grant and deny permission for individual files and folders. You can also set a disk quota.

You can’t format USB flash drives with the NTFS file system in Windows XP by default. But with a little tweaking, you can and here’s how. Before you follow these steps, make sure your important data is removed from the drive as the data will be permanently lost during formatting.

Insert the USB flash drive into the USB port. Right click on ‘My computer’ and then click ‘Properties’.

Select ‘Hardware’ and open ‘Device Manager’.
You can see the ‘Disk Drives’ tab here. Expand it to display all the drives.

Select your USB flash drive and double click to open ‘Properties’.
Go to ‘Policies’. The selected default option will be ‘Optimize for Quick removal’, change it to ‘Optimize for Performance’ and click ‘OK’.

Now close the window and open ‘My computer’. Right click on the USB flash drive and select ‘Format’.

The Format box will now have the option to format with the NTFS file system or FAT and FAT32 systems. (The options would have been limited to FAT and FAT32 if the steps above had not been taken).

Select ‘NTFS file system’ and start formatting.

Now your USB drive will be formatted with the NTFS format.

With NTFS formatting, your files will be more secure and you can also enjoy more space for your files and folders.
next How to keep your USB flash drive virus free

Counteracting known risks

2012-05-08T23:10:00.000-07:00

previous A recycle bin for USB flash drives

USB flash drives have definitely made data transfer and storage very convenient. To make the most out of these tiny yet powerful devices it’s important to understand the possible risks associated with using them and to have knowledge of how to overcome those risks.

Getting a virus is perhaps the most common risk associated with USB flash drives. Kids (and adults!) swapping games, images and files can end up infecting the family computer. USB flash drives are often connected to various mobile devices and different networks which increase the chances of them being infected with viruses. So, how do you protect your USB flash drive from viruses?

Unfortunately, the Autorun of a USB drive may be where a virus can be hidden. Windows uses Autorun to give you the option to explore, open or copy the contents of a USB drive. If this is enabled, Windows will read the flash drive automatically and inadvertently infect the computer with the virus in the process. Disabling Autorun may prevent this.

It is important to scan your USB flash drive before transferring any data to or from your USB flash drive. Most of the time this keeps your USB drives clean. You can try various free antivirus software such as Panda, Avast, and AVG.

Another possible risk for USB flash drives is the corruption of data. Do you religiously follow the 'Safely Remove your USB Device' instructions on your computer or other devices? If you are in the habit of simply pulling out the USB flash drive from the USB port as soon as you’ve finished, you could end up losing important data.

Even if you think that you have closed all the files on the flash drive, it is possible that the device is still active in the background without any visible indication. If you have important data on your USB flash drive and no back up, you might lose the data. Disconnecting the flash drive is so simple - right click on it and select 'Safely Remove Hardware' or double click the icon in the system tray of your computer.

If you have lost data on a USB flash drive, there are various data recovery tools and simple system tweaks to recover it.

What about data lost due to the loss of the device itself? A USB drive carrying nearly 16,000 student and employee social security numbers was stolen from Roane State Community College in Harriman, Tennessee, causing embarrassment for authorities. Encryption of data can prevent such data from being accessed, even if a drive is stolen. There are free tools available to encrypt data on a USB flash drive.

next How to format a drive with the NTFS file system

A recycle bin for USB flash drives

2012-05-08T22:37:00.000-07:00

previous Ten USB Flash Drive Tips

iBin is a small application that works as a portable Recycle Bin for USB drives when they’re connected to a computer (PC, notebook, netbook, etc). iBin is compatible with all versions of Windows and can be used with various removable storage devices.

To install iBin on your Ontop USB flash drive, download the iBin zip file from http://www.autohotkey.net/~FirstToyLab/project_iBin_download.htm to your USB flash drive.

Extract the zip file in the usual way.

Double click on the iBin.exe file. The utility will create a container in the USB flash drive’s root folder to store deleted files. When you install iBin on the USB flash drive, it can be accessed from the system tray of your Windows operating system.

Now that iBin is installed, when you delete a file or folder from your USB flash drive, iBin pops up with a message to give you the option to delete the file permanently, or put it to the iBin so that it can be retrieved, if required in the future.

To take a look at what’s in the iBin at any time, click on the iBin icon from the system tray. The Dumping Management window will pop up, showing you all the deleted files that are being stored on the USB flash drive, just in case you change your mind. Just like the Windows Recycle Bin, you can empty the iBin completely.

The iBin Custom Options window allows you to setup your own preferences. If you wish to increase or decrease the space limit of the iBin container, just move the slider to set the size limit to be anything from 1 % to 50% of the total free space on the USB flash drive.

If the iBin container exceeds the allocated space the Auto-Cleaner deletes the data automatically. If you delete a file from the USB flash drive, which is bigger than the size of the iBin container, it won’t store it in the iBin.
next Counteracting known risks

Ten USB Flash Drive Tips

2012-05-08T06:30:00.000-07:00

There is a lot more you can do with a USB flash drive other than storage and data transfer. The latest USB flash drives offer ample space and ultrafast data transfers for multiple desktop applications, hi-definition media files, as well as routine data transfers. The top ten USB flash drive tips help you get the best use out of your USB flash drive.

Firstly, did you know that there are a host of portable applications that can be stored on USB flash drives and used from USB flash drives without being installed on a computer or portable device? We show you how to setup an MP3 player with your collection, handle email between computers, and access productivity apps including a full office suite, for free.

Of course using a USB flash drive is not without risks, unless you know how to set it up properly. We explain how to format a drive with the NTFS file system, protect it from viruses and get the jump on common concerns like data corruption.

To personalize your use of your USB flash drive, we’ll also show you how to customize your desktop and then take it with you to any PC. We’ll also explain how to set up a Recycle Bin function on a USB flash drive.

USB flash drives are also great maintenance tools for your computer. They can be used for disk usage analysis and even to install an operating system!

Turn a USB flash drive into bootable media

If you still think that pen drives are used only to store and carry data, you may need to think again. Netbooks and other MIDs are fantastically convenient devices, but how do you install operating systems on them without an optical drive? The solution? A USB flash drive!

Preparing the USB drive

Before you get started, make sure you have access to a Windows Vista or Windows 7 machine.

Connect the USB flash drive to the USB port and follow the steps below:

Click Start > Accessories and hover on Command Prompt.

Right click on the Command Prompt and select Run as administrator.

Type ‘diskpart' and press the Enter key. This will initiate the built in Windows disk partitioning utility.

Type 'list disk' and press the Enter key. Identify which disk is your USB flash drive.

In this example, disk 7 is my USB flash drive so I will type 'select disk 7' and press Enter.

Type 'clean' and press Enter to clean the connected USB flash drive.

Type 'create partition primary’ and hit Enter.

Type 'select partition 1' and press Enter.

Type 'active' and press Enter to make the selected partition active.

Type 'format fs=fat32' and press Enter to format the partition using the FAT32 file system.

To assign a drive letter, type 'assign' and press Enter.
Type 'exit' and you are done!
Once you have successfully executed all the steps mentioned above, you have turned your USB flash drive into bootable storage media. You can even still use the flash drive for storing data as per usual at the same time!
To get it ready to install an OS, put the operating system DVD in a computer’s DVD drive and copy all the files from the DVD to the USB flash drive. If you have an image of the OS instead of a DVD, use a third party program like MagicISO to mount the image and copy all the files to the USB flash drive.
To use the USB flash drive as an installation media, set the first boot device to USB flash drive from the BIOS and then go forward with the installation just as you would if you were using the DVD!
next A recycle bin for USB flash drives