On exploring databases on the emulator and available devices:

Many content providers in Android use SQLite databases (http://www.sqlite.org/),

user can use tools provided both by Android and by SQLite to examine the databases.

Many of these tools reside in the \android-sdk-install-directory\tools subdirectory.

One of the tools is a remote shell on the device that allows user to execute a command-line

SQLite tool against a specified database.

Android uses another command-line tool called Android Debug Bridge (adb), which is

available as " tools\adb.exe "

Android Database:

Android's Java interface to its relational database, SQLite.

It supports an SQL implementation rich enough for anything you're likely to need in a mobile application, including a cursor facility.

ContentProvider:

An interface used between applications.

The server application that hosts the data manages it through basic create, read, update, and delete (CRUD) operations.

The client application uses a similar API, but the Android framework transmits the client's requests to the server.

test3

test2

Test

Android Database Design Considerations :

There are main two considerations specific to Android that consider when designing database:

A.)  Files (such as bitmaps or audio fi les) are not usually stored within database tables.

Instead, use a string to store a path to the fi le, preferably a fully qualifi ed Content Provider URI.

B.)  While not strictly a requirement, it’s strongly recommended that all tables include an 

auto-increment key fi eld, to function as a unique index value for each row. 

It’s worth noting that if you plan to share your table using a Content Provider, 

this unique ID fi eld is mandatory.

Opening and Creating Databases without the SQLiteHelper:

You can create and open databases without using the SQLiteHelper class with the 

openOrCreateDatabase method on the application Context.

Setting up a database is a two-step process. 

First, call openOrCreateDatabase to create the new data-base. 

Then, call execSQL on the resulting database instance to run the SQL commands that will create 

your tables and their relationships. 

Using the SQLiteOpenHelper:

SQLiteOpenHelper is an abstract class that wraps up the best practice pattern for creating, opening, and upgrading databases. 

By implementing and using an SQLiteOpenHelper, you hide the logic used to decide if a database needs to be created or upgraded before it’s opened.

The code snippet shows how to extend the SQLiteOpenHelper class by overriding the construc-tor, onCreate, and onUpgrade methods to handle the creation of a new database and upgrading to a new version, respectively. 

Example of use of databse in Android Apps. code:

  public MyObject getEntry(long _rowIndex) {

    MyObject objectInstance = new MyObject();

    // TODO Return a cursor to a row from the database and

    // use the values to populate an instance of MyObject

    return objectInstance;

  }

  public int updateEntry(long _rowIndex, MyObject _myObject) {

    String where = KEY_ID + “=” + _rowIndex;

    ContentValues contentValues = new ContentValues();

    // TODO fill in the ContentValue based on the new object

    return db.update(DATABASE_TABLE, contentValues, where, null);

  }

Android and use of Databases:

Plan to create a database adapter, which adds an abstraction layer that encapsulates database inter - actions. It should provide intuitive, strongly typed methods for adding, removing, and updating items. 

A database adapter should also handle queries and wrap creating, opening, and closing the database.

It’s often also used as a convenient location from which to publish static database constants, including table names, column names, and column indexes.

SQLite Cursors and Content Values:

ContentValues objects are used to insert new rows into database tables (and Content Providers). Each Content Values object represents a single row, as a map of column names to values. 
Queries in Android are returned as Cursor objects. Rather than extracting and returning a copy of the result values, Cursors act as pointers to a subset of the underlying data. Cursors are a managed way of controlling your position (row) in the result set of a database query. 

The Cursor class includes several functions to navigate query results including, but not limited to, the following:

moveToFirst >> Moves the cursor to the fi rst row in the query result.

moveToNext >> Moves the cursor to the next row.

moveToPrevious >> Moves the cursor to the previous row.

getCount >> Returns the number of rows in the result set.

getColumnIndexOrThrow >> Returns an index for the column with the specifi ed name (throw-
ing an exception if no column exists with that name).

getColumnName >> Returns the name of the specifi ed column index.

getColumnNames >> Returns a String array of all the column names in the current cursor.

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.

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.

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 spe-cifi c 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.

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 specifi c 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 connec-tions, Wi-Fi, Bluetooth, accelerometers, touch screen, and power management.

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 traffi conditions.
  
