Bug 45801 - UNUserNotificationCenter resets UNTimeIntervalNotificationTrigger when adding other triggers.
Summary: UNUserNotificationCenter resets UNTimeIntervalNotificationTrigger when adding...
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: XI 10.0 (iOS10)
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Future Cycle (TBD)
Assignee: Alex Soto [MSFT]
Depends on:
Reported: 2016-10-21 19:25 UTC by Matt Gerber
Modified: 2016-12-07 20:32 UTC (History)
4 users (show)

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

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 Matt Gerber 2016-10-21 19:25:04 UTC
I am using the new UNUserNotificationCenter to schedule three notifications, each using a UNTimeIntervalNotificationTrigger. Suppose that at 10:00:00 I schedule these to trigger after 5, 10, and 30 seconds, respectively (i.e., at 10:00:05, 10:00:10, and 10:00:30). At 10:00:03 I then add a fourth time interval notification to trigger after 60 seconds and check the list of pending notifications. Here's what I see:

#1:  10:00:08
#2:  10:00:13
#3:  10:00:33
#4:  10:01:03

It appears that adding #4 reschedules all of the previous requests based on the time that #4 was requested. This does not seem correct. Requests #1, #2, and #3 should not be changed by subsequent requests. Any ideas about what might be going on?
Comment 1 Alex Soto [MSFT] 2016-10-23 22:01:54 UTC
Hello Matt

Thanks for contacting us Xamarin.iOS is a very thin layer on top of the CocoaTouch frameworks so it is very likely this is an apple bug. That being said is there any chance you could share with us a small test case so we can reproduce and see the exact APIs that you are using? This would help a lot to give you an accurate response.

Also please include your version information. The easiest way to get exact version information is to use the "Xamarin Studio" menu, "About Xamarin Studio" item, "Show Details" button and copy/paste the version informations (you can use the "Copy Information" button).

Comment 2 Matt Gerber 2016-10-26 04:52:39 UTC
Thanks for the response. I don't have code for you, but here's what you can do:

1) Schedule notification with UNTimeIntervalNotificationTrigger using interval = 5.
2) Print out next fire date for each pending notification.
3) Thread.Sleep(1000)
4) Schedule notification with UNTimeIntervalNotificationTrigger using interval = 10.
5) Print out next fire date for each pending notification.

You'll see that the next fire date for the first notification changes from (2) to (5), and you won't get the first notification 5 seconds after it was scheduled.

Here's my XS setup;

=== Xamarin Studio Community ===

Version 6.1.1 (build 15)
Installation UUID: df8071f4-bfec-4c12-95f4-9da31a57d67c
	Mono 4.6.1 (mono-4.6.0-branch-c8sr0/ef43c15) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 406010005

=== NuGet ===


=== Xamarin.Profiler ===

Not Installed

=== Xamarin.Android ===

Version: (Xamarin Studio Community)
Android SDK: /Users/matthewgerber/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		4.0.3 (API level 15)
		4.4   (API level 19)
		5.0   (API level 21)
		5.1   (API level 22)
		6.0   (API level 23)

SDK Tools Version: 25.1.3
SDK Platform Tools Version: 24.0.0
SDK Build Tools Version: 23.0.2

Java SDK: /usr
java version "1.8.0_66"
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)

Android Designer EPL code available here:

=== Xamarin Android Player ===

Not Installed

=== Apple Developer Tools ===

Xcode 8.0 (11246)
Build 8A218a

=== Xamarin.iOS ===

Version: (Xamarin Studio Community)
Hash: ad1cd42
Branch: cycle8-sr0-xi
Build date: 2016-10-03 15:18:44-0400

=== Xamarin.Mac ===

Version: (Xamarin Studio Community)

=== Build Information ===

Release ID: 601010015
Git revision: fa52f02641726146e2589ed86ec4097fbe101888
Build date: 2016-09-22 08:03:02-04
Xamarin addins: 75d65712af93d54dc39ae4c42b21dfa574859fd6
Build lane: monodevelop-lion-cycle8-sr0

=== Operating System ===

Mac OS X 10.11.5
Darwin Matthews-MacBook-Pro.local 15.5.0 Darwin Kernel Version 15.5.0
    Tue Apr 19 18:36:36 PDT 2016
    root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64
Comment 3 Vincent Dondain [MSFT] 2016-12-07 19:52:24 UTC

So I've created a quick test case so we can all agree on the issue: https://www.dropbox.com/s/3ht2lp5cto9xs8u/Bug45801.zip?dl=0

Now I would like to know if that matches the code you wrote to delay the 4th notification by 3 seconds or if it was different.

The test case has 1 button "Trigger" that will trigger 3 notifications at T+5, +10 and +30 as well as a 2nd button called "4th" to trigger the 4th notification at T+5.

Clicking the "Trigger" button and the "4th" button 3 seconds later give me this:

Trigger Button Start - T0
FourthNotification Button Start - T03
Notification 1 - T08
Notification 4 - T08
Notification 2 - T13
Notification 3 - T33

Since the UNUserNotificationCenter is shared is seems indeed to delay all subsequent notifications.

Nothing we can do on our end though, seems like the way the API is designed and if there's an other way to do it you'll have more chances of getting the proper answer on the forums.

Please let me know if your code matches this test case, if not please update the test case and share it with us so we can discuss your code, however if there's nothing special you're doing then I'd stick to the fact it's not on our end.
Comment 4 Matt Gerber 2016-12-07 20:21:28 UTC
Yes, your code is functionally equivalent to the code that I was running. You're seeing the same problem that I was seeing, and we agree on the issue.
Comment 5 Vincent Dondain [MSFT] 2016-12-07 20:32:19 UTC
Right, then unfortunately this is how the API is designed.

As Alex said Xamarin.iOS is a very thin layer on top of the CocoaTouch frameworks and there's nothing here *we* can do.

I'd like to be able to help you more on this but at this point your best options are:

1. File a radar at https://bugreport.apple.com so someone at Apple can explain why it's been done like that or what are the other ways to achieve your goals.
2. Ask on the Apple forums https://forums.developer.apple.com so other users can help you work around this behavior.
3. Ask on our forums https://forums.xamarin.com to the see if you can gather other idea from our users.