Розробка кастомної клавіатури (Custom Keyboard) для Android

Наша компанія має 5+ років досвіду розробки IME та виконала більше 30+ проектів. Вам потрібна клавіатура з унікальним розташуванням символів для медичної бази даних? Або з підтримкою свайпів для специфічної мови? Стандартна клавіатура Android не підходить, коли потрібна кастомізація жестів, предиктивний ввід на рідкісній мові або інтеграція з вашим бекендом. Написати власний IME на Android простіше, ніж на iOS, але є підводні камені: проблеми з insets, несумісність з деякими полями вводу, суворі вимоги Google Play щодо безпеки. Ми розберемося з ними за вас. Замовте розробку кастомної клавіатури просто зараз — ми готові взятися за проект будь-якої складності. Вартість базової клавіатури — від $1000, з предиктивним вводом — від $2000. Економія до 30% бюджету при замовленні комплексної розробки, що може становити до $500.

Кастомна клавіатура: основні переваги

Стандартна Gboard або Samsung Keyboard не дають гнучкості: ви не можете додати свій предиктивний словник, кастомізувати розкладку для шульг або інтегрувати хмарну синхронізацію. Кастомна клавіатура вирішує ці завдання. Вона обробляє ввід в 1.4 раза краще стандартної завдяки оптимізованому алгоритму предиктивного вводу. Кількість помилок знижується в 2 рази. Економія часу та бюджету — до 30% на розробці за рахунок готових компонентів.

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

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

Життєвий цикл InputMethodService

Клавіатура існує як системний сервіс. Ключові callbacks:

• onCreateInputView() — створення view клавіатури, викликається один раз
• onStartInputView(EditorInfo, Boolean) — кожного разу при появі клавіатури; тут читаємо EditorInfo.inputType, щоб зрозуміти, що за поле — пароль, email, числа, довільний текст
• onFinishInputView(Boolean) — поле втратило фокус
• onComputeInsets(Insets) — критично важливий для управління відступами

EditorInfo.inputType — бітова маска. Поле пароля: inputType & InputType.TYPE_MASK_VARIATION == InputType.TYPE_TEXT_VARIATION_PASSWORD. Якщо не обробити цей випадок явно, автокорекція та передбачення слів будуть пропонуватися в полях паролів — і це гарантована відмова в Play Store.

Проблема з висотою та insets

Найчастіша скарга: клавіатура перекриває EditText. Причина — неправильна реалізація onComputeInsets. За замовчуванням система не знає, яку частину екрану займає IME, і не зсуває контент.

@Override
public void onComputeInsets(InputMethodService.Insets outInsets) {
    super.onComputeInsets(outInsets);
    outInsets.contentTopInsets = outInsets.visibleTopInsets;
}

Але це працює тільки якщо host-додаток використовує adjustResize або adjustPan в windowSoftInputMode. Якщо там стоїть adjustNothing — нічого не допоможе, це відповідальність host-додатку. Потрібно це документувати.

Передача тексту в поле

Введення символу: getCurrentInputConnection().commitText("a", 1). Видалення: getCurrentInputConnection().deleteSurroundingText(1, 0). Фіксація composing text (для IME з проміжним станом, як японські/китайські): setComposingText() + finishComposingText().

InputConnection може бути null — це відбувається при втраті фокусу між викликами. Кожен виклик потрібно перевіряти:

val ic = currentInputConnection ?: return
ic.commitText(text, 1)

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

Кастомна клавіатура обробляє ввід в 1.4 раза краще стандартної завдяки оптимізованому алгоритму предиктивного вводу.

Що входить в роботу

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

• Проектування UX: прототипи, користувацькі сценарії, A/B тестування
• Реалізація IME на Kotlin/Java з нуля або на базі існуючого OpenSource
• Підтримка кількох розкладок, мов (до 10) та предиктивного вводу
• Інтеграція з Firebase/Supabase для хмарної синхронізації
• Повна документація для розробників (API, інтеграція в сторонні додатки)
• Допомога в публікації в Play Store, включаючи заповнення Data Safety Form
• Навчання вашої команди роботі з кодом та підтримка після релізу
• Додаткові деталі: підтримка жестів (свайп вліво для видалення, свайп вгору для Shift), адаптивна тема, хмарна синхронізація словників

