Develop Reference

MVVM - How to cleanly incorporate AlertDialog?

I have a FragmentOne which contains the MVVM pattern. The Fragment has it's own ViewModel, FragmentOneViewModel. I am unsure on how to cleanly incorporate an AlertDialog in my case.
In the Fragment it contains a RecyclerViewAdapter, with each row that contains a Button to create an AlertDialog. Do I need a ViewModel for the AlertDialog?
Or can I use an interface callback and implement it on my Fragment, which will be called when the user clicks on buttons in the AlertDialog. And then use that input to call the Fragment's ViewModel?:
public class ActivateUserDialog extends AlertDialog {
//Should I use callback methods?
private Context mContext;
public interface DialogOnClickListener{
void onCancelBtnClick();
void onConfirmBtnClick(String amount);
}
public ActivateUserDialog(#NonNull Context context) {
super(context);
this.mContext = context;
}
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.dialog_activate);
ButterKnife.bind(this);
}
#OnClick(R.id.btn_cancel)
public void onBtnDismiss() {
this.dismiss();
}
#OnClick(R.id.btn_confirm)
public void onBtnConfirm() {
//Call the fragment
MainActivity activity = (MainActivity) mContext;
MembersFragment fragment = (MembersFragment) .... get the fragment;
fragment.onConfirmBtnClick(amount);
}
}
And then calling the viewmodel from the callback method:
//Fragment class:
public class MembersFragment extends Fragment implements ActivateUserDialog.DialogOnClickListener
#Override
public void onConfirmBtnClick(String amount){
mViewModel.activateUser(amount);
}
Is this a clean way to do it?

I don't think there's a single answer to it and would say it's opinionated. Both would be valid in my opinion.
You also need to consider that architecture components don't work "out of the box" with AlertDialogs, so even if you want a VM for it you will have to retrieve it through the fragment/activity (basically a ViewModelProvider) or use some other solution like DI.
You would also have to manage the lifecycle of the AlertDialog to gain some of the benefits of the ViewModel.
Here are possible solutions:
Consider the AlertDialog as part of the View of FragmentOne and communicate with it via callbacks. In the implementation communicate with FragmentOneViewModel.
Use a DialogFragment with a ViewModel instead. Since DialogFragment is basically just a Fragment you get all the benefits of the architecture components ViewModel. You can either share FragmentOneViewModel between the two or create a new ViewModel dedicated to the dialog. Whether to share or create a new one is up to your needs but I would consider the complexity of the Dialog and whether it should be stand-alone. If you decide to share the ViewModel, be careful which ViewModelProvider you use to make sure they are actually shared and not a different instance.
As for communicating back from the AlertDialog, I would suggest using an interface with callbacks instead of passing Context and casting directly.
You can accept an implementation in the constructor.

You want to use a dialog box on some click in recycler-view adapter which is based on MVVM pattern and want some callback on adapter after dialog box action right?
Yes this is what I am doing in my code above, but I don't know if
this is the best practice way to do it with Dialog – DIRTY DAVE
As I think its a good way easy to understand and maintainable. However, dialog box is part of the UI and so interaction with it. So it should be in the Fragment. The fragment then interacting with the view-model is a reliable way to do things as that's the main home for your logic.
As the MVVM design pattern is similar to the well known MVC pattern in that the M (Model) and V (View) are relatively the same. The only difference resides between the C (Controller) and the VM (View Model).
Model
Represents the Data + State + Business logic. It is not tied to the view nor to the controller, which makes it reusable in many contexts.
View
Binds to observable variables and actions exposed by the View Model. It is possible for multiple views to bind to a single View Model.
View Model
Responsible for wrapping the model and preparing observable data needed by the view. It also provides hooks for the view to pass events to the model. An important thing to keep in mind is that the View Model is not tied to the view.
Source

Implementing MVP on a single activity with two (or multiple) fragments

I'm developing a small application that shows a list, and when an item is clicked it opens a secondary screen with the item details. I want to implement MVP as my architecture for this app, and i have been struggling figuring out how to do that when I have a single activity with 2 fragments.
Some questions came up as when an item from the list is clicked, a callback is sent to the first presenter, but at this point, who is in charge of opening the second fragment? do the presenters 'talk' to each other? should i do it through the activity?
Been looking around for examples of single activity with multiple fragments implementing MVP, but couldn't find something like that yet.
(Yes, it can be done otherwise, but the purpose of the app is to learn implementing MVP on a single activity with multiple fragments)
Appreciate any help!
Thanks!

