Android API's

Android API's : Android provides a large number of specific libraries for applications development, in addition to many Java APIs. The following list of core Android APIs gives an insight into what will be surely supported by all Android devices:
Core APIs:
- Data structures

- File Structures

- Network Access

- Graphics

- Other Utilities

android.util: contains low-level classes like specialized containers, string formatters, and XML parsing utilities;

android.os: provides access to basic operating system services like message passing, inter process communication, clock functions, and debugging;

android.graphics supplies the low-level graphics classes;

android.text for displaying and parsing text;

android.database provides the low-level classes required for handling cursors when working with databases;

android.content is used to manage data access and publishing through services for dealing with resources, content providers, and packages;

android.view supplies classes for building the Graphic User Interface;

android.widget for drawing elements of the GUI's such as lists, buttons and layouts;

com.google.android.maps, a high-level API providing access to native map controls;

android.app, a high-level package providing access to the application model (including Activity and Service APIs);

android.provider to ease developer access to certain standard Content Providers (such as 
the contacts database);

android.telephony allows to directly interact with the device’s phone stack in order to make, receive, and monitor phone calls, phone status, and SMS messages.

android.webkit 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 these core APIs some advanced libraries for more complex applications are available. Their detailed features and functionalities depend on the specific device. Let’s list some of them:

android.location gives applications access to the device’s current physical location, using whatever position-fixing hardware or technology is available on the device;

android.media provides support for playback and recording of audio and video media files, including streamed media;

android.opengl offers a powerful 3D rendering engine using the OpenGL ES API for creating dynamic 3D user interfaces for your applications;

android.hardware, where available, exposes sensor hardware including the camera, accelerometer, and compass sensors;

android.bluetooth, android.net.wifi , and android.telephony provide low-level access to the hardware platform, including Bluetooth, Wi-Fi, and telephony.

Intents and Intent filters in Android

Intents

Intents are simple message-passing frameworks providing a facility for late run-time binding between components in the same or different applications. The Intent object itself  is a passive data structure holding an abstract description of an operation to be performed or, in the case of broadcasts, a description of something that has happened and is being announced. 

Intents are messages that describe operations to perform (such as “send an email” or “choose a photo”), or in the case of broadcasts, provide descriptions of external events that have occurred (a device’s camera being activated, for example) and are being announced. These messages are implemented as instances of the android.content.Intent class. Intents can be divided into two groups.

Explicit intents:  designate the target component by its name. Since component names would generally not be known to developers of other applications, they are typically used for application-internal messages — such as an activity starting a subordinate service or launching another activity.

Implicit intents: An implicit intent doesn't name a target (the component name is not assigned a value). Implicit intents are often used to start components in other apps. Android searches for the best component (a single activity or service to perform the requested action) or components (a set of broadcast receivers to respond to the broadcast announcement) to handle the implicit intent. During the search, Android compares the contents of the Intent object to intent filters, manifest information associated with components that can potentially receive intents. They are often used to activate components in other applications.

Intent Filters : Filters advertise a component’s capabilities and identify only those intents that the component can handle. They open up the component to the possibility of receiving implicit intents of the advertised type. If a component has no intent filters, it can receive only explicit intents. In contrast, a component with filters can receive explicit and implicit intents. Android consults an Intent object’s action, category, data, and type when comparing the intent against an intent filter. It doesn't take extras and flags into consideration.

 A component with filters can receive both explicit and implicit intents. An explicit intent is always delivered to its target, no matter what it contains; the filter is not consulted. But an implicit intent is delivered to a component only if it can pass through one of the component's filters.

An Intent object describes a message in terms of some combination of the following items:

Action: A string naming the action to be performed or, in the case of broadcast intents, the action that took place and is being reported. Actions are described by Intent constants such as ACTION_CALL (initiate a phone call), ACTION_EDIT (display data for the user to edit), and ACTION_MAIN (start up as the initial activity). You can also define your own action strings for activating the components in your app. These strings should include the app package as a prefix   ("com.example.project.SELECT_COLOR", for example).

Category: A string that provides additional information about the kind of component that should handle the intent. For example, CATEGORY_LAUNCHER means that the calling activity should appear in the device’s app launcher as a top-level app.

Component name: A string that specifies the fully qualified name (package plus name) of a component class to use for the intent. The component name is optional. If set, the Intent object is delivered to an instance of the designated class. If not set, Android uses other information in the Intent object to locate a suitable target.

