Source of information

The source of all the post is from this amaizing blog : http://saigeethamn.blogspot.in 
Thanks Sai Geetha's for your information, and sorry if I don't write the source of information before.
best regards,
Mariano!

Designing For Android

Android Smartphones And Display Sizes

When starting any digital design project, understanding the hardware first is a good idea. For iOS apps, that would be the iPhone and iPod Touch. Android, meanwhile, spans dozens of devices and makers. Where to begin?

The old baseline for screens supported for Android smartphone devices was the T-Mobile G1, the first commercially available Android-powered device which has an HVGA screen measuring 320 x 480 pixels.

HVGA stands for “half-size video graphics array” (or half-size VGA) and is the standard display size for today’s smartphones. The iPhone 3GS, 3G and 2G use the same configuration.

T-Mobile G1, the first commercially available Android device and the baseline for Android screen specifications.

To keep things simple, Android breaks down physical screen sizes (measured as the screen’s diagonal length from the top-left corner to bottom-right corner) into four general sizes: small, normal, large and xlarge.

Two common Android screen sizes. (Image from Google I/O 2010)

320 × 480 is considered a “normal” screen size by Android. As for “xlarge,” think tablets. However, the most popular Android smartphones today have WVGA (i.e. wide VGA) 800+ × 480-pixel HD displays. So, what’s “normal” is quickly changing. For now, we’ll say that most Android smartphones have large screens.

Diagram of various screen configurations available from emulator skins in the Android SDK. (Image: Android Developers website)

The variety of display sizes can be challenging for designers who are trying to create one-size-fits-all layouts. I’ve found the best approach is to design one set of layouts for 320 x 533 physical pixels and then introduce custom layouts for the other screen sizes.

While this creates more work for both the designer and developer, the larger physical screen size on bigger devices such as the Motorola Droid and HTC Evo might require changes to the baseline layouts that make better use of the extra real estate.

WHAT YOU NEED TO KNOW ABOUT SCREEN DENSITIES

Screen sizes are only half the picture! Developers don’t refer to a screen’s resolution, but rather its density. Here’s how Android defines the terms in its Developers Guide:

• Resolution
  The total number of physical pixels on a screen.
• Screen density
  The quantity of pixels within a physical area of the screen, usually referred to as DPI (dots per inch).
• Density-independent pixel (DP)
  This is a virtual pixel unit that you would use when defining a layout’s UI in order to express the layout’s dimensions or position in a density-independent way. The density-independent pixel is equivalent to one physical pixel on a 160 DPI screen, which is the baseline density assumed by the system of a “medium”-density screen. At runtime, the system transparently handles any scaling of the DP units as necessary, based on the actual density of the screen in use. The conversion of DP units to screen pixels is simple: pixels = DP * (DPI / 160). For example, on a 240 DPI screen, 1 DP equals 1.5 physical pixels. Always use DP units when defining your application’s UI to ensure that the UI displays properly on screens with different densities.

It’s a bit confusing, but this is what you need to know: Like screen sizes, Android divides screen densities into four basic densities: ldpi (low), mdpi (medium), hdpi (high), and xhdpi (extra high). This is important because you’ll need to deliver all graphical assets (bitmaps) in sets of different densities. At the very least, you’ll need to deliver mdpi and hdpi sets for any smartphone apps.

What this means is all bitmap graphics need to be scaled up or down from your baseline (320 x 533) screen layouts (note: there is also a way for parsing SVG files that provides a way to scale vector art on different screens sizes and densities without loss of image quality).

The bitmap requirement is similar to preparing graphics for print vs. the Web. If you have any experience with print production, you’ll know that a 72 PPI image will look very pixelated and blurry when scaled up and printed. Instead, you would need to redo the image as a vector image or use a high-resolution photo and then set the file’s resolution at around 300 PPI in order to print it without any loss of image quality. Screen density for Android works similar, except that we’re not changing the file’s resolution, only the image’s size (i.e. standard 72 PPI is fine).

Let’s say you took a bitmap icon measuring 100 × 100 pixels from one of the screens of your baseline designs (remember the “baseline” is a layout set at 320 × 480). Placing this same 100 × 100 icon on a device with an lDPI screen would make the icon appear big and blurry. Likewise, placing it on a device with an hDPI screen would make it appear too small (due to the device having more dots per inch than the mDPI screen).

