Status Update
Comments
il...@google.com <il...@google.com>
ks...@gmail.com <ks...@gmail.com> #2
This is a particularly hard device to come by - do you happen to have access to the device? If so could you provide us with the output of: adb shell dumpsys media.camera > info.txt
Thanks!
sa...@gmail.com <sa...@gmail.com> #3
Stacktrace:
Caused by: java.lang.IllegalArgumentException: Can not get supported output size under supported maximum for the format: 34
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes(SupportedSurfaceCombination.java:355)
at androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions(SupportedSurfaceCombination.java:197)
at androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions(Camera2DeviceSurfaceManager.java:198)
at androidx.camera.core.CameraX.calculateSuggestedResolutions(CameraX.java:943)
at androidx.camera.core.CameraX.bindToLifecycle(CameraX.java:293)
at androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle(ProcessCameraProvider.java:227)
Below are some findings based on our debugging
When Dex is connected
previewConfig.getMaxResolution() is returning "731x411" as maxSize.
Inside Preview.Builder.build() -> Default_MAX_resolution is set to "CameraX.getSurfaceManager().getPreviewSize()" which is 731x411
this is being picked as maxSize.
While rendering maxSize is 731x411 and minSize is 640x480 and below are available outputSizes
0 = {Size@11860} "4032x3024"
1 = {Size@11861} "3984x2988"
2 = {Size@11862} "4032x2268"
3 = {Size@11863} "3024x3024"
4 = {Size@11864} "2976x2976"
5 = {Size@11865} "3840x2160"
6 = {Size@11866} "3264x2448"
7 = {Size@11867} "4032x1960"
8 = {Size@11868} "2880x2160"
9 = {Size@11869} "3264x1836"
10 = {Size@11870} "2160x2160"
11 = {Size@11871} "2560x1440"
12 = {Size@11872} "2224x1080"
13 = {Size@11873} "2048x1152"
14 = {Size@11874} "1920x1080"
15 = {Size@11875} "1440x1080"
16 = {Size@11876} "1088x1088"
17 = {Size@11877} "1280x720"
18 = {Size@11878} "1024x768"
19 = {Size@11879} "1056x704"
20 = {Size@11880} "960x720"
21 = {Size@11881} "960x540"
22 = {Size@11882} "720x720"
23 = {Size@11883} "800x450"
24 = {Size@11884} "720x480"
25 = {Size@11885} "640x480"
26 = {Size@11886} "352x288"
27 = {Size@11887} "320x240"
28 = {Size@11888} "256x144"
29 = {Size@11889} "176x144"
and couldn't find any size in this range.
When Dex not connected
minsize = 640x480
maxsize = 1920x1080
0 = {Size@11836} "4032x3024"
1 = {Size@11837} "3984x2988"
2 = {Size@11838} "4032x2268"
3 = {Size@11839} "3024x3024"
4 = {Size@11840} "2976x2976"
5 = {Size@11841} "3840x2160"
6 = {Size@11842} "3264x2448"
7 = {Size@11843} "4032x1960"
8 = {Size@11844} "2880x2160"
9 = {Size@11845} "3264x1836"
10 = {Size@11846} "2160x2160"
11 = {Size@11847} "2560x1440"
12 = {Size@11848} "2224x1080"
13 = {Size@11849} "2048x1152"
14 = {Size@11850} "1920x1080"
15 = {Size@11851} "1440x1080"
16 = {Size@11852} "1088x1088"
17 = {Size@11853} "1280x720"
18 = {Size@11854} "1024x768"
19 = {Size@11855} "1056x704"
20 = {Size@11856} "960x720"
21 = {Size@11857} "960x540"
22 = {Size@11858} "720x720"
23 = {Size@11859} "800x450"
24 = {Size@11860} "720x480"
25 = {Size@11861} "640x480"
26 = {Size@11862} "352x288"
27 = {Size@11863} "320x240"
28 = {Size@11864} "256x144"
29 = {Size@11865} "176x144"
and we have 12 available sizes in this range
Camera2DeviceSurfaceManager.java:: getPreviewSize()
mCameraSupportedSurfaceCombinationMap.get(cameraId).getSurfaceDefinition().getPreviewSize() = "1920x1080"
cameraId=0
co...@gmail.com <co...@gmail.com> #4
The issue root cause is that CameraX will default filter out sizes smaller than 640x480. For Preview, the max size will be limited to under display size. I checked the HW spec info for the issue related devices. Display size of FUJITSU F-04J/F-05J is 360x640. That will result int that no size exists in the conditions that is larger or equal to 640x480 and smaller or equal to 360x640.
A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
For device FUJITSU arrowsM04, I checked its HW spec info and its display size I found is 1280x720. It seems that the problem should not exist in the device.
Could you confirm that the problem exist on arrowsM04 device? What will be the returned value when using Display#getRealSize to obtain the display size?
co...@gmail.com <co...@gmail.com> #5
> A temporary workaround for this situation is to use Preview.Builder#setTargetResolution() to set a size smaller than 640x480 to bypass the problem.
OK. I will try it.
> Could you confirm that the problem exist on arrowsM04 device?
We receive the crash report (Crashlytics) that this crash has occurred on arrowsM04.
We don't have this device so we can't confirm that the problem really exist on arrowsM04.
> What will be the returned value when using Display#getRealSize to obtain the display size?
We can't investigate it for the same reason.
Thank you.
ez...@gmail.com <ez...@gmail.com> #6
This issue happened on devices that the display size is smaller than 640x480. In original auto-resolution mechanism, supported sizes smaller than 640x480 will be default filter out.
The auto-resolution mechanism encodes the guaranteed configurations tables in CameraDevice#createCaptureSession(SessionConfiguration). It defines that the PREVIEW size is the small one of the device display size and 1080p. The PREVIEW size will be the maximal size limitation for Preview use case. The reason it limits the size to display size and 1080p is the stream output in display size or 1080p has been able to provide good enough preview quality. Therefore, auto-resolution mechanism will limit the selected size to be smaller than the small one of the device display size and 1080p.
With above two conditions, in this issue, all sizes smaller than 640x480 have been filter out, therefore, there is no size smaller than the display size 320x240 can be selected to use. And cause the exception.
Solution:
When the display size is smaller than 640x480, auto-resolution mechanism won't filter out those small sizes smaller than 640x480. This makes those small size be left and can be selected for the Preview use case on small display devices.
The solution has been merged and will be included in next CameraX release.
he...@gmail.com <he...@gmail.com> #7
Hello.
This crash still occurs.
- CAMERAX VERSION: 1.0.0-beta4
- ANDROID OS BUILD NUMBER: Android 7.1.1
- DEVICE NAME: FUJITSU F-02H
We receive following crash report from FUJITSU F-02H. So far We have received this crash report only from F-02H.
java.lang.IllegalArgumentException
Can not get supported output size under supported maximum for the format: 34
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSupportedOutputSizes (SupportedSurfaceCombination.java:349)
androidx.camera.camera2.internal.SupportedSurfaceCombination.getSuggestedResolutions (SupportedSurfaceCombination.java:197)
androidx.camera.camera2.internal.Camera2DeviceSurfaceManager.getSuggestedResolutions (Camera2DeviceSurfaceManager.java:198)
androidx.camera.core.CameraX.calculateSuggestedResolutions (CameraX.java:949)
androidx.camera.core.CameraX.bindToLifecycle (CameraX.java:351)
androidx.camera.lifecycle.ProcessCameraProvider.bindToLifecycle (ProcessCameraProvider.java:230)
(our application's package name).CameraFragment.bindCameraUseCases (CameraFragment.java:174)
ru...@gmail.com <ru...@gmail.com> #8
Could you help to provide the following information to clarify the issue?
1. Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
2. Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
ru...@gmail.com <ru...@gmail.com> #9
- Is the full name of the device Fujitsu Arrows NX F-02H that has a 1440x2560 display?
Yes
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
Since we don't have this device, we'll try to collect this information in the next version of our app. The next version will be released later this month.
sj...@gmail.com <sj...@gmail.com> #10
Hello.
- Please help to provide the supported output sizes of ImageFormat.PRIVATE that is obtained by StreamConfigurationMap#getOutputSizes(int).
We have collected the output of the device where the crash occurs.
Device1
- Model : arrows Be F-05J
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Device2
- Model : Fujitsu arrows M04
- Android Version : 7.1.1
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0: 480x480
CameraId 1: 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
Additional Information
CameraX version : 1.0.0-beta04
We collect the supported output sizes by following code.
val errorString = buildString {
append("The supported output sizes of ImageFormat.PRIVATE: ")
(requireContext().getSystemService(Context.CAMERA_SERVICE) as CameraManager).apply {
cameraIdList.forEachIndexed { index, cameraId ->
val msg = if (VERSION.SDK_INT >= VERSION_CODES.M) {
val configurationMap =
getCameraCharacteristics(cameraId).get(CameraCharacteristics.SCALER_STREAM_CONFIGURATION_MAP)
val sizes = configurationMap?.getOutputSizes(ImageFormat.PRIVATE)
"CameraId $index: ${sizes?.joinToString(" ,")}"
} else {
"CameraId $index: This device version is under M."
}
append(msg)
}
}
}
st...@gmail.com <st...@gmail.com> #11
il...@google.com <il...@google.com> #12
I tried to find the device specs and both 720x1280
size display. For the camera id 0 device, it is a different case that the display size is larger than 640x480
but the device only supports a 480x480
size. The case also caused the same IllegalArgumentException and was also fixed by 1.0.0-beta04
release. Before 480x480
size would be filtered out and then caused the IllegalArgumentException. After it was merged, the 640x480
size threshold was removed and then the 480x480
size would be kept and selected to use.
It looks like 1.0.0-beta04
release had been used to collect the supported sizes information. But the issue should have been fixed by 1.0.0-beta04
release. Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
CameraX's 1.0.0-beta04
version. Maybe you can also consider to upgrade to the latest 1.0.0-rc01
version for your application. Thanks.
ap...@google.com <ap...@google.com> #13
Did you only check the device model name to collect the supported sizes information or collect the information when the IllegalArgumentException issue happens again?
We collect informations only from the device on which IllegalArgumentException happened.
Our latest app uses CameraX version 1.0.0-beta10
and this issue still occurres.
However we don't receive crash report from Fujitsu arrows Be F-05J
or Fujitsu arrows M04
so far. (This doesn't mean this issue is fixed on these devices because our app is heavily rely on camera so these device's user wouldn't use our app anymore.)
Instead, we receive crash report from
- Model : Fujitsu F-03K
- Android Version : 7.1.2
- Supported output sizes of ImageFormat.PRIVATE
CameraId 0 : 480x480
CameraId 1 : 2048x1536 ,1920x1080 ,1280x720 ,960x720 ,640x480 ,320x240 ,176x144
ng...@gmail.com <ng...@gmail.com> #14
I missed some settings when I simulated the issue by robolectric test so that I was not able to reproduce it. Now, I can reproduce the issue if the device only supports one 480x480 resolution. I'm working on the solution and target to make it included in next release.
lo...@gmail.com <lo...@gmail.com> #15
Branch: androidx-main
commit 69d15dff7bb857ee33a0f643ff42a0f8bc475ab2
Author: charcoalchen <charcoalchen@google.com>
Date: Fri Jan 08 18:30:03 2021
Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Do not filter out sizes smaller than 640x480 when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480.
Relnote:"Fixed IllegalArgumentException issue happened when all preview supported sizes are smaller than 640x480 and display size is larger than 640x480."
Bug: 150506192
Test: SupportedSurfaceCombinationTest
Change-Id: I2a63ce8e2ad42a9cc060c8635ac3603bf440b1ec
M camera/camera-camera2/src/main/java/androidx/camera/camera2/internal/SupportedSurfaceCombination.java
M camera/camera-camera2/src/test/java/androidx/camera/camera2/internal/SupportedSurfaceCombinationTest.java
ba...@gmail.com <ba...@gmail.com> #16
da...@gmail.com <da...@gmail.com> #17
This issue isn't market as fixed.
My guess is that the box modification + injected modifier will allow adding modifiers to handle transitioning between screens.
de...@gmail.com <de...@gmail.com> #18
ra...@gmail.com <ra...@gmail.com> #19
why delayed again and again?
de...@gmail.com <de...@gmail.com> #20
Why not give
ap...@google.com <ap...@google.com> #22
Branch: androidx-main
commit 8194329aa262cf1e5759c76129a2845d0b74f675
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Jun 16 17:14:30 2021
Add transition apis to NavigatorState
Added the addWithTransition and popWithTransition APIs to the
NavigatorState. These APIs provide an OnTransitionComplete callback for
doing the actual add/pop once some action has been completed (after a
transition).
Relnote: "You can now use the add/popWithTransition APIs to add or pop a
destination aynchronously."
Test: all existing tests pass
Bug: 172112072
Change-Id: Ic4d7cc6530bf576c4d812d1fd0c5a2697874d384
M navigation/navigation-common/api/api_lint.ignore
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/src/main/java/androidx/navigation/NavigatorState.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
M navigation/navigation-testing/src/androidTest/java/androidx/navigation/testing/TestNavigatorStateTest.kt
M navigation/navigation-testing/src/main/java/androidx/navigation/testing/TestNavigatorState.kt
ap...@google.com <ap...@google.com> #23
Branch: androidx-main
commit 6a6cfa99a3e857318e82cf1b7401835de1b65ede
Author: Jeremy Woods <jbwoods@google.com>
Date: Mon Jun 21 12:06:50 2021
Use push instead of add for NavigatorState
Changing the name from add to push to symmetry with the pop API.
RelNote: "The `add` function in `NavigatorState` has been renamed to
`push`. All current calls to `add()` will need to be changed to push()."
Test: ./gradlew checkApi
Bug: 172112072
Change-Id: Ie89fcbcf0753d6918f91450e322b156ff2fd6e9b
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/src/main/java/androidx/navigation/Navigator.kt
M navigation/navigation-common/src/main/java/androidx/navigation/NavigatorState.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/ComposeNavigator.kt
M navigation/navigation-fragment/src/main/java/androidx/navigation/fragment/DialogFragmentNavigator.kt
M navigation/navigation-fragment/src/main/java/androidx/navigation/fragment/FragmentNavigator.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
M navigation/navigation-testing/src/androidTest/java/androidx/navigation/testing/TestNavigatorStateTest.kt
M navigation/navigation-testing/src/main/java/androidx/navigation/testing/TestNavigatorState.kt
ap...@google.com <ap...@google.com> #24
Branch: androidx-main
commit cab838c721195adf0f7ef7236c29a970f608d17d
Author: Jeremy Woods <jbwoods@google.com>
Date: Mon Jul 12 01:21:06 2021
Add Transitions to Navigation Compose
Now that we have the new Navigator APIs from base navigation we can
properly delay destroying destinations until after transitions have been
completed. This means that viewModels will survive if a transition is
canceled and we can properly support animations in Navigation Compose.
RelNote: "Navigation compose now always uses Crossfades when navigating
through destinations."
Test: NavHostTest
Bug: 172112072
Change-Id: I07049268d9c78bfbc6bb49f94bf2a1284d4f1180
M navigation/navigation-common/src/main/java/androidx/navigation/NavBackStackEntry.kt
M navigation/navigation-compose/build.gradle
M navigation/navigation-compose/src/androidTest/java/androidx/navigation/compose/NavHostTest.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/ComposeNavigator.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
b9...@gmail.com <b9...@gmail.com> #25
Sorry I don't get the point. Why always uses Crossfades effect? Could we change to different transition effect?
ap...@google.com <ap...@google.com> #26
Branch: androidx-main
commit 013d94b69530f18051a4df9674dc7a08d52022f0
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Jul 21 11:57:44 2021
Fix popWithTransition in TestNavigatorState
When we popWithTransition the entry being popped should remain in a
CREATED state before being the transition is completed and the entry
coming to the top of the back stack should remain in the STARTED state
until its transition is completed.
This change adds the logic to ensure we hold the entries in their proper
state while the transition is happening.
RelNote: "When calling `popWithTransition()` from `TestNavigatorState`
the entries will now have the proper state while the transition is
running before it receives the `onTransitionComplete()` callback."
Test: modified TestNavigatorStateTest
Bug: 172112072
Change-Id: I66cddae843f476c19ac3a6c40a7cd5031355768a
M navigation/navigation-testing/src/androidTest/java/androidx/navigation/testing/TestNavigatorStateTest.kt
M navigation/navigation-testing/src/main/java/androidx/navigation/testing/TestNavigatorState.kt
ap...@google.com <ap...@google.com> #27
Branch: androidx-main
commit e3b742c6b338c04f6be0e6560c39c878376ad3ca
Author: Jeremy Woods <jbwoods@google.com>
Date: Fri Jul 16 16:22:09 2021
Mark destination navigating away from as transitioning
When navigating forward with transitions, although we don't hold the
lifecycle of the entry being kept on the back stack above CREATED during
the transition, we should still mark it as transitioning until its
transition is actually complete.
RelNote: "When navigating away from a `NavBackStackEntry` and using the
`pushWithTransition` API, the `NavigatorState` will now properly mark
the previous entry as transitioning."
Test: modified test
Bug: 172112072
Bug: 194301889
Fixes: 191870023
Change-Id: If0543dd1c20e7338078115e98b5585623f9b8f1c
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/src/main/java/androidx/navigation/NavigatorState.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/ComposeNavigator.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavBackStackEntryTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
M navigation/navigation-testing/src/androidTest/java/androidx/navigation/testing/TestNavigatorStateTest.kt
M navigation/navigation-testing/src/main/java/androidx/navigation/testing/TestNavigatorState.kt
M testutils/testutils-navigation/src/main/java/androidx/testutils/TestNavigator.kt
ag...@xmartlabs.com <ag...@xmartlabs.com> #28
I am experiencing an issue with the transition. When my app is opened, the splash is shown and on exit transition it has a broken crossfade. Also, after this, no interaction is registered by the app. This issue is introduced in 2.4.0-alpha05
sw...@gmail.com <sw...@gmail.com> #29
cf...@gmail.com <cf...@gmail.com> #30
I am experiencing the same issue as
@Composable
fun ScreenThatRequiresAuth(navController: NavController, authenticated: Boolean) {
if (authenticated) {
// emit UI content for this screen
} else {
navController.navigate("login-screen")
}
}
no longer works because the navigation no longer happens instantaneously, so navController.navigate("login-screen")
is called repeatedly on subsequent recompositions as the animation proceeds. Therefore we are indefinitely navigating and crossfading, resulting in that visual glitch. If there is no way navigate without an animation anymore, then alpha05 breaks most implementations of this officially recommended pattern. My current workaround is to navigate inside of a LaunchedEffect
block so that it doesn't happen again on recompositions while animating the transition. The UI content of ScreenThatRequiresAuth
is still not shown if we have no auth, but now it is less clean than an if/else statement:
@Composable
fun ScreenThatRequiresAuth(navController: NavController, authenticated: Boolean) {
LaunchedEffect(authenticated) {
if (!authenticated) {
navController.navigate("login-screen")
}
}
if (authenticated) {
// emit UI content for this screen
}
}
This works, it just means that the login screen has to fade in from nothing, which may look awkward, and now the code required to implement this pattern is less straightforward. Since we should not be showing ScreenThatRequiresAuth
at all if there is no auth, it doesn't make sense to fade it out -- this transition should happen without an animation. When will this be possible?
je...@gmail.com <je...@gmail.com> #31
Navigating on recomposition seems like an anti pattern to me. I think calling 'navigate' should only happen upon a UI event. If you want to show a login screen, you should probably check if the app has persisted credentials and then either show the log-in (if there are no credentials) screen or the main screen (if there are some).
The composable could look like this:
@Composable
fun ContentView(
registration: Registration
) {
when (registration) {
is Registration.Registered -> MainView(...)
else -> OnboardingView(...)
}
}
Navigation is then happening inside the MainView composable and the OnboardingView composable. There you have your destinations like such:
@Composable
fun MainView(
...
) {
val navController = rememberNavController()
val actions = remember(navController) { NavActions(navController) }
NavHost(navController = navController, startDestination = Destinations.Home) {
composable(Destinations.Home) {
HomeView(
profileSelected = { navController.navigate(route = Destinations.Profile) },
...
)
}
...
}
}
Handling the credentials could be done in a separate class, which is instantiated in an activity:
sealed class Registration {
class Registered(val credentials: Credentials): Registration()
object Onboarding: Registration()
}
class AppState(private val persistence: Persistence): ViewModel() {
companion object {
var registration by mutableStateOf<Registration>(Registration.Onboarding)
private set
}
init {
load()
}
private fun load() {
val credentials = persistence.readCredentials()
registration = if (credentials != null)
Registration.Registered(credentials)
else
Registration.Onboarding
}
fun setCredentials(credentials: Credentials) {
persistence.saveCredentials(credentials)
registration = Registration.Registered(credentials)
}
}
jb...@google.com <jb...@google.com> #32
As of compose 1.0.1
many of the @Experimental
.
In the interest of providing a solution for Navigation with custom Compose Animations as soon as possible, we opted to provide a new module in 1.1.0
, we will move the implementation back into the Jetpack Navigation library
from Accompanist Navigation Animation
.
The bug we will use for tracking folding the APIs back into Jetpack Navigation is
For more details, see the
me...@gmail.com <me...@gmail.com> #33
Should we still be using Accompanist Navigation Animation? We're on Compose 1.2.0-beta02 by the way.
jo...@gmail.com <jo...@gmail.com> #34
I would like to do something like navigationController.navigate(AnotherScreen(name: String, anotherArgument: Boolean), animated = NavigationAnimation.Push) and thats it.
To achieve a push animation which is used so often in apps, it's way too hard to achieve.
bl...@gmail.com <bl...@gmail.com> #35
#34 I found it's easier & much more flexible to just implement your own navigation solution. It need not be super complicated in Compose. The Jetpack nav library really isn't worth the hassle.
jo...@gmail.com <jo...@gmail.com> #36
lo...@gmail.com <lo...@gmail.com> #37
I can't understand why you have such a negative view on compose and the navigation approach given. I use the
Description
Version used: 1.0.0-alpha01
Devices/Android versions reproduced on: All
Provide a way to navigate composable screens with animations (slide, fade etc')