Fixed
Status Update
Comments
il...@google.com <il...@google.com>
mi...@gmail.com <mi...@gmail.com> #2
Also, it would be great to return Observable, cause Flowable has some overhead.
au...@gmail.com <au...@gmail.com> #3
We are going to add Single for queries (and Maybe) but for @insert, @Update and @Delete it is a bit more tricky because we would be reading those values when the computable runs, in which case developer may change them by mistake. We've not decided whether we want to take that risk or not. (We could copy but that would be additional hidden load, especially if the input is a long list).
#2, flowable can easily turn into an observable, would you like to escalate on why you think the overhead is a problem?
#2, flowable can easily turn into an observable, would you like to escalate on why you think the overhead is a problem?
be...@gmail.com <be...@gmail.com> #4
Cool for Single/Maybe for queries :)
For @insert, @Update and @Delete I personally would like to have the possibility to have Single/Maybe... because I will 100% of the time wrap the call into a Single to make it asynchronous and have the possibility to chain other actions with it. I understand that copying entries will take additional resources but in that case we'll have the possibility to not use the RX return type.
That my opinion ^^
Thanks !
For @insert, @Update and @Delete I personally would like to have the possibility to have Single/Maybe... because I will 100% of the time wrap the call into a Single to make it asynchronous and have the possibility to chain other actions with it. I understand that copying entries will take additional resources but in that case we'll have the possibility to not use the RX return type.
That my opinion ^^
Thanks !
md...@gmail.com <md...@gmail.com> #5
Shouldn't this be typed as a feature request?
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #6
ap...@google.com <ap...@google.com> #7
This issue is half year old and it's still not implemented. Without this the library is unusable.
an...@gmail.com <an...@gmail.com> #9
+1 Here as well. I would like Completable support.
il...@google.com <il...@google.com> #10
+1 i think Completable support is necessary
an...@gmail.com <an...@gmail.com> #11
+1 for Completable support as well
il...@google.com <il...@google.com> #12
+1 for completable - just missed it on the fly while coding
an...@gmail.com <an...@gmail.com> #13
+1 for Completable support as well
se...@google.com <se...@google.com> #14
+1 for completable for @Delete @Update and @Insert
jo...@gmail.com <jo...@gmail.com> #15
+1 for Completable support as well
il...@google.com <il...@google.com> #16
Please Give a star instead of adding new comments.
st...@gmail.com <st...@gmail.com> #17
This would be a nice improvement!
My initial response is to wrap the insert in a Completable when exposing the call to a consumer because of the time spent writing to the file system on the main thread. Guessing would probably desire the same API for delete.
Out of the box without LiveData/RxJava support for those types of calls it would violate strict rules and run into the guards of Room ensures that database is never accessed on the main thread.
My initial response is to wrap the insert in a Completable when exposing the call to a consumer because of the time spent writing to the file system on the main thread. Guessing would probably desire the same API for delete.
Out of the box without LiveData/RxJava support for those types of calls it would violate strict rules and run into the guards of Room ensures that database is never accessed on the main thread.
il...@google.com <il...@google.com> #18
It's really necessary thing and it's not implemented still(
Description
The navigation components use the value in `android:label` to set the [toolbar] title depending on where in the navigation graph the use has navigated to. This works fine except I want to have the title reflect the category of things the screen is referring to, but the specific thing that the user is about to edit.
Normally I would have piece of code like `updateTitle` below on the activity and then call it from the fragment (onResume) with:
``` kotlin
updateTitle(getString(R.string.book_title, bookNumber))
```
but this does not work unless I also remove the `android:label` attribute from the nav_graph.xml.
Component used:
'android.arch.navigation:navigation-fragment-ktx:1.0.0-alpha01'
'android.arch.navigation:navigation-ui-ktx:1.0.0-alpha01'
Version used:
as above
Devices/Android versions reproduced on:
All
- Sample project to trigger the issue.
``` xml
// snippet from nav_graph.xml
<fragment
android:id="@+id/bookFragment"
android:name="com.example.bookFragment"
android:label="@string/book_title" >
<argument
android:name="bookId"
app:type="integer" />
</fragment>
// snippet from sttrings.xml
<string name="book_title">book %1$d</string>
```
Some snippets from the way I would otherwise do it.
``` kotlin
// actrivity, implements updateTitle( from an interface (Foo)
override fun updateTitle(title: String) {
toolbar?.title = title
}
// fragment
override fun onResume() {
super.onResume()
// foo is the activity cast to Foo
foo?.updateTitle(getString(R.string.reading_title, 1))
}
```
- A screenrecord or screenshots showing the issue (if UI related).
Actual title vs expected