Разширения на приложения и системни интеграции в мобилната разработка: какво са, типове и как работят

Разширения на приложения на iOS: джаджи и разширения за споделяне на съдържание

Разширенията на приложения на iOS се появиха в iOS 8 и станаха основа за системните интеграции в мобилната разработка. Това са отделни двоични файлове, опаковани заедно с основното приложение, но стартирани в изолиран процес. Всяко разширение има свой собствен Info.plist и входна точка, дефинирана чрез NSExtensionPrincipalClass. Системата управлява жизнения цикъл на разширенията на приложения — те не могат да останат на заден план след завършване на задача.

WidgetKit и Today Widget

WidgetKit (iOS 14+) е модерна рамка за създаване на джаджи на началния екран. WidgetKit използва SwiftUI за описание на интерфейса и TimelineProvider за определяне на графици за обновяване. Джаджите се предлагат в три размера: малък (2×2 клетки), среден (4×2) и голям (4×4). Старата Today Widget, базирана на UICollectionViewController, все още се поддържа, но Apple препоръчва мигриране към WidgetKit. Разширенията на приложения на WidgetKit не поддържат анимация, клавиатурен вход или жестове — те са статични или псевдоанимирани елементи с периодични обновявания.

Share Extension и Action Extension

Share Extension позволява изпращане на съдържание от всяко приложение към вашето чрез системния лист за споделяне. Share Extension получава данни чрез NSExtensionItem и използва SLComposeServiceViewController за потребителския интерфейс. Action Extension обработва съдържанието на място — например превежда текст в браузъра без преминаване към друго приложение. И двата типа трябва да завършат работата си в ограничено време, в противен случай системата "убива" разширението. Това е важно ограничение на разширенията на приложения в мобилно приложение — фоновите задачи не са достъпни на ниво разширение.

CallKit, PushKit и SiriKit — системни интеграции за глас и известия

Системните интеграции на iOS надхвърлят джаджите: CallKit, PushKit и SiriKit позволяват на мобилното приложение да работи на системно ниво. Тези рамки изискват специални разрешения, но предоставят на потребителя безпроблемно изживяване — разговорите чрез CallKit изглеждат като обикновени телефонни разговори, а Siri обработва заявки без отваряне на приложението.

CallKit — VoIP разговори в системния интерфейс

CallKit интегрира разговори на приложения на трети страни в системния екран за разговори, включително заключения екран. CXProvider регистрира приложението като VoIP услуга, а CXCallController управлява разговорите. CallKit автоматично блокира дублиращи се разговори и поддържа Call Directory Extension за блокиране на нежелани номера. Системните интеграции в мобилната разработка с CallKit са критични за приложенията за гласова комуникация — WhatsApp, Skype и Zoom го използват за показване на входящи разговори.

PushKit — фонови push известия

PushKit доставя push известия директно на мобилното приложение без показване на потребителя. PushKit събужда приложението от "убито" състояние и предава данни чрез делегата PKPushRegistryDelegate. Това е основният механизъм за VoIP приложения: PushKit доставя информация за разговора, а CallKit я показва. PushKit има по-висок приоритет на доставка от обикновените push известия и не изисква показване на банер. Разширенията на приложения в мобилните приложения често комбинират PushKit с CallKit за гласова комуникация.

SiriKit и Intents Extension

SiriKit позволява обработка на заявки чрез Siri и приложението Преки пътища. Intents Extension е отделно разширение на приложение, което регистрира поддържаните намерения и ги обработва. SiriKit поддържа повече от 20 домейна: разговори, съобщения, плащания, бележки, тренировки. Преките пътища позволяват на потребителя да създава автоматизации — например "Изпрати съобщение в WhatsApp чрез Siri." Системните интеграции с SiriKit и Преки пътища повишават ангажираността, тъй като потребителят извършва действия без отваряне на приложението.

BroadcastReceiver и системни услуги на Android

BroadcastReceiver е Android компонент, който реагира на системни широкообхватни съобщения. За разлика от разширенията на приложения на iOS, BroadcastReceiver не изисква отделен двоичен файл — достатъчно е да регистрирате приемника в манифеста или в кода чрез Context.registerReceiver. Системните интеграции на Android често започват с BroadcastReceiver: от стартиране на услуга при зареждане на устройството до реакция на мрежова връзка.

IntentFilter за системни събития

IntentFilter свързва BroadcastReceiver с конкретно системно събитие. Типични събития: BOOT_COMPLETED (зареждане на устройство), CONNECTIVITY_ACTION (промяна на мрежа), BATTERY_LOW (нисък заряд), TIME_SET (промяна на време). Приемникът се регистрира в AndroidManifest.xml или чрез Context.registerReceiver за динамична регистрация. Динамичната регистрация е за предпочитане — не изисква разрешения в манифеста и действа само докато приложението е активно. Разширенията на приложения на Android не съществуват като концепция, но BroadcastReceiver играе подобна роля — разширява възможностите на приложението чрез системни интеграции.

