Event alarms are not created correctly in EventKit with iOS4.3 / calendars synchronized with Google Calendar.

I have a seemingly simple tutorial that uses EventKit to create events with alarms. No wonder this will not work. That's what I'm doing:

  • Create an EKEvent using [EKEvent eventWithEventStore:] and populate a bunch of properties
  • Add an alarm with [myEvent addAlarm:[EKAlarm alarmWithRelativeOffset:]]
  • Save the event using [myEventStore saveEvent:span:error:]

The only β€œunusual” things in the whole process are that I use the phone with the old version of iOS (iOS4.3.3 on iPhone 4) and that all the calendars that I use are synchronized with Google Calendars.

I have one calendar (let him call it CalendarA) that is configured on Google Calendars to have an automatic 30-minute alarm for new events and another calendar (CalendarB) that is not configured for any automatic alarms.

Here is the broken behavior that I see:

  • When I add EKAlarm with some non-zero relative value (e.g. 5 minutes) to CalendarA, the calendar ignores my offset and sets it to 30 minutes.
  • When I do the same in CalendarB, my alarm is completely ignored and the event ends without alarm

Which is really strange: If I set relativeOffset to zero, everything works fine for this special case! (A zero offset alarm has been correctly added, in both CalendarA and CalendarB cases). By the way, if I do not create an alarm at all, events in CalendarA will still receive a 30-minute signal. I think nothing can be done there about this.

I also tried to save the event immediately after creating the event, and then immediately add an alarm to the already saved instance and save it again. It did not help.

If I manually create alarm events through my own Calendar application on the phone, the alarms work fine, so I know that you can synchronize arbitrary alarms with Google Calendars - the question is how to do this using the code.

How can I properly configure my event alarms?

+4
source share
2 answers

Wow, I just solved it ... Apparently, it had nothing to do with iOS versions, Google Calendaring, etc. I just did not understand that I needed to pass a negative value to alarmWithRelativeOffset. It was completely unintuitive. With negative bias, it works great. This also explains why a zero offset was previously performed.

(maybe this might be a bit related to Google calendars ... I assume that other calendars may support alarms after the event, and this would make it easier for me to debug the problem, but it is not supported in Google Calendars, so the wrong "future alarm" just ignored).

There is still a minor problem when there is no way to create an alarm-free event in CalendarA, but I assume that nothing can be done here - even then, the native calendar application has this problem.

0
source

This worked for me on iOS 4.2, see if this helps you too

  EKEventStore* eventStore = [[EKEventStore alloc] init]; EKEvent* event = [EKEvent eventWithEventStore:eventStore]; // set startDate, endDate, title, location, etc. [event addAlarm:[EKAlarm alarmWithRelativeOffset:60.0f * -5.0f]]; // 5 min [event setCalendar:[eventStore defaultCalendarForNewEvents]]; NSError* error = nil; BOOL success = [eventStore saveEvent:event span:EKSpanThisEvent error:&error]; 
+1
source

Source: https://habr.com/ru/post/1490766/


All Articles