Fixed
Status Update
Comments
[Deleted User] <[Deleted User]> #2
I've experienced seen this issue, even on 26.0.0-beta1.
fl...@google.com <fl...@google.com>
da...@google.com <da...@google.com>
ap...@google.com <ap...@google.com> #3
Thank you for reporting this issue. We have shared this with our engineering team and will update this issue with more information as it becomes available.
[Deleted User] <[Deleted User]> #4
I think I'm running into this issue again--but this time it's with deep-linking and synthesizing a fragment back stack. If I have postponeEnterTransition in the fragment I'm deep-linking to, I see the other (backstacked) fragments briefly show on screen.
In one project, I'm using the Navigation Component. The graph is just two fragments: A1 is the start destination with a deep-link to A2. I see A1 show momentarily if I use postponeEnterTransition in A2. And I see similar results in another project that does its own fragment transactions; in that case, I can use setReorderingAllowed(false) to prevent the issue.
In one project, I'm using the Navigation Component. The graph is just two fragments: A1 is the start destination with a deep-link to A2. I see A1 show momentarily if I use postponeEnterTransition in A2. And I see similar results in another project that does its own fragment transactions; in that case, I can use setReorderingAllowed(false) to prevent the issue.
da...@google.com <da...@google.com> #5
This has been fixed internally and will be avilable in Fragment 1.3.0-alpha08.
Note: this fix relies on using the
ma...@marcardar.com <ma...@marcardar.com> #6
Relating to the original request, how about allowing a return type of Deferred<LiveData<T>> which suspends until LiveData<T>'s value has been set the first time?
je...@gmail.com <je...@gmail.com> #7
I just tested out Room 2.1.0-alpha03 and added suspend to all of my functions.... there appears to be an issue with functions that use @Query() and UPDATE and DELETE queries. Examples:
Code Example 1:
@Query("DELETE FROM individual")
suspend fun deleteAll()
Error:
Deletion methods must either return void or return int (the number of deleted rows).
Code Example 2:
@Query("UPDATE individual SET firstName = :firstName WHERE id = :id")
suspend fun updateFirstName(id: Long, firstName: String)
Error:
Not sure how to convert a Cursor to this method's return type (kotlin.Unit).
Code Example 1:
@Query("DELETE FROM individual")
suspend fun deleteAll()
Error:
Deletion methods must either return void or return int (the number of deleted rows).
Code Example 2:
@Query("UPDATE individual SET firstName = :firstName WHERE id = :id")
suspend fun updateFirstName(id: Long, firstName: String)
Error:
Not sure how to convert a Cursor to this method's return type (kotlin.Unit).
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.