NotificationListenerService и AccessibilityService

NotificationListenerService е услуга, която получава всички системни известия. NotificationListenerService изисква разрешение BIND_NOTIFICATION_LISTENER_SERVICE и достъп чрез настройките за достъпност. AccessibilityService е по-мощен инструмент за системна интеграция: той може да чете съдържание на екрана, да симулира кликвания и да автоматизира действия. И двете услуги изискват изрично включване от потребителя в настройките, което повишава сигурността. Системните интеграции в мобилни приложения чрез AccessibilityService се използват за автоматични попълвачи, екранни четци и инструменти за достъпност.

class BootReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Intent.ACTION_BOOT_COMPLETED) {
            WorkManager.getInstance(context)
                .enqueueUniqueWork("post-boot", ...)
        }
    }
}

Примерът регистрира BroadcastReceiver за събитието BOOT_COMPLETED. WorkManager се използва за отложено изпълнение на задача след зареждане на устройството — това е стандартният подход за Android приложения.

App Widget Provider — създаване на джаджи на Android

App Widget Provider на Android е аналогът на разширенията на приложения на iOS в контекста на джаджи: това е компонент, който показва интерактивно съдържание на началния екран. За разлика от WidgetKit, Android джаджите могат да приемат потребителски вход — кликвания, превключвания и жестове. App Widget Provider се регистрира в манифеста чрез XML описание на размера и честотата на обновяване.

RemoteViews и AppWidgetProvider

RemoteViews описва интерфейса на джаджата чрез XML оформление и поддържа само ограничен набор от изгледи. RemoteViews не позволява персонализирани изгледи — само стандартни компоненти: TextView, ImageView, Button, ProgressBar. AppWidgetProvider е базовият клас, който обработва обновявания, включване и изтриване на джаджата. Методът onUpdate се извиква чрез таймер чрез updatePeriodMillis или чрез WorkManager за прецизен контрол. Системните интеграции с джаджи на Android изискват внимание — твърде честите обновявания изтощават батерията.

Glance API (Jetpack) — модерен подход

Glance API е Jetpack библиотека за създаване на джаджи чрез Kotlin DSL вместо XML. Glance API се компилира до RemoteViews и поддържа синтаксис, подобен на Compose: GlanceComposable, Column, Row, Text. Библиотеката решава проблема със сложния XML код и позволява тестване на джаджи чрез JUnit. Glance API все още не поддържа всички функции на RemoteViews — за сложни интерактивни джаджи класическият подход е по-добър. Разширенията на приложения в мобилната разработка на Android еволюират към Glance API, опростявайки създаването и поддръжката на джаджи.

Content Provider, FileProvider и обмен на данни между приложения

Content Provider е Android компонент за обмен на структурирани данни между приложения чрез единен интерфейс ContentResolver. За разлика от разширенията на приложения на iOS, Content Provider не създава отделен процес — данните се заявяват синхронно в контекста на викащото приложение. Content Provider е в основата на системните интеграции на Android: контакти, медийни файлове, календар и стандартни приложения го използват за публикуване на данни.

FileProvider за безопасно споделяне на файлове

FileProvider е подклас на ContentProvider за безопасно прехвърляне на файлове между приложения. FileProvider генерира временни content:// URI вместо директни file:// пътища, които са забранени на Android 7+. За използване трябва да посочите files-path или external-files-path в XML конфигурацията. Разширенията на приложения в мобилната разработка на Android не съществуват като отделна концепция, но FileProvider изпълнява тяхната функция — разширява възможностите за обмен на данни извън едно приложение.

Аналог на iOS: File Provider Extension

На iOS ролята на обмен на файлове се изпълнява от File Provider Extension. File Provider Extension публикува файловете на приложението в приложението Файлове чрез NSFileProviderManager. За разлика от FileProvider, iOS разширението изисква отделен двоичен файл и работи в изолиран процес. File Provider Extension поддържа NSFileProviderItem за описание на файлове и NSFileProviderEnumerator за навигация в папки. Системните интеграции в мобилни приложения чрез File Provider Extension позволяват на потребителя да управлява файловете на приложението от приложението Файлове, без да го отваря.

class MyFileProviderExtension: NSFileProviderExtension {
    override func item(for identifier: NSFileProviderItemIdentifier) throws -> NSFileProviderItem {
        return MyFileProviderItem(identifier: identifier)
    }
}

Примерът показва минимална реализация на File Provider Extension на Swift. Методът item(for:) връща обект NSFileProviderItem по идентификатор — системата го извиква при показване на файлове в приложението Файлове.