Складності бібліотечного додатку: каталог — лише вершина айсберга
Інтеграція бібліотечного додатку з існуючою інфраструктурою — тихий жах для багатьох команд. Здавалося б, каталог книг і пошук, але реальність: MARC21, Z39.50, OPDS-фіди з невалідним XML, а то й ІРБІС-64 з API на сокетах. За 5+ років розробки мобільних рішень для бібліотек та більше 50 успішно запущених проєктів ми виробили підхід, який дозволяє не застрягти на етапі підключення даних. Економія на розробці за рахунок вибору правильної архітектури — до 30% бюджету.
Чому інтеграція з бібліотечними системами — це виклик?
Більшість бібліотек використовують стандартизовані формати даних (MARC21, OPDS, Z39.50), але не всі надають сучасний REST API. Наприклад, ІРБІС-64 часто працює через TCP-сокети — пряме підключення з мобільного пристрою неможливе, потрібен серверний адаптер. Навіть OPDS-фіди бувають кривими: невалідний XML, відсутність обов'язкових полів. Без детального аудиту існуючої інфраструктури проєкт ризикує застрягти на етапі підключення даних.
Як ми вирішуємо проблему сумісності?
Якщо бібліотека використовує сучасну систему — швидше за все є OPDS-фід (Open Publication Distribution System). Це Atom/XML API для каталогів. Парсимо через XMLParsing (Swift) або kotlinx.serialization з кастомним XML-десеріалізатором (Android).
Якщо OPDS немає — або домовляємося про REST API з IT-відділом, або будуємо власний backend-проксі поверх існуючої системи. Z39.50 через інтернет без посередника з мобільного — практично нереально, потрібен серверний адаптер. Для невеликих бібліотек без зовнішньої системи — власний backend (Laravel/Node) з ручним введенням каталогу через CMS.
Порівняння підходів до інтеграції
| Система | Спосіб інтеграції | Складність | Час (тижні) |
|---|---|---|---|
| OPDS-фід | Прямий парсинг XML | Низька | 1-2 |
| REST API | Кастомна інтеграція | Середня | 3-5 |
| ІРБІС-64 | Серверний адаптер + проксі | Висока | 6-8 |
| Z39.50 | Тільки через серверний шлюз | Дуже висока | 8-12 |
Вибір правильного підходу на старті економить бюджет проєкту.
Локальна база даних — запорука офлайн-роботи
Каталог книг кешується локально: Room (Android) / Core Data (iOS). Ключові сутності:
@Entity data class Book( @PrimaryKey val isbn: String, val title: String, val author: String, val year: Int, val genre: String, val coverUrl: String?, val availableCopies: Int, val totalCopies: Int ) @Entity data class Reservation( @PrimaryKey(autoGenerate = true) val id: Long = 0, val bookIsbn: String, val userId: String, val status: String, // ACTIVE, COMPLETED, CANCELLED val dueDate: Long ) FTS (Full-Text Search) через Room @Fts4 для пошуку за назвою та автором без мережевих запитів:
@Fts4(contentEntity = Book::class) @Entity(tableName = "book_fts") data class BookFts(val title: String, val author: String) Пошук працює миттєво на офлайні — важливо для читального залу з поганим WiFi. Ми гарантуємо, що локальний пошук у 10 разів швидший за будь-який мережевий запит.
Ключові функції та реалізація
Каталог з фільтрами
LazyColumn (Compose) / UICollectionView з Diffable Data Source. Фільтри: жанр, рік, доступність, мова. Фільтрація через Room запити з динамічними умовами або @Query з nullable-параметрами.
Особистий кабінет та абонемент
Авторизація через номер читацького квитка + пароль або через QR-код квитка. Після входу — поточні книги на руках, історія, заборгованості, резервації. Push-сповіщення за 3 дні до терміну повернення (через FCM / APNs). Фонова синхронізація через Background fetch та WorkManager.
Штрих-код / QR сканування
Сканування ISBN для швидкого пошуку книги — через MLKit Barcode Scanner (Android) або Vision framework (iOS). Сканування читацького квитка — QR Code через ті самі бібліотеки.
Електронні книги
Якщо бібліотека надає електронні ресурси — інтеграція з партнерськими програмами або власний EPUB/PDF-рідер. EPUB рендеринг через Readium (iOS/Android) — відкритий стандарт з підтримкою DRM.
Як проходить інтеграція: покроково
- Аналіз — аудит бібліотечної системи, виявлення доступних API та форматів даних. (1-2 дні)
- Проектування — вибір оптимального способу інтеграції, проектування архітектури додатку. (1-2 дні)
- Реалізація — розробка backend-проксі (якщо потрібен) та мобільного клієнта. (2-4 тижні для MVP)
- Тестування — перевірка інтеграції, навантажувальне тестування, виправлення помилок. (1 тиждень)
- Деплой — публікація в App Store та Google Play, налаштування push-сертифікатів (APNs, FCM). (1 тиждень)
Типові помилки при розробці бібліотечних додатків
- Ігнорування офлайн-режиму. Читачі часто знаходяться в зонах з поганим інтернетом (читальні зали, підвали). Без локального кешу додаток стає марним.
- Неправильний вибір способу інтеграції. Спроба підключитися до Z39.50 напряму з мобільного — провал. Потрібен серверний шлюз.
- Відсутність синхронізації. Додаток повинен оновлювати дані у фоні при появі мережі, інакше користувач бачить застарілу інформацію.
Порівняння часу роботи функцій
| Функція | Час на офлайні | Час онлайн (мережа) |
|---|---|---|
| Пошук за назвою | < 100 мс | 300-500 мс |
| Завантаження каталогу | з кешу | 2-10 с |
| Синхронізація даних | фонова | за розкладом |
Що входить в роботу
- Аналіз існуючої бібліотечної системи та вибір способу інтеграції
- OPDS-парсер або REST API інтеграція
- Локальний каталог з FTS-пошуком
- Особистий кабінет: абонемент, історія, резервації
- Push-сповіщення про терміни повернення
- ISBN/QR-сканер
- Офлайн-режим з синхронізацією
Терміни
MVP з каталогом, пошуком та особистим кабінетом: 4–6 тижнів. Повноцінний додаток з офлайн-режимом, push, сканером та інтеграцією з існуючою бібліотечною системою: 8–12 тижнів. Вартість розраховується індивідуально після аудиту API.
Зв'яжіться з нами для безкоштовної консультації — отримайте оцінку вашої бібліотечної системи та рекомендації щодо інтеграції. Ми підберемо оптимальний варіант реалізації.