Status Update
Comments
il...@google.com <il...@google.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!
ne...@gmail.com <ne...@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
ma...@gmail.com <ma...@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?
il...@google.com <il...@google.com>
mi...@gmail.com <mi...@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.
jo...@gmail.com <jo...@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.
il...@google.com <il...@google.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)
da...@gmail.com <da...@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).
il...@google.com <il...@google.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.
da...@gmail.com <da...@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)
}
}
}
il...@google.com <il...@google.com> #11
da...@gmail.com <da...@gmail.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.
ar...@gmail.com <ar...@gmail.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
ko...@gmail.com <ko...@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.
me...@destil.cz <me...@destil.cz> #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
re...@infinum.com <re...@infinum.com> #16
ko...@gmail.com <ko...@gmail.com> #17
Is this feature to be released in near future?
am...@gmail.com <am...@gmail.com> #18
[Deleted User] <[Deleted User]> #19
ar...@gmail.com <ar...@gmail.com> #20
si...@gmail.com <si...@gmail.com> #21
il...@google.com <il...@google.com>
ke...@map72.com <ke...@map72.com> #22
ca...@gmail.com <ca...@gmail.com> #23
ke...@gmail.com <ke...@gmail.com> #24
[Deleted User] <[Deleted User]> #25
ng...@gmail.com <ng...@gmail.com> #26
ta...@gmail.com <ta...@gmail.com> #27
mo...@gmail.com <mo...@gmail.com> #28
ca...@gmail.com <ca...@gmail.com> #29
ke...@map72.com <ke...@map72.com> #30
il...@google.com <il...@google.com> #31
is...@gmail.com <is...@gmail.com> #32
am...@gmail.com <am...@gmail.com> #33
SharedViewModel fits well in cases where you have a known Subflow where each internal Fragment of this Subflow share/know about the same Subflow Logic and they know about each other.
However, when you want to trespass Subflow boundaries, lets say Subflow_1 launches Subflow_2 and expect a result back. Creating a SharedViewModel for this will pollute the code with a SharedViewModel per Subflow pair. Understand a Subflow could be a single Fragment, for instance a dialog that collects some User data and returns a result to whomever launched it.
Having a feature like this would be great. People including me will clean our code full of workarounds to achieve this.
What I currently do, I have an Activity scoped ViewModel shared by all the Fragments. This ViewModel I named MailBoxStore, that has internally MailBoxes. Each MailBox has the FragmentID it corresponds to. Actually each Fragment has 2 MailBoxes, one for Results and one for Inputs.
Every time a fragment is started after a navigation move, it ask the MailBoxStore if someone sent him either an Input or a Result. Depending on the type of message sent it will call then two methods like onStartWithInput or onFragmentResult.
I really would love a feature like this built in.
Also if the result could be an instance reference and not a Serializable Bundle, it would be much better!
Thanks
li...@booking.com <li...@booking.com> #34
vi...@gmail.com <vi...@gmail.com> #35
b9...@gmail.com <b9...@gmail.com> #36
[Deleted User] <[Deleted User]> #37
ra...@gmail.com <ra...@gmail.com> #38
mo...@tikalk.com <mo...@tikalk.com> #39
ka...@gmail.com <ka...@gmail.com> #40
al...@gmail.com <al...@gmail.com> #41
te...@gmail.com <te...@gmail.com> #42
mo...@gmail.com <mo...@gmail.com> #43
he...@gmail.com <he...@gmail.com> #44
as...@gmail.com <as...@gmail.com> #45
ca...@gmail.com <ca...@gmail.com> #46
ka...@gmail.com <ka...@gmail.com> #47
As for BottomNavigationView - you can make it work by using code from the sample project provided by the team.
Also there's no need to be rude to the team or express your frustration to everyone who starred the issue.
ca...@gmail.com <ca...@gmail.com> #48
So lets start again, the "work around" u mention about DialogFragment does not appear on any docs only the sharedViewModel "work around" if u can call it as that, second the "work arround" for bottomNavigationView has a lots of problems, the back navigation is not working as expected and also has a lots of open issues and nobody from google is answering to those..
ca...@gmail.com <ca...@gmail.com> #49
vi...@gmail.com <vi...@gmail.com> #50
ri...@gmail.com <ri...@gmail.com> #51
ap...@google.com <ap...@google.com> #52
Branch: androidx-master-dev
commit e493164e9a9ca69485b2642580134417b7d20aab
Author: Jeremy Woods <jbwoods@google.com>
Date: Mon Feb 10 01:44:58 2020
Provide getSavedStateHandle() on NavBackStackEntry
Added an API to allow users to retrieve a SavedStateHandle from a
NavBackStackEntry. Using the SavedStateHandle, users can store
Parcelable and Serializable objects on the NavBackStackEntry that will
persist over process death.
Test: Added NavBackStackEntryTest tests
Bug: 79672220
Change-Id: I81bb4b11581d2f6ac43afab5aa29a888f38286c0
M navigation/navigation-runtime/api/2.3.0-alpha02.txt
M navigation/navigation-runtime/api/current.txt
M navigation/navigation-runtime/api/public_plus_experimental_2.3.0-alpha02.txt
M navigation/navigation-runtime/api/public_plus_experimental_current.txt
M navigation/navigation-runtime/api/restricted_2.3.0-alpha02.txt
M navigation/navigation-runtime/api/restricted_current.txt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavBackStackEntryTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavBackStackEntry.java
ap...@google.com <ap...@google.com> #53
Branch: androidx-master-dev
commit 9e9ad24016a882826334b9793af9006d06fb8a30
Author: Jeremy Woods <jbwoods@google.com>
Date: Fri Feb 07 14:40:33 2020
Add getPreviousBackStackEntry() to NavController
Added a method that allows users to get the previous visible
NavBackStackEntry. (This means that it will not return NavGraphs)
Test: Added NavControllerTest
Bug: 79672220
Change-Id: I9486f8e3344bbce477a64b42adc933552c7f2c79
M navigation/navigation-runtime/api/2.3.0-alpha02.txt
M navigation/navigation-runtime/api/current.txt
M navigation/navigation-runtime/api/public_plus_experimental_2.3.0-alpha02.txt
M navigation/navigation-runtime/api/public_plus_experimental_current.txt
M navigation/navigation-runtime/api/restricted_2.3.0-alpha02.txt
M navigation/navigation-runtime/api/restricted_current.txt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
ap...@google.com <ap...@google.com> #54
Branch: androidx-master-dev
commit 316d65d9645ba5eff8146e23616c09288a603419
Author: Jeremy Woods <jbwoods@google.com>
Date: Fri Feb 07 14:39:01 2020
Add getCurrentBackStackEntry to NavController
Adding a convenience method to allow users to get the topmost
NavBackStackEntry instead of using getBackStackEntry() and
getCurrentDestination().
Also rewrote getCurrentDestination to use the new
getCurrentBackStackEntry.
Test: Added NavControllerTest
Bug: 79672220
Change-Id: I1477150b586fd8d26a63b99dc03cd839442e775c
M navigation/navigation-runtime/api/2.3.0-alpha02.txt
M navigation/navigation-runtime/api/current.txt
M navigation/navigation-runtime/api/public_plus_experimental_2.3.0-alpha02.txt
M navigation/navigation-runtime/api/public_plus_experimental_current.txt
M navigation/navigation-runtime/api/restricted_2.3.0-alpha02.txt
M navigation/navigation-runtime/api/restricted_current.txt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
jb...@google.com <jb...@google.com> #55
This has been fixed internally and will be available in the Navigation 2.3.0-alpha02 release.
With this change, you can now get a
If Fragment A
needs a result from Fragment B
..
A
should get the savedStateHandle from the currentBackStackEntry, call getLiveData providing a key and observe the result.
findNavController().currentBackStackEntry?.savedStateHandle?.getLiveData<Type>("key")?.observe(
viewLifecycleOwner) {result ->
// Do something with the result.
}
B
should get the savedStateHandle from the previousBackStackEntry, and set the result with the same key as the LiveData in A
findNavController().previousBackStackEntry?.savedStateHandle?.set("key", result)
Because this uses SavedStateHandle, all results need to be types that can be added to a Bundle (i.e
ia...@gmail.com <ia...@gmail.com> #56
How do I
[Deleted User] <[Deleted User]> #57
For your use case it's much more appropriate to use navGraphScoped ViewModel which would be common and shared among all A, B, C:
Or just pass it back through B...
mo...@gmail.com <mo...@gmail.com> #58
il...@google.com <il...@google.com> #59
Re #58 - the
If you’d only like to handle a result only once, you must call
on the remove()
SavedStateHandle
to clear the result. If you do not remove the result, theLiveData
will continue to return the last result to any newObserver
instances.
The result is scoped to the NavBackStackEntry
you access and will otherwise live as long as that destination is on the back stack.
[Deleted User] <[Deleted User]> #60
My "previous" Fragment has a ViewModel with SavedState handle, and right now I have to forward Fragments' SavedState handle into the ViewModel even though the ViewModel has it's own SavedState handle...
Or am I missing something? How can I reference ViewModel of the previousBackStackEntry and its' SavedStateHandle?
il...@google.com <il...@google.com> #61
Re #60 - there's two separate things to keep in mind:
-
previousBackStackEntry
is not tied to your Fragment at all, it is agnostic to what type of destination you are using (it would equally well if you were using Views or Composables for your destinations). It therefore provides no way to access anything related to your Fragment. This is intentional. -
A
NavBackStackEntry
(such as the one returned bypreviousBackSTackEntry
) is aViewModelStoreOwner
and therefore can be used to store any ViewModels you want viaby navGraphViewModels(R.id.your_previous_id)
orby viewModels({ findNavController().previousBackStackEntry!!})
. TheSavedStateHandle
we provide is just a shorthand for creating a ViewModel in theNavBackStackEntry
and getting itsSavedStateHandle
.
re...@lunabee.com <re...@lunabee.com> #62
Re #57
You could theoretically instead "previousBackStackEntry" use "getBackStackEntry(int destinationId)" and get its' savedStateHandle.. But it would be a very bad practice to hardcode a fragment to return it's result 2 steps back..
For your use case it's much more appropriate to use navGraphScoped ViewModel which would be common and shared among all A, B, C:https://developer.android.com/reference/kotlin/androidx/navigation/package-summary#navgraphviewmodels .
Or just pass it back through B...
What if I want to reuse fragments B&C in another nested graph so I don't want to hardcode the nav graph id in navGraphScoped? The only solution I found is to pass the graph id trough fragment args.
il...@google.com <il...@google.com> #63
Re #62 - that's certainly a valid option if you want to deliver results to a specific destination on your back stack. previousBackStackEntry
is just a helper for the most common case, nothing more.
[Deleted User] <[Deleted User]> #64
il...@google.com <il...@google.com> #66
Re #65 - yes, you can use the new Fragment Result APIs between Fragments when using the Navigation Component. Note that much of the
ja...@gmail.com <ja...@gmail.com> #67
hi. i found some issues with this
1) in code example..you have 'findNavController()' inside fragment 'onCreate'. When you rotate device app crash due to 'findNavController()' call. I found that when i rotate device then fragment (onCreate) is 'called' first and after that is called 'activity' (onCreate). I think that this is reason why navController is not available and throws this exception: 'Caused by: java.lang.IllegalStateException: NavController is not available before onCreate()'.
2) when i put code inside 'onViewCreated' then 'result' from dialog fragment is correctly propagated into 'previous fragment' but when i rotate device when dialog is shown and then i set 'result' and dialog is closed, no 'result' is received on 'previous fragment'. I guess its because
navBackStackEntry.lifecycle.addObserver(LifecycleEventObserver { _, event ->
if (event == Lifecycle.Event.ON_RESUME) // This event is never 'ON_RESUME' when fragment was recreated in time when dialog was shown
I also tried 'findNavController().currentBackStackEntry?.savedStateHandle?.getLiveData<String>("key")?.observe(viewLifecycleOwner) { //action }' but when device is rotated when 'dialog fragment' is shown, then this live data is not called (otherwise its called fine)
Please can you check this and show us some example how to handle 'dialog fragment' results in previous fragment even when you rotate device when dialog is shown? You can reproduce this issues very easily.
Just small suggested improvement 'navController.currentBackStackEntry!!' -> navController.requireCurrentBackStackEntry()
il...@google.com <il...@google.com> #68
Re #67 - please see
b9...@gmail.com <b9...@gmail.com> #69
#68 Is that link require googler account?
il...@google.com <il...@google.com> #70
il...@google.com <il...@google.com> #71
Well, apparently I can't paste links correctly today. It's
br...@gmail.com <br...@gmail.com> #72
lb...@gmail.com <lb...@gmail.com> #73
We have registerForActivityResult for Activity which is much nicer.
Why can't we have something like that?
Even the startActivityForResult is easier and shorter to remember than this...
And it's not even clear on
Description
screen that then returns the result to its previous screen).
Is that something planned? How is it expected to create flows like this with current version?