An application without density support. (Image: Android Developers website)

To adjust for the different device screen densities, we need to follow a 3:4:6:8 scaling ratio between the four density sizes. (For the iPhone, it’s easy: it’s just a 2:1 ratio between the iPhone 4 and 3GS.) Using our ratios and some simple math, we can create four different versions of our bitmap to hand off to our developer for production:

• 75 × 75 for low-density screens (i.e. ×0.75);
• 100 × 100 for medium-density screens (our baseline);
• 150 × 150 for high-density screens (×1.5);
• 200 × 200 for extra high-density screens (×2.0). (We’re concerned with only lDPI, mDPI and hDPI for Android smartphone apps.)

The final graphic assets would appear like this using the four different screen densities.

After you’ve produced all of your graphics, you could organize your graphics library as follows:

The suggested organization and labeling of asset folders and files. In preparing our star graphic, all file prefixes could be preceded by the name ic_star, without changing the names of the respective densities.

You might be confused about what PPI (pixels per inch) to set your deliverables at. Just leave them at the standard 72 PPI, and scale the images accordingly.

Using Android Design Patterns

Clients often ask whether they can use their iPhone app design for Android. If you’re looking for shortcuts, building an app for mobile Web browsers using something likeWebkit and HTML5 is perhaps a better choice. But to produce a native Android app, the answer is no. Why? Because Android’s UI conventions are different from iPhone’s.

The big difference is the “Back” key, for navigating to previous pages. The Back key on Android devices is fixed and always available to the user, regardless of the app. It’s either a physical part of the device or digitally fixed to the bottom of the screen, independent of any app, as in the recently released Android 3.0 for tablets (more on this later).

The hard “Back” key on a smartphone running Android 2.0.

The presence of a Back key outside of the app itself leaves space for other elements at the top of the screen, such as a logo, title or menu. While this navigational convention differs greatly from that of iOS, there are still other differentiators that Android calls “design patterns.” According to Android, a design pattern is a “general solution to a recurring problem.” Below are the main Android design patterns that were introduced with version 2.0.

DASHBOARD

This pattern solves the problem of having to navigate to several layers within an app. It provides a launch pad solution for rich apps such as Facebook, LinkedIn and Evernote.

The dashboard design pattern, as used by Facebook and LinkedIn.

ACTION BAR

The action bar is one of Android’s most important design patterns and differentiators. It works very similar to a conventional website’s banner, with the logo or title typically on the left and the navigation items on the right. The action bar’s design is flexible and allows for hovering menus and expanding search boxes. It’s generally used as a global feature rather than a contextual one.

The action bar design pattern as used by Twitter.

SEARCH BAR

This gives the user a simple way to search by category, and it provides search suggestions.

The search bar design pattern as used in the Google Search app.

QUICK ACTIONS

This design pattern is similar to iOS’ pop-up behavior that gives the user additional contextual actions. For example, tapping a photo in an app might trigger a quick action bar that allows the user to share the photo.

The quick action design pattern as used by Twitter.

COMPANION WIDGET

Widgets allow an app to display notifications on the user’s launch screen. Unlike push notifications in iOS, which behave as temporary modal dialogs, companion widgets remain on the launch screen. (Tip: to select a widget for your Android device, simply tap and hold any empty space on one of the launch screens.)

Companion widgets by Engadget, New York Times and Pandora.

Using established design patterns is important for keeping the experience intuitive and familiar for your users. Users don’t want an iPhone experience on their Android device any more than a Mac user wants a Microsoft experience in their Mac OS environment. Understanding design patterns is the first step to learning to speak Android and designing an optimal experience for its users. Your developers will also thank you!

Android Design Deliverables

OK, so you’ve designed your Android app and are ready to make it a reality. What do you need to hand off to the developer? Here’s a quick list of deliverables:

