Application Structure

src

 ·         This folder contains all packages and source code i.e., .Java classes

gen

 ·         Android framework will generate R.java class which we can find in this folder.

R.java:

android.R.java is not just where XML ids are stored. It also contains access to resources - such as drawables, layouts, strings, arrays, and basically anything you can declare in resources.

Personally I find that it is useful when using Eclipse. I can simply type findViewById(R.id. and Eclipse will show a tooltip with a list of options to choose from.

However at a platform level, I would say that the hardcoded id variables help prevent errors when using Strings to identify resources -- something that can be debuggable while programming (or during compilation, rather than runtime).

Assets:

Android offers one more directory where you can keep files which also will be included in package. This directory called /assets. The difference between /res and /assets is that Android doesn’t generate IDs for assets content. You need to specify relative path and name for files inside /assets. I am going to show simple example which shows how you can access /assets content.

res:

·         drawable-hdpi: To keep high density pixel images

·         drawable-ldpi: To keep low density pixel images

·         drawable-mdpi: To keep medium density pixel images

·         layout: It contains all .xml files which represents user interfaces

·         values: It contains all .xml files which represents static data for an Android applications.  

String Resources:

A string resource provides text strings for your application with optional text styling and formatting. There are three types of resources that can provide your application with strings:

String:XML resource that provides a single string.

String Array:XML resource that provides an array of strings.

Quantity Strings (Plurals):XML resource that carries different strings for different quantities of the same word or phrase.

All strings are capable of applying some styling markup and formatting arguments.

Android Manifest.xml

• Navigation, completion, validation, find usages and rename support for activity, intent, service, receiver and instrumentation classes
• Completion for action and category names in intent filters
• Completion of permission IDs in uses-permission tags

Navigation, validation and completion of resource references from android:label and          android:icon values

—  Activity Manager: This controls the life cycle of applications and maintains a common “back stack” for user navigation.

—  Services:

1) Windows Manager: The window manager creates display surfaces for the application. It is Responsible for organizing the screen and display of different layers of application.

2) Telephony Manager: Provides core telephoning functionalities.

3) Resource manager: Resources are anything that goes with your program that is not code.

4) Location manager: An Android phone always knows where it is.

5) Notification manager: Events such as arriving messages, appointments, proximity alerts, alien invasions, and more can be presented in an unobtrusive fashion to the user.

—  Content providers: These objects encapsulate data that needs to be shared between applications, such as contacts.

—  View System: Enabling applications to access data from other applications or to share their own data .

Activity:

An activity is a single, focused thing that the user can do. Almost all activities interact with the user, so the Activity class takes care of creating a window for you in which you can place your UI with setContentView(View). While activities are often presented to the user as full-screen windows, they can also be used in other ways: as floating windows (via a theme with windowIsFloating set) or embedded inside of another activity (using ActivityGroup). There are two methods almost all subclasses of Activity will implement:

• onCreate(Bundle) is where you initialize your activity. Most importantly, here you will usually call setContentView(int) with a layout resource defining your UI, and using findViewById(int) to retrieve the widgets in that UI that you need to interact with programmatically.
• onPause() is where you deal with the user leaving your activity. Most importantly, any changes made by the user should at this point be committed (usually to the ContentProvider holding the data).

Activity Lifecycle:

Activities in the system are managed as an activity stack. When a new activity is started, it is placed on the top of the stack and becomes the running activity -- the previous activity always remains below it in the stack, and will not come to the foreground again until the new activity exits.

An activity has essentially four states:

• If an activity in the foreground of the screen (at the top of the stack), it is active or running.
• If an activity has lost focus but is still visible (that is, a new non-full-sized or transparent activity has focus on top of your activity), it is paused. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.
• If an activity is completely obscured by another activity, it is stopped. It still retains all state and member information, however, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.
• If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.

The following diagram shows the important state paths of an Activity. The square rectangles represent callback methods you can implement to perform operations when the Activity moves between states. The colored ovals are major states the Activity can be in.

There are three key loops you may be interested in monitoring within your activity:

• The entire lifetime of an activity happens between the first call to onCreate(Bundle) through to a single final call to onDestroy(). An activity will do all setup of "global" state in onCreate(), and release all remaining resources in onDestroy(). For example, if it has a thread running in the background to download data from the network, it may create that thread in onCreate() and then stop the thread in onDestroy().
• The visible lifetime of an activity happens between a call to onStart() until a corresponding call to onStop(). During this time the user can see the activity on-screen, though it may not be in the foreground and interacting with the user. Between these two methods you can maintain resources that are needed to show the activity to the user. For example, you can register a BroadcastReceiver in onStart() to monitor for changes that impact your UI, and unregister it in onStop() when the user no longer sees what you are displaying. The onStart() and onStop() methods can be called multiple times, as the activity becomes visible and hidden to the user.
• The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time the activity is in front of all other activities and interacting with the user. An activity can frequently go between the resumed and paused states -- for example when the device goes to sleep, when an activity result is delivered, when a new intent is delivered -- so the code in these methods should be fairly lightweight.

The entire lifecycle of an activity is defined by the following Activity methods. All of these are hooks that you can override to do appropriate work when the activity changes state. All activities will implement onCreate(Bundle) to do their initial setup; many will also implement onPause() to commit changes to data and otherwise prepare to stop interacting with the user. You should always call up to your superclass when implementing these methods.

 public class Activity extends ApplicationContext {

     protected void onCreate(Bundle savedInstanceState);

     protected void onStart();

     protected void onRestart();

     protected void onResume();

     protected void onPause();

     protected void onStop();

     protected void onDestroy();

 }