Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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 for Bug 43589 on
Developer Community or GitHub if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
On Android, I find that the busy indicator for a Page only shows when the UI thread is NOT busy (which is a tad ironic).
For instance, if a Command handler for a Button does the following, the busy indicator is not displayed on Android (it is on iOS):
thisPage.IsBusy = true;
// a load of stuff here that keeps the UI thread busy for a potentially prolonged period
thisPage.IsBusy = false;
However, if the Command handler does the following, the busy indicator is displayed on Android:
thisPage.IsBusy = true;
View newView = await MethodThatRunsATaskThatReturnsAView();
thisPage.Content = newView;
thisPage.IsBusy = false;
That requires code to be restructured so that nothing in MethodThatRunsATaskThatReturnsAView() actually touches the UI hierarchy of thisPage, with the only touch being after the await has returned (in this case an assignment to thisPage.Content).
However... there are issues with this workaround when executed on UWP (e.g. https://bugzilla.xamarin.com/show_bug.cgi?id=39399 ), so to show the Page's busy indicator Android, requires extra Task code and then workarounds to stop it breaking on UWP, typically using Device.BeginInvokeOnMainThread on UWP
See also http://forums.xamarin.com/discussion/17439/using-contentpage-isbusy where other people also describe having issues with IsBusy on Android
For more information regarding this, see the forum thread at http://forums.xamarin.com/discussion/77473/loading-indicator-during-pages-navigation#latest
Are you on AppCompat? Also, do you expect it to show inside the toolbar/actionbar or centered on the screen?
It seems easier to add it in the center. For some reason, adding views to Toolbar does not work.
When I logged this bug, I don't think I was using AppCompat. Since then, I have installed/updated various NuGet packages, including AppCompat. Interestingly, I don't see the busy indicator at all now on Android. Would AppCompat have killed it off?
Previously, the busy indicator for the page was on the NavBar. As for where I would prefer it - as long as it's large enough to be seen (on iOS it's small, on Windows it's barely visible or not visible at all - separate bug for that), I'm not that fussed. Whilst the center of the page would be my instinctive answer, the NavBar seems to be a sensible enough place for the built-in busy indicator.
Unfortunately, the busy indicator does not work at all on AppCompat. The iOS approach is incorrect. It's using network busy indicator on the status bar. A page can be busy for many reasons.
Is there a particular reason (other than the built-in nature) you want to use IsBusy instead of layering an ActivityIndicator on top of your UI?
I am using it in the context of page creation. So when page A is visible and some interaction A.I will result in page B appearing, I set A.IsBusy = true from the time of the interaction A.I until the await of PushAsync(B) returns. It should be very rare that page creation takes long enough for the user to even spot the busy indicator, but for those times when there is a delay, I'd like the user to know that the app is busy doing something (but without giving any indication of how long it might be). For this, the built-in IsBusy property should be ideal, if it actually did something visible. If it's not going to do anything visible, it might as well be marked Obsolete. Of course, it would be even better if IsBusy did something visible when the app is using its UI thread (iOS manages to do this).
What I now do is to do as much page creation as possible using a separate Task, only attaching the Page.Content after that Task completes and execution is on the UI thread. This should be fine and before AppCompat allowed Android to display the busy indicator sensibly, but there are problems with setting font properties using a separate Task on Windows (another logged bug). As a result, the separate Task is used for everything other than fonts, and the fonts are forcibly set on the UI thread.
"and before AppCompat" => "and before AppCompat was used"
I created a PR to loop in the dev team. In my opinion, instead of fighting fires, we should let this go so people can make their own indicators. I don't think that should require a lot of work.
The current implementation, if it at all works, is simply not extendable.
Apologies for delay in responding - just got back from vacation. I would prefer to see the IsBusy indicator on the page actually do something, rather than get rid of it.