App-tillägg och systemintegrationer i mobil utveckling: vad de är, typer och hur de fungerar

App-tillägg på iOS: widgets och tillägg för innehållsdelning

App-tillägg på iOS dök upp i iOS 8 och blev grunden för systemintegrationer inom mobil utveckling. Dessa är separata binärer som paketeras med huvudappen men startas i en isolerad process. Varje tillägg har sin egen Info.plist och en ingångspunkt definierad via NSExtensionPrincipalClass. Systemet hanterar livscykeln för App-tillägg — de kan inte stanna i bakgrunden efter att en uppgift är slutförd.

WidgetKit och Today Widget

WidgetKit (iOS 14+) är ett modernt ramverk för att skapa widgets på hemskärmen. WidgetKit använder SwiftUI för att beskriva gränssnittet och TimelineProvider för att definiera uppdateringsscheman. Widgets finns i tre storlekar: liten (2×2 celler), medel (4×2) och stor (4×4). Den gamla Today Widget baserad på UICollectionViewController stöds fortfarande, men Apple rekommenderar migrering till WidgetKit. App-tillägg på WidgetKit stöder inte animering, tangentbordsinmatning eller gester — de är statiska eller pseudo-animerade element med periodiska uppdateringar.

Share Extension och Action Extension

Share Extension gör det möjligt att skicka innehåll från vilken app som helst till din app via systemets delningsark. Share Extension tar emot data via NSExtensionItem och använder SLComposeServiceViewController för gränssnittet. Action Extension bearbetar innehåll på plats — till exempel översätter text i webbläsaren utan att växla till en annan app. Båda typerna måste slutföra arbetet inom begränsad tid, annars "dödar" systemet tillägget. Detta är en viktig begränsning av App-tillägg i en mobil app — bakgrundsuppgifter är inte tillgängliga på tilläggsnivå.

CallKit, PushKit och SiriKit — systemintegrationer för röst och aviseringar

Systemintegrationerna på iOS går långt bortom widgets: CallKit, PushKit och SiriKit gör att en mobil app kan fungera på systemnivå. Dessa ramverk kräver särskilda rättigheter men ger användaren en sömlös upplevelse — samtal via CallKit ser ut som vanliga telefonsamtal och Siri behandlar förfrågningar utan att öppna appen.

CallKit — VoIP-samtal i systemgränssnittet

CallKit integrerar samtal från tredjepartsappar i systemets samtalskärm, inklusive den låsta skärmen. CXProvider registrerar appen som en VoIP-tjänst och CXCallController hanterar samtal. CallKit blockerar automatiskt dubbletter av samtal och stöder Call Directory Extension för att blockera oönskade nummer. Systemintegrationer inom mobil utveckling med CallKit är avgörande för röstkommunikationsappar — WhatsApp, Skype och Zoom använder det för att visa inkommande samtal.

PushKit — push-aviseringar i bakgrunden

PushKit levererar push-aviseringar direkt till den mobila appen utan att visa dem för användaren. PushKit väcker appen från ett "dödat" tillstånd och skickar data via delegaten PKPushRegistryDelegate. Detta är den primära mekanismen för VoIP-appar: PushKit levererar samtalsinformation och CallKit visar den. PushKit har högre leveransprioritet än vanliga push-aviseringar och kräver inte visning av en banner. App-tillägg i mobila appar kombinerar ofta PushKit med CallKit för röstkommunikation.

SiriKit och Intents Extension

SiriKit gör det möjligt att behandla förfrågningar via Siri och appen Genvägar. Intents Extension är ett separat App-tillägg som registrerar och hanterar stödda avsikter. SiriKit stöder över 20 domäner: samtal, meddelanden, betalningar, anteckningar, träning. Genvägar gör att användaren kan skapa automatiseringar — till exempel "Skicka ett meddelande i WhatsApp via Siri." Systemintegrationer med SiriKit och Genvägar ökar engagemanget eftersom användaren utför åtgärder utan att öppna appen.

BroadcastReceiver och systemtjänster på Android

BroadcastReceiver är en Android-komponent som reagerar på systembroadcastmeddelanden. Till skillnad från iOS App-tillägg kräver BroadcastReceiver ingen separat binär — det räcker att registrera mottagaren i manifestet eller i koden via Context.registerReceiver. Systemintegrationer på Android börjar ofta med BroadcastReceiver: från att starta en tjänst vid enhetsstart till att reagera på nätverksanslutning.

IntentFilter för systemhändelser

