Реалізація календаря та планувальника в мобільному застосунку

Календар мобільного застосунку: де ламається логіка часу

Календар мобільного застосунку ламається не на відрисовці сітки, а на логіці подій: зберігання часу, повторюваність і синхронізація — три незалежні шари, і помилка в будь-якому видна користувачу як «застосунок бреше».

Класика — зберігання локального часу замість абсолютного моменту. Пристрій переходить в інший часовий пояс або на літній час, і зустріч, збережена як «10:00 за місцем», перетворюється на «11:00» або зсувається на добу.

Ті самі помилки під час вибору дати дають зсув на межі місяця й року, коли розрахунок іде за локальною датою без нормалізації.

Лікується розведенням двох сутностей: момент початку — завжди в єдиному базисі, а відображення та правила нагадувань обчислюються вже під часовий пояс пристрою на момент показу.

Збої повторюваних подій — окремий клас. Серія задається правилом, але якщо винятки й перенесення одного екземпляра зберігаються не як окремі записи, а як правки шаблону, то вже перша скасована зустріч забирає всю серію.

Інший сценарій — відсутність ідентифікатора екземпляра: під час повторної синхронізації сервер вважає зустріч новою, і події дублюються. Детермінований ключ події та явний шар винятків прибирають обидва випадки.

Розсинхрон розкладу зазвичай росте з офлайн-черги. Правки накопичуються на пристрої, а під час виходу в мережу застосовуються не в тому порядку — перемагає останній запис, і частина змін мовчки губиться.

Розв'язання конфліктів за серверним часом із журналом правок і коректним приведенням часу відгуку пристрою робить список однаковим на всіх телефонах.

Ціна цих дефектів видна в підтримці: скарги виду «у мене інший розклад» не відтворюються без прив'язки до часового поясу й стану черги. Розбираємо, як закривається кожен із шарів.

Що дає надійний планувальник продукту та підтримці

Єдина логіка подій на всіх платформах

Надійний планувальник будується навколо одного джерела правди: правила повторюваності, межі доби та переходи часових поясів обчислює серверна модель, а застосунок лише показує результат.

До цього кожен клієнт рахував календар сам, і єдиний список подій розходився — на телефоні зустріч стояла на день раніше, ніж на планшеті, а нагадування приходило в чужому поясі.

Частка розходжень на приймальному наборі з переходів на літній час, зміни поясу й довгих серій скоротилася до нуля, бо їх тепер перевіряє один сценарій перевірки, а не користувач.

Менше звернень до підтримки щодо дат

Зменшення звернень до підтримки починається з того, що стан перестав жити лише на пристрої.

Зміни пишуться до журналу, тому час відновлення після збою вимірюється хвилинами: застосунок дограє пропущені операції під час наступного підключення замість перевстановлення й ручного повернення зустрічей.

Зникає цілий клас відмов виду «подія є на телефоні й немає на планшеті» — він закритий архітектурно, а не інструкцією для оператора. Навантаження на першу лінію падає в рази: питання щодо дат і нагадувань найчастіше були наслідком розсинхронізації, а не помилки людини. Розбір одного випадку займає один запит до історії змін замість листування з користувачем.

Режими роботи планувальника: порівняння підходів

Режим планувальника визначає, де зберігається джерело правди про події: на пристрої, у зовнішній системі чи на нашому сервері. Від цього залежать робота без мережі, розв'язання конфліктів і обсяг робіт під час додавання спільних нагадувань.

Як вибрати режим під сценарій користувача

Дайте відповідь на три запитання: чи потрібен спільний доступ, чи має планувальник працювати без мережі, хто володіє повторами. Якщо подія створюється в корпоративній системі, а застосунок лише показує її — достатньо синхронізації. Якщо користувач сам створює події та ділиться ними — потрібна серверна модель.

Межі застосовності кожного варіанта

Локальний режим упирається в перевстановлення застосунку та зміну пристрою. Синхронізація — у затримку зовнішньої системи та її схему прав. Серверна модель потребує фонової відправки й зрозумілого розв'язання конфліктів. Гібрид виправданий, коли особистий і робочий контури не можна змішувати в одному сховищі.

Порядок впровадження: від аудиту до передачі в підтримку

Роботи йдуть фіксованими етапами: кожен закриває свій клас помилок і закінчується артефактом, який перевіряємо до переходу далі. Так календар не розходиться з планувальником під час переведення годинників і зміни часового поясу в частини користувачів.

Що робимо на аудиті та під час проєктування схеми