1. Annotated wireframes of the user experience based on the baseline large screen size of 320 x 533 physical pixels. Include any additional screens for instances where a larger or smaller (320 x 480) screen size requires a modified layout or a landscape version is required.
2. Visual design mockups of key screens for WVGA large size (320 x 533) screens (based on a WVGA 800 x 480 hdpi physical pixel screen size) in addition to any custom layouts needed for other screen sizes.
3. Specifications for spacing, font sizes and colors, and an indication of any bitmaps.
4. A graphics library with lDPI, mDPI and hDPI versions of all bitmaps saved as transparent PNG files.
5. Density-specific app icons, including the app’s launch icon, as transparent PNG files. Android already provides excellent tips for designers on this topic, along with some downloads, including graphic PSD templates and other goodies.

How To Take Screenshots

Your product manager has just asked for screenshots of the developer’s build. The developer is busy and can’t get them to you until tomorrow. What do you do?! As of this writing, Android has no built-in way to take screenshots (bummer, I know). The only way is to just deal with it, and that means pretending to be a developer for a while and downloading some really scary software. Let’s get started!

The following software must be downloaded:

1. All USB drivers for your Android device,
2. Android software development kit (SDK),
3. Java SE SDK

Then, on your computer:

1. Extract the USB drivers to a folder on your desktop,
2. Extract the Android SDK to a folder on your desktop,
3. Install the Java SE SDK.

On your Android device:

1. Open “Settings” (you’ll find it in the apps menu),
2. Tap on “Applications,”
3. Tap on “Development,”
4. Check the box for “USB debugging.”

Now, for the fun part:

1. Connect your Android device to your computer via USB. Windows users: allow Windows to install all drivers. One of the drivers may not be found and will require you to go to the Window’s Device Manager under the Control Panel. There, you can locate the device (having a yellow warning icon next to it) and right-click on it.
2. Choose to “update/install” the driver for your device.
3. Go to your desktop. Open the Android SDK folder and select SDK Setup.exe.
4. Allow it to automatically refresh its list of the operating system SDKs that are available, and select to install all packages.
5. Once finished, exit the application.
6. Go back to the opened Android SDK folder on your desktop, and open the “Tools” folder.
7. Click on the file ddms to open the Dalvik Debug Monitor.
8. Select your device from the “Name” pane.
9. In the application’s top menu, open the “Device” menu, and choose “Screen capture…” A Device Screen Capture window will open, and you should see the launch screen of your Android device.

The Dalvik Debut Monitor.

To navigate:

1. Grab your Android device and navigate to any page. Go back to your computer and select “Refresh” in the Device Screen Capture window. The current screen from your Android device should appear.
2. If you’re on a Mac, you can just do the old Shift + Command + 4 trick to take a screenshot. In Windows, you can copy and paste it into one of the Windows media applications.

About Android Tablets

At CES 2011, companies rained down Android tablets, with an array of screen sizes. However, after a quick review of the most popular ones, we can conclude that the two important screen sizes to focus on in terms of physical pixels are 1280 × 800 and 800 × 480.

With the Android 3.0 Honeycomb release, Google provided device makers with an Android UI made for tablets. Gone is the hard “Back” button, replaced by an anchored software-generated navigation and system status bar at the bottom of the screen.

The anchored navigation and system bar in Android 3.0.

Android 3.0 got a visual refresh, while incorporating all of the design patterns introduced in Android 2.0. One of the major differences with 3.0 is the Action Bar which has been updated to include tabs, drop-down menus or breadcrumbs. The action bar can also change its appearance to show contextual actions when the user selects single or multiple elements on a screen.

The new action bar with tabs, introduced in Android 3.0.

Another new feature added to the Android framework with 3.0 is a mechanism called “fragments.” A fragment is a self-contained component in a layout that can change size and position depending on the screen’s orientation and size. This further addresses the problem of designing for multiple form factors by giving designers and developers a way to make their screen layout components elastic and stackable, depending on the screen limitations of the app. Screen components can be stretched, stacked, expanded and collapsed, and revealed and hidden.

Diagram showing examples of how fragments can be used.

The next Android release, scrumptiously dubbed Ice Cream Sandwich, promises to bring this functionality to Android smartphones as well, giving designers and developers the option to build an app using a one-size-fits-all strategy. This could be a paradigm shift for designers and developers, who will need to learn to think of app design in terms of puzzle pieces that can be stretched, stacked, expanded or hidden to fit the form factor. In short, this will allow one Android OS to run anywhere (with infinite possibilities!).

A WORD OF ADVICE