After looking into different existing MVP sample projects I've decided to follow most of the concepts in the 'TODO-MVP-TABLET' git project by Google which can be found here:
https://github.com/googlesamples/android-architecture/tree/dev-todo-mvp-tablet
I've chosen this solution due to the level of abstraction and the ability to later on reuse any fragment in other activities without changing any code.
Solution principles:
Each fragment has a presenter defined by an interface.
There is a bigger presenter implementing all the smaller presenters.
The bigger presenter holds references to all of the smaller presenters and when a method is invoked it simply delegates the action to the relevant presenter.
Fragments are given the 'big' presenter as their presenter without actually being aware this is the case.
Smaller presenters should hold the reference to the view.
Diagram taken from Google's github page:
Update:
Link isn't valid, seems like Google removed the project from their samples. Will leave it in case they reupload it.

There are possibly many ways to implement MVP. Majorly we use 3 things.
- View
- Presenter
- Modal
you should be clear with your working of screen before creating these things.
eg if you want a login screen.
create structure (using interface) of activity first. like what your presenter and view will contain
eg.
public interface LoginPresenter {
void validateCredentials(String username, String password);
void onDestroy();
}
View structure:
public interface LoginView {
void showProgress();
void hideProgress();
void setUsernameError();
void setPasswordError();
void navigateToHome();
}
Now these are the classes you need to implement on your view class (Activity/fragment) and presenter where your logic part resides.
Now about your queries.
which means the activity will have both presenters instances.
No, your activity should not require to have multiple presenter. it already has opened fragment reference (by findfragmentby id or tag).
who is in charge of opening the second fragment?
you can open it from any of them either Activity/fragment.
if Activity use getfragmentsupportManager
if fragment use getfragmentManager
NOTE: For more info follow this git example.
https://github.com/antoniolg/androidmvp

Android MVP WeakRefrence

In mvp we save that reference of an activity in a weak reference.
WeakReference<Activity> view = new WeakReference<Activity>(activity);
If we lose the reference. can we get it back?

If you lose the reference to your Activity it means the activity was garbage collected and it doesn't exist anymore. You can't get back what doesn't exist.
Ex. If this happens because of configuration change it means a new activity was created.
You need a way to attach the newly created view to the same presenter.
If you are looking for libraries to help you, take a look at mosby and nucleus.

I don't think you should be saving a reference to an Activity in MVP at all - doesn't matter if it's hard or weak!
I'm assuming you're storing this reference in the Presenter. To really decouple the layers you should create an interface that describes your View (Activity) and use it instead of the activity.
So you'd do:
public interface LoginView {
displayUsernameError(String error);
displayPasswordError(String error);
openMainScreen();
}
Your Activity should implement the interface from above.
public class LoginActivity implements LoginView {
...
}
In your presenter you'd have:
class LoginPresenter {
private LoginView mView;
public LoginPresenter(LoginView view) {
mView = view;
}
public onLoginButtonClicked(String username, char[] password) {
...
mView.openMainScreen();
}
}
Immediate benefits of doing this:
The different layers are really decoupled. You can change your Activity (say you decide to use Fragments instead) without touching your Presenter.
Your presenter is fully testable using JUnit only! No need to use anything fancy to verify your interactions are correct, just plain Mockito to mock the LoginView.
One other point to note - are you sure you want your Presenter to outlive your View? There are some situations when that can't be avoided, but in most cases they have the same life span - when the View is destroyed the Presenter should be as well.

How did you set the reference in the first place?
You should be setting it with a setter method in Activity's onCreate.
This "setter" method is often called "attach" or "bind".
fun attach(view: View) {
this.view = view
}
So when new Activity is created due to configuration change, it will set itself to the presenter again. Note that you might be dealing with a new instance of the presenter too. However, based on your question I believe you want to attach the newly created activity to the same instance of presenter. If you got your presenter scoped right, this will work for both cases :)

Android Fragments fundamentals: why? Is this conceptually wrong?