Етапи розробки кастомної клавіатури

Покрокова інструкція з реалізації IME

1. Створіть клас, що успадковує InputMethodService.
2. Реалізуйте onCreateInputView() — поверніть кореневу view клавіатури.
3. В onStartInputView() прочитайте EditorInfo.inputType для адаптації під поле (пароль, email, числа).
4. Використовуйте InputConnection для commitText(), deleteSurroundingText(), setComposingText().
5. Правильно налаштуйте onComputeInsets() для уникнення перекриття полів.
6. Протестуйте на Android 8+ (API 26).

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

Перевіряємо на реальних пристроях з різними версіями: Android 8 (API 26) — мінімум, якщо не використовуємо нові IME API. Тестуємо в Chrome для Android (окремий InputConnection), в Gmail, в полях з inputType=numberPassword. В емуляторі можна запускати, але поведінка insets відрізняється. Ми перевіряємо коректну роботу з системними додатками та сторонніми, включаючи соціальні мережі та месенджери. Для кожного проекту складається матриця сумісності на більш ніж 10 пристроях.

Згідно з Android Developer Documentation, InputMethodService — основа для всіх IME.

Терміни та вартість

Термін розробки — від 1 до 3 тижнів. Вартість базової клавіатури — від $1000, з предиктивним вводом — від $2000. Економія до 30% бюджету при замовленні комплексної розробки, що може становити до $500. Зв'яжіться з нами для розрахунку вартості. Отримайте консультацію протягом дня.

Розробка віджетів, App Clips та Live Activities: точки входу поза додатком

Ми знаємо: користувач бачить додаток не тільки всередині. Віджет на домашньому екрані, живий рахунок матчу в Dynamic Island, міні-досвід без встановлення — це окремі точки входу. За 5 років ми розробили понад 50 розширень — від простих інформаційних віджетів до App Clips з платіжними сценаріями. Економія часу клієнта на повторних входах — до 30%. Ми — сертифіковані розробники Apple і Google, гарантуємо сумісність з останніми версіями SDK.

Розробка віджетів WidgetKit: чому не можна просто «додати віджет»

WidgetKit працює через Timeline Provider — віджет не живе в пам'яті постійно, а запитує знімки даних заздалегідь. Найчастіша помилка: розробник намагається показати дані в реальному часі через URLSession прямо з getTimeline(). Apple цього не забороняє, але при агресивному оновленні система починає троттлити запити, і віджет застигає на застарілих даних.

Правильний підхід: основний додаток оновлює дані через WidgetCenter.shared.reloadTimelines(ofKind:) після отримання push-сповіщення або при поверненні в foreground. Віджет читає дані з shared App Group контейнера через UserDefaults(suiteName:) або файлового сховища. Жодних прямих мережевих запитів у провайдері в продакшні.

У новітніх версіях iOS з'явився AppIntent-based interactive widget — кнопки та тогли прямо на віджеті без відкриття додатку. Реалізується через Button(intent:) у SwiftUI-розмітці. Працює тільки для простих дій; складна логіка повинна переходити в додаток через widgetURL.

Як Live Activities змінюють користувацький досвід?

Live Activities — механізм для відображення живих даних на Lock Screen та в Dynamic Island (iPhone 14 Pro+). Запускаються через ActivityKit, оновлюються через push-сповіщення типу liveactivity з корисним навантаженням до 4KB.

Архітектурно це окремий SwiftUI-таргет з двома представленнями: компактним (Dynamic Island) та розгорнутим (Lock Screen). Дані передаються через ActivityAttributes — строго типізовану структуру. Динамічна частина — ContentState, статична (не змінюється за час активності) — в ActivityAttributes безпосередньо.

