Fixed
Status Update
Comments
[Deleted User] <[Deleted User]> #2
The problem is reproducible using support lib 26.1.0, this is the updated activity:
class LiveDataTestActivity : AppCompatActivity() {
private val myLiveData = MutableLiveData<Int>().apply { value = 0 }
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val textView = TextView(this).apply {
text = "AAAA"
setOnClickListener {
val sendIntent = Intent().apply {
action = Intent.ACTION_SEND
putExtra(Intent.EXTRA_TEXT, "This is my text to send.")
type = "text/plain"
}
startActivityForResult(sendIntent, 123)
}
}
setContentView(textView)
myLiveData.observe(this, Observer<Int> {
textView.text = it.toString()
})
}
override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {
super.onActivityResult(requestCode, resultCode, data)
myLiveData.value = (myLiveData.value ?: 0) + 1
println("Value ${myLiveData.value}")
}
override fun onResume() {
super.onResume()
println("resume ${lifecycle.currentState}")
}
}
class LiveDataTestActivity : AppCompatActivity() {
private val myLiveData = MutableLiveData<Int>().apply { value = 0 }
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val textView = TextView(this).apply {
text = "AAAA"
setOnClickListener {
val sendIntent = Intent().apply {
action = Intent.ACTION_SEND
putExtra(Intent.EXTRA_TEXT, "This is my text to send.")
type = "text/plain"
}
startActivityForResult(sendIntent, 123)
}
}
setContentView(textView)
myLiveData.observe(this, Observer<Int> {
textView.text = it.toString()
})
}
override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {
super.onActivityResult(requestCode, resultCode, data)
myLiveData.value = (myLiveData.value ?: 0) + 1
println("Value ${myLiveData.value}")
}
override fun onResume() {
super.onResume()
println("resume ${lifecycle.currentState}")
}
}
fl...@google.com <fl...@google.com>
da...@google.com <da...@google.com>
ap...@google.com <ap...@google.com> #3
thanks for the reports.
After further investigation:
good news, this is not a very serious bug, it recovers right after onResume. (also the bug does not happen in latest versions of the OS)
bad news, properly fixing it requires changes in the support library so it may not catch 1.0.0 release.
details:
Lifecycles moves state to CREATED when onSavedInstanceState is called. This is done because FragmentManager disables fragment transactions when onSavedInstanceState is called. Lifecycles API guaratees that you can run a fragment transaction inside an observer. This behavior is usually fine because onSavedInstanceState is always followed by onStop.
Turns out, this is not the case for API21..
things to do:
* make sure we have tests that fragments are handled properly and observers don't receive an unexpected STARTED event.
* in the next support lib version, make sure the state is set to at least STARTED when FragmentController#noteStateNotSaved is called.
After further investigation:
good news, this is not a very serious bug, it recovers right after onResume. (also the bug does not happen in latest versions of the OS)
bad news, properly fixing it requires changes in the support library so it may not catch 1.0.0 release.
details:
Lifecycles moves state to CREATED when onSavedInstanceState is called. This is done because FragmentManager disables fragment transactions when onSavedInstanceState is called. Lifecycles API guaratees that you can run a fragment transaction inside an observer. This behavior is usually fine because onSavedInstanceState is always followed by onStop.
Turns out, this is not the case for API21..
things to do:
* make sure we have tests that fragments are handled properly and observers don't receive an unexpected STARTED event.
* in the next support lib version, make sure the state is set to at least STARTED when FragmentController#noteStateNotSaved is called.
[Deleted User] <[Deleted User]> #4
Fabio, thanks for the bug report and example code. We have a fix in the works that will update the TextView on 5.0 (the problem actually existed on 6.0 and below) just like it should on 6.0.
However, note that on 6.0 and below your onResume method will continue to print "CREATED" as Yigit mentioned above.
Thanks again!
However, note that on 6.0 and below your onResume method will continue to print "CREATED" as Yigit mentioned above.
Thanks again!
da...@google.com <da...@google.com> #5
reopened. fix for live data is in but the greater fix to make lifecycles consistent is still not merged.
ma...@marcardar.com <ma...@marcardar.com> #6
Norm
je...@gmail.com <je...@gmail.com> #7
Fragment ransaction bug:
UncaughtException
java.lang.IllegalStateException: The specified child already has a parent. You must call removeView() on the child's parent first.
at android.view.ViewGroup.addViewInner(ViewGroup.java:4937)
at android.view.ViewGroup.addView(ViewGroup.java:4768)
at android.view.ViewGroup.addView(ViewGroup.java:4708)
at android.view.ViewGroup.addView(ViewGroup.java:4681)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1425)
at android.support.v4.app.FragmentManagerImpl.moveFragmentToExpectedState(FragmentManager.java:1750)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1819)
at android.support.v4.app.BackStackRecord.executePopOps(BackStackRecord.java:855)
at android.support.v4.app.FragmentManagerImpl.executeOps(FragmentManager.java:2587)
at android.support.v4.app.FragmentManagerImpl.executeOpsTogether(FragmentManager.java:2377)
at android.support.v4.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(FragmentManager.java:2332)
at android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:2239)
at android.support.v4.app.FragmentManagerImpl$1.run(FragmentManager.java:700)
at android.os.Handler.handleCallback(Handler.java:790)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6494)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
UncaughtException
java.lang.IllegalStateException: The specified child already has a parent. You must call removeView() on the child's parent first.
at android.view.ViewGroup.addViewInner(ViewGroup.java:4937)
at android.view.ViewGroup.addView(ViewGroup.java:4768)
at android.view.ViewGroup.addView(ViewGroup.java:4708)
at android.view.ViewGroup.addView(ViewGroup.java:4681)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1425)
at android.support.v4.app.FragmentManagerImpl.moveFragmentToExpectedState(FragmentManager.java:1750)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1819)
at android.support.v4.app.BackStackRecord.executePopOps(BackStackRecord.java:855)
at android.support.v4.app.FragmentManagerImpl.executeOps(FragmentManager.java:2587)
at android.support.v4.app.FragmentManagerImpl.executeOpsTogether(FragmentManager.java:2377)
at android.support.v4.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(FragmentManager.java:2332)
at android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:2239)
at android.support.v4.app.FragmentManagerImpl$1.run(FragmentManager.java:700)
at android.os.Handler.handleCallback(Handler.java:790)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6494)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
da...@google.com <da...@google.com> #8
Async return types with @Query that perform UPDATE, DELETE or INSERT are not yet supported. This also applies to coroutines. We are actively working on adding this for the next alpha of 2.1.0. Subscribe to the bug for updates: https://issuetracker.google.com/issues/120227284
[Deleted User] <[Deleted User]> #9
Hello.
Any updates on returning Channel<T> from DAO?
Will contributions be accepted for that feature?
Any updates on returning Channel<T> from DAO?
Will contributions be accepted for that feature?
yb...@google.com <yb...@google.com> #10
Channels are experimental right now so we probably want to wait until it is stable.
cr...@shou.tv <cr...@shou.tv> #11
Channels +1
da...@google.com <da...@google.com> #12
Marking as fix since core coroutines are supported in 2.1, in the mean time we'll keep an eye on the Channels API to potentially support it once its upgraded out of experimental. https://issuetracker.google.com/issues/127328278
pi...@gmail.com <pi...@gmail.com> #13
Is it expected that we still have to ensure that suspended functions aren't dispatched from the main thread?
The first call (eg `final SupportSQLiteStatement _stmt = __preparedStmtOfDeleteAll.acquire();`) is not wrapped in a callable and can't be done on the ui thread, so we still have to wrap suspensions with our own context.
The first call (eg `final SupportSQLiteStatement _stmt = __preparedStmtOfDeleteAll.acquire();`) is not wrapped in a callable and can't be done on the ui thread, so we still have to wrap suspensions with our own context.
ai...@gmail.com <ai...@gmail.com> #14
Kotlinx.coroutines 1.2 released with cold stream abstraction Flow:
https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-flow/index.html
It's in "preview" status, but maybe we also could expect some experimental version of Room with Flow support for observable requests
It's in "preview" status, but maybe we also could expect some experimental version of Room with Flow support for observable requests
Description
Version used: 1.0.0
Room currently supports RxJava and LiveData, but it would be great to also have support for Kotlin's Coroutines.
In a basic implementation this could be achieved with supporting the following types:
- Query: Deferred<T>
- Insert: Job or Deferred<Long>
- Delete: Job or Deferred<Int>
- Update: Job or Deferred<Int>
What could be really awesome though would be implementing support for the `suspend` keyword, as the developer would be able to write just:
```
@Query("SELECT * FROM ITEMS")
suspend fun getItems(): List<Item>
```
I understand this might be tricky to implement on your side though, since a suspend function has got a continuation parameter and that might be an issue with the way Room currently works.