Fixed
Status Update
Comments
vi...@google.com <vi...@google.com>
vi...@google.com <vi...@google.com>
yb...@google.com <yb...@google.com> #2
ViewModels need to be cleared on Fragments that are being really destroyed, where "really destroyed" means that they are being destroyed without their state being saved, indicating that there's no chance they are going to be restored at a later time.
Unfortunately, isStateSaved(), despite its name, does double duty as a check on whether it is safe to do Fragment Transactions and is always true after onStop(), meaning it can be true even if the state has really not been saved, oddly enough.
We'll just not use isStateSaved() here and rely on a separate indicator for the "really destroyed" case.
Unfortunately, isStateSaved(), despite its name, does double duty as a check on whether it is safe to do Fragment Transactions and is always true after onStop(), meaning it can be true even if the state has really not been saved, oddly enough.
We'll just not use isStateSaved() here and rely on a separate indicator for the "really destroyed" case.
he...@gmail.com <he...@gmail.com> #3
@ comment #2 Fixed in which version?
he...@gmail.com <he...@gmail.com> #5
We have to update compile SDK to 28 to adapt this fix?!
ap...@google.com <ap...@google.com> #7
When will 27.1.1 be released? It is a critical bug seriously.
ap...@google.com <ap...@google.com> #8
This also seems to have caused a side effect / bug where a ViewModel instance is recreated when its Activity is in the background when device is rotated.
yb...@google.com <yb...@google.com>
it...@gmail.com <it...@gmail.com> #9
yb...@google.com <yb...@google.com> #10
Re #9
This issue I was referring to was only reproducible with 27.1.0 though. The one you were referring to was reported prior to 27.1.0 release. Anyway I'll report it as a separate issue. Thanks.
This issue I was referring to was only reproducible with 27.1.0 though. The one you were referring to was reported prior to 27.1.0 release. Anyway I'll report it as a separate issue. Thanks.
Description
ANTLR Tool version 4.5.3 used for code generation does not match the current runtime version 4.7.1ANTLR Runtime version 4.5.3 used for parser compilation does not match the current runtime version 4.7.1ANTLR Tool version 4.5.3 used for code generation does not match the current runtime version 4.7.1ANTLR Runtime version 4.5.3 used for parser compilation does not match the current runtime version 4.7.1error: cannot generate view binders java.lang.StackOverflowError
And then a list of calls that caused the java.lang.StackOverflowError
at android.databinding.tool.expr.Expr.resolveListeners(Expr.java:209)
at android.databinding.tool.expr.Expr.resolveListeners(Expr.java:211)
at android.databinding.tool.expr.Expr.resolveListeners(Expr.java:211)
at android.databinding.tool.expr.Expr.resolveListeners(Expr.java:211)
at android.databinding.tool.expr.Expr.resolveListeners(Expr.java:211)
at android.databinding.tool.expr.Expr.resolveListeners(Expr.java:211)
at android.databinding.tool.expr.Expr.resolveListeners(Expr.java:211)
at android.databinding.tool.expr.Expr.resolveListeners(Expr.java:211) (etc)
It seems that it is known issue with data binding and room mismatch from what I read online but the solution of forcing a particular version of antlr4 doesn't work for me.
When forcing a version of antlr4 like so
configurations.all() {
resolutionStrategy.force "org.antlr:antlr4-runtime:4.5.3"
resolutionStrategy.force "org.antlr:antlr4-tool:4.5.3"
}
I can;'t compile Room with error Caused by: java.lang.ClassNotFoundException: org.antlr.v4.runtime.CharStreams
when forcing it to 4.7.1 it does nothing. Same error with version mismatch. Downgrading Room does nothing.