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.