Bug 29275 - Xamarin.Forms doesn't handle activity restarts, provides no good way to work around it
Summary: Xamarin.Forms doesn't handle activity restarts, provides no good way to work ...
Alias: None
Product: Forms
Classification: Xamarin
Component: Android ()
Version: 1.4.2
Hardware: PC Mac OS
: Normal enhancement
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2015-04-21 12:48 UTC by Adam Kemp
Modified: 2017-04-10 21:57 UTC (History)
19 users (show)

Tags: ac
Is this bug a regression?: ---
Last known good build:

Test case (924.60 KB, application/zip)
2015-04-21 12:48 UTC, Adam Kemp

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Adam Kemp 2015-04-21 12:48:03 UTC
I feel certain that this is something Xamarin is aware of, but I couldn't find any existing bug reports, and it keeps coming up on the forums. Xamarin.Forms does not handle activity destruction/recreation properly on Android, and it is causing a great deal of pain for developers. The advice I've seen from Xamarin engineers on the forums is to disable activity destruction on configuration changes (see here: https://forums.xamarin.com/discussion/26873/how-to-restore-the-navigation-stack-after-page-suspend-resume-in-xamarin-forms), but not only is that NOT the recommended approach by Google, but it doesn't help at all for other cases in which an activity is destroyed. For example, if you start a new activity using StartActivity then your current activity may be destroyed and recreated. Or if you just leave the app and come back.

The way this works now is that the Forms application's lifecycle is tied to the main activity. This is wrong. I don't think anything is going to make this better until the application lifecycle is detached form the activity lifecycle.

Google's recommendation for this is to use a retained fragment. The activity looks for the fragment in its fragment manager when it's created, and if it doesn't find one it creates a new one. All important state is kept in the fragment, and the activity does almost nothing. That's what we need here. Instead of FormsApplicationActivity we need FormsApplicationFragment.

I'm honestly not sure how Xamarin.Forms developers have gotten by this far in the state that this is in. I wouldn't even consider shipping an app that doesn't handle this properly, which basically means I wouldn't consider shipping an app on Android with Xamarin.Forms because it doesn't handle it properly.

To see an example, run the attached project in Xamarin, click the button, and then press the back button. Then repeat. Each time you do that, if the activity is destroyed, the MessagingCenter subscription is duplicated, and you get multiple media pickers. You can also set a breakpoint in OnCreate to see it getting called multiple times. You can force this to happen if you enable the developer option "Don't keep activities", but even with that off this issue will reproduce occasionally in real-world scenarios.
Comment 1 Adam Kemp 2015-04-21 12:48:22 UTC
Created attachment 10842 [details]
Test case
Comment 2 Adam Kemp 2015-06-12 12:32:05 UTC
Here's another person running into this issue:


I've seen several others as well, and I still don't understand how anyone is comfortable shipping a Xamarin.Forms app with this behavior. I haven't seen anyone explain how they work around this. It seems like any Forms app will (at best) appear to relaunch itself every time you sneeze at it.
Comment 3 Maarten 2015-07-21 04:52:19 UTC
Temp fix for the MessagingCenter is to clear it yourself in the OnCreate function.

			//Messagingcenter is not clearing itself so we have to do it...
			MethodInfo dynMethod = typeof(MessagingCenter).GetMethod("ClearSubscribers", BindingFlags.NonPublic | BindingFlags.Static);
			dynMethod.Invoke (null, null);
Comment 4 alemarko 2015-07-21 14:47:18 UTC
Another workaround: I went with the 'nuclear' option of killing the 
process in 'MainActivity.OnDestroy()'.

Reason is that I'm afraid that values of static members in libraries I use could be in some undesirable state (similar to situation with 'Resolver'),
so this way I ensure a clean start of app.

protected override void OnDestroy()
Comment 5 Geoff Armstrong 2015-08-26 12:38:27 UTC
Yeah, I'm getting this too, intermittently. Happens when I launch.

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)
Caused by: java.lang.reflect.InvocationTargetException
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
... 1 more
Caused by: md52ce486a14f4bcd95899665e9d932190b.JavaProxyThrowable: System.NullReferenceException: Object reference not set to an instance of an object
at Xamarin.Forms.Platform.Android.FormsApplicationActivity.OnPrepareOptionsMenu (Android.Views.IMenu) <0x00020>
at Android.App.Activity.n_OnPrepareOptionsMenu_Landroid_view_Menu_ (intptr,intptr,intptr) <0x0005b>
at (wrapper dynamic-method) object.385a6ee4-47be-4098-8536-f05276e7c218 (intptr,intptr,intptr) <0x0004b>