1. Аудит логіки дат. Збираємо всі місця роботи з часом: відповіді сервера, локальні нагадування, повторювані події, позначки в кеші. Позначаємо, де зберігається момент часу, а де — локальні дата й час без зміщення, і де ці підходи змішані.
2. Проєктування моделі подій. Описуємо сутності: подія, серія повторів, виняток із серії, учасник, право доступу. Правило — у сховищі момент часу, у місцевий переводимо лише під час виведення на екран.
3. Синхронізація та права. Визначаємо джерело правди, розв'язання конфліктів під час правки з двох пристроїв, поведінку при втраті зв'язку та потрапляння чужих подій у вибірку.
4. Перевірка граничних сценаріїв. Проганяємо перехід на літній час, подію в неіснуючій годині, повтор «останнє число місяця», зміну часового поясу в дорозі та скасування серії з уже зміненими екземплярами.
5. Навантажувальна перевірка. Дивимося, як поводяться вибірки й нагадування на щільному розкладі та великій кількості учасників, де з'являються затримки.
6. Передача в підтримку. Віддаємо схему даних, опис моделі повторів, перелік перевірених граничних випадків та інструкцію з розбору скарг на зниклі або задвоєні нагадування.

Налаштування, схеми й регламенти, які передаємо

Передаємо не лише працюючий застосунок, а й комплект документів, за яким ваша команда зможе розвивати планувальник і розбирати звернення без нас. Нижче — що саме залишається у вас на руках.

Документація щодо логіки подій і прав

• Конфігурація планувальника: параметри повторів, правила обробки пересічних подій, поведінка під час зміни часового поясу та переходу на літній час.
• Схема моделі подій: сутності «подія», «учасник», «нагадування», «виняток із серії», обов'язкові та обчислювані поля, зв'язки між ними.
• Схема прав доступу: ролі власника календаря, учасника й спостерігача, що кожна може читати та змінювати, як права успадковуються на спільні й зовнішні календарі.
• Опис синхронізації: які джерела двосторонні, які лише для читання, як розв'язуються конфлікти одночасних правок і що бачить користувач під час втрати зв'язку.

Регламент оновлення й підтримки

• Регламент оновлення подій: порядок випуску змін у правилах повторів і нагадувань так, щоб уже створені записи не губилися й не дублювалися.
• Інструкції для підтримки: дерево рішень за типовими зверненнями — подія не з'явилася, нагадування спрацювало двічі, права не застосувалися.
• Порядок відкату та точки контролю: яка версія схеми сумісна з попередньою збіркою, що робити при розходженні даних на пристроях.

Документи оформлені в репозиторії поруч із кодом і перевіряються на актуальність під час кожного релізу. Передачу закриваємо розбором із вашою командою — щоб документацією користувалися, а не зберігали її.

Кейс: синхронізація календаря із зовнішніми системами

Клієнт — сервіс запису на послуги: мобільний застосунок і панель адміністратора, календар яких жив окремо від Google Calendar, куди менеджери вносили зустрічі вручну.

Частка розходжень сягала 6% обсягу подій: перенесена зустріч залишалася в старому слоті, підтримка отримувала близько 40 звернень «запис є, а майстра немає», а розбір одного інциденту займав у середньому 25 хвилин — журнали застосунку та зовнішньої системи не сходилися за ідентифікаторами.

У межах кейсу впровадження планувальника ми перевели обмін на постійний двосторонній цикл із журналом змін. Кожна подія отримала стабільний ідентифікатор і позначку ревізії, а мобільний клієнт — локальний кеш, з якого інтерфейс малюється миттєво, зокрема без мережі.

Зміни йдуть чергою та повторюються після відновлення зв'язку, тому втрачений пакет більше не перетворюється на втрачену зустріч.

Обробка конфліктів і повторюваних подій

Конфлікти правок подій вирішуємо не за принципом «хто останній, той і правий». Правка із зовнішньої системи порівнюється за позначкою ревізії: перемагає новіша версія, а та, що програла, не зникає — вона йде в історію й показується адміністратору як пропозиція.

Повторювані події зберігаються серією зі списком винятків і замін, а не розгорнутими копіями: перенесення однієї зустрічі не ламає серію, а зміна часового поясу не зсуває весь графік.

Через два місяці розходження скоротилися з 6% до 0,3%, звернення щодо календаря — з 40 до 5 на місяць, розбір інциденту — з 25 до 7 хвилин завдяки наскрізному ідентифікатору події.

«Головний результат не в цифрах, — каже наш інженер, — а в тому, що ручної звірки двох календарів більше немає: якщо щось розходиться, система сама показує, де й коли».

Готовий модуль планування чи власна модель подій?

Готовий модуль закриває базовий випадок: подія — точка в часі з назвою, учасниками та нагадуванням. Він дає показ місяця й тижня, прості правила повтору, повідомлення та читання системного календаря пристрою.

