View

#View Privvy Views refer to the view classes provided by the Android framework (i.e. Activity, Fragment, etc). Privvy Views, however, are dumb classes whose only purpose is to inflate layouts from XML, receive UI events (such as a click), and pass them off to be handled elsewhere (their Presenter). There is minimal to no logic in the entire class due to this delegation of responsibility. In addition to the references to the UI widgets, Views need a reference to their Presenter, which they get from the Host component (more on Dagger to come).

There is some boilerplate that goes into a Privvy View that would be better suited in a base class. This will likely be an option in a future release.

Example of a Skeleton View is below. Every portion of this code is necessary:

import ....

/**
* Views must implement their Component-specific Contract's View interface
**/
public class SkeletonFragment extends Fragment implements SkeletonContract.View {

    @Inject
    SkeletonComponent skeletonComponent;

    private SkeletonContract.Presenter presenter;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        //The MainActivity is whoever the Host to this Fragment is
        ((MainActivity) getActivity()).hostComponent.newPrivvyComponent().inject(this);
        presenter = skeletonComponent.presenter();
    }

    @Nullable
    @Override
    public View onCreateView(LayoutInflater inflater, @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
        return inflater.inflate(R.layout.main_activity, container, false);
    }

    @Override
    public void onViewCreated(View view, @Nullable Bundle savedInstanceState) {
        super.onViewCreated(view, savedInstanceState);
        ButterKnife.bind(this, view);

        //Setting the View is required for the Presenter to know who is fulfilling the View Contract
        //In an Activity, one would call this method in the onCreate callback, after setContentView
        presenter.setView(this);
    }

    @Override
    public void onDestroyView() {
        super.onDestroyView();

        //This is to clear the reference to the View to prevent memory leaks
        //This will also unsubscribe any RxJava Subscriptions in the Presenter.
        presenter.onDestroyView();
    }

    /* Additional overridden Contract methods would go here
    @Override
    void displayNumber(NumberViewModel number) {
        textView.setText(number.value());
    } */
    
}

If a View holds a reference to any layout in need of an adapter, not much changes by way of architecture. The adapter would simply define a nested interface, and the View would be passed in as a callback to the adapter's constructor. In the event of a UI interaction, the View would handle that event and pass it to its Presenter, business as usual.