I have a question about "proper programming" in Android.
I am currently developing an app using fragments. It involves dynamically added fragments to Activity, fragments inflated from XML, nested fragments from XML or dynamically added. Let's just say, a bit of everything.
The concept this question focuses on is the communication process involved with fragments. So, I've read the docs and this is not the first time I try to use fragments.
The common sense (and docs) tell that if a Fragment wants to speak or communicate with it's activity, we should use an interface.
Example:
TestFragment
public class TestFragment extends Fragment {
private TestFragmentInterface listener;
public interface TestFragmentInterface {
void actionMethod();
}
#Override
public void onViewCreated(View view, Bundle savedInstanceState) {
if (getActivity() instanceof TestFragmentInterface) {
listener = (TestFragmentInterface) getActivity();
}
// sending the event
if (listener != null) listener.actionMethod();
}
}
TestActivity
public class Test implements TestFragmentInterface {
#Override
public void actionMethod() {
..
}
}
Everything fine here.
This improves re-usability, as my TestFragment this way can interact with any kind of Activity, given the Activity implements the interface I declare.
The other way around, the Activity can interact with the fragment by holding a reference and calling its public methods. This is also the suggested way to fragment-to-fragment communication, using the Activity as a bridge.
This is cool, but sometimes it feels like using an interface for this is just a bit "too much".
Question A
In the scenario the fragments I attach have a pretty focused role, meaning they are done for that particular activity and would not be used otherwise, is it conceptually wrong to ignore the interface implementation and just do something like
((TestActivity) getActivity().myCustomMethod();
?
This also goes to the scenario where (not my case, but just taking it as a "at its worst") my activity has to deal with a wide variety of these DIFFERENT fragments, meaning it should implement one method for every fragment it should handle. This brings the code to a big mess of "potentially not-needed lines".
Moving further on: still with the use of "focused" fragments, aimed to work only under certain way, what is with the use of nested fragments?
Added them like
public class TestFragment extends Fragment {
private void myTestMethod() {
NestedFragment nested = new NestedFragment();
getChildFragmentManager()
.beginTransaction()
.add(R.id.container, nested)
.commit();
}
}
this binds NestedFragment to TestFragment. I say it again, NestedFragment, just like TestFragment, is to be used only in this way, it has no meaning to work otherwise.
Back to the question, how should I behave in this situation?
Question B
1) should I provide an interface in NestedFragment, and make so that TestFragments implements NestedFragmentInterface? In this case I would act as following
NestedFragment
public class NestedFragment extends Fragment {
private NestedFragmentInterface listener;
public interface NestedFragmentInterface {
void actionMethodNested();
}
#Override
public void onViewCreated(View view, Bundle savedInstanceState) {
if (getParentFragment() instanceof NestedFragmentInterface) {
listener = (NestedFragmentInterface) getParentFragment();
}
// sending the event
if (listener != null) listener.actionMethodNested();
}
}
2) should (or could) I ignore interface, and just call
getParentFragment().publicParentMethod();
?
3) should I create the interface in NestedFragment, but let the activity implements it, so that the activity will call TestFragment ?
Question C
Regarding the idea of using the Activity as a bridge between fragments, I believe it is made so for proper handling lifecycle of all these objects. Is it still viable to do a direct fragment-to-fragment (using interface or directly call public methods) while trying to handle manually the exception the system might throw me?

Ill do my best to answer the wall of text here :)
Question A:
Fragments are designed to be reusable modules that can be plug and played with any activity. Because of this the only correct way way to interface with the activity is to have the activity inherit from a interface that the fragment understands.
public class MapFragment extends Fragment {
private MapFragmentInterface listener;
public interface MapFragmentInterface {
//All methods to interface with an activity
}
#Override
public void onViewCreated(View view, Bundle savedInstanceState) {
// sending the event
if (listener != null) listener.anyMethodInTheAboveInterface();
}
}
Then have the activity implement the interface
public class MainActivity extends Activity implement MapFragmentInterface{
//All methods need to be implemented here
}
This allows your fragment to be used with any activity as long as the activity implements this interface. The reason why you need this interface is because the fragment can be used with any activity. Calling a method like
((TestActivity) getActivity().myCustomMethod();
relies on the fact that your fragment only can work within a test activity and therefore "breaks" the rules of fragments.
Question B and C:
Assuming that you are following the correct guidelines for fragments and that they are independent modules. Then you should never have a situation where fragments need to know about each other. 99% of the time that people think they need fragments to directly communicate they can re-factor their problem to the situation I gave above by using a MVC patten or something similar. Have the activity act like the controller and tell the fragments when they need to update and then create a separate data store.

I will try to clear it all a little bit.
First of all, consider you approach of setting listener for fragment. It is no good to set listener in onViewCreated method, because it leeds to excess reseting listener any fragment is created. It is enough to set it up into onAttach method.
I told about code lines. Take me to notice, it is good to have BaseFragment implemented common behavior in you app as setting FragmentListener creating view from resource.
And more than that to reduce code lines and to get part of code reuse you can use generic in BaseFragment. So look at next code snippet:
public abstract BaseFragment<T extends BaseFragmentListener> extends Fragment {
T mListener;
public void onAttach(Activity activity) {
super.onAttach(activity);
if (Activity instanceof T)
mListener = (T) activity;
}
abstract int getLayoutResourceId();
#Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
View layout = inflater.inflate(getLayoutResourceId(), null);
// you can use some view injected tools here, mb ButterKnife
return layout;
}
}
Answer A (For Question A):
If you have fragment only exactly one activity you need to decide: "Do you really need to use Fragment here?". But mb it is good to have fragment exactly for one activity to extract some view logic from activity and clearing base logic. But for clearing base architecture logic for your app use Listeners. This will make life easier for other developers
Answer B:
For nested fragments you need to solve, what they need to use exact activity or just fragments and use it as a bridge to other system. If you know that nested fragment will be nested all time you, you need to declare parent fragment as listener otherwise you have to use other approach.
Notice:
As the base approach to communicate between diff part of App you can use events, try too look at event bus for example. It gives you common approach for communication and you can extract logic of calling custom methods of listeners and more another, all logic will be situated into handling events and you will have one mediator system for cooperation.
Answer C:
I partially explain one of approaches to cooperating between fragments. Using one event dispatcher avoids you to have many listeners for all different communication. Some times it is very profitably.
Or I think it is more usable to use Activity, or other class lives in Activity, for a mediator for Fragments cooperation because there is many situation of Fragments changing during lifecycle both handling and system. And it focuses all this logic in one place and makes your code more clear.
Hope my considerations helps you.

