Как поставщик календаря хранит экземпляры бесконечно повторяющихся событий? - PullRequest
Новая
       71

Как поставщик календаря хранит экземпляры бесконечно повторяющихся событий?

3 голосов
/ 18 февраля 2020

В Поставщик календаря есть несколько таблиц данных, есть таблица событий, в которой хранятся сведения об отдельных событиях, и есть таблица экземпляров, в которой хранятся время начала и окончания каждого события.

Мой вопрос:

Как именно вхождения хранятся в таблице Экземпляров, например, как таблица может хранить каждое вхождение для события, если событие повторяется каждый день навсегда? Для этого потребуется бесконечное количество строк в таблице, а также не потребуется ли много места для хранения? Событие, которое повторяется каждый день в течение одного года, будет содержать 365 записей в таблице, так что не стоит ли тратить впустую каждое событие?

Ответы [ 2 ]

0 голосов
/ 25 февраля 2020

Как обычно работают календари, основано на том, что называется RRule (правило повторения) ( RF C -5545 ) Спецификация ICalendar.

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

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

RRULE - это то, что позволяет повторяющимся событиям храниться как одно событие. В противном случае, как вы сказали, это будет очень ресурсоемким.

RRule будет выглядеть примерно так:

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

Учитывая RRule и диапазон дат, вы можете вычислять экземпляры событий календаря между указанным диапазоном дат.

Я не уверен, что провайдер Календаря делает с базой данных экземпляра, но это может быть просто для кэширования этого вычисления.

0 голосов
/ 21 февраля 2020

Когда вы создаете повторяющееся событие без конечной даты, поставщик расширяет его, чтобы заполнить ваш календарь как минимум на год. Если вы прокручивали свой календарь в течение более года, он будет расширять событие до последней просмотренной даты.

Да, это довольно неэффективно в теории, но не так уж плохо на практике. В моих тестах ежедневное событие, запланированное на 5 лет, занимало около 150 КБ в размере базы данных (1858 строк). Еженедельное событие - 30 КБ (266 строк).

Это не проблема для нормализованной базы данных с индексами даже на младших устройствах.

...