Bug 28176 - Xamarin.Forms.Device.StartTimer stops receiving notifications, when running on iPhone 6 iOS 8.2
Summary: Xamarin.Forms.Device.StartTimer stops receiving notifications, when running o...
Status: CONFIRMED
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 1.4.2
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2015-03-18 20:49 UTC by Ed
Modified: 2017-08-29 12:27 UTC (History)
12 users (show)

Tags: ios, functional, ac, timer
Is this bug a regression?: ---
Last known good build:


Attachments
Project that demonstrates the issue (4.12 MB, application/zip)
2015-03-18 20:49 UTC, Ed
Details
Demo project based on Foundation.NSTimer.CreateScheduledTimer (201.77 KB, application/zip)
2015-04-21 04:24 UTC, Ed
Details
Xcode swift project, similar GUI updating loop, runs smoothly (28.89 KB, application/zip)
2015-04-21 14:26 UTC, Ed
Details
iOS app with native interface (20.44 KB, application/zip)
2015-04-21 18:29 UTC, Ed
Details


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 for Bug 28176 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 original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description Ed 2015-03-18 20:49:36 UTC
Created attachment 10404 [details]
Project that demonstrates the issue

Timer created with Xamarin.Forms.Device.StartTimer stops receiving notifications after a while, when running on iPhone 6 iOS 8.2. To continue receiving notification one has to tap on the screen. This behavior is easily reproducible when the time spent in the notification handler roughly equals the notification interval.

Simple test project that demonstrates this issue is attached to this bug report.

Xamarin forum discussion: http://forums.xamarin.com/discussion/36071/problem-with-xamarin-forms-device-starttimer
Comment 1 Anonymous 2015-03-31 13:02:00 UTC
I can confirm running into this issue as well whilst trying to set up a timer to rotate an image at a given interval.
Comment 2 Ed 2015-04-20 05:13:57 UTC
It appears that this is a correct behavior for an IOS timer that invokes a CPU intensive procedure. In fact i believe that  Xamarin's timer is directly linked to scheduledTimerWithTimeInterval. Which indeed stops firing after a while, when it's callback is CPU intensive (most probably to keep GUI responsive).

I would note this in the documentation to avoid further confusion.
Comment 3 Ed 2015-04-20 05:17:38 UTC
For a CPU intensive task i would recommend using either threads or ThreadPool. This is what i did in my case to resolve this issue.
Comment 4 Adam Kemp 2015-04-20 14:42:20 UTC
@Ed, I can't come up with a test case using Xcode and Objective-C that shows the same behavior. Do you have an example?
Comment 5 Ed 2015-04-21 04:24:36 UTC
Created attachment 10836 [details]
Demo project based on Foundation.NSTimer.CreateScheduledTimer
Comment 6 Ed 2015-04-21 04:28:40 UTC
I posted another project that exhibits the same behavior. It's based on Foundation.NSTimer.CreateScheduledTimer.

I will check in Xcode later today. I guess in Xcode it's less likely to reproduce because Xamaron.Forms introduce additional overhead over the UI run loop on their own?
Comment 7 Adam Kemp 2015-04-21 11:47:01 UTC
In both cases the timer actually keeps running (you can set a breakpoint to prove it), but the UI doesn't update. That's the behavior I couldn't reproduce without Xamarin.Forms. I'm not certain it's a bug yet, but something about how Xamarin.Forms triggers UI updates seems to make this worse. Maybe it's just that much more CPU time. I don't know. I wish I could trigger it without Forms to be confident it's not something that could be fixed.
Comment 8 Ed 2015-04-21 14:26:48 UTC
Created attachment 10846 [details]
Xcode swift project, similar GUI updating loop, runs smoothly

Adam, you are absolutely right. The timer still gets called, but GUI stops being updated. I checked this with Console.WriteLine("..") calls. I also created a swift project in Xcode with similar GUI updating loop, and it runs smoothly (attached to this bug report). So, I guess there is indeed something wrong under the hood in Xamarin.Forms. Reopening this issue.
Comment 9 Ed 2015-04-21 18:29:29 UTC
Created attachment 10852 [details]
iOS app with native interface

I tried the same GUI updating loop in an iOS app with native UI, no issues. So, i guess  there is really an issue with Xamarin.Forms.
Comment 10 Ed 2015-04-21 18:31:39 UTC
In fact, in the app i am currently developing, even after i moved all heavy stuff into ThreadPool there is still stuttering from time to time. And the more controls on the screen the more likely interface will intermittently freeze.
Comment 11 Ed 2015-04-22 07:15:44 UTC
Created new thread on Xamarin.Forms forum http://forums.xamarin.com/discussion/38843/label-value-is-not-updated-when-inotifypropertychanged-property-changes#latest

Hope this one gets attention from Xamarin team.
Comment 12 John Miller [MSFT] 2015-04-22 10:18:17 UTC
I was able to reproduce this with the project linked in the forum post from Comment 11.
Comment 13 Ed 2015-04-22 12:02:48 UTC
Just a note why i would consider this bug critical. What happens here is that updates to GUI are being lost and this leads to a situation when GUI is not synchronized anymore with the underneath model.
Comment 14 Chris King 2015-05-28 19:04:48 UTC
Ed, thanks for taking the time to bring this issue to our attention. Very interesting issue! 

I would expect Forms to be able to update a bindable property at greater than 60hz and have Forms ignore updates between the 16ms refresh periods. So that if in 16ms the property is set to A, then B, then C that forms would ignore A, and B and only do heavy work when it's decided to render C. We'll do further investigation but I'd expect that we're simply doing to much work after each update (A and B) and not optimizing for the case where the value is simply going to be overridden by a new value (C) before the next layout. 

To help us prioritize optimizing this use case can you tell us why you need to update a bindable property 1000x within a 16ms (60hz) window given that the user will only see 1 out of 1000 of the values?

Warm regards,
Xamarin Forms Team
Comment 15 Ed 2015-05-29 06:18:51 UTC
Chris, i made this loop in the test app to make this bug 100% reproducible, otherwise it's intermittent in our application.

Since you say that that issue might be due to the GUI thread being overloaded and thus skipping values, i assume that transferring parameters from the main thread to the GUI thread is done through some kind of queue? Probably a workaround would be keeping the lastly set value for a property in that queue while pushing out the others? Just guessing.

As for the priority for this issue, i tried hard to mitigate this issue in our project, but it still remains of a high priority for us, since it still manifests itself from time to time, not that frequently though as it was before.

It might become a real problem after it triggers to its full extent and becomes intolerable due to the changes we constantly do to our application.

Best regards,
Edward
Comment 17 Adam Kemp 2016-12-09 15:55:44 UTC
There's a test app attached. Did you try that on a recent iOS?
Comment 18 Paul DiPietro [MSFT] 2016-12-09 21:12:44 UTC
This was mistakenly closed
Comment 19 Mike Norman 2017-06-19 14:19:41 UTC
This repros on 10.3 in the simulator. Timers are created every 20ms that should range between 0.0-1.0s, but the UI is updated like every 4 or 5 seconds.