at md5530bd51e982e6e7b340b73e88efe666e.FormsApplicationActivity.n_onPrepareOptionsMenu(Native Method)
at md5530bd51e982e6e7b340b73e88efe666e.FormsApplicationActivity.onPrepareOptionsMenu(FormsApplicationActivity.java:110)
at android.app.Activity.onPreparePanel(Activity.java:2841)
at com.android.internal.policy.impl.PhoneWindow.preparePanel(PhoneWindow.java:577)
at com.android.internal.policy.impl.PhoneWindow.doInvalidatePanelMenu(PhoneWindow.java:921)
at com.android.internal.policy.impl.PhoneWindow$1.run(PhoneWindow.java:259)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5254)
... 4 more
Comment 6 mgwalm 2015-09-27 08:27:48 UTC
I have exactly the same problem.

Please do something about this - ASAP./

Also, seeing Xamarin.Forms is supposed to be cross-platform, the details of all this should be hidden from the app developer. because it works differently on each platform, Xamarin should hide the detail of what is happening. at the least it should provide overridable methods or properties or attributes on the Application class that we can use (in a platform independent manner) to react to and control such behaviour.
Comment 7 Jason Smith [MSFT] 2016-04-08 19:46:23 UTC
Thank you for taking the time to submit this feature request. We like this idea and have added it to our internal feature tracking system.

Warm regards,
Xamarin Forms Team
Comment 8 faceoffers28 2016-05-09 15:31:09 UTC
I just upgraded to XF and now my Android app won't start unless I remove this line of code (see below). I did some research and according to Adam Kemp, this bug is the reason why. 

#region Resolver Init
SimpleContainer container = new SimpleContainer();
container.Register<IDevice>(t => AndroidDevice.CurrentDevice);
container.Register<IDisplay>(t => t.Resolve<IDevice>().Display);
container.Register<INetwork>(t => t.Resolve<IDevice>().Network);


My XLabs Camera feature relies on this line of code, so without it, I can't launch my application.

NOTE: This was not a problem when I was running XF
Comment 9 faceoffers28 2016-06-04 17:56:25 UTC
I see that this is resolved, but based on Adam Kemp's detailed explanation and my inability to use the XLabs Camera in my Android project, I see this as a show stopper. Are you treating this as a bug that needs to be fixed in a future release of Xamarin.Forms? If not, please explain why. Also, if customers like Adam and I need to escalate this issue, please let us know how to do so. Now that you are part of Microsoft, I would expect to see escalation procedures in place for Microsoft Partners. Thanks for your attention to this matter.
Comment 10 faceoffers28 2016-06-27 00:34:45 UTC
Can someone from Xamarin please provide an update on this? Has this been fixed in the release?
Comment 11 faceoffers28 2016-06-27 18:08:02 UTC
I moved my Solution over to Windows 10 over the weekend to test some new Package builds based on the Android SDK 23 issue and Xamarin.Forms. I am now using both Visual Studio 2013 Prem Update 5 along with Xamarin Studio 6 (build 5174). The XLabs Camera is now working in my Xamarin.Forms Android Project. 

I saw another small issue that seem to be fixed, so I just tried to uncomment my Resolver code and it worked. I wonder if this is based on different versions of the software running in both development environments. If so, this is encouraging, but also opens all kinds of questions in terms of development environment integrity. Hope this helps someone else who might run into the issue. This was happening in my Mac environment using Xamarin Studio 5.10.3 (build 51).
Comment 12 John Miller [MSFT] 2017-03-16 18:16:21 UTC
I've moved this to a discussion on the Evolution forums for better visibility and feedback from the community. I've only summarized the information from the OP and not any comments. Please weigh in with your comments on any suggestions on how to handle this better in that forum post. Thank you!