Реалізація історії версій у мобільних додатках
Історія версій — це не просто журнал. Це можливість повернутися до попередньої версії документа, порівняти зміни та зрозуміти, хто і коли що змінив. Для документів, таблиць, нотаток або налаштувань це може бути критично важливою функцією. Невірна реалізація призводить до вибухового зростання розміру бази даних або втрати даних під час конфліктів.
Два підходи: Snapshot vs Event Sourcing
Snapshot: При кожному збереженні створюють повну копію об'єкта. Просто реалізується, легко відновити. Проблема — розмір сховища. Якщо документ 50 КБ, а користувач редагує його 50 разів на день — 50 × 50 КБ = 2,5 МБ на день тільки для одного документа.
Event sourcing / Delta: Зберігають лише різницю між версіями. Компактно, але складніше відновити довільну версію — потрібно відтворити всі дельти від початкового стану. Для текстового контенту — unified diff через DiffMatchPatch (доступна на Android і iOS як порт Google's diff-match-patch).
Для більшості мобільних додатків — гібридний підхід: snapshot кожні N версій або кожні M днів, між ними — дельти. Відновлення: беремо найближчий snapshot, застосовуємо дельти.
Схема даних
@Entity(tableName = "document_versions")
data class DocumentVersion(
@PrimaryKey(autoGenerate = true) val id: Long = 0,
val documentId: String,
val versionNumber: Int,
val deltaJson: String?, // null якщо snapshot
val snapshotJson: String?, // null якщо delta
val authorId: String,
val deviceId: String,
val createdAt: Long = System.currentTimeMillis(),
val comment: String? = null // "Автозбереження" / "Збережено вручну"
)
Індекс за (documentId, versionNumber) — обов'язковий для швидкого отримання історії конкретного документа.
Обмеження глибини історії
Зберігати всі версії вічно — недоцільно. Стратегії:
- Фіксована кількість: зберігати останні N версій (наприклад, 50). Старі видаляються через scheduled job.
-
Часовий період: версії за останні 30 днів. Через
WorkManager(Android) /BGProcessingTask(iOS) раз на день видаляємо застарілі. - Інтелектуальне розрідження: повні версії за сьогодні, одна на день за останній тиждень, одна на тиждень за останній місяць.
// Android — видалення старих версій через WorkManager
@Transaction
suspend fun pruneVersions(documentId: String, keepCount: Int) {
val versions = getVersionsByDocument(documentId)
if (versions.size > keepCount) {
val toDelete = versions.drop(keepCount)
deleteVersions(toDelete.map { it.id })
}
}
UI історії версій
Список версій із датою, автором, пристроєм та типом (автозбереження / ручне). Натиск на версію — попередній перегляд. Дві кнопки: «Відновити» та «Порівняти з поточною».
Порівняння версій — diff-view з виділенням доданого (зелене) та видаленого (червоне). На мобільному це зазвичай side-by-side або inline diff. Inline простіше для малих екранів: стандартний підхід із SpannableString (Android) / NSAttributedString (iOS), кольорові вставки та закреслення.
Автозбереження та дебаунс
Автозбереження не повинно створювати версію на кожний символ. Дебаунс 2–3 секунди після останньої зміни:
// iOS — дебаунс автозбереження
private var saveTask: Task<Void, Never>?
func textDidChange(_ text: String) {
saveTask?.cancel()
saveTask = Task {
try? await Task.sleep(nanoseconds: 2_000_000_000)
guard !Task.isCancelled else { return }
await saveVersion(text, type: .auto)
}
}
Обсяг роботи
- Вибір стратегії (snapshot / delta / гібрид) під обсяг даних
- Схема даних з індексами та зовнішніми ключами
- Дебаунс автозбереження
- UI списку версій із метаданими
- Diff-view для порівняння версій
- Очищення застарілих версій за розкладом
Строки
Snapshot-історія з базовим UI: 1,5–2 дні. Гібрид з дельтами, diff-view та інтелектуальним розрідженням: 4–5 днів. Вартість залежить від формату збережених даних та вимог до глибини історії.