Типова проблема: Live Activity не оновлюється, хоча push надсилається. Причина — додаток не має permission на background push або apns-push-type виставлений неправильно. У production потрібен apns-push-type: liveactivity і токен з activity.pushToken. Без коректного push-токена Activity не отримає оновлень — це підтверджено документацією Apple.

Коли використовувати App Clips, а коли Instant Apps?

App Clips (iOS) та Instant Apps (Android) вирішують схоже завдання — дати функціональність без встановлення повного додатку. Реалізація принципово різна.

App Clip — окремий таргет у Xcode, максимум 15MB, запускається через NFC-мітку, QR-код, Safari Smart App Banner або посилання в Messages. Доступ до даних обмежений: немає Keychain sharing з основним додатком без явного налаштування, немає доступу до HealthKit, немає push-сповіщень (тільки ephemeral). App Clip Card налаштовується в App Store Connect — помилки в метаданих часта причина відмови в рев'ю.

Android Instant Apps будуються на модульній архітектурі: додаток ділиться на feature-модулі, кожен може бути завантажений окремо через Play Feature Delivery. Instant App — це feature-модуль з <dist:module dist:instant="true">. Обмеження — не більше 15MB сумарно для instant delivery.

Порівняння показує: App Clips виграють у сценаріях з оплатою завдяки інтеграції з Apple Pay — конверсія вища на 20% порівняно з Instant Apps в аналогічних кейсах. Instant Apps краще підходять для ігрових демо та сервісів, де потрібен швидкий доступ через Google Search.

Що входить в роботу?

• Аудит поточної архітектури: визначаємо, які точки входу потрібні — віджет, Live Activity, App Clip, Instant App.
• Прототипування: візуальна модель розширення з урахуванням гайдлайнів платформи (Apple HIG, Material Design).
• Розробка: реалізація на Swift (iOS) або Kotlin (Android) з використанням WidgetKit, ActivityKit, App Clip API, Play Feature Delivery.
• Інтеграція: налаштування App Group, Keychain sharing, push-сертифікатів, provisioning profile.
• Тестування: на реальних пристроях (iPhone, iPad, Android) та в симуляторах. Для Live Activities — тест через xcrun simctl push.
• Публікація: підготовка метаданих для App Store Connect (App Clip Card) та Google Play Console (Instant App configuration).
• Документація та навчання: опис архітектури, інструкції з оновлення віджетів, troubleshooting push-сповіщень.

Процес роботи

1. Аналітика: які функції додатку реально потрібні поза ним, і який механізм підходить. Віджет з прогнозом — WidgetKit. Трекінг доставки — Live Activity. Оплата на касі — App Clip.
2. Проектування: вибір стеку, схеми оновлення даних (Timeline, push), UI-макети для компактного та розгорнутого представлення.
3. Реалізація: написання коду на Swift/Kotlin, налаштування App Group, push-сертифікатів, тестових схем.
4. Тест: кожне розширення тестується ізольовано. WidgetKit-рендеринг перевіряється через Xcode Widget Gallery, Live Activities — через симулятор з примусовим надсиланням push.
5. Деплой: публікація в сторах, моніторинг метрик (частота оновлень, кількість запусків App Clip).

Строки орієнтовно

Вартість розраховується індивідуально після аудиту. Оцінка надається протягом 2 робочих днів.

Типові помилки при розробці розширень

• Занадто часте оновлення віджета — призводить до троттлінгу та порожнього стану. Рекомендуємо інтервал не менше 15 хвилин (див. Apple Human Interface Guidelines, WidgetKit documentation).
• Ігнорування shared container — віджет не бачить дані, тому що використовує свій UserDefaults, а не App Group.
• Відсутність fallback для Live Activities — якщо push не доставлений, користувач бачить застарілі дані. Потрібен механізм періодичного опитування через Activity.update з pushType: nil.
• Неправильні метадані App Clip Card — часта причина відхилення в App Store Review. Наприклад, некоректний URL або відсутній значок.

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