Android Application Lifecycle

In Android, the applications are run as a separate Linux process. So the application lifecycle is closely related to the process lifecycle. The application process lifecycle is handled by the system depending on the current system memory state.

In case of low memory, the Android system kills some less important process. The process importance is decided depending on the state of the process components.

The process types depending on the importance are as follows (from most important to least important):

1. Foreground process: A foreground process is the application process with which the user is currently interacting. The process is considered to be foreground if its Activity is at the top of the Activity stack (its onResume() has been called) or BroadcastReceiver is currently running (onReceive() method is currently getting executed) or its Service is executing callback functions like onCreate(), onStart() or onDestroy() methods.

2. Visible Process: A visible process is the process which has an Activity visible to the user (its onPause() method has been called).

3. Service Process: Service process contains a Service for which startService method is called and the service is running.

4. Background Process: The background process does not have any visible activities to the user. (Activity onStop() method has been called).

5. Empty Process: Empty process is the one that does not have any active application components. These processes are kept on for caching purpose.

It is important that application developers understand lifecycle of the application process. Not using these correctly can result in the system killing the application’s process while it is doing important work.

Adding Background Colors and Images to Your Table Views

Setting the background color of your table view is very easy.
All you need to do is set the backgroundColor property to the
color you want to see. For example, I have created a table view
here in the app delegate and simply set the background
property from here:

UITableViewController *tvc = [[UITableViewController alloc] initWithStyle:UITableViewStyleGrouped]; tvc.view.backgroundColor = [UIColor redColor]; [window addSubview:tvc.view]; [window makeKeyAndVisible];

If you are using sub-classing, you may also rather set this property in the initWithStyle.

You can use also an image as your background to really spice things up.

Here is that code:

UIView *backgroundView = [[UIView alloc] initWithFrame: window.frame]; backgroundView.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@"TableViewBackground.png"]]; [window addSubview:backgroundView]; [backgroundView release];

yourTableViewController = [[ATableViewController alloc] initWithStyle:UITableViewStyleGrouped]; yourTableViewController.view.backgroundColor = [UIColor clearColor]; [window addSubview:yourTableViewController.view]; [window makeKeyAndVisible];

This one takes a little more code - essentially you are putting an image into a view, inserting that into the
app window and then setting the background to a transparent color. Simply setting the background
color of the table view to the image would produce artifacts.

That is it! I hope that this tip will add some more pizazz to your apps!

Signing Your BlackBerry Application Before Deployment

Overview

• Why the need to sign your BlackBerry code
• Registering and obtaining signature keys
• Signing your application
  

Why You Need to Sign Your Code

The concept of “controlled” API's has existed since BlackBerry 3.6 as a way for Research In Motion (RIM) to track the use of some API's for security and export control reasons. In practical terms, this means that in order to run an application on a handheld, you need to register and sign the application. Signing of applications is not required to run applications using the BlackBerry device simulator.

The BlackBerry API is divided into five groups. The first group includes all standard Java API's from MIDP and CLDC and some BlackBerry-specific API's. This group is open for all developers, and applications that use only these open API's require no signatures. The remaining four groups are all controlled API's: RIM Runtime API's, some BlackBerry API's, RIM Cryptography and Certicom Cryptography.

Registering and Obtaining Signature Keys

The registration process serves to verify the developer's identity. It involves downloading and filling out a registration form that you need to fax to RIM. There’s also a one-time processing fee associated with it. RIM will send you a set of signature keys after the registration form and fee are received.

Signing Your Application

Once you receive the signature keys from RIM, you need to install them on your development environment. The detailed instructions on how to do this can be found in the BlackBerry Java Developer Guide, Volume 2 - Advanced Topics. I recommend that you study this procedure, since installing the keys incorrectly will cause the signing process to fail.
Signing the application is very easy once the keys are installed. You need to manually start the Signature Tool from the Build menu in the JDE:

 

 

When you press the Request button, the Signature Tool submits a hash of the application to RIM's signing authority. The signing authority automatically returns the required signature, that is automatically appended to the application. The application can be loaded onto a device after this step.


Note that RIM does not receive a copy of your application, only a hash of the file(s). This allows them to determine the author of the application by matching the hash of the application against records of the hash kept by the signing authorities.

Where to Find More Information

You can find more information on this topic in the BlackBerry Java Developer Guide, Volume 2 - Advanced Topics.