Data: The uniform resource identifier of the data on which to operate (such as a person record in a contacts database).

Extras: A set of key-value pairs providing additional information that should be delivered to the component handling the intent. For example,given an action for sending an email, this information could include the message’s subject, body, and so on.

Flags: Bit values that instruct Android on how to launch an activity (for example, which task the activity should belong to) and how to treat the activity after launch (for example, whether the activity can be considered a recent activity). Flags are represented by constants in the Intent class; for example, FLAG_ACTIVITY_NEW_TASK specifies that this activity will become the start of a new task on this activity stack.

Type: The MIME type of the intent data. Normally, Android infers a type from the data. By specifying a type, you disable that inference.

Data Models in DBMS

Data Models:
Data model is a way of storing and retrieving the data. There are three different data models. Data models differ in the way they allow users to view and manipulate relationships between entities. Each has its own way of storing the data. The following are the three different data models:

• Hierarchical
• Network
• Relational

Hierarchical:
In this model, data is stored in the form of a tree. The data is represented by parent child relation ship. Each tree contains a single root record and one or more subordinate records. For example, each batch is root and students of the batch will be subordinates. This model supports only one-to-many relationship between entities. This was used in IBM’s Information management system, IMS.



Network:
Data is stored along with pointers, which specify the relationship between entities. This was used in Honeywell's Integrated Data Store, IDS. This model is complex. It is difficult to understand both the way data is stored and the way data is manipulated. It is capable of supporting many-to-many relationship
between entities, which hierarchical model doesn't.


Relational:
This stores data in the form of a table. Table is a collection of rows and columns.

Session in Servlets

Session:
HTTP is a protocol which does not maintain the state of the client. It is state-less protocol, to make the protocol stateful we need to provide the session handling mechanism. This will be provided as per the need of the Application.The basic categories are 4 ways:
1. Using Cookies
2. Using Session API in Servlets
3. Using Hidden form fields
4. URL Rewriting.
The best one is using Session objects with help of Session API. Cookies are harmful because they are allowed to store on to the client machine. This way you can send a virus file as cookie So normally The system admin disables them to protect their network. The session API allows us to create SessionID and set for the client. per Client you can have one session object which will run in the Server.

DBMS

DBMS:
A DBMS is a set of programs that is used to store and manipulation data. Manipulation
of data include the following:

1. Adding new data, for example adding details of new student.
2. Deleting unwanted data, for example deleting the details of students who have completed course.
3. Changing existing data, for example modifying the fee paid by the student.

A DBMS provides various functions like data security, data integrity, data sharing, data concurrence, data independence, data recovery etc. 



Data sharing, concurrency and locking:


DBMS also allows data to be shared by two or more users. The same data can be accessed by multiple users at the same time – data concurrency. However when same data is being manipulated at the same time by multiple users certain problems arise. To avoid these problems, DBMS locks data that is being manipulated to avoid two users from modifying the same data at the same time. The locking mechanism is transparent and automatic. Neither we have to inform to DBMS about locking nor we need to know how and when DBMS is locking the data.


Data Security:


While DBMS allowing data to be shared, it also ensures that data in only accessed by authorized users. DBMS provides features needed to implement security at the enterprise level. By default, the data of a user cannot be accessed by other users unless the owner gives explicit permissions to other users to do so.



Data Integrity:


Maintaining integrity of the data is an import process. If data loses integrity, it becomes unusable and garbage. DBMS provides means to implement rules to maintain integrity of the data. Once we specify which rules are to be implemented, then DBMS can make sure that these rules are implemented always.
Three integrity rules – domain, entity and referential are always supported by DBMS.

Fault tolerance and recovery:


DBMS provides great deal of fault tolerance. They continue to run in spite of errors, if possible, allowing users to rectify the mistake in the mean time. DBMS also allows recovery in the event of failure. For instance, if data on the disk is completely lost due to disk failure then also data can be recovered to the point of failure if proper back up of the data is available.


DBMS supports a data access and manipulation language. The most widely used data access language for RDBMS (relational database management systems) is SQL. Apart from supporting a non-procedural language like SQL to access and manipulate data DBMS now a days also provides a procedural language for data processing. Oracle supports PL/SQL and SQL Server provides T-SQL.