Can android activity be designed without having to override all kinds of lifecycle methods?

Question

When I write my activities on android, I have to override a lot of "lifecycle" methods, such as onCreate, onActivityResult:

class MyAcitivity extends Activity {

    @Override
    public void onCreate(...) {}

    @Override
    public void onStart(...) {}

    @Override
    public void onActivityResult(...) {}

    @Overide
    public void onBackPressed(...) {}
}

I don't like this, because I found my logical code are split to everywhere in my class. I do some operation in this method, but I have to handle the result in another method.

Is it the only way to design Activity like this? Is there any other solution can let me do the same without overriding methods from super classes?

---

Update

I do some operation in this method, but I have to handle the result in another method.

For example:

public void onCreate(...) {
    startActivityForResult(new Intent(this, AnotherAcitity.class), INTENT_ANOTHER);
}

public void onActivityResult(...) {
    if(requestCode == INTENT_ANOTHER)  {
        // do something
    }
}

Update again

I know how to use these lifecycle methods, what I'm thinking is the "design". Is there any different way to design android (in theory) without "overriding lifecycle methods" to write activities. Does ios and win8 on mobiles use the same design as android? If I develop an ios or win8 application, do I have to override all kinds of lifecycle methods as I do on android?

Answer 1

This is just a generic framework pattern, framework doesn't depend on you, just notifies you, all your actions are optional for framework. It's called Inversion of Control.

This is just opposite to the direct style of programming where you decide everything about the Application, and give commands to framework.

Google developers designed Activity class, and Android only works through them. Android calls these methods whenever it pleases. Android does not care what you do in those methods, it just cares to notify you of the life cycle events.

Since everything is optional, you just have to fill in the places you are really interested in. An empty Activity runs just fine.

 public class MyActivity extends Activity { }

If anything additional needs to be done, just add the code at correct place:

 public class MyActivity extends Activity { 
   @Override
   public void onCreate(...) {
      //---whatever you want to do in this stage of life cycle----
   }
 }

Answer 2

You only need to override the methods you're using in your Activity. So if your activity simple displays a help page that has already been populated in the XML, you only have to override onCreate() and call setContentView().

In general, if your overriden method is like:

public void myOverridenMethod() {
    super.myOverridenMethod();
}

That is to say, it contains nothing but a super call, you need not override it.

In the example you provided, you must override the appropriate lifecycle methods as the calling of these is beyond your control, unless you're willing to develop a custom ROM for your device(s).

EDIT

The Android lifecycle methods are called by the system at specific predefined points in your app's life.

You cannot design an Activity in a different way, as if you do Android has no idea which method does what. However, it knows exactly when to call which method in the Android lifecycle. By using your own methods instead of these, you have an app which Android cannot interact with.

Additionally, many lifecycle methods like onCreate() etc. help setup the initial bits of your app (like getting it a Context).

iOS and Windows Phone and BlackBerry have similar lifecycle methods, but they don't always have an exact Android equivalent, as all are different platforms and handle their apps differently.

Answer 3

You dont necessarily need to override all methods of life cycle of an activty. They all are for a specified purpose

onCreate() :

Called when the activity is first created. This is where you should do all of your normal static set up: create views, bind data to lists, etc. This method also provides you with a Bundle containing the activity's previously frozen state, if there was one. Always followed by onStart().

onRestart() :

Called after your activity has been stopped, prior to it being started again. Always followed by onStart()

onStart() :

Called when the activity is becoming visible to the user. Followed by onResume() if the activity comes to the foreground, or onStop() if it becomes hidden.

onResume() :

Called when the activity will start interacting with the user. At this point your activity is at the top of the activity stack, with user input going to it. Always followed by onPause().

onPause ():

Called as part of the activity lifecycle when an activity is going into the background, but has not (yet) been killed. The counterpart to onResume(). When activity B is launched in front of activity A, this callback will be invoked on A. B will not be created until A's onPause() returns, so be sure to not do anything lengthy here.

onStop():

Called when you are no longer visible to the user. You will next receive either onRestart(), onDestroy(), or nothing, depending on later user activity.

Note that this method may never be called, in low memory situations where the system does not have enough memory to keep your activity's process running after its onPause() method is called.

onDestroy() :

The final call you receive before your activity is destroyed. This can happen either because the activity is finishing (someone called finish() on it, or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method.