• A WebKit-based web browser.
  
• An Instant Messaging Client.
  
• A music player and picture viewer.
  
• The Android Marketplace client for downloading thied-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. 

More XML Layouts :

RelativeLayout :

Each child element is laid out in relation to other child elements. 
Relationships can be established so that children will start themselves where a previous child ends. Children can relate only to elements that are listed before them. So, build your dependency from the beginning of the XML file to the end.

AbsoluteLayout :

Each child must be given a specific location within the bounds of the parent layout object. The AbsoluteLayout object is probably the easiest to build and visualize but the hardest to migrate to a new device or screen size. 

TableLayout :

TableLayout is a layout object that allows you to specify table rows. 
Android tries to arrange each of the child elements into the correct row and columns. 

Easy and Fast, the XML Layout :

XML layouts might seem simple at first, but it’s going to get complicated really quickly.

Laying Out :
Most XML screens will be wrapped in a layout object. Layout objects come in many different flavors. 

LinearLayout : 
All elements are arranged in a descending column from top to bottom or left to right.

Each element can have gravity and weight properties that denote how they dynamically

grow and shrink to fill space. Elements arrange themselves in a row or column notation

based on the android:orientation parameter. 

Creating an XML Layout File :

Now that you have an image resource, you can add it to your XML layout file.

These files are kept in res/layout/, and you should currently have one called main.xml.

Add a new XML file called splash.xml, and copy the contents of the main.xml file into it.

Next, modify the file by removing the tag and add an tag that

looks like the following: 

android:layout_width="fill_parent" 

android:layout_height="fill_parent"> 

 

Using Android’s XML layout objects is simple and straightforward.

As I mentioned, files in the /res directories can be referenced with the @ symbol

as shown earlier, for example, android:src="@drawable/menu_background".

Further, layout_width and layout_height dictate the size of the image view.

Look to make sure your new layout file has been added to R.java.

It should appear as follows:

public static final int splash=0x7f030001; 

Adding the Image Resource :

First you’ll need a sample splash screen image. The “socially awkward” splash screen I’ve included is not going to win any awards, but it is a good poke at the rash of social networking applications that seem to keep cropping up in the mobile space right now. 

To add this new resource, I’ve placed menu_background.jpg inside res/drawable.

Make sure a new ID is added to R.java.

It should look something like this: 

public static final int menu_background=0x7f020001; 

This is now your means of loading and drawing the image from within your code.

You’ll return to this concept in the next chapter on user interaction. 

Android Functionality :

Just like the midlet, an activity uses a series of functions to interact with the outside world.

At its base, your activity must override the method onCreate. Other functions you’ll want to override are onStop, onPause, onResume, and onKeyDown. These few functions are what will let you tie your activity into the Android handset at large. 

By default, new Android applications created within Eclipse will implement a “Hello, World” application. I’ll show you how to go from this basic application to a fully functional splash screen. 

Android vs. Java ME vs. BREW :

A BREW application will, in the vast majority of all cases, consist of a single applet.

That applet communicates with the rest of the handset through receiving and sending events. You can think of a Java ME application, on the other hand, as an extension of the Midlet class.

The midlet has functions for starting, stopping, pausing, key handling, and performing any other interaction between the handset and application.

A Java ME application usually consists of a single midlet. 

Android applications can have any number of activities registered with the 
handset through the AndroidManifest.xml file. Android’s multiactivity 
architecture is probably the major difference between developing for Android   and developing for other handset SDKs.

This single fact makes it much easier to write modular, compartmentalized code. In BREW and Java ME, a developer will implement most functionality within the confines of the midlet or the applet. In Android, you can write an activity, content handler, intent receiver, or service to handle nearly anything.

Once you’ve written an activity to edit a text file, you can refer to this activity in all future applications you write by sending and receiving intent actions.

This isn’t to say that such architecture isn’t possible within BREW or Java ME. 
It just has to be done at the Java, C, or C++ level or, in Brew, with cumbersome extensions instead of being built smoothly into the application 
framework.