Rozszerzenia aplikacji i integracje systemowe w rozwoju mobilnym: czym są, typy i jak działają

Rozszerzenia aplikacji na iOS: widgety i rozszerzenia udostępniania treści

Rozszerzenia aplikacji na iOS pojawiły się w iOS 8 i stały się fundamentem integracji systemowych w rozwoju mobilnym. Są to osobne pliki binarne spakowane z główną aplikacją, ale uruchamiane w izolowanym procesie. Każde rozszerzenie ma własny Info.plist i punkt wejścia zdefiniowany przez NSExtensionPrincipalClass. System zarządza cyklem życia rozszerzeń aplikacji — nie mogą one pozostawać w tle po zakończeniu zadania.

WidgetKit i Today Widget

WidgetKit (iOS 14+) to nowoczesny framework do tworzenia widgetów na ekranie głównym. WidgetKit używa SwiftUI do opisu interfejsu i TimelineProvider do definiowania harmonogramów aktualizacji. Widgety występują w trzech rozmiarach: mały (2×2 komórki), średni (4×2) i duży (4×4). Stary Today Widget oparty na UICollectionViewController jest nadal obsługiwany, ale Apple zaleca migrację do WidgetKit. Rozszerzenia aplikacji na WidgetKit nie obsługują animacji, wprowadzania z klawiatury ani gestów — są to statyczne lub pseudoanimowane elementy z okresowymi aktualizacjami.

Share Extension i Action Extension

Share Extension pozwala wysyłać treści z dowolnej aplikacji do twojej za pomocą systemowego arkusza udostępniania. Share Extension odbiera dane przez NSExtensionItem i używa SLComposeServiceViewController do interfejsu. Action Extension przetwarza treści na miejscu — na przykład tłumaczy tekst w przeglądarce bez przełączania się do innej aplikacji. Oba typy muszą zakończyć pracę w ograniczonym czasie, w przeciwnym razie system „zabija" rozszerzenie. To ważne ograniczenie rozszerzeń aplikacji w aplikacji mobilnej — zadania w tle nie są dostępne na poziomie rozszerzenia.

CallKit, PushKit i SiriKit — integracje systemowe dla głosu i powiadomień

Integracje systemowe na iOS wykraczają daleko poza widgety: CallKit, PushKit i SiriKit pozwalają aplikacji mobilnej działać na poziomie systemu. Te frameworki wymagają specjalnych uprawnień, ale zapewniają użytkownikowi płynne doświadczenie — połączenia przez CallKit wyglądają jak zwykłe połączenia telefoniczne, a Siri przetwarza zapytania bez otwierania aplikacji.

CallKit — połączenia VoIP w interfejsie systemowym

CallKit integruje połączenia aplikacji zewnętrznych z systemowym ekranem połączeń, w tym zablokowanym ekranem. CXProvider rejestruje aplikację jako usługę VoIP, a CXCallController zarządza połączeniami. CallKit automatycznie blokuje duplikujące się połączenia i obsługuje Call Directory Extension do blokowania niechcianych numerów. Integracje systemowe w rozwoju mobilnym z CallKit są krytyczne dla aplikacji komunikacji głosowej — WhatsApp, Skype i Zoom używają go do wyświetlania przychodzących połączeń.

PushKit — push powiadomienia w tle

PushKit dostarcza powiadomienia push bezpośrednio do aplikacji mobilnej bez pokazywania ich użytkownikowi. PushKit wybudza aplikację ze stanu „zabitego" i przekazuje dane przez delegata PKPushRegistryDelegate. To podstawowy mechanizm dla aplikacji VoIP: PushKit dostarcza informacje o połączeniu, a CallKit je wyświetla. PushKit ma wyższy priorytet dostarczania niż zwykłe powiadomienia push i nie wymaga wyświetlania banera. Rozszerzenia aplikacji w aplikacjach mobilnych często łączą PushKit z CallKit do komunikacji głosowej.

SiriKit i Intents Extension

SiriKit pozwala przetwarzać zapytania przez Siri i aplikację Skróty. Intents Extension to osobne rozszerzenie aplikacji, które rejestruje obsługiwane intencje i je przetwarza. SiriKit obsługuje ponad 20 domen: połączenia, wiadomości, płatności, notatki, treningi. Skróty pozwalają użytkownikowi tworzyć automatyzacje — na przykład „Wyślij wiadomość w WhatsApp przez Siri". Integracje systemowe z SiriKit i Skrótami zwiększają zaangażowanie, ponieważ użytkownik wykonuje czynności bez otwierania aplikacji.

BroadcastReceiver i usługi systemowe na Androidzie

BroadcastReceiver to komponent Androida, który reaguje na systemowe komunikaty rozgłoszeniowe. W przeciwieństwie do rozszerzeń aplikacji iOS, BroadcastReceiver nie wymaga osobnego pliku binarnego — wystarczy zarejestrować odbiornik w manifeście lub w kodzie przez Context.registerReceiver. Integracje systemowe na Androidzie często zaczynają się od BroadcastReceiver: od uruchomienia usługi przy starcie urządzenia do reakcji na połączenie sieciowe.

IntentFilter dla zdarzeń systemowych

