todo-mvp | Todo Lite app following MVP Architecture in Java | Architecture library

As you can see in Google's samples (https://github.com/googlesamples/android-architecture), Activities create Presenters. Also Views attach to Activity and Presenters get views (Fragments) as parameter.

After Fragment transaction committed or Fragment (view) state restored Presenters get created and take Fragments (views) as parameter than call

That is an interesting question. I think my first answer will be no, Content Provider is not an implementation of the Repository Pattern.

As you mentioned, the Repository Pattern is meant to separate the business logic (domain) from the data layer. This approach allows you to create unit tests for your business logic (so domain should not depend on Android at all). By using a Content Provider you will need to have some sort of Android objects in your domain.

You could imagine a way to hide the Content Provider logic behind an Interface, but you will loose many of the nice stuff a Content Provider allows you to do.

If you are interested in Android Architecture I would recommend you to have a look at this Github project Android Clean Architecture. You will find a nice way to separate your presentation, domain and data layer, and the communication between the domain and data is done by using a Repository Pattern.

Hope this will help!

1. For what you want to achieve, you won't be using the FragmentLoader Class. Remove it (just for the tabs Activities). And the getSupportFragmentManager line.

2. In Home Activity, how you set up the tabLayout and Viewpager, it's fine. Remove addFragment line. Add the following after setAdapter:

   mTabLayout.setupWithViewPager(mViewPager);

3. In the tabPagerAdapter, just create the object presenter and fragment there. In the getItem method, case 0, you can have:

   HomeFragment homeFragment = HomeFragment.newInstance(); homePresenter = new HomePresenter(repo, homeFragment); return homeFragment;

4. Oh and in the TabPagerAdapter, you can pass your repo argument there for creating your presenter.

I hope I was clear. Let me know if you have any issues.

If I were you I would just put the logic of getting a token in a separate interactor (maybe named getTokenInteractor) and call that interactor from your others interactor who may need it. That way, it would be in an interactor that you chose either to use a token (and call or not your getTokenInteractor) and also in an interactor that you retrieve it and deal with errors. I would do the same for your "getVersionChanges" use case and let an interactor chain the calls.

Let's imagine you have a presenter who needs to display the version changes. He will call a first interactor (GetVersionChangesInteractor) who will first check if he has a token (by calling getTokenInteractor), then call GetLastLoginDateRepository for retrieving the date, and call GetVersionChangesRepository with that date and finally give the result to your presenter.

That way, your business logic can stay 100% in your interactor and your presenter can focus on how he will display that on screen.

By the way, if your API needs a token for every call you should move it in an Interceptor so you do not have to deal with it at every call.

Remove final from your class

replace DaggerAppComponent with DaggerApplicationComponent since your component name is ApplicationComponent not AppComponent

To be honest, fragments in Android are such a hassle, I get frustrated by them to this day after quite a few years of Android development. I use something like this, will be useful in this case:

You can have a Presenter without the need of having a view explicitly linked to that Presenter. In other words, you can have a presenter only to encapsulate some logical. In your case, you can have a presenter that only knows how to fetch and provide some images. And your view can make use of this specific presenter.

I did not get why would you have to pass the context to the model.

Right now, my idea is to add the web service request logic on the Model (I'm also using the Repository pattern) and the download logic on the Presenter. Something like this (the code is just an example):

You could do that. However, it seems more like MVVM where you put logical into Model and the Model knows how to fetch data.

In your case, you want to follow MVP, so the model only holds data (pieces of information/data). So, you can have one Presenter that knows how to download your images. And you can have some Utils that could help you with the request part. You can have another model for that Presenter that download images for saving your images, like a cache. And, again if you want to make some sort of cache logic, you should do on the same presenter that knows how to download an image. Or, if it becoming too big and complex, you can make a Presenter that only knows hot to cache stuff.

Once your Presenter only knows how to download an image, or only knows how to save an image. You can test it easy, just pass a link to your Presenter method and check if it could handle download the image.

Note: I did not understand how could be convenient or important you pass context for your model unless it knows some sort of cache using Android preferences?

NOTE 2: I would love if I could unit test this part of the app (Mocking the DownloadManager). So, passing the Context to the Model is not an option, as it breaks the MVP (IMHO) and would be much harder to unit test it.

1. Since the singleton pattern tries to guarantee only one living instance of a given class at any time, it's not very compatible with the idea of a versatile class that can accept or produce different results depending on its current generic type. For generics to be any useful, you need to be able to create different flavors of the same type (usual exemple: a List of String and a List of Integer)
2. N/A
3. If you are passing a parameter to the getInstance of a singleton, then you are not really wanting a singleton but a factory. A singleton can only be non parameterized, or else the first call freezes the context.

Do not abuse of singleton. They are the first pattern you may try to implement, because it's the first in every book, but it's almost always at least useless, at most a performance bottleneck and a bad design decision (not very OO)

EDIT:

you assumption that each new instance couldn't share the same cache is basically wrong, for two reasons:

1. not using a Singleton does not forces you to use several instances of the same type. It just allows you to do so, as well as enabling inheritance (which the singleton simply cann't). If you use Spring and a singleton-scoped bean (the default), then your repository exists only once in memory - even if it does not implement the singleton pattern as described in the books - and is shared between all consummers (thus only one cache). This can be accomplished without spring too, just use some kind of factory or registry.
2. caching with an hashmap in your class is a bit fishy, too. Caching is an implementation detail and you should not try to implement it in this way (you will end up eating the whole memory quite easily, at least, use WeakHashMap instead - or the Guava version, using CacheBuilder). You could also declare your cache as static so it will only exist once in memory. Modern applications treat caching as an aspect, like transactions for example. It should not leak to your code. For example, look at ehcache, redis, terracotta, etc. they all implement the JSR-107 and are configured directly on your method prototype, with some annotation (@Cacheable, etc.). Ho and caching usually goes to the service layer - you do not cache the state of the db, you cache the responses sent to the users after processing of the business logic (even if this rule is not absolutely strict)

The singleton also has a very big problem: it is directly responsible to instantiate the object, that is, direct use of the new keyword. This is a pain, as you can not change the concret type of the implementation at runtime (for testing purpose, or any other use). Look at the factory/factory method pattern to see a better way to change the type at runtime.

What you can do is having an abstract base class, generified, that your concret dao will extend (but those will not be generic). Something like this: