Sunday, October 9, 2011

Things to know before starting Android App Development

Android is a software stack for mobile devices that includes an operating system, middleware and key applications. The Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language. Before jumping into the Android Development, knowing the background of the platform might be helpful.
A Brief History of Android
Android was first publicly noticed in 2005 when Google acquired a small startup called Android, Inc. In 2008, the release of version 1.0 of Android put an end to all speculation, and Android became the new challenger on the mobile market. Since then, it’s been battling it out with already established platforms such as iOS (then called iPhone OS) and BlackBerry, and its chances of winning look rather good.
Why Android?

1. Because Android is open source.
2. Handset manufacturers have a low barrier of entry when using the new platform.
3. They can produce devices for all price segments, modifying Android itself to accommodate the processing power of a specific device.
4. Android is therefore not limited to high-end devices but can also be deployed to low budget devices, thus reaching a wider audience.
5. A crucial ingredient for Android’s success was the formation of the Open Handset Alliance (OHA) in late 2007. The OHA includes companies such as HTC, Qualcomm, Motorola, and NVIDIA, which collaborate to develop open standards for mobile devices. Although Android’s core is developed mainly by Google, all the OHA members contribute to its source in one form or another.
Since its release in 2008, Android has received seven version updates which are as follows:
1. Version 1.1 (No code name)
2. Cupcake (Version 1.5 )
3. Donut (Version 1.6 )
4. Eclair (Version 2.0)
5. Froyo (Version 2.2)
6. Gingerbread (Version 2.3)
7. Honeycomb (Version 3.0)
8. Icecream Sandwich (Version 4.0) to be released on 11th Oct 2011

Android System is practically a complete development environment with a complete software stack which contains the operating system (based on the Linux 2.6 kernel), a middle-layer application framework, a set of C/C++ libraries used by various components of the system to which we have access through the application framework mentioned above, and some core applications that you can also have access to, programmatically.
Having the Linux 2.6 Kernel at the core of the operating systems makes the platform pretty safe and well established when considering the Linux Kernel process management, memory management, networking stack, and driver model have undergone a long and arduous process of R&D for years.
The most important thing to know is that each application runs in its own safe-box: it has a unique user ID assigned by the OS, a unique process and therefore a unique virtual machine. No application can access the files or the memory of another one without being allowed to do so by Android’s kernel system.


• Application framework enabling reuse and replacement of components
• Dalvik virtual machine optimized for mobile devices
• Integrated browser based on the open source WebKit engine
• Optimized graphics powered by a custom 2D graphics library; 3D graphics based on the OpenGL ES 1.0 specification (hardware acceleration optional)
• SQLite for structured data storage
• Media support for common audio, video, and still image formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)
• GSM Telephony (hardware dependent)
• Bluetooth, EDGE, 3G, and WiFi (hardware dependent)
• Camera, GPS, compass, and accelerometer (hardware dependent)
• Rich development environment including a device emulator, tools for debugging, memory and performance profiling, and a plugin for the Eclipse IDE

Application Components:
Each application can be comprised of four distinct parts called Application Components:
  •  the Activities,
  •  Services,
  •  Content Providers and
  •  Broadcast Receivers components.
What is remarkable is that from the application we can access components that belong to a different application and this it’s simply executed within its own kernel assigned process that has its uniquely assigned user ID. Because the Android system allows every application to start another application’s component we can practically use components from already developed applications into our own as if they are an integral part of your program. Pretty neat!
Because each application is loaded by its own process into its own address space, and because each application can start (use) any others’ component this means that there is no central station, no entry point of the whole system or as Android’s Documentation puts it “Android applications don’t have a single entry point (there’s no main() function, …..)“.

What are the application components?

Activities are simply a single screen or window that contains a user interface. A certain application can contain lots of activities designed to achieve a specific goal. They all are part of the application even though they are treated as separate when you program their functionality.
Services are simply background processes which can run for the whole execution time of the application. You can think of them as the core/heart of you application because they can coordinate the activities for the other components, they can trigger specific actions at certain times, they can access the network, etc.
Broadcast receivers are simply listeners for system broadcasts or application broadcasts. Our own application can generate broadcasts that can be caught by Broadcast receivers. These components can have a wide variety of uses one being that they can be used as triggers in your application’s workflow logic when certain system events or other application generated events take place.
And finally, Content Providers. They are data storage providers: databases, file system data, web storage, etc., these can all be accessed by means of a Content Provider. What’s interesting is that different applications can share (read, modify) data contained in the same Content Provider object which is practically a shared set of application data; one interesting example is the contacts (ContactsContract.Data) Content Provider which contains user contact information (such as a phone number) and its associated metadata (such as whether it is a work or home number, email, etc) and can be accessed and modified by applications that have the appropriate privileges (meaning the ones that have been programmed to have these privileges, and subsequently have been installed by the user of the device).

Android Architecture
android architecture
android architecture

Activating Application Components
The Activities, Services and Broadcast Receivers components can be activated directly by announcing the kernel we intent to use an activity that is part of our own application or someone else’s, to start a service, or to start a broadcast. we simply have to pass a Intent object to the Android system through a specific method (startActivity() or startActivityForResult() for Activities, startService() or bindService() for Services, andsendBroadcast(), sendOrderedBroadcast(), or sendStickyBroadcast() for Broadcasting).
What is more interesting is that besides, of course, being able to specify the name of the class of the component which we wish to start, the Android system lets us act more implicit by allowing us to use another type of intent : Intent Actions : these represent types of actions which you can let the OS handle for you. For example we can let the Android system know that our application is in need for a “send” action of an e-mail, so if the OS finds multiple components that are registered with this action it provides the user with a list to choose from. We can even create our own application components and register them with your own actions. Now that’s complete modularity! Genius!

The Manifest File
The manifest file is practically the application configuration file which the Android System reads in order to find out what components comprise our application. Here we declare all your activities, services, broadcasts, and content providers.
We can even create filters for our application so that only the devices that have the required hardware implementation and the specific software libraries will be able to run it. You can filter for the screen size and density, user input mechanisms, hardware capabilities like the camera, the light sensor, Bluetooth, or the fidelity of the touchscreen, the version of the Android system, etc. We can even create multiple language texts, different UIs for different devices so that your application can automatically load the correct ones with no need to modify the source code. All these can be achieved in the AndroidManifest.xml file.
More here and here.

No comments:

Post a Comment

thank you