Hi guys,

It looks to me as though the presenters' lifecycles are coupled to their instantiating activity's. Please let me know if I missed something, and whether or not this is a conscious design choice.

Thank you!

Dagger_GalleryActivityTest$TestGalleryComponent

F:\Git\Samples\u2020-mvp\app\src\androidTest\java\ru\ltst\u2020mvp\tests\GalleryActivityTest.java Error:(89, 5) error: ru.ltst.u2020mvp.tests.GalleryActivityTest.TestGalleryComponent (unscoped) cannot depend on scoped components: @ru.ltst.u2020mvp.ui.ApplicationScope ru.ltst.u2020mvp.U2020Component @ru.ltst.u2020mvp.ui.gallery.GalleryScope ru.ltst.u2020mvp.ui.gallery.GalleryComponent

Hi, I am looking at your code in GalleryDatabase, and I see this comment:

    // Warning: Gross shit follows! Where you at Java 8?

galleryService.listGallery(section, Sort.VIRAL, 1) .filter(Results.isSuccess()) .map(new GalleryToImageList()) .flatMap(new Func1<List<Image>, Observable<? extends Image>>() { @Override public Observable<? extends Image> call(List<Image> iterable) { return Observable.from(iterable); } }) .filter(new Func1<Image, Boolean>() { @Override public Boolean call(Image image) { return !image.is_album; // No albums. } }) .toList() .subscribeOn(Schedulers.io()) .observeOn(AndroidSchedulers.mainThread()) .subscribe(galleryRequest);

I have thought about how to enhance this code block with Java 8, but cannot figure it out. I mean, Java 8 Streams are nice, but they won't provide any improvement to the code you've already written.

Thoughts? Igor

Hi! could you please verify if in the class GalleryComponent.java this line GalleryActivity.Presenter presenter() is necessary? Direct like: https://github.com/LiveTyping/u2020-mvp/blob/master/app/src/main/java/ru/ltst/u2020mvp/ui/gallery/GalleryComponent.java#L14

In can compile/execute the app without the line, in fact the presenter in injected in the GalleryActivity.

Ps. I'm studying/testing Dagger2 in these days, so I'm not sure if this is a real issue or not! :wink:

After unlock device the previous activity remain above of lock screen. For understanding, please see video

Case from video:

1. Start application
2. Lock device
3. Unlock device (Showed previous activity of application instead of common lock screen)
4. Select item (After that showed common lock screen)
5. Unlock deveice (Passes to next activity after click by item)

Hi, What is the purpose of ActivityHierarchyServer NONE here: https://github.com/IgorGanapolsky/u2020-mvp/blob/master/app/src/main/java/ru/ltst/u2020mvp/ui/ActivityHierarchyServer.java#L14

It seems similar to the Empty inner class below it.

In u2020-mvp as example of app the Registry looks like a good solution for attachment/detachment a view to presenter. But for production app there's problems with attachment view to presenter when I try to open the same activity that already has existed in activity stack with Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_SINGLE_TOP flags.

For example, there're in activity stack:

Activity A1 (ViewA1, presenterA1) Activity B (ViewB, presenterB)

And I add new Activity A:

Activity A2 (ViewA2)

So, I haven't had the attached presenter.

What it's happened when I made startActivity(ActivityA.class):

ActivityA2.onCreate(); /* Created a new presenter for Activity2. 
Generated key in Registry class. This key the same like as at 
Activity1 presenter. So it will be replaced. */
ActivityA2.onStart(); /* Look for the existing presenter by key 
and makes the attachment the view to presenter. */
ActivityB.onStop();
ActivityA1.onStop(); /* Look for the presenter by key and makes
 the detachment view from presenter. */

So, we got ActivityA2 with presenter without attached view.

It's hard to find a good example of Dagger2 being used with different product flavours. Yours seems to be a good example, but a lot of the SDKs are out of date. I've updated a bunch of them.

• added test component which provides application scope dependencies and can inject test classes
• added test module which force mock mode
• added test application inherited from project application which eliminates the needs to change app component runtime
• changed test instrumentation runner to use test project application instead of regular app during instrumentation testing
• added some tests
• added some testing utils
• refactored existing tests

This isn't so much of an issue but more of a design question. How would you go about reusing common views in u2020-mvp?

For example, I'd like to create a common LoginView which can be shown in different activities/fragments. The associated LoginComponent, LoginPresenter, and LoginModule all use @LoginScope. The idea here is to have all the functionality of logging-in encapsulated in LoginView which I can use at anytime.

I tried to accomplish this in few ways and ran into issues. For the examples below, let's assume we want to put LoginView into our MainActivity.

• Include LoginModule in MainComponent as follows. I ran into issues with Dagger complaining about @LoginScope being used in @MainScope.

@MainScope
@Component(
        dependencies = ApplicationComponent.class,
        modules = {
            MainModule.class,
            LoginModule.class
       }
)

• Defining LoginComponent as the "parent" component and MainComponent as a subcomponent. This solution is not desirable either because the common component acts as the "parent" component. Also you run into the issue of not being able to use multiple common components.

@MainScope
@Subcomponent(
    modules = MainModule.class)

@LoginScope
@Component(
        dependencies = ApplicationComponent.class,
        modules = LoginModule.class
)

Is there no proper way to use common views in u2020-mvp?

The other option is to include the common view as part of a Fragment however there isn't an example here of mvp with Dagger injection of Fragments, views and its presenters.

Now we're making the attaching/detaching View to Presenter through onStart()/onStop() methods in Activity. I offer to use onAttachedToWindow()/onDetachedToWindow() methods instead of them.