Fixed
Status Update
Comments
le...@gmail.com <le...@gmail.com> #2
Also, it would be great to return Observable, cause Flowable has some overhead.
ja...@veeva.com <ja...@veeva.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?
ho...@google.com <ho...@google.com>
ko...@gmail.com <ko...@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 !
os...@google.com <os...@google.com>
cl...@google.com <cl...@google.com> #5
Shouldn't this be typed as a feature request?
ap...@google.com <ap...@google.com> #6
jr...@gmail.com <jr...@gmail.com> #7
This issue is half year old and it's still not implemented. Without this the library is unusable.
ap...@google.com <ap...@google.com> #8
+1
os...@google.com <os...@google.com> #9
+1 Here as well. I would like Completable support.
Description
ConstraintLayout version: constraintlayout-compose:1.1.0-alpha12
Jetpack Compose version: 1.6.0-alpha04
Jetpack Compose component used: ConstraintLayout
Android Studio Build: Android Studio Giraffe | 2022.3.1 Build #AI-223.8836.35.2231.10406996, built on June 29, 2023 Runtime version: 17.0.6+0-17.0.6b829.9-10027231 aarch64 VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Kotlin version: 1.9.10
Material Version: material3:1.2.0-alpha06
This is a regression issue, latest version of
constraintlayout-compose
which worked well:1.1.0-alpha05
Steps to Reproduce or Code Sample to Reproduce:
visibility = if (!detailVisible) Visibility.Gone else Visibility.Visible
)width = Dimension.fillToConstraints
property causes the other ComposeView not to be shown on the screenSample Code
Here you can find a sample project to reproduce it:https://github.com/jarroyoesp/ConstraintLayoutIssue
And this issue just happens in case we use
Visibility.Gone
. If we useVisibility.Invisible
it works well.Temporary Fix
We find a possible fix. If we only set
width
toDimension.fillToConstraints
and in other case we set toDimension.wrapContent
, all the ComposeViews are shown when is their time.