excilys/androidannotations — Issue #5: Listeners on activity callbacks
Author: pyricau
Created: 2012-01-06 10:19:18+00:00
State: open
Labels: Enhancement

I'd like to implement a new Listener system for the activity callbacks, somehow inspired from RoboGuice and other sources.

Here is the idea :

We would create some listener callback interfaces, such as OnCreateListener, OnResumeListener, OnPauseListener... they may all inheriting from an AndroidCallbackListener interface (a marker interface useful from the framework point of view).

Users would write a listener class :

```
public class MyListener implements OnCreateListener, OnResumeListener {

public void onCreate(Activity activity, Bundle savedInstanceState) {
// do something
}

public void onResume(Activity activity) {
// do something
}
}
```

Then, they would be registered in the activity :

```
@EActivity
@Listeners(MyListener.class)
public class MyActivity extends Activity {

}
```

And that's all : onCreate and onResume in the listener will be called immediately after the callback are called in MyActivity.

The implementation would just create a new instance of MyListener and set it in a field of MyActivity_, and delegate the calls to onCreate, onResume, etc.

This whole thing is not precisely defined yet, we need feedback, so please everyone tell me what you think of this.

The listeners could also be written with a constructor given activity, instead of something method based (so it shows that there is one instance of listener per activity :

```
public class MyListener implements OnCreateListener, OnResumeListener {

public MyListener(Activity activity) {
}

public void onCreate(Bundle savedInstanceState) {
// do something
}

public void onResume() {
// do something
}
}
```

On the activity side, we could use an @EActivity field instead of a dedicated annotation :

```
@EActivity(listeners = {MyListener.class})
public class MyActivity extends Activity {

}
```

BTW, what do you guys think : should it be one listener per activity, or one per application ?

Should we provide a way to use a specific kind of activity ? For instance, having an OnCreateListener interface, we could do this :

```
public class MyListener implements OnCreateListener {

public void onCreate(MyAbstractActivity activity, Bundle savedInstanceState) {
// do something
}

}
```

Or if we go with the constructor solution, then we could allow subclasses of activity, and check that the listener can be used on the activity.

Any other idea ?

This would be a great alternative for issue 110 (provide a vendor specific annotation that do some stuff in some callbacks), because we could then do something like :

```
public class CapptainListener implements OnPauseListener, OnResumeListener {

private Activity activity;

public CapptainListener(Activity activity) {
this.activity = activity;
}

@Override
public void onResume() {
CapptainAgent.getInstance(activity).startActivity(activity, activity.getClass().toString, null);
}

@Override
public void onPause() {
CapptainAgent.getInstance(activity).endActivity();
}
}
```

@vincent.barat, Nov 1, 2011 :
Yes, I think it would be a much better way to handle Capptain integration and other Activity related listeners.
I vote for it ! :)