Is it preferable to use Activity.onAttachFragment or Fragment.onAttach to communicate between an Activity and a nested fragment?

The Android documentation suggests that to communicate from an activity to a hosted fragment, the fragment can define a callback interface and require that the host activity implement it. The basic pattern involves implementing onAttach in your fragment, and casting the activity to a callback inteface. See http://developer.android.com/guide/components/fragments.html#CommunicatingWithActivity.
Here's an example of providing a fragment some initialization data, as well as listening for a navigation callback.
public class HostActivity extends Activity implements FragmentHost {
#Override
UiModel getUiModel() {
return mUiModel;
}
#Override
FragmentNavListener getNavListener() {
return mNavListener;
}
...
}
public class HostedFragment extends Fragment {
#Override
public void onAttach(Activity activity) {
super.onAttach(activity);
if (activity instanceof FragmentHost) {
FragmentHost host = (FragmentHost) activity;
setUiModel(host.getUiModel());
setNavListener(host.getFragmentNavListener());
}
}
...
}
Compare this to using onAttachFragment in the host activity to explicitly initialize the fragment:
public class HostActivity extends Activity {
#Override
public void onAttachFragment(Fragment fragment) {
super.onAttachFragment(fragment);
if (fragment instanceof HostedFragment) {
HostedFragment hostedFragment = ((HostFragment) fragment);
hostedFragment.setUiModel(mUiModel);
hostedFragment.setNavListener(mNavListener);
}
}
...
}
To me, it seems like the first pattern has some drawbacks:
It makes the fragment harder to use from different activities, since
since all of those activities must implement the required interface. I can imagine cases where a given fragment instance doesn't require being fully configured by the host activity, yet all potential host activities would need to implement the host interface.
It makes the code slightly harder to follow for someone unfamiliar with the pattern being used. Initializing the fragment in onFragmentAttached seems easier to follow, since the initialization code lives in the same class that creates the fragment.
Unit testing using a library like Robolectric becomes harder, since when calling onAttach, you must now implement FragmentHost rather than just calling onAttach(new Activity().
For those of you who've done activity to fragment communication, what pattern do you find preferable, and why? Are there drawbacks to using onAttachFragment from the host activity?

I cant speak personally with respect to testing but there is alternatives to fragment / activity callback interface communication.
For example you can use a event bus to decouple the fragments and your activity. An excellent event bus can be found here:
Otto - An event Bus by Square
It is actively being developed by some very talented engineers at Square.
You can also use the LocalBroadcastManager that is packaged in the Android Support Library.
LocalBroadcastManager
Eric Burke from square has a presentation where he mentions both which can be found here:
Android App Anatomy

Update : As per the latest guidelines we are supposed to use a sharedViewModel class to communicate between fragments and activities.
However if you don't use viewModels and use callbacks, you should still consider removing onAttachFragment callback as it is deprecated now.
Instead on onAttachFragment, the suggested way is to add a listener to your fragmentManager who is associated with that transaction using addFragmentOnAttachListener.
See the example below:
childFragmentManager.addFragmentOnAttachListener { _, fragment ->
if (fragment is RetryDialogFragment) {
//Do your work here.
}
}
You should also be mindful of where you add this listener. You most probably want to add this listener before you execute the fragment transaction and should make sure that you are not adding the listener more than once.

I have used the Fragment.onAttach(...) pattern in my last project. I see two advantages:
you can check early that the hosting activity implements the required interface and throw an exception if not
there's less risk of holding onto a reference of the hosting context after the fragment has been detached
In order to take advantage of 2., you must not store references to UiModel and NavListener, as you do in your code sample. Instead, whenever you want to interact with these instances, you should use code like ((FragmentHost) getActivity).getNavListener().onNav(this), or alternatively ((FragmentHost) getActivity).onNav(this). You could store the fragment host in a field which you set to null in onDetach(...) as a middle ground approach, if you want to avoid the constant casting.
I agree that initializing a fragment from the activity that creates it seems more intuitive.
Having said all that, I'm going to skip fragments altogether in my current project. The following post reflects the lessons learned from my last one pretty well: https://corner.squareup.com/2014/10/advocating-against-android-fragments.html