Do get your hands on an Android phone and tablet, and spend some time downloading apps and exploring their interfaces. In order to design for Android, you have to immerse yourself in the environment and know it intimately. This might sound obvious, but it’s always surprising to hear when even the product manager doesn’t have an Android device.

Online Resources

Here are some links to online resources I’ve found especially useful:

PRESENTATIONS

• Android Design Patterns
• Android User Interface Design Tips

VIDEOS

• Android UI Design Patterns (Google I/O 2010)
• Designing and Implementing Android UIs for Phones and Tablets (Google I/O 2011)

DOCUMENTS

• Comparison of Android Devices

BLOGS

• Designer’s Guide to Supporting Multiple Android Device Screens
• Android UI Design Patterns
• Android Patterns

PRODUCT REVIEWS

• Best Android Phones (CNET, May 2011)
• Best Android Tablets (CNET, May 2011)

ANDROID DEVELOPERS

• Supporting Multiple Screens
• Icon Design
• Android 3.0 Platform Highlights

OTHER

• Android App Developers GUI Kits, Icons, Fonts and Tools

Getting started Eclipse with Android

There’s a lot to get excited about in mobile application development today. With increasingly sophisticated hardware, tablet PCs and a variety of software platforms (Symbian OS, iOS, WebOS, Windows Phone 7…), the landscape for mobile developers is full of opportunities — and a little complex as well.

So much choice can be overwhelming when you just want to get started building mobile applications. Which platform should you choose? What programming language should you learn? What kit do you need for your planned project? In this tutorial, you’ll learn how to start writing applications forAndroid, the open-source mobile operating system popularized by Google.

Why Develop for Android?

Android is an open-source platform based on the Linux kernel, and is installed onthousands of devices from a wide range of manufacturers. Android exposes your application to all sorts of hardware that you’ll find in modern mobile devices — digital compasses, video cameras, GPS, orientation sensors, and more.

Android’s free development tools make it possible for you to start writing software at little or no cost. When you’re ready to show off your application to the world, you can publish it to Google’s Android Market. Publishing to Android Market incurs a one-off registration fee (US $25 at the time of writing) and, unlike Apple’s App Store which famously reviews each submission, makes your application available for customers to download and buy after a quick review process — unless the application is blatantly illegal.

Here are a few other advantages Android offers you as a developer:

• The Android SDK is available for Windows, Mac and Linux, so you don’t need to pay for new hardware to start writing applications.
• An SDK built on Java. If you’re familiar with the Java programming language, you’re already halfway there.
• By distributing your application on Android Market, it’s available to hundreds of thousands of users instantly. You’re not just limited to one store, because there are alternatives, too. For instance, you can release your application on your own blog. Amazon have recently been rumoured to be preparing their own Android app store also.
• As well as the technical SDK documentation, new resources are being published for Android developers as the platform gains popularity among both users and developers.

Enough with the talk — let’s get started developing for Android!

Installing Eclipse and the Android SDK

The recommended environment for developing Android applications is Eclipse with the Android Development Toolkit (ADT) plugin installed. I’ll summarize the process here. If you need more detail, Google’s own developer pages do a good job of explaining the installation and configuration process.

• Download the Android SDK for your platform (Windows, Mac OS X, or Linux).
• Extract the downloaded file to somewhere memorable on your hard drive (on Linux, I use /opt/local/).
• If you don’t already have Eclipse installed, download and install the Eclipse IDE for Java Developers package. For programming, Google recommends using Eclipse 3.5 (Galileo).
• Run Eclipse and choose Help->Install New Software.
• Click Add in the Available Software window.
• Enter Android Development Tools in the Name field, and https://dl-ssl.google.com/android/eclipse/ in the Location field.
• Click OK and check Developer Tools in the list of available software. This will install the Android Development Tools and DDMS, Android’s debugging tool.

Large image
• Click Next and Finish to install the plugin. You’ll need to restart Eclipse once everything is installed.
• When Eclipse restarts, choose Window->Preferences and you should seeAndroid listed in the categories.
• You now need to tell Eclipse where you’ve installed the Android SDK. ClickAndroid and then Browse to select the location where you extracted the SDK files. For example, /opt/local/android-sdk.
  
  Large view
• Click OK to have Eclipse save the location of your SDK.

