Comments (9)
Would you be open for a PR? I have a working solution which looks roughly like this
Bundle
is wrapped by aTiBundle
interface (and their implementation for the JVM and Android in the corresponding modules)TiConfiguration
gets a new field which enables this feature (off by default)TiPresenter
has a newonSaveInstanceState(TiBundle)
method
For recreating the state I see two options. The first would be changing TiPresenter.onCreate()
to onCreate(TiBundle)
. Problem is that this would break every app out there. So better would be this option:
TiPresenter
has the methodsrestoreInstanceState(TiBundle)
andonRestoreInstanceState(TiBundle)
, which is invoked by the delegates, if the presenter needs to be recreated (not found in memory) and the bundle is not null- The method is invoked before
.create()
, because then we already need to use the saved state
That's nothing complicated, but would be a nice addition.
(I also saw the other issue where someone needs to store the webview state in a bundle, this would fix this issue probably, too)
from thirtyinch.
ThirtyInch can nothing do against process death and has no APIs to restore the state. It was developed by assuming that the process rarely gets killed which is true for modern phones.
When you see your app process getting killed you have all Android tools to restore the state you already know.
savedInstanceState
You can save the state of the presenter in onSaveInstanceState(Bundle)
and restore the state when the presenter gets recreated providePresenter()
after a process death
public class MyActivity extends TiActivity<MyPresenter, MyView> implements MyView {
// make it accessible in providePresenter()
private Bundle mSavedInstanceState = null;
@Override
protected void onCreate(final Bundle savedInstanceState) {
mSavedInstanceState = savedInstanceState;
super.onCreate(savedInstanceState);
}
@Override
protected void onSaveInstanceState(final Bundle outState) {
super.onSaveInstanceState(outState);
// using a byte[] here because the presenter should have zero Android dependencies
// Bundle is hard to mock
outState.putByteArray("presenterState", getPresenter().getPersistentState());
}
@NonNull
@Override
public MyPresenter providePresenter() {
// called when the presenter gets first created and
// when the presenter gets created after a process death
byte[] persistentState = null;
if (mSavedInstanceState != null) {
persistentState = mSavedInstanceState.getByteArray("presenterState");
}
return new MyPresenter(persistentState);
}
}
app storage
You should really think about your usecase. Often it is not useful to restore a state when the Activity was in background for days. Another solution is to manually save the state as file in the app directory. Or in the SharedPreferences. It could be good practice to also save the timestamp and check if the state is still relevant in the current situation.
from thirtyinch.
I really love seeing what @vRallev suggested, this will save us loads of stuff to do on the activity/fragment, imagine we are saving some state of an expensive API call in the presenter, the activity is being recreated due to some activity in the backstack is being crashed, now the whole activities are being recreated and the presenter lost its state & data. i really appreciate your effort on making this possible @vRallev & @passsy
from thirtyinch.
this also could happen in Activity B where it crashed, then activity A (MainActivity) is now being recreated.
from thirtyinch.
@vRallev I fear that the TiPresenter
ends up being a subset of Activity
with similar callback methods and similar lifecycle but surviving orientation changes. While this could be a reasonable direction for this library I'm looking forward to move it in a more advanced direction.
I prefer to interpret callbacks from the Activity like Activity#onSaveInstanceState(outstate)
as indicators when it is a good time to do something rather then using the bundle to save the state.
I'd prefer writing the state to disk without having to worry about the Activity. onSaveInstanceState
would trigger this mechanism but also the user of Ti
could decide when it is a good time to save the state and do it manually as often as he likes. It also grants us to save the state while the Activity is paused and onSaveInstanceState has already been called. Think about a heavy calculation which finishes when the activity is in background. It's not possible to save such a state with onSaveInstanceState
.
The past showed that using Activity APIs isn't the best solution. I.e. onRetainCustomNonConfigurationInstance()
to survive the orientation change works (most of the time) but it's better to keep a reference in our own PresenterSavior
.
Having a complete standalone way to save the state is much more flexible. It would allow us to have a maximum of X active Presenters while the others will be killed (and save state). Another idea would be to kill all Presenters when the App has been moved to background after X Seconds. So many possibilities which aren't possible when we rely on onSaveInstanceState
.
Nothing has been decided yet and I'd be happy to get more feedback from people like you. Anyways, it's open source and you have all rights to maintain you own fork which could be integrated once a decision has been made.
from thirtyinch.
@passsy any news about this?
from thirtyinch.
Work started based on #50. Not finished yet but you can have a look:
branch feature/persist-presenter
from thirtyinch.
@passsy You might want to create another PR even if it's WIP. I already have a few comments.
from thirtyinch.
cool, i'm looking forward for it.
from thirtyinch.
Related Issues (20)
- Debugging a @CallOnMainThread annotated method crashes the app HOT 2
- Create Kotlin module/extensions HOT 2
- Switch from compileOnly to implementation HOT 1
- [Discussion] Should manageViewDisposable() throw an exception
- Support for AndroidX HOT 4
- BackstackReader doesn't work with AndroidX HOT 3
- "Don't add observers when the presenter reached the DESTROYED state" EXCEPTION HOT 1
- sendToView HOT 4
- Lint warning with sendToView, but not with deliverToView
- Why saving the Presenter on orientation change HOT 1
- Problems with @CallOnMainThread
- Lint does not report by abstract classes without implementation View
- Crash using AndroidX with ProGuard enabled HOT 2
- Lint reports: Obsolete custom lint check
- bundle[buildType] was replaced with AGP 3.2.0
- Package thirtyinch-kotlin-coroutines not published HOT 3
- Plugin module not available with version 0.9.5 HOT 2
- Release for androidx HOT 2
- Restore old BackstackReader.isInBackstack() implementation once AndroidX Fragment 1.2.1 is released HOT 1
- Migrate away from JCenter HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from thirtyinch.