I'm using MVVM on android application and i want to manage requests and rxJava on device rotation, how can i disable request after rotation device and countinue from last request?
this is my simple code to know how can i doing that, but i can't find any document and sample code about it
#Override
public void onCreate(#Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
binding = DataBindingUtil.setContentView(this, R.layout.activity_register);
...
Observer<String> myObserver = new Observer<String>() {
#Override
public void onError(Throwable e) {
// Called when the observable encounters an error
}
#Override
public void onComplete() {
}
#Override
public void onSubscribe(Disposable d) {
}
#Override
public void onNext(String s) {
// Called each time the observable emits data
Log.e("MY OBSERVER", s);
}
};
Observable.just("Hello").subscribe(myObserver);
}
I'm using latest version of rxJava
Handling rotation is a cool challenge in Android. There're a few ways to do that.
1- Services: You can use a service and handle your network requests or other background operations in service. Also with Services, you'll seperate your business logic from ui.
2- Worker Fragment: Worker fragment is a fragment instance without a layout. You should set your worker fragment's retainInstanceState to true. So you'll save your fragment from orientation change and will not lose your background operations.
Why Worker Fragment? If you set retainInstanceState true to a fragment with layout, you'll leak views.
If you're using MVVM you can implement ViewModel as a Worker Fragment which as setRetainInstanceState = true
3- Global Singleton Data Source: You can create a global singleton data source class which handles your operations in an independent scope from Activity / Fragment lifecycle in your application.
4- Loaders: Loaders can recover state from orientation changes. You handle your operations with loaders but they are designed to load data from disk and are not well suited for long-running network requests.
Extra: You can use Path's Priority Job Queue to persist your jobs:
https://github.com/path/android-priority-jobqueue
Edit: You can check my repo for handling device rotation without using Google's new architecture components. (As an example of Worker Fragment which i pointed in my answer.)
https://github.com/savepopulation/bulk-action
You have the following options:
Use some global Singleton, or your Application class, that holds your logic, not within your Activity's lifecycle
Use a Service that runs next to your activity/application
Use a Loader
Global state is often bad and makes your code hard to test / debug. Services tend to be overkill.
For your use case of device rotation and continuing where one left off you'd usually use a Loader, which keeps running on rotation and only gets destroyed once you leave the activity.
I also recently wrote an article about one possible solution to use Loaders together with RxJava to keep state during orientation changes.
You can take advantage of Fragment#setRetainInstance(true). With that flag set, fragment is not destroyed after device rotation and can be used as an object container. Please look at this sample which also stores Observable - https://github.com/krpiotrek/RetainFragmentSample
you need to override
#Override
public void onSaveInstanceState(Bundle outState) {
super.onSaveInstanceState(outState);
}
When device is rotated store data in bundle then inside on create check
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
if(savedInstanceState == null){
//saved instance is null
}else{
//get your stored values here
counter = savedInstanceState.getInt("value",0); //here zero is the default value
}
}
How I'm doing this is to have a singleton class (or any long living Object as explained by savepopulation earlier, but - the trick is to store the loaded data in a BehaviorSubject, and subscribe to that subject in the Activity instead of the original network request.
This way:
public class MyNetworkSingleton {
// This static service survives orientation changes
public static MyNetworkSingleton INSTANCE = new MyNetworkSingleton();
private final BehaviorSubject<String> dataSubject = BehaviorSubject.create();
public Observable<String> getData() {
if (!dataSubject.hasValue()) {
refreshData(); // No data is loaded yet, load initial data from network
}
return dataSubject;
}
public void refreshData() {
someDataSourceCall().subscribe(new Observer<String>() {
#Override
public void onError(Throwable e) {
// Remember, this point also needs error handling of some form,
// e.g. propagating the error to the UI as a Toast
}
#Override
public void onComplete() {
}
#Override
public void onSubscribe(Disposable d) {
}
#Override
public void onNext(String data) {
dataSubject.onNext(data); // this refreshes the internally stored data
}
});
}
private Observable<String> someDataSourceCall() {
return // some network request here etc. where you get your data from
}
}
and then:
#Override
public void onCreate(#Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
...
Observer<String> myObserver = new Observer<String>() {
#Override
public void onError(Throwable e) {
// Called when the observable encounters an error
}
#Override
public void onComplete() {
}
#Override
public void onSubscribe(Disposable d) {
}
#Override
public void onNext(String s) {
// Called each time the observable emits data
Log.e("MY OBSERVER", s);
}
};
MyNetworkSingleton.INSTANCE.getData().subscribe(myObserver);
myRefreshButton.setOnClickListener(new Button.OnClickListener() {
public void onClick(View v) {
// refresh data from network only when button is pressed
MyNetworkSingleton.INSTANCE.refreshData();
}
});
}
This way only first time you need the data from network it will be loaded, or when the user clicks a refresh button (myRefreshButton).
Related
I'm new to RxJava and I need to integrate it into an existing project. I need to refactor the existing code, adding Observables for networking (Socket IO).
Currently when a network request is made (client -> server) a callback (interface) is added to a HashMap and once the request is completed, it will deliver the data back to the caller:
// Singleton
public class API {
public void checkTicket(String ticketId, final String networkRequestId, Callback callback) {
// Add the callback to the hashmap
registerCallback(networkRequestId, callback);
JSONObject json = RequestFactory.createTicketCheckerRequest(ticketId);
// Make the network request
getSocket().checkTicket(json, new Callback() {
#Override
public void onRequestDone(Response response) {
// Retrieve the callback
callback = getCallback(networkRequestId);
// Don't keep reference, remove from hashmap
unsubscribeCallback(networkRequestId);
// Check if it's unsuccessful and build the corresponding error response
if (!response.isSuccess()) {
// build custom error response
response = ResponseFactory.buildError(response);
}
// Deliver response from server
callback.onRequestDone(response);
}
});
}
}
It can be called from Activities and Fragments:
private void checkTicket() {
String ticketId = editText.getText().toString();
API.getInstance().checkTicket(ticketId, REQUEST_ID_CHECK_TICKET, new Callback() {
#Override
protected void onRequestDone(Response response) {
textView.setText(response.getData());
}
});
}
#Override
public void onDestroy() {
super.onDestroy();
// Removes callback from HashMap in case of the UI is destroyed before the arrives
API.getInstance().unsubscribe(REQUEST_ID_CHECK_TICKET);
}
The above code works but it's really tight with the UI's lifecycle and sometimes it's causing memory leak, because onDestroy() is not getting called (if you navigate between activities and Android OS kills the "paused" activities from the stack) or because the anonymous inner classes (callbacks) which are holding a reference to the UI, and from now on I need to support orientation change.
This is the code that I have implemented using RxJava:
API:
public Observable<Response> checkTicket(String ticketId) {
return Observable.create(subscriber -> {
JSONObject json = RequestFactory.createTicketCheckerRequest(ticketId);
// Make the network request
getSocket().checkTicket(json, new Callback() {
#Override
public void onRequestDone(Response response) {
subscriber.onNext(response);
subscriber.onComplete();
}
});
});
}
This is how it's called from the UI:
private CompositeDisposable mDisposables = new CompositeDisposable();
private void checkTicket() {
//////
Disposable disposable = API.getInstance().checkTicket(ticketId)
.observeOn(AndroidSchedulers.mainThread())
.subscribeOn(Schedulers.io())
.subscribe(result -> {
textView.setText(result.getData());
});
mDisposables.add(disposable);
}
#Override
public void onStop() {
super.onStop();
if (!mDisposables.isDisposed()) {
mDisposables.dispose();
}
}
The above RxJava is working, however if an orientation change occurs the data is not returned because the Observer is unsubscribed.
Is the above implementation correct?
How should I subscribe without executing the request? Subscribe and wait for data change.
Another alternative would be EventBus but this is just Plan B. EventBus fits exactly my requirements, subscribe and wait for data change, but I want to evict boilerplate.
I have read other articles by using Fragment's setRetainInstance(true) but what if I need to use it from an Activity? What if I don't want to retain the state of the Fragment?
People suggested to use MVVM or MVP architecture, but I don't have the time to refactor the entire project.
I will suggest you move to MVVM. With your presented code, it is not that hard. Here is a sample code of how it will look like
Your ModelView
public class MyViewModel extends ViewModel {
private CompositeDisposable mDisposables = new CompositeDisposable();
private MutableLiveData<Response> response;
public LiveData<Response> getResponse() {
if (response == null) {
response = new MutableLiveData<Response>();
loadData();
}
return response;
}
private void loadData() {
Disposable disposable = API.getInstance().checkTicket(ticketId)
.observeOn(AndroidSchedulers.mainThread())
.subscribeOn(Schedulers.io())
.subscribe(result -> {
response.postValue(result.getData());
});
mDisposables.add(disposable);
}
void onCleared()
{
super.onCleared();
mDisposables.clear(); //no more leaks. It takes care of lifecycle for you
}
}
Your Activity
public class MyActivity extends AppCompatActivity {
public void onCreate(Bundle savedInstanceState) {
MyViewModel model = ViewModelProviders.of(this).get(MyViewModel.class);
model.getResponse().observe(this, response -> {
// update UI
textView.setText(response); //response = Response object from Live data
});
}
}
If you don't want to handle configuration changes and want to cache data from observables, you can use BehaviorSubjects and a hot observable. This will allow you to get the most recent item that the observable published.
Other than that, I suggest you use the ViewModel from the architecture components. It will allow you to create a component that is bound to the activity but will not be affected by the lifecycle (except termination, obviously). Surprisingly enough, ViewModelProviders are implemented as fragments with setRetainInstance(true). You don't have to completely refactor the entire app. Just move the ones that you want to preserve during configuration changes.
You need to consider the logical scope of your network requests, and this is entirely separate from whether you're using RxJava. Background tasks like network requests need to be owned by an Android component (Application, Activity, etc.) with the appropriate lifetime. The usual way to make activity-scoped background tasks survive a config change is to host them in a retained fragment. You would still do that if you were using RxJava.
Android OS kills the "paused" activities from the stack
This doesn't happen unless something has changed in Android 8 or newer. The documentation suggests that the framework could destroy individual activities in the backstack, but currently it only destroys the entire task when it's in the background. Your app is correct and future-proof if and only if it works with the "don't keep activities" developer option on.
The suggested way to implement ViewModel is to expose the changing data by using LiveData objects to activities, fragments and views. There are cases, when LiveData is not an ideal answer or no answer at all.
The natural alternative would be, to apply the observer pattern to the ViewModel, make it an observable. When registering observers to the ViewModel, the ViewModel will hold callback references to notify the observers.
The documentation says, a ViewModel must not hold references to activities, fragments or views. The only answer to the question "why" I found is, that this may cause memory leaks. Then how about cleaning up the references to avoid memory leaks?
For views this is a difficulty. There is no defined moment, when the view goes away. But activities and fragments have a defined lifecycle. So there are places to unregister as observers.
What do you think? Is it valid to register activities as observers to ViewModels if you take care to always unregister them? Did you hit upon any valid information about this question?
I set a small reward for the best answer. It's not because I think it a recommended solution (as it does not work with views). I just want to know and extend my options.
public class ExampleViewModel extends ViewModel {
public interface OnEndListener {
public void onEnd();
}
private List<OnEndListener> onEndListeners = new ArrayList<>();
public void setOnEndListener(OnEndListener onEndListener) {
onEndListeners.add(onEndListener);
}
public void removeOnEndListener(OnEndListener onEndListener) {
onEndListeners.remove(onEndListener);
}
public void somethingHappens() {
for (OnEndListener onEndListener: new ArrayList<OnEndListener>(onEndListeners) ) {
onEndListener.onEnd();
}
}
}
public class ExampleActivity extends AppCompatActivity {
ExampleViewModel exampleViewModel;
ExampleViewModel.OnEndListener onEndListener;
#Override
protected void onCreate(#Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
onEndListener = new ExampleViewModel.OnEndListener() {
#Override
public void onEnd() {
finish();
}
};
exampleViewModel = ViewModelProviders.of(this).get(ExampleViewModel.class);
exampleViewModel.setOnEndListener(onEndListener);
}
#Override
protected void onDestroy() {
super.onDestroy();
exampleViewModel.removeOnEndListener(onEndListener);
}
}
To ask "am I allowed..." is not really a useful question, IMO. The docs are clear that what you are suggesting is discouraged and why. That said, I expect that your code would probably work as expected and is therefore "allowed" (i.e. not prevented by a technical constraint).
One possible gotcha scenario: InstanceA of ExampleActivity is started and kicks off some long-running task on the ExampleViewModel. Then, before the task completes, the device is rotated and InstanceA is destroyed because of the configuration change. Then, in between the time when InstanceA is destroyed and a new InstanceB is created, the long-running task completes and your view model calls onEndListener.onEnd(). Except: Oh no! The onEndListener is null because it was cleared when InstanceA was destroyed and hasn't yet been set by InstanceB: NullPointerException
ViewModel was designed (in part) precisely to handle edge cases like the gotcha scenario above. So instead of working against the intended use of the ViewModel, why not just use the tools it offers along with LiveData to accomplish the same thing? (And with less code, I might add.)
public class ExampleActivity extends AppCompatActivity {
ExampleViewModel exampleViewModel;
#Override
protected void onCreate(#Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
exampleViewModel = ViewModelProviders.of(this).get(ExampleViewModel.class);
exampleViewModel.getOnEndLive().observe(this, new Observer<Boolean>() {
#Override
public void onChanged(#Nullable Boolean onEnd) {
if (onEnd != null && onEnd) {
finish();
}
}
});
}
}
public class ExampleViewModel extends ViewModel {
private MutableLiveData<Boolean> onEndLive = new MutableLiveData<>();
public MutableLiveData<Boolean> getOnEndLive() {
return onEndLive;
}
public void somethingHappens() {
onEndLive.setValue(true);
}
}
Think of the LiveData in this case not as actual "data" per se, but as a signal that you can pass from your ViewModel to your Activity. I use this pattern all the time.
I am working on an Android app. The code I attach is creating a recyclerview. The very first thing we do is to create an asynctask that would fetch data on an SQLite database and load it into the adapter->recylcerview. While the background task is working, a progressdialog is shown to the user.
public class HomeActivity extends AppCompatActivity
{
private RecyclerView recycler;
private RecyclerViewAdapter adapter;
private SwipeRefreshLayout swipeRefresh;
private progressDialog progressDialog;
// ... some code here
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// ... some code here
createRecyclerView();
loadRecyclerView();
// ... some code here
}
private void loadRecyclerView()
{
new LoadingBackgroundTask().execute();
}
private void createRecyclerView()
{
Context context = getApplicationContext();
recycler = (RecyclerView) findViewById(R.id.recycle_view_home);
recycler.setHasFixedSize(true);
RecyclerView.LayoutManager lManager = new LinearLayoutManager(context);
recycler.setLayoutManager(lManager);
adapter = new RecyclerViewAdapter();
recycler.setAdapter(adapter);
recycler.setItemAnimator(new DefaultItemAnimator());
}
private class LoadingBackgroundTask extends AsyncTask<Void, Void, List<items>> {
#Override
protected void onPreExecute() {
super.onPreExecute();
progressDialog = ProgressDialog.show(HomeActivity.this, getString(R.string.dialog_load_list),getString(R.string.dialog_please_wait), false, false);
}
#Override
protected List doInBackground(Void... params) {
List<items> lists;
//Data Source Class ( SQLite)
ListDS listDS = new ListDS(getApplicationContext());
list = listDS.getList();
return list;
}
#Override
protected void onPostExecute(List result) {
super.onPostExecute(result);
//it inserts de list on recyclerview performing animation
adapter.animate(result);
progressDialog.dissmiss();
swipeRefresh.setRefreshing(false);
recycler.scrollToPosition(0);
}
}
}
So far, so good. However, as you probably know this code has some well-known issues; for example if I rotate the screen while asynctask is doing its magic, it will crash the app.
I've tried an alternative I've seen Googling, rxandroid.
(Sorry if I typed something wrong, I am doing it by memory)
public class HomeActivity extends AppCompatActivity
{
private Subscriber suscriptor;
private progressDialog progressDialog;
//some code ....
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
suscriptor = new Subscriber() {
#Override
public void onCompleted() {
progressDialog.dismiss();
Log.d("SUSCRIPTOR","ON COMPLETE");
}
#Override
public void onError(Throwable e) {
Log.d("SUSCRIPTOR","ON ERROR");
}
#Override
public void onNext(Object o) {
adapter.animate((List<items>)o);
}
};
Observable.create(
new Observable.OnSubscribe<List<items>>() {
#Override
public void call(Subscriber<? super List<items>> sub) {
progressDialog = ProgressDialog.show(HomeActivity.this, getString(R.string.dialog_load_list),getString(R.string.dialog_please_wait), false, false);
List<items> lists;
//Data Source Class ( SQLite)
ListDS listDS = new ListDS(getApplicationContext());
list = listDS.getList();
sub.onNext(list);
sub.onCompleted();
}
#Override
protected void finalize() throws Throwable {
super.finalize();
Log.d("OBSERAVBLE","FINALIZED");
}
})
.observeOn(AndroidSchedulers.mainThread())
.subscribeOn(Schedulers.newThread())
.cache()
.subscribe(suscriptor);
}
#Override
public void onDestroy()
{
if(suscriptor!=null)
{
if(!suscriptor.isUnsubscribed())
{
suscriptor.unsubscribe();
}
}
super.onDestroy();
}
}
Now the app is not crashing anymore when I rotate the screen. However, the observable keeps working on the background until it finishes but as I unsubscribe to avoid crashing, I don't receive the results properly. Moreover, progressbar disappears even though the observable keeps working as I mentioned.
Looking for a solution, I found there is a pattern called "Ted Mosby" which seems to solve my problem. Although it looks promising, I think is too much coding for something I felt it is not worth it and that rxandroid may have a workaround.
So, my question is how can I get what I want without getting immersed in an architectural coding mess too big for my purpose? Could you give an example if you guys have solved this? Do you think I am wrong and I should implement TedMosby pattern?
Mosby is a Model-View-Presenter (MVP) library. So the pattern you named "ted mosby pattern" is actually MVP.
But you didn't have understood what MVP is all about. It's not about retaining async running taks, even thought this could be achieved with Mosby. MVP is about separation of concerns. View is just displaying UI elements, Presenter is controlling the View, i.e. the presenter tells the view: now display the progress diaolog, now hide the progress dialog, etc. In other words, the presenter controls the state of the view. The Model could be an async task or a RxJava Observable. The Presenter than gets the result back and tell the view to display it. You code is decoupled into 3 layers Model (also called business logic) and Presenter and View. The advantage is that you can change the view (i.e. replace progress dialog with an progressbar widget) without touching any code that loads data (Presenter and business logic). Additionally with MVP your code becomes testable.
So what you should compare is: Should I use AsyncTask or RxJava for loading data. With Mosby you would execute your http request in the presenter. While orientation changes are done the presenter doesn't get destroyed (and hence the background task doesn't get canceled).
However, MVP is not the solution for everything. If you have to ensure that a single http call is executed correctly (i.e. sign up for a community) you should think about using an android service.
What you can do is whatever you do in activity like your AsycTask and RecyclerView, put it inside a fragment and, setRetainInstance(true) in onCreateView() method of fragment and load that fragment in your activity.
setRetainInstance(true) won't let your fragment instance destroy when screen is rotated.
Your Observable should handle himself the fact on unsubscription. There are two mechanism for this:
check subscriber.isUnsubscribed. You can do it between or after "heavy" steps
add unsubscription callback. You can use it to stop long running operations, release resources etc
Take a look at this code:
Observable.create(
new Observable.OnSubscribe<List<items>>() {
#Override
public void call(Subscriber<? super List<items>> sub) {
sub.add(Subscriptions.create(new Action0() {
#Override
public void call() {
cancelLongRunningOperationIfItStillRunning();
}
}));
if (!sub.isUnsubscribed()) {
//start long running operation here
}
}
})
.doOnSubscribe(new Action0() {
#Override
public void call() {
}
})
You shouldn't reference to your activity/context/progress dialog etc inside Observable. Instead use doOnSubscribe if you want to do some side effects.
I'm using SQLite database in android and want to listening for any database changes. How can I do this?
Thanks for all future help!
In fact, SQLite offers such functionality: SQLite Data Change Notification Callbacks
How it can be used in Android is another story though..
SQLite doesn't offer any change listener functionality; you have to monitor it yourself. The simplest way to achieve this would be to send a Broadcast (or even better, a LocalBroadcast) anytime you modify the database. Some of the database libraries already offer functionality that is similar to this - check out GreenDAO.
a simple implementation of changeListener for the database on Android
suppose that you have a class to handle your queries in your android app, we need to make the database methods observable.
and also we need some listeners to observe the abovementioned observable. let's make the database handler observable:
let's make the observable interface:
public interface DatabaseObservable {
//register the observer with this method
void registerDbObserver(DatabaseObserver databaseObserver);
//unregister the observer with this method
void removeDbObserver(DatabaseObserver databaseObserver);
//call this method upon database change
void notifyDbChanged();
}
now implement the observable in your database class
public class LocalStorageDb extends SQLiteOpenHelper implements DatabaseObservable {
LocalStorageDb lDb;
//make it Singleton
public static synchronized LocalStorageDB getInstance(Context context) {
if (mlLocalQuickChatDB == null) {
mlLocalQuickChatDB = new LocalStorageDB(context.getApplicationContext());
}
return mlLocalQuickChatDB;
}
//there are some methods to do some queries
public void createContact(Foo foo, Bar bar){
//some queries here
//call the Observable Method to let know the observers that it has changed
onDatabaseChanged();
}
//now override the DatabaseObservable method which is responsible to notify the listeners
#Override
public void onDatabaseChanged() {
for (DatabaseObserver databaseObserver:observerArrayList){
if (databaseObserver!= null){
databaseObserver.onDatabaseChanged();
}}
}
//also you need functions to **register** or **unregister** the observers:
#Override
public void registerDbObserver(DatabaseObserver databaseObserver) {
if (!observerArrayList.contains(databaseObserver)){
observerArrayList.add(databaseObserver);
}
#Override
public void removeDbObserver(DatabaseObserver databaseObserver) {
observerArrayList.remove(databaseObserver);
}
then we need an observer to observe the changes:
public interface DatabaseObserver {
void onDatabaseChanged();
}
now in your activity or fragment, there is a function to fetch the changes, like getLocalContact. implement the observer on the fragment for example:
public class ExampleFragment extends Fragment implements DatabaseObserver {
LocalStorageDB localStorageDB;
#Override
public void onCreate(#Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
localStorageDB = LocalStorageDB.getInstance();
}
#Override
public void onPause() {
super.onPause();
localStorageDB.removeObserver(this);
}
#Override
public void onResume() {
localStorageDB.registerObserver(this);
super.onResume();
}
public ExampleFragment() {
// Required empty public constructor
}
#Override
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
// Inflate the layout for this fragment
return inflater.inflate(R.layout.fragment_example, container, false);
}
#Override
public void onDatabaseChanged() {
getLocalContact();
}
private void getLocalContact(){
//function to fetch contacts from database
}
}
Hi I'd like to add a new suggestion Incase of firebase usage. You can make a new json node for users messages and use On Data Change to detect the new number of unread messages then update your ui in the onDatachange. Is that smart or far away from the main idea?
Some third party libraries use hooks into the activity lifecycle to work correctly - for instance, the Facebook SDK (https://developers.facebook.com/docs/android/login-with-facebook/).
I'm having some trouble figuring out how to reconcile this model cleanly with a single-activity flow+mortar setup.
For instance, if I want to use Facebook login as part of a login Flow (w/ FlowView/FlowOwner), but not otherwise in the activity, what's the smartest way to pull this off if you need hooks for that particular flow in onCreate, onResume, onPause, onDestroy, onSaveInstanceState, onActivityResult, etc?
It's not immediately obvious what the cleanest path is - create an observable for each lifecycle activity stage and subscribe the flow to it? Seems like that path quickly devolves to the same Android lifecycle if you're not careful. Is there a better way?
I love the single activity model, and I'd really like to keep everything managed by flow/mortar and not activities, if possible. Or am I thinking about this in a way that is fundamentally making it more difficult than it should be?
We haven't had a need for start and stop so far, but do have a few spots that rely on pause and resume. We use an ActivityPresenter as you suggest, but avoid any kind of universal superclass. Instead it exposes a service that interested presenters can opt in to. This kind of hookup need is why the onEnterScope(Scope) method was added. Here's the code.
First, have the activity implement this interface:
/**
* Implemented by {#link android.app.Activity} instances whose pause / resume state
* is to be shared. The activity must call {#link PauseAndResumePresenter#activityPaused()}
* and {#link PauseAndResumePresenter#activityResumed()} at the obvious times.
*/
public interface PauseAndResumeActivity {
boolean isRunning();
MortarScope getMortarScope();
}
And have it inject the presenter and make the appropriate calls:
private boolean resumed;
#Inject PauseAndResumePresenter pauseNarcPresenter;
#Override protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
pauseNarcPresenter.takeView(this);
}
#Override public boolean isRunning() {
return resumed;
}
#Override protected void onResume() {
super.onResume();
resumed = true;
pauseNarcPresenter.activityResumed();
}
#Override protected void onPause() {
resumed = false;
super.onPause();
pauseNarcPresenter.activityPaused();
}
#Override protected void onDestroy() {
pauseNarcPresenter.dropView(this);
super.onDestroy();
}
Now interested parties can inject a registrar interface to opt-in to pause and resume calls, without subclassing anything.
/**
* Provides means to listen for {#link android.app.Activity#onPause()} and {#link
* android.app.Activity#onResume()}.
*/
public interface PauseAndResumeRegistrar {
/**
* <p>Registers a {#link PausesAndResumes} client for the duration of the given {#link
* MortarScope}. This method is debounced, redundant calls are safe.
*
* <p>Calls {#link PausesAndResumes#onResume()} immediately if the host {#link
* android.app.Activity} is currently running.
*/
void register(MortarScope scope, PausesAndResumes listener);
/** Returns {#code true} if called between resume and pause. {#code false} otherwise. */
boolean isRunning();
}
Have the client presenter implement this interface:
/**
* <p>Implemented by objects that need to know when the {#link android.app.Activity} pauses
* and resumes. Sign up for service via {#link PauseAndResumeRegistrar#register(PausesAndResumes)}.
*
* <p>Registered objects will also be subscribed to the {#link com.squareup.otto.OttoBus}
* only while the activity is running.
*/
public interface PausesAndResumes {
void onResume();
void onPause();
}
And hook things up like this. (Note that there is no need to unregister.)
private final PauseAndResumeRegistrar pauseAndResumeRegistrar;
#Inject
public Presenter(PauseAndResumeRegistrar pauseAndResumeRegistrar) {
this.pauseAndResumeRegistrar = pauseAndResumeRegistrar;
}
#Override protected void onEnterScope(MortarScope scope) {
pauseAndResumeRegistrar.register(scope, this);
}
#Override public void onResume() {
}
#Override public void onPause() {
}
Here's the presenter that the activity injects to make it all work.
/**
* Presenter to be registered by the {#link PauseAndResumeActivity}.
*/
public class PauseAndResumePresenter extends Presenter<PauseAndResumeActivity>
implements PauseAndResumeRegistrar {
private final Set<Registration> registrations = new HashSet<>();
PauseAndResumePresenter() {
}
#Override protected MortarScope extractScope(PauseAndResumeActivity view) {
return view.getMortarScope();
}
#Override public void onExitScope() {
registrations.clear();
}
#Override public void register(MortarScope scope, PausesAndResumes listener) {
Registration registration = new Registration(listener);
scope.register(registration);
boolean added = registrations.add(registration);
if (added && isRunning()) {
listener.onResume();
}
}
#Override public boolean isRunning() {
return getView() != null && getView().isRunning();
}
public void activityPaused() {
for (Registration registration : registrations) {
registration.registrant.onPause();
}
}
public void activityResumed() {
for (Registration registration : registrations) {
registration.registrant.onResume();
}
}
private class Registration implements Scoped {
final PausesAndResumes registrant;
private Registration(PausesAndResumes registrant) {
this.registrant = registrant;
}
#Override public void onEnterScope(MortarScope scope) {
}
#Override public void onExitScope() {
registrations.remove(this);
}
#Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Registration that = (Registration) o;
return registrant.equals(that.registrant);
}
#Override
public int hashCode() {
return registrant.hashCode();
}
}
}
So I've been porting a personal app over to flow and mortar to evaluate it for businesses use. I haven't encountered a scenario where I HAD to have the entire activity lifecycle yet, but as things stand with the current version of flow (v0.4) & mortar (v0.7), this is something I think you will have to creatively solve for yourself. I've recognized this as a potential problem for myself and have put some thought of how to overcome it:
I would also like to note that I haven't actually used the Facebook SDK. You will have to choose the best method for yourself.
You could post events from the activity for each Activity life cycle event. You essentially mentioned this approach using RXJava's Observables. If you really really wanted to use RXJava, you could use a PublishSubject for this, but I'd probably go with simple events from an EventBus you could subscribe to. This is probably the easiest approach.
You could also, depending on how the Facebook SDK works, possibly inject the Facebook SDK component in the activity, and from there initialize it. Then also inject the Facebook SDK component into your view to be used. Flow and Mortar's entire system is deeply integrated into dependency injection after all? This approach is also fairly simple, but depending on how the Facebook SDK works it probably isn't the best option. If you did go this route, you'd need to heed my warning at the bottom of this post.
This brings us to my last idea. Square had a similar problem when they needed access to an Activity's ActionBar in it's sub-views/presenters. They exposed access to the ActionBar in their sample app via something they called the ActionBarOwner.java. They then implement the ActionBarOwner interface and give an instance of itself in the DemoActivity.java. If you study how they implemented this and share it through injection, you could create a similar class. AcivityLifecycleOwner or something (the name needs work), and you could subscribe to callbacks on it from a presenter. If you decide to go down this route, and aren't careful you can easily end up with a memory leak. Any time you would subscribe to any of the events (I'd recommend you subscribe in the presenter), you'd need to make sure you unsubscribe in the onDestroy method as well. I've created a short untested sample of what I mean for this solution below.
No matter which approach you use, you'll probably need to make sure your onCreate and onDestroy methods actually come from your presenter, and not the exact events from the activity. If you are only using the sdk on a single view, the activity's onCreate has been called long before your view is instantiated probably, and the onDestroy for the Activity will be called after your view is destroyed. The presenter's onLoad and onDestroy should suffice I think, however I haven't tested this.
Best of luck!
Untested code example for solution #3:
All your presenters could extend this class instead of ViewPresenter and then override each method you wanted events for just like you would in an activity:
public abstract class ActivityLifecycleViewPresenter<V extends View> extends ViewPresenter<V>
implements ActivityLifecycleListener {
#Inject ActivityLifecycleOwner mActivityLifecycleOwner;
#Override protected void onLoad(Bundle savedInstanceState) {
super.onLoad(savedInstanceState);
mActivityLifecycleOwner.register(this);
}
#Override protected void onDestroy() {
super.onDestroy();
mActivityLifecycleOwner.unregister(this);
}
#Override public void onActivityResume() {
}
#Override public void onActivityPause() {
}
#Override public void onActivityStart() {
}
#Override public void onActivityStop() {
}
}
Activity Lifecycle owner that would be injected into the activity and then hooked up to the corresponding events. I purposely didn't include onCreate and onDestroy, as you presenter's wouldn't be able to get access to those events as they wouldn't be created or they would already be destroyed. You'd need to use the presenters onLoad and onDestroy methods in place of those. It's also possible that some of these other events wouldn't be called.
public class ActivityLifecycleOwner implements ActivityLifecycleListener {
private List<ActivityLifecycleListener> mRegisteredListeners
= new ArrayList<ActivityLifecycleListener>();
public void register(ActivityLifecycleListener listener) {
mRegisteredListeners.add(listener);
}
public void unregister(ActivityLifecycleListener listener) {
mRegisteredListeners.remove(listener);
}
#Override public void onActivityResume() {
for (ActivityLifecycleListener c : mRegisteredListeners) {
c.onActivityResume();
}
}
#Override public void onActivityPause() {
for (ActivityLifecycleListener c : mRegisteredListeners) {
c.onActivityPause();
}
}
#Override public void onActivityStart() {
for (ActivityLifecycleListener c : mRegisteredListeners) {
c.onActivityStart();
}
}
#Override public void onActivityStop() {
for (ActivityLifecycleListener c : mRegisteredListeners) {
c.onActivityStop();
}
}
}
Now you need to hook the lifecycle owner to the activity:
public class ActivityLifecycleExample extends MortarActivity {
#Inject ActivityLifecycleOwner mActivityLifecycleOwner;
#Override protected void onResume() {
super.onResume();
mActivityLifecycleOwner.onActivityResume();
}
#Override protected void onPause() {
super.onPause();
mActivityLifecycleOwner.onActivityPause();
}
#Override protected void onStart() {
super.onStart();
mActivityLifecycleOwner.onActivityStart();
}
#Override protected void onStop() {
super.onStart();
mActivityLifecycleOwner.onActivityStop();
}
}