8

In Calendar Provider there are multiple data tables, there's the Events table, which store details of individual Events, and there's the Instances table, which store the start and end time for each occurrence of an Event.

My question is:

How exactly are occurrences stored in the Instances table, like how could the table store every occurrence for an Event if the Event is repeating everyday forever? It would need infinite number of rows in the table, and also wouldn't this require much storage space? An Event that repeats everyday for one year would have 365 entries in the table, so isn't it a waste to store every occurrence of an Event?

Azzam Alsharafi
  • 673
  • 1
  • 6
  • 11
  • Are you asking the logic/algorithm (in general) of storing such instance? Or you want to know exactly how Calendar Provider works in doing so? – Harry Timothy Feb 21 '20 at 03:33
  • I'm asking for the logic of storing "infinite" data in a database table, and why isn't it considered a waste of space and inefficient to store every instance. – Azzam Alsharafi Feb 21 '20 at 06:25

2 Answers2

5

When you create a recurring event without end date, the provider expands it to fill your calendar for at least a year. If you scrolled your calendar down for more than a year, it will expand the event to the last date viewed.

Yes, it is quite inefficient in theory, but not so bad in practice. In my tests, a daily event scheduled for about 5 years took about 150KB in the database size (1858 rows). A weekly event - 30 KB (266 rows).

This is not an issue for a normalized database with indices even on low-end devices.

Константин Осипов
  • 741
  • 4
  • 11
  • What about querying from the table, wouldn't it take much time if the table has for example 5000+ rows(multiple daily events)? – Azzam Alsharafi Feb 21 '20 at 17:24
  • No, it would utilize the RRule to query the table. Refer to my post below. – Bodman Feb 25 '20 at 20:48
  • For people curious – go to your google calendar, setup a recurring meeting and fast-forward ~14-15 years. The event will likely be present and then will disappear from the calendar. – mdmb Nov 14 '22 at 15:35
  • 1
    @mdmb For me it's ~2 years only and the guy here also mentions 730 instances https://stackoverflow.com/questions/30599745/google-calendar-api-recurring-event-with-max-time-limit – Andrey Stukalin Feb 17 '23 at 10:27
0

The way calendars generally work is based on what is called a RRule (Recurrence Rule) (RFC-5545) ICalendar Specification .

https://icalendar.org/iCalendar-RFC-5545/3-8-5-3-recurrence-rule.html

https://developer.android.com/reference/android/provider/CalendarContract.EventsColumns#RRULE

The RRULE is what allows recurring events to be stored as a single event. Otherwise like you said, it would be very resource-intensive.

An RRule will look something like this :

"FREQ=MONTHLY;BYMONTH=1,3,5,7;BYMONTHDAY=4,8,12;COUNT=20"

Given an RRule and a date range, you can calculate calendar event instances between said date range.

I'm not sure what Calendar Provider is doing with the instance database, but it may just be to cache that calculation.

Community
  • 1
  • 1
Bodman
  • 7,938
  • 3
  • 29
  • 34
  • 1
    I thought about it the idea that maybe it generates the Instances when you request them, but if that's the case how can it do it quickly? You can scroll down in Google Calendar app very quickly and you wouldn't notice any slowness. – Azzam Alsharafi Feb 26 '20 at 02:48
  • Creating instances from the RRule is quick. You probably wouldn't notice a slowdown. I've created calendar applications before and navigating through a calendar with recurring calendar events is instantaneous – Bodman Feb 26 '20 at 16:06
  • But then why doesn't Google Calendar app generates instances as you scroll, because as the other person said, when you create a daily Event, instances of the Event will be generated for the next two years only (730 instances in total) so in Google Calendar the instances aren't generated dynamically as you said. – Azzam Alsharafi Feb 26 '20 at 16:17
  • If that's the case. They care caching the calculation. Most likely just a tradeoff between memory and speed to improve user experience on lower-end devices. I shouldn't have said instantaneous. All of the implementations I have does this are on the server, rather than on device where processor speed isn't the bottleneck. – Bodman Feb 26 '20 at 18:08