Щойно з'являється предметна логіка — зміни, вікна запису, залежності між завданнями — починається обхід його обмежень.

Межі застосовності визначає одна ознака: хто володіє моделлю події. Якщо розклад описується парою «початок — кінець» і одним типом запису, модуль окупається швидко — менше коду, передбачувана поведінка під час зміни часового поясу та переходу на літній час.

Якщо тип події задає доступні дії та допустиму тривалість, модель потрібна своя, а модуль залишається шаром відрисовки.

Основне обмеження — типи подій не розширюються. Зайві атрибути складають в одне поле нотаток, і фільтрація за ними перетворюється на ручну вибірку за текстом.

Свій шар подій задає тип, набір полів і правила їх поєднання: календар залишається інтерфейсом, а джерелом істини стає ваша модель, а не компонент.

Якщо частина розкладу вже розгорнута на іншій логіці, напівзаходи обходяться дорожче. Розумніше зафіксувати поточні типи й правила, залишити їх працювати, а новий інтерфейс поставити поверх через шар перетворення: попередні записи читаються, нові пишуться одразу в цільову модель. Перехід іде поступово, без зупинки для користувачів.

Вибір роблять за кількістю сутностей, а не за смаком. Якщо достатньо штатних полів і одного правила повтору — беремо готовий модуль. Якщо типів більше двох або правила конфліктують між собою — власна модель подій дешевша в підтримці. Далі розбираємо, як це лягає на конкретний розклад.

Часті технічні питання щодо реалізації

Питання на прийманні зазвичай стосуються не відрисовки сітки місяця, а поведінки на стиках: перехід через опівніч, зміна поясу в дорозі, довгі серії повторень, одночасна правка з двох пристроїв. Нижче — короткі відповіді інженерів про те, як ці сумніви закриваються в коді та в процесі.

Як влаштовані повторювані події?

Серія зберігається правилом, а не набором дат: «кожен другий вівторок», «останній робочий день місяця». Винятки й перенесення одного входження лежать окремими записами — правка одного дня не переписує всю серію, а в довгих правил задано межу розкриття.

Що відбувається під час одночасної правки з двох пристроїв?

У події є ревізія, і при розходженні сервер зливає зміни за полями, а не затирає дані останнім запитом. Пристрій отримує актуальну версію після синхронізації, тому правка заголовка на телефоні не знищує перенесення часу на планшеті.

Чи можна змінювати логіку планувальника без випуску версії в магазини?

Частину поведінки — ліміти на довжину серії, формати нагадувань, набір доступних правил — винесено в серверну конфігурацію. Такі зміни доходять до користувачів одразу, а в застосунку залишається лише логіка, яка має працювати офлайн.

Як перевіряєте календар перед випуском?

Окремим прогоном за крайовими сценаріями: подія о 23:59 із переходом через добу, серія без дати закінчення, 29 лютого, часовий пояс, що змінюється в активного повторення, переведення пристрою вперед і назад.

Чек-ліст приймання календаря: «Граничні сценарії ламають планувальник частіше, ніж основний потік, — тому кожен випуск проганяється за ними окремо, до перевірки звичайних сценаріїв».

Обговоримо завдання й повернемося з оцінкою та планом

Перш ніж називати терміни, фіксуємо межі завдання: від цього залежить і оцінка, і те, які сценарії календаря мобільного застосунку потрапляють у першу версію, а які — у другу. Нижче — що уточнюємо у вас під час розбору та що додаємо до плану робіт із впровадження.

• Сценарії використання: особистий розклад, командний календар, бронювання ресурсів — які обов'язкові до запуску, а які можна відкласти.
• Ролі та права: хто створює події, хто бачить чужий розклад, чи потрібне підтвердження участі та повідомлення про зміни.
• Зовнішні системи: з якими сервісами потрібна синхронізація, у який бік іде обмін, як розв'язуємо конфлікт записів і розрив зв'язку.
• Обсяг розкладу: скільки подій припадає на користувача, чи потрібні повторювані записи, кілька часових поясів, пов'язані ресурси.
• Робота без мережі та нагадування: як застосунок поводиться офлайн, що синхронізує при поверненні зв'язку, які повідомлення критичні для користувача.
• Терміни та обмеження: дата, до якої потрібен запуск, прив'язка до випусків, очікуване навантаження в пікові періоди.
• Обмеження на вашій стороні: доступи та стенди, вимоги до зберігання даних, готовність серверної частини до обміну.

У відповідь ви отримуєте план робіт із впровадження: склад етапів, оцінку термінів за кожним, зони відповідальності нашої команди та вашої сторони, порядок приймання з критеріями готовності. Опишіть завдання — повернемося з оцінкою та планом.