Targeting Android Platforms

Before you can start writing applications for Android, you need to download the SDK platforms for the Android devices for which you want to develop apps. Each platform has a different version of the Android SDK that may be installed on users’ devices. For versions of Android 1.5 and above, there are two platforms available: Android Open Source Project and Google.

The Android Open Source Project platforms are open source, but do not include Google’s proprietary extensions such as Google Maps. If you choose not to use the Google APIs, Google’s mapping functionality won’t be available to your application. Unless you have a specific reason not to, I’d recommended you to target one of the Google platforms, as this will allow you to take advantage of Google’s proprietary extensions.

• Choose Window->Android SDK and AVD Manager.
• Click Available Packages in the left column and check the repository to show a list of the available Android platforms.
• You can choose which platforms to download from the list, or leave everything checked to download all the available platforms. When you’re done, clickInstall Selected and follow the installation instructions.
  Large image

Once everything has been successfully downloaded, you’re ready to start developing for Android.

Creating a New Android Project

Eclipse’s New Project Wizard can create a new Android application for you, generating files and code that are ready to run right out of the box. It’s a quick way to see something working, and a good starting point from which to develop your own applications:

• Choose File->New->Project…
• Choose Android Project
• In the New Project dialog, enter the following settings:

  1	Project Name: BrewClock

  2	Build Target: Google Inc. 1.6 (Api Level 4)

  3	Application Name: BrewClock

  4	Package Name: com.example.brewclock

  5	Create Activity: BrewClockActivity

  6	Min SDK Version: 4

  

After clicking Finish, Eclipse will create a new Android project that’s ready to run. Notice you told Eclipse to generate an Activity called BrewClockActivity? This is the code that Android actually uses to run your application. The generated code will display a simple ‘Hello World’ style message when the application runs.

PACKAGES

The package name is an identifier for your application. When the time comes and you are willing to publish on Android Market, it’s exactly this identifier that will be used to track your application for updates, so it’s important to make sure it’s unique. Although we’re using the com.example.brewclock namespace here, for a real application it’s best to choose something likecom.yourcompanyname.yourapplication.

SDK VERSIONS

The Min SDK Version is the earliest version of Android on which your application will run. With each new release of Android, the SDK adds and changes methods. By choosing an SDK version, Android (and the Android Market) knows that your application will only run on devices with a version of Android later or equal than the specified version.

Running Your Application

Now let’s try running the application in Eclipse. As this is the first run, Eclipse will ask what type of project you are working on:

• Choose Run->Run or press Ctrl+F11.
• Choose Android Application and click OK.

Eclipse will now try to run the application on an Android device. At the moment, though, you don’t have any Android devices running, so the run will fail and you’ll be asked to create a new Android Virtual Device (AVD).

ANDROID VIRTUAL DEVICES

An Android Virtual Device (AVD) is an emulator that simulates a real-world Android device, such as a mobile phone or Tablet PC. You can use AVDs to test how your application performs on a wide variety of Android devices, without having to buy every gadget on the market.

You can create as many AVDs as you like, each set up with different versions of the Android Platform. For each AVD you create, you can configure various hardware properties such as whether it has a physical keyboard, GPS support, the camera resolution, and so on.

Before you can run your application, you need to create your first AVD running the target SDK platform (Google APIs 1.6).

Let’s do that now:

• If you haven’t tried to run your application yet, click Run now (or hit Ctrl+F11)
• When the target device warning pops up, click Yes to create a new AVD.
• Click New in the Android SDK and AVD Manager dialog that appears.
• Enter the following settings for the AVD:

  1	Name: Android_1.6

  2	Target: Google APIs (Google Inc.) - API Level 4

  3	SD Card Size: 16 MiB

  4	Skin Built In: Default (HVGA)

• Click Create AVD to have Android build your new AVD.
• Close the Android SDK and AVD Manager dialog.

RUNNING THE CODE

Try running your application again (Ctrl+F11). Eclipse will now build your project and launch the new AVD. Remember, the AVD emulates a complete Android system, so you’ll even need to sit through the slow boot process just like a real device. For this reason, once the AVD is up and running, it’s best not to close it down until you’ve finished developing for the day.

When the emulator has booted, Eclipse automatically installs and runs your application: