Weird presenter lifecycle behavior?

[oradkovsky]

Hi.

I am observing this behavior that looks like bug to me:

pseudo code of presenter's onCreate { restartableLatestCache (ABC, () ->{}, (v,r)->{}, (v,e)->{} }

if(savedState==null) {
    start(ABC)
}

}

When app runs, presenter's screen is rendered correctly. Now in certain situations (can also be emulated on android emulator by turning Background Process Limit to 1, running the above screen -> Home -> run any other app -> Home -> run orginal app), of the above block only if(savedState==null) is executed (false), then presenter goes directly into onTakeView. I was expecting restartable's (v,r)->{} block to be called. Is described behavior by design?

Bigger picture shown by logging:

1. normal run: enter presenter's oncreate-> savedstate check (true) -> start restartable -> onTakeView -> restartable's payload gets delivered
2. pressing android's "Home": onDropView -> onSave
3. getting back to app after jumping to other app under the above mentioned dev settings: presenter's onCreate gets called -> savedstate check (false) -> going directly into onTakeView

[konmik]

If Observable completes it will not be restarted by itself after the process recreation.

If you need it to be started every time, just remove the if condition :)

[oradkovsky]

Thnx for answer. Pls share real world use case of restartablelatestcache then? I was so far relying on this claim: "In case of process restart Nucleus automatically restarts background tasks. "

[konmik]

it restarts them if they were not completed and were killed.

cache is needed when you read profile from network, for example. You don't want to make requests every time user flips the screen.

[oradkovsky]

ok. last question before I stop bothering you :)

can the following scheme be implemented with this library: presenter created -> read profile from network -> presenter recreated -> read profile from state ?

my example at the beginning of this thread was my effort to implement the above with means of the library.

[konmik]

where are you going to keep the state?

[oradkovsky]

I was normally using icepick to manage state (and presenter's onsave/oncreate)

[konmik]

Then you don't need to retry background task. I would keep the profile inside of view to avoid unneeded complexities in the presenter.

[oradkovsky]

Thing is, I like to store all the logic in presenter and keep views thin, and I really like how your library is allowing the logic to "know" when view becomes available. I think I can implement what's needed with restartfirst and if(state==null) logic. Thnx for replying.

[oradkovsky]

I was normally using icepick for the purpose,

23 жовт. 2016 12:55 дп "Konstantin Mikheev" notifications@github.com пише:

where are you going to keep the state?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/konmik/nucleus/issues/117#issuecomment-255556320, or mute the thread https://github.com/notifications/unsubscribe-auth/AJPusORP8_aT_fMyaDdUykagzfiWtkZnks5q2oY5gaJpZM4KYDUd .