IntentFilter binder BroadcastReceiver till en specifik systemhändelse. Typiska händelser: BOOT_COMPLETED (enhetsstart), CONNECTIVITY_ACTION (nätverksändring), BATTERY_LOW (lågt batteri), TIME_SET (tidsändring). Mottagaren registreras i AndroidManifest.xml eller via Context.registerReceiver för dynamisk registrering. Dynamisk registrering är att föredra — den kräver inga manifestbehörigheter och fungerar bara medan appen är aktiv. App-tillägg på Android finns inte som koncept, men BroadcastReceiver spelar en liknande roll — det utökar appens kapacitet genom systemintegrationer.

NotificationListenerService och AccessibilityService

NotificationListenerService är en tjänst som tar emot alla systemaviseringar. NotificationListenerService kräver behörigheten BIND_NOTIFICATION_LISTENER_SERVICE och åtkomst via tillgänglighetsinställningar. AccessibilityService är ett kraftfullare verktyg för systemintegration: det kan läsa skärminnehåll, simulera klick och automatisera åtgärder. Båda tjänsterna kräver explicit aktivering av användaren i inställningarna, vilket ökar säkerheten. Systemintegrationer i mobila appar via AccessibilityService används för autofyllning, skärmläsare och tillgänglighetsverktyg.

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

Exemplet registrerar en BroadcastReceiver för händelsen BOOT_COMPLETED. WorkManager används för fördröjd körning av uppgifter efter enhetsstart — detta är standardmetoden för Android-appar.

App Widget Provider — skapa widgets på Android

App Widget Provider på Android är motsvarigheten till iOS App-tillägg i widgetsammanhang: det är en komponent som visar interaktivt innehåll på hemskärmen. Till skillnad från WidgetKit kan Android-widgets acceptera användarinmatning — klick, växlingar och gester. App Widget Provider registreras i manifestet via en XML-beskrivning av storlek och uppdateringsfrekvens.

RemoteViews och AppWidgetProvider

RemoteViews beskriver widgetgränssnittet via en XML-layout och stöder endast en begränsad uppsättning vyer. RemoteViews tillåter inte anpassade vyer — endast standardkomponenter: TextView, ImageView, Button, ProgressBar. AppWidgetProvider är basklassen som hanterar widgetuppdateringar, aktivering och borttagning. Metoden onUpdate anropas via timer via updatePeriodMillis eller via WorkManager för exakt kontroll. Systemintegrationer med widgets på Android kräver försiktighet — alltför frekventa uppdateringar förbrukar batteriet.

Glance API (Jetpack) — modern metod

Glance API är ett Jetpack-bibliotek för att skapa widgets med Kotlin DSL istället för XML. Glance API kompileras till RemoteViews och stöder en Compose-liknande syntax: GlanceComposable, Column, Row, Text. Biblioteket löser problemet med komplex XML-kod och gör det möjligt att testa widgets via JUnit. Glance API stöder ännu inte alla RemoteViews-funktioner — för komplexa interaktiva widgets är den klassiska metoden bättre. App-tillägg inom mobil utveckling på Android utvecklas mot Glance API, vilket förenklar skapandet och underhållet av widgets.

Content Provider, FileProvider och datadelning mellan appar

Content Provider är en Android-komponent för att dela strukturerad data mellan appar via ett enhetligt ContentResolver-gränssnitt. Till skillnad från iOS App-tillägg skapar Content Provider ingen separat process — data begärs synkront i den anropande appens sammanhang. Content Provider ligger till grund för systemintegrationer på Android: kontakter, mediafiler, kalender och standardappar använder det för att publicera data.

FileProvider för säker fildelning

FileProvider är en underklass till ContentProvider för säker filöverföring mellan appar. FileProvider genererar temporära content:// URI:er istället för direkta file://-sökvägar, som är förbjudna på Android 7+. För att använda det måste du ange files-path eller external-files-path i XML-konfigurationen. App-tillägg inom mobil utveckling på Android finns inte som ett separat koncept, men FileProvider fyller deras funktion — det utökar datadelningsmöjligheterna bortom en enda app.

Motsvarighet på iOS: File Provider Extension

På iOS utförs filhanteringsrollen av File Provider Extension. File Provider Extension publicerar appens filer i appen Filer via NSFileProviderManager. Till skillnad från FileProvider kräver iOS-tillägget en separat binär och körs i en isolerad process. File Provider Extension stöder NSFileProviderItem för filbeskrivning och NSFileProviderEnumerator för mappnavigering. Systemintegrationer i mobila appar via File Provider Extension gör att användaren kan hantera appfiler från appen Filer utan att öppna den.

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

Exemplet visar en minimal implementering av File Provider Extension i Swift. Metoden item(for:) returnerar ett NSFileProviderItem-objekt baserat på identifierare — systemet anropar den när filer visas i appen Filer.