Implement APIs to pass results between Fragments [149787344]

Fixed

Feature Request

Status Update

No update yet.

Description

jb...@google.com

created issue #1

Feb 19, 2020 12:07AM

We should add a clean way of passing results between two Fragments.

It should be able to properly handle process death and with it, we can deprecate target fragment.

Target fragment requires directly accessing the instance of another Fragment and not only is that discouraged, but the state of the Fragment being accessed is unpredictable so it is also dangerous. Target fragment is also not supported in Navigation.

Long term, the Fragment Lifecycle methods will be driven with a LifecycleObserver and target fragment cannot exist in that world.

Comments

ap...@google.com <ap...@google.com> #2Apr 2, 2020 08:43PM

Seems to be a DNS problem with systems that have 'obtain DNS server address automatically'. Changed my system to a manual setting and the browser etc now work. SDK 2.2 didn't seem to mind the auto setting though.

ap...@google.com <ap...@google.com> #3Apr 3, 2020 05:22PM

Could you please describe how/where you changed your system to a manual setting?

ap...@google.com <ap...@google.com> #4Apr 3, 2020 06:12PM

Based on its date, this issue was originally reported before Android 2.3. Because of the many changes that existed in Android 4.x compared to previous versions, it's very likely that this issue doesn't exist in recent versions of Android like 4.2.2 or newer. Because of the high likelihood that this issue is obsolete, it is getting closed automatically by a script, without a human looking at it in detail. If the issue still exists on a Nexus 4 or Nexus 7 running Android 4.2.2 and is not related to Google applications, please open a new report accordingly.

jb...@google.com <jb...@google.com> #5Apr 3, 2020 06:32PM

Marked as fixed.

java.lang.IllegalArgumentException: Unable to locate adb
at com.android.tools.idea.run.editor.DeployTargetPickerDialog.<init>(DeployTargetPickerDialog.java:144)
at com.android.tools.idea.run.editor.ShowChooserTargetProvider.showPrompt(ShowChooserTargetProvider.java:113)
at com.android.tools.idea.run.AndroidRunConfigurationBase.getDeployTarget(AndroidRunConfigurationBase.java:600)
at com.android.tools.idea.run.AndroidRunConfigurationBase.doGetState(AndroidRunConfigurationBase.java:281)
at com.android.tools.idea.run.AndroidRunConfigurationBase.getState(AndroidRunConfigurationBase.java:241)
at com.intellij.execution.runners.ExecutionEnvironment.getState(ExecutionEnvironment.java:158)
at com.intellij.execution.runners.BaseProgramRunner.execute(BaseProgramRunner.java:55)
at com.intellij.execution.runners.BaseProgramRunner.execute(BaseProgramRunner.java:50)
at com.intellij.execution.ProgramRunnerUtil.executeConfigurationAsync(ProgramRunnerUtil.java:92)
at com.intellij.execution.ProgramRunnerUtil.executeConfiguration(ProgramRunnerUtil.java:41)
at com.intellij.execution.impl.ExecutionManagerImpl.restart(ExecutionManagerImpl.java:93)
at com.intellij.execution.impl.ExecutionManagerImpl.access$300(ExecutionManagerImpl.java:44)
at com.intellij.execution.impl.ExecutionManagerImpl$3.run(ExecutionManagerImpl.java:442)
at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:232)
at com.intellij.util.Alarm$Request.runSafely(Alarm.java:356)
at com.intellij.util.Alarm$Request.run(Alarm.java:343)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at com.intellij.util.concurrency.SchedulingWrapper$MyScheduledFutureTask.run(SchedulingWrapper.java:228)
at com.intellij.openapi.application.TransactionGuardImpl$2.run(TransactionGuardImpl.java:315)
at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.doRun(LaterInvocator.java:435)
at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.runNextEvent(LaterInvocator.java:419)
at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.run(LaterInvocator.java:403)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:762)
at java.awt.EventQueue.access$500(EventQueue.java:98)
at java.awt.EventQueue$3.run(EventQueue.java:715)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:732)
at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:755)
at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:704)
at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:391)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

de...@gmail.com <de...@gmail.com> #6May 15, 2020 01:28PM

voilà ce qu'on m'affiche lorsque j’exécute mon programme

de...@gmail.com <de...@gmail.com> #7May 15, 2020 02:10PM

je ne vois pas comment résoudre ce problème. svp aidez moi

jb...@google.com <jb...@google.com> #8May 15, 2020 07:37PM

As stated in the documentation "You can have only a single listener and result for a given key."

The Fragment result listeners are not stored in the Fragment, it is actually stored in the FragmentManager. So adding another listener, with the same key for two Fragments with the same FragmentManager will overwrite the first listener.

b9...@gmail.com <b9...@gmail.com> #9May 18, 2020 10:34AM

        LifecycleEventObserver observer = new LifecycleEventObserver() {
                if (event == Lifecycle.Event.ON_DESTROY) {
                    lifecycle.removeObserver(this);    // only remove observer when onDestroy
                    mResultListeners.remove(requestKey);
                }
            }
        };
        lifecycle.addObserver(observer);

I think it would be better remove observer right after the callback is fired, sometimes we don't want the observer keep listening. In that way we could wrap the whole task in one block (like coroutine style), more flexible.

il...@google.com <il...@google.com> #10May 18, 2020 08:20PM

Re #9 - you can certainly clear out your FragmentResultListener after you receive a result if that's the behavior you want for your business logic. The clean up mentioned in your comment is only to prevent memory leaks and not for business logic purposes.