IntentFilter wiąże BroadcastReceiver z konkretnym zdarzeniem systemowym. Typowe zdarzenia: BOOT_COMPLETED (uruchomienie urządzenia), CONNECTIVITY_ACTION (zmiana sieci), BATTERY_LOW (niski poziom baterii), TIME_SET (zmiana czasu). Odbiornik jest rejestrowany w AndroidManifest.xml lub przez Context.registerReceiver do rejestracji dynamicznej. Rejestracja dynamiczna jest preferowana — nie wymaga uprawnień w manifeście i działa tylko podczas aktywności aplikacji. Rozszerzenia aplikacji na Androidzie nie istnieją jako koncepcja, ale BroadcastReceiver pełni podobną rolę — rozszerza możliwości aplikacji poprzez integracje systemowe.

NotificationListenerService i AccessibilityService

NotificationListenerService to usługa, która odbiera wszystkie powiadomienia systemowe. NotificationListenerService wymaga uprawnienia BIND_NOTIFICATION_LISTENER_SERVICE i dostępu przez ustawienia dostępności. AccessibilityService to potężniejsze narzędzie do integracji systemowej: może czytać zawartość ekranu, symulować kliknięcia i automatyzować działania. Obie usługi wymagają wyraźnego włączenia przez użytkownika w ustawieniach, co zwiększa bezpieczeństwo. Integracje systemowe w aplikacjach mobilnych przez AccessibilityService są używane do autofillera, czytników ekranu i narzędzi dostępności.

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

Przykład rejestruje BroadcastReceiver dla zdarzenia BOOT_COMPLETED. WorkManager jest używany do opóźnionego wykonywania zadań po uruchomieniu urządzenia — to standardowe podejście dla aplikacji Android.

App Widget Provider — tworzenie widgetów na Androidzie

App Widget Provider na Androidzie to odpowiednik rozszerzeń aplikacji iOS w kontekście widgetów: to komponent wyświetlający interaktywną treść na ekranie głównym. W przeciwieństwie do WidgetKit, widgety Androida mogą przyjmować dane wejściowe użytkownika — kliknięcia, przełączniki i gesty. App Widget Provider jest rejestrowany w manifeście poprzez opis XML rozmiaru i częstotliwości aktualizacji.

RemoteViews i AppWidgetProvider

RemoteViews opisuje interfejs widgeta przez układ XML i obsługuje tylko ograniczony zestaw widoków. RemoteViews nie pozwala na niestandardowe widoki — tylko standardowe komponenty: TextView, ImageView, Button, ProgressBar. AppWidgetProvider to klasa bazowa, która obsługuje aktualizacje, włączanie i usuwanie widgeta. Metoda onUpdate jest wywoływana przez timer przez updatePeriodMillis lub przez WorkManager w celu precyzyjnej kontroli. Integracje systemowe z widgetami na Androidzie wymagają ostrożności — zbyt częste aktualizacje wyczerpują baterię.

Glance API (Jetpack) — nowoczesne podejście

Glance API to biblioteka Jetpack do tworzenia widgetów przy użyciu Kotlin DSL zamiast XML. Glance API kompiluje się do RemoteViews i obsługuje składnię podobną do Compose: GlanceComposable, Column, Row, Text. Biblioteka rozwiązuje problem złożonego kodu XML i umożliwia testowanie widgetów przez JUnit. Glance API nie obsługuje jeszcze wszystkich funkcji RemoteViews — dla złożonych interaktywnych widgetów lepsze jest klasyczne podejście. Rozszerzenia aplikacji w rozwoju mobilnym na Androidzie ewoluują w kierunku Glance API, upraszczając tworzenie i utrzymanie widgetów.

Content Provider, FileProvider i udostępnianie danych między aplikacjami

Content Provider to komponent Androida do udostępniania strukturyzowanych danych między aplikacjami przez ujednolicony interfejs ContentResolver. W przeciwieństwie do rozszerzeń aplikacji iOS, Content Provider nie tworzy osobnego procesu — dane są żądane synchronicznie w kontekście wywołującej aplikacji. Content Provider leży u podstaw integracji systemowych na Androidzie: kontakty, pliki multimedialne, kalendarz i standardowe aplikacje używają go do publikowania danych.

FileProvider do bezpiecznego udostępniania plików

FileProvider to podklasa ContentProvider do bezpiecznego przesyłania plików między aplikacjami. FileProvider generuje tymczasowe URI content:// zamiast bezpośrednich ścieżek file://, które są zabronione na Androidzie 7+. Aby go użyć, należy określić files-path lub external-files-path w konfiguracji XML. Rozszerzenia aplikacji w rozwoju mobilnym na Androidzie nie istnieją jako osobna koncepcja, ale FileProvider pełni ich funkcję — rozszerza możliwości udostępniania danych poza jedną aplikację.

Odpowiednik na iOS: File Provider Extension

Na iOS rolę udostępniania plików pełni File Provider Extension. File Provider Extension publikuje pliki aplikacji w aplikacji Pliki przez NSFileProviderManager. W przeciwieństwie do FileProvider, rozszerzenie iOS wymaga osobnego pliku binarnego i działa w izolowanym procesie. File Provider Extension obsługuje NSFileProviderItem do opisu plików i NSFileProviderEnumerator do nawigacji po folderach. Integracje systemowe w aplikacjach mobilnych przez File Provider Extension pozwalają użytkownikowi zarządzać plikami aplikacji z aplikacji Pliki bez jej otwierania.

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

Przykład pokazuje minimalną implementację File Provider Extension w Swift. Metoda item(for:) zwraca obiekt NSFileProviderItem po identyfikatorze — system wywołuje ją podczas wyświetlania plików w aplikacji Pliki.