Android-guider: Forretning, arkitektur og professionel udvikling

Hvis du er begyndt at spille Android, vil du før eller siden få brug for noget... Gode ​​Android-guider, der forklarer både forretningssiden og app-udviklingssidenDet er ikke nok at vide, hvordan man programmerer et par skærme: nu om dage er det nødvendigt at forstå jobprofiler, administrerede enheder, moderne arkitektur, sikkerhed, SSO, testning ... og meget mere.

I denne omfattende guide finder du en En komplet og opdateret oversigt over, hvordan man udvikler Android-apps designet til virksomheder og til flere enhederFra det grundlæggende i Android Enterprise og enhedsstyring til strukturering af kode med en robust og skalerbar arkitektur, vil dette kursus hjælpe dig med at udvikle et klart mentalt kort over alt, hvad du skal mestre for at skabe professionelle og let vedligeholdelige applikationer.

Android Enterprise: Sådan forbereder du dine apps til virksomhedsmiljøer

Android inkluderer et sæt standardfunktioner Virksomhedsfunktioner, der gør det muligt for organisationer at administrere enheder, apps og data sikkertDen gode nyhed er, at alle standard Android-apps understøtter disse funktioner; den knap så gode nyhed er, at hvis du vil have din app til at skinne i virksomhedsmiljøer, bliver du nødt til at gå et skridt videre og tilpasse den.

For at få mest muligt ud af Android Enterprise er det bedst at starte med en Android-appen er allerede oprettet, klar til modifikation og med en minimumversion af 5.0 Lollipop (selvom 6.0 Marshmallow eller højere anbefales). Disse senere niveauer tilbyder avancerede funktioner, især til dedikerede enheder og strengere administrationspolitikker.

Organisationer bruger disse funktioner til at muliggøre Scenarier for administreret mobilitet: fra medarbejdermobiler med separate personlige og arbejdsmæssige data til engangsautomaterSom udvikler er det vigtigt at forstå dette økosystem for at undgå uforeneligheder og frem for alt for at forhindre, at virksomheder begrænser deres anvendelse af din app.

Arbejdsprofiler på Android: Adskillelse mellem privatliv og arbejdsliv

Nøglekonceptet bag Android Enterprise er arbejdsprofil, en virksomhedscontainer, der administreres på brugerens enhedDenne profil er knyttet til enhedens hovedkonto, men opretholder en klar adskillelse mellem applikationer og personlige og professionelle data.

I praksis fungerer jobprofilen som en isoleret område, hvor virksomhedsapps har et specifikt badge og administreres med deres egne politikkerBrugeren beholder kontrollen over sit personlige område, mens IT-afdelingen kun administrerer de forretningsdata og applikationer, der interesserer dem, uden at invadere resten af ​​enheden.

Blandt de vigtigste karakteristika ved en jobprofil er følgende: sikker dataseparation, appdistribution via administreret Google Play og specifikke administrationsfunktioner kontrolleret af en administrator, alt sammen bakket op af fuld enhedskryptering.

En vigtig detalje er, at når enheden har både personlige og arbejdsprofiler, bruges den normalt en enkelt APK til begge områder, mens policy controlleren (DPC) er begrænset til arbejdsprofilenAdministrationen udføres via DevicePolicyManager-klassen, hvilket betyder, at du skal tage disse API'er i betragtning, hvis du udvikler avancerede virksomhedsløsninger.

For at undgå problemer er det vigtigt, at Gå ikke ud fra, at en hvilken som helst Intent blot vil kunne gå fra én profil til en anden.Nogle er blokeret af sikkerhedsmæssige årsager, og du vil kun opdage dette ved test. Før du starter en aktivitet, anbefales det at ringe Intent.resolveActivity()Hvis den returnerer null, betyder det, at der ikke er nogen komponent, der kan håndtere den pågældende intent i den profil.

Når du udveksler filer mellem profiler, anbefaler Android at bruge Indholds-URI'er med FileProvider, delt via Intents med specifikke tilladelserDette sikrer, at adgangen er begrænset til den korrekte profil, og at andre apps kun ser det, der er essentielt. I modsætning hertil den gamle file:// URI'er, der peger på absolutte filsystemstier, fungerer ikke på tværs af profiler og kan forårsage fejl, når man forsøger at åbne ressourcer fra den anden side.

Administrerede konfigurationer: fjernstyring af appen af ​​IT

En grundlæggende søjle i virksomhedsmiljøer er Administrerede konfigurationer, et sæt parametre, som administratorer kan anvende eksternt på apps af brugerne. Den store fordel er, at de er universelle: de fungerer med enhver EMM-løsning (Enterprise Mobility Management).

Takket være disse konfigurationer kan IT-afdelingen centralt justere, hvordan applikationen opfører sig på kritiske områder såsom forbindelse, sikkerhed eller brugsbegrænsningerFor eksempel kan du bestemme, om appen kun synkroniserer via Wi-Fi eller også via mobildata, hvilke URL'er der er tilladt i en integreret browser, hvordan e-mailkontoen er konfigureret, om udskrivning er aktiveret eller ej, eller hvilke favoritter der er forudindlæst.

Fra udviklerens synspunkt ligger nøglen i Tjek disse begrænsninger på de relevante tidspunkter i appens livscyklusVed opstart anbefales det, at koden tjekker ind onStart() eller onResume() resultatet af getApplicationRestrictions() for at finde ud af, om appen administreres, om der allerede er definerede begrænsninger, eller om der er en afventende konfigurationsstatus.

Værdien, der returneres af getApplicationRestrictions(), kan være en pakke med specifikke begrænsninger, en tom pakke eller en struktur med nøglen KEY_RESTRICTIONS_PENDINGI sidstnævnte tilfælde ved din app, at den er under administration, men DPC'en har endnu ikke anvendt politikken korrekt, så det klogeste er at begrænse brugen af ​​den og henvise brugeren til at kontakte IT-administratoren.

Derudover kan politikkerne ændres når som helst, hvilket er grunden til, at din app skal Registrer liveændringer ved dynamisk at logge ACTION_APPLICATION_RESTRICTIONS_CHANGED-udsendelsenIdeelt set bør du abonnere, når aktiviteten eller tjenesten er aktiv, og annullere registreringen ved hjælp af onPause() for at undgå lækager eller uventet adfærd.

Dedikerede enheder: kiosker, POS-systemer og digital skiltning

En anden udbredt praksis i virksomheder er brugen af Enhedsudstyr til én funktion (dedikerede enheder), såsom kiosker, POS-systemer eller skiltedisplaysI disse tilfælde er Android konfigureret til kun at vise én app eller et meget begrænset sæt, hvilket blokerer adgangen til de primære eller seneste apps.

Når en enhed er konfigureret som dedikeret, ser brugeren en enkelt, kontrolleret oplevelse, uden nogen nem måde at forlade hovedappen påDu kan også definere en gruppe af tilladte applikationer, for eksempel i en bibliotekskiosk, der kun viser kataloget og en virksomhedswebbrowser.

For at nå disse scenarier er det nødvendigt at følge strømmene af Tilvejebringelse af dedikerede enheder som beskrevet i den officielle dokumentationI disse scenarier overtager DPC'en rollen som enhedsejer. Som udvikler skal du sikre dig, at din app kan køre i kiosktilstand uden standardnavigationsknapper eller multitasking, og at den reagerer godt på kontrollerede nedbrud og genstarter.

Single sign-on (SSO) med brugerdefinerede Chrome-faner

I erhvervslivet er det meget almindeligt, at brugerne skal godkende i flere forskellige apps, og hvis oplevelsen ikke administreres omhyggeligt, kan det ende med... gentagelse af brugernavn og adgangskode igen og igenWebView har traditionelt været brugt til login, men denne løsning har klare ulemper.

På den ene side tilbyder mange implementeringer med WebView ikke en Ægte SSO, fordi hver WebView administrerer sine egne cookies og sessionPå den anden side er der sikkerhedsrisici, da det er muligt at inspicere cookies eller indsætte skadelig JavaScript, hvis en tredjepartsapp eller et SDK opfører sig uhensigtsmæssigt.

Det anbefalede alternativ er at udnytte Brugerdefinerede faner, især Chromes brugerdefinerede faner, som har eksisteret siden Chrome 45.Disse faner fungerer som en integreret systembrowservisning med en sikker kontekst, hvor værtsappen ikke kan snuse på indholdet.

Når du bruger brugerdefinerede faner til godkendelse, vil browserdækkende cookiestatus, der muliggør single sign-on på tværs af flere appsBrugeren logger kun ind én gang, og resten af ​​applikationerne kan stole på den allerede autentificerede kontekst, hvilket forbedrer brugervenligheden og reducerer friktion.

For at implementere SSO med brugerdefinerede faner kan du bruge AppAuth, et open source OAuth-klientbibliotek understøttet af OpenID Connect-arbejdsgruppenDette bibliotek forenkler integration med identitetsudbydere og håndterer sikkerhedsoplysninger og kompatibilitet med brugerdefinerede faner.

Apptestning i administrerede miljøer: DPC-testning, profiler og enheder

Når du har tilføjet understøttelse af arbejdsprofiler, administrerede konfigurationer og dedikerede enheder, er det tid til den mindre glamourøse, men mere kritiske del: Test din app på både arbejdsprofiler og reelt administrerede enhederDet er her, Test DPC-applikationen kommer i spil.

Test-DPC er en App designet til udviklere, der simulerer adfærden af ​​en virksomheds DPC i et testmiljøMed den kan du indstille EMM-politikker og administrerede konfigurationsværdier, som om en organisation administrerede enheden via sin konsol.

For at teste din app i en arbejdsprofil er den grundlæggende arbejdsgang Installer Test DPC, åbn konfigurationsindstillingen Test DPC i Android-vælgeren, og følg instruktionerne for at klargøre arbejdsprofilen.Derefter installerer du din app og tjekker, hvordan den opfører sig i den profil med et arbejdsbadge, hvilket bekræfter tilladelser, intenter, dataadgang og anden følsom adfærd.

Hvis du vil simulere en fuldt administreret enhed, skal du Sørg for, at terminalen ikke har andre brugere, arbejdsprofiler eller konti konfigureret.Installer derefter Test DPC og kør følgende kommando i adb:

adb shell dpm set-device-owner com.afwsamples.testdpc/.DeviceAdminReceiver

Når denne proces er afsluttet, vil enheden være under fuld kontrol af Test DPC som enhedsejerDerfra kan du teste din app i en kontekst med absolut administration, med særlig opmærksomhed på, hvordan administrerede konfigurationer anvendes, hvordan begrænsede intentioner reagerer, og hvad der sker med appen i blokeringsscenarier og strenge politikker.

Når du har valideret adfærden i lokale tests, er det ideelle at tage det et skridt videre og lave en end-to-end-testning i et rigtigt cloud-miljø, der replikerer det flow, som en kunde ville følgeDette indebærer at have en EMM-testkonsol, gøre krav på et administreret Google-domæne, linke det til den pågældende konsol og udgive en testversion af din app (med et andet ApplicationId) i den private Google Play-kanal for det pågældende domæne.

Fra EMM-konsollen vil du kunne Konfigurer arbejdsenheder, distribuer appen, angiv dine administrerede konfigurationer, og angiv enhedspolitikkerPå denne måde verificerer du, at alt fungerer, som det ville i en produktionsimplementering, fra den første registrering til anvendelsen af ​​avancerede politikker.

Android-læringsvejledninger: fra begynder til avanceret

Ud over det rent forretningsmæssige aspekt, hvis du vil blive en god Android-udvikler, har du brug for en en struktureret læringsforløb, der dækker alt fra grundlæggende koncepter til avancerede emner og hold dig opdateret med Teknologinyheder om mobiltelefoner, apps og digital kulturI den forstand er guider eller kurser, der opdeler indholdet i niveauer – begynder, mellemniveau og avanceret – meget nyttige.

I den indledende fase er fokus på Grundlæggende om Android, Kotlin eller Java, aktivitetslivscyklus, grundlæggende visninger og layoutoprettelseMange moderne ressourcer er nu 100% fokuseret på Kotlin, men der findes stadig fremragende bøger og materialer baseret på Java og miljøer som Eclipse, der, selvom de er noget forældede, stadig er nyttige til at forstå platformens udvikling.

Efterhånden som du gør fremskridt, er det vigtigt at introducere emner som f.eks. datapersistens, samtidig programmering, sikkerhed, netværkskommunikation og testningDet er også en god idé at gøre dig bekendt med Fragment, moderne arkitekturer og koncepter som modularisering, så dine projekter ikke bliver kaotiske, efterhånden som de vokser.

På avanceret niveau kommer de allerede i spil Udgivelse på Google Play, versionsstyring, monetisering, beskyttelse af betalte apps (f.eks. med LVL) og opdateringsmekanismerEmner som AppWidgets, adgang til geoplacering, ydeevneoptimering, understøttelse af flere Android-versioner og tilpasning til tablets og foldbare enheder dækkes også ofte.

Nogle klassiske lærebøger dækker Fra forberedelse af udviklingsmiljøet, oprettelse af den første app, design af brugergrænsefladen til den endelige implementering i produktionSom en ekstra værdi ledsages de normalt af eksempelprojekter, der kan downloades, og som praktisk illustrerer alt, hvad der forklares i teksten.

Moderne Android-apparkitektur: et fundament for seriøse projekter

Hvis du vil have, at din app ikke falder fra hinanden, så snart den vokser lidt, har du brug for en En veldesignet apparkitektur, der er i stand til at skalere og tilpasse sig til mobiltelefoner, tablets, foldbare enheder, ChromeOS, biler og XR-enheder.Ideen er at minimere afhængigheden af ​​framework-komponenter og sikre, at koden er nem at vedligeholde og teste.

En typisk Android-app består af flere komponenter erklæret i manifestet: tjenester, indholdsudbydere, modtagere af udsendelser og aktiviteterHistorisk set var brugergrænsefladen organiseret med adskillige aktiviteter, men den nuværende anbefaling er at bruge en arkitektur af unik aktivitet med skærmbilleder baseret på fragmenter eller Jetpack Compose-destinationer.

Da din app kan køre på meget forskellige enheder, kan du ikke antage hverken en fast orientering eller en enkelt skærmstørrelseKonfigurationsændringer (rotation, vinduesændringer i ChromeOS, foldning af en foldbar enhed) kræver omstrukturering af brugerfladen og kan forårsage genskabelse af komponenter, så enhver vigtig tilstand bør holdes uden for Aktiviteter og Fragmenter.

Derudover er Android et ressourcebegrænset miljø, hvor systemet Det kan dræbe baggrundsprocesser i apps for at frigøre hukommelseDen kan også starte komponenter i en uordnet tilstand og ødelægge dem uden varsel. Derfor den klassiske anbefaling: gem ikke tilstands- eller forretningsdata i Aktiviteter, Tjenester eller BroadcastReceivers, da de er flygtige af natur.

Det ledende princip er Ansvarsadskillelse: Brugergrænsefladen er ansvarlig for at vise data og reagere på hændelser, mens forretningslogik og datahåndtering ligger i andre lag.Når en grænsefladekomponent genskabes, bevares tilstanden derfor takket være velorganiserede ViewModels, arkiver og datakilder.

Arkitekturlag: brugergrænseflade, data og domæne

Den anbefalede arkitektur skelner mellem mindst to lag: UI (præsentations-) lag og datalagEventuelt kan et tredje domænelag tilføjes for at indkapsle kompleks eller genanvendelig forretningslogik mellem forskellige ViewModels.

UI-laget er ansvarligt for vise data på skærmen og reagere på ændringerDette sker enten gennem brugerhandlinger eller eksterne input såsom netværksresponser. Det er her, visuelle elementer (views eller composables fra Jetpack Compose) og tilstandscontainere (ViewModel) kommer i spil, hvor de vedligeholder og eksponerer grænsefladen.

I adaptive grænseflader er ViewModels normalt eksponere en tilstand, der allerede tager højde for vinduesstørrelsesklassenved hjælp af værktøjer som currentWindowAdaptiveInfo(). Komponenter som NavigationSuiteScaffold kan bruge disse oplysninger til automatisk at skifte mellem NavigationBar, NavigationRail eller NavigationDrawer afhængigt af den tilgængelige plads.

Datalaget koncentrerer forretningslogik og de regler, der bestemmer, hvordan data oprettes, lagres og ændresDet er baseret på arkiver, der grupperer og abstraherer en eller flere datakilder: lokale databaser, netværkstjenester, filer osv. Hver type information (film, betalinger, brugere osv.) har normalt sit eget arkiv, der er ansvarligt for at eksponere data, centralisere ændringer og løse konflikter.

Datakilder er de klasser, der De kommunikerer direkte med systemet eller med eksterne tjenester: SQL-forespørgsler, filadgang, HTTP-anmodninger osv.Resten af ​​appen bør ikke afhænge af dens specifikke implementering, men kun af de grænseflader, der eksponeres af repository'et.

Efterhånden som kompleksiteten stiger, er det nyttigt at introducere et domænelag bestående af brugsscenarier eller interaktioner, der hver især er dedikeret til en specifik funktionalitetFor eksempel en GetTimeZoneUseCase, der returnerer den relevante tidszone for at konstruere brugerdefinerede meddelelser, der kan genbruges af flere ViewModels.

Datamodeller, SSOT og ensrettet datastrøm

Et andet nøgleprincip er, at grænsefladen skal feed med datamodeller, helst persistenteDisse modeller repræsenterer appens tilstand og er fuldstændig uafhængige af brugergrænsefladen og framework-komponentens livscyklus. På denne måde overlever de genskabelser af Aktiviteter og Fragmenter og forsvinder kun, når systemet afslutter processen.

I forbindelse med dette er det værd at anvende mønsteret med enkelt sandhedskilde (SSOT)Hver vigtig datatype har en enkelt ejer, der kan ændre den; de andre lag observerer den kun gennem uforanderlige typer. Mutationer udføres gennem veldefinerede funktioner eller gennem hændelser, der når den pågældende sandhedskilde.

SSOT kombineres normalt med ensrettet datastrøm (UDF), hvor tilstanden flyder fra top til bund, og begivenhederne flyder fra bund til topI Android betyder det, at applikationsdata bevæger sig fra kilderne (netværk, database) til brugergrænsefladen, mens brugerhandlinger omdannes til hændelser, der bevæger sig fra brugergrænsefladen til domænet eller datalaget, hvor tilstanden opdateres.

At følge dette mønster forbedrer Tilstandskonsistens reducerer fejl, letter ræsonnement om app-adfærd og forenkler fejlfinding.At have én enkelt komponent, der styrer, hvordan dataene ændrer sig, gør det nemmere at finde kilden til en fejl.

Afhængighedsinjektion og generelle bedste praksisser

For at appens forskellige klasser kan samarbejde uden unødvendig kobling anbefales det at bruge en afhængighedsstyringsmønster såsom afhængighedsinjektion (DI) eller en servicelokaliseringsfunktionI Android er den foretrukne løsning Hilt, som automatiserer objektopbygning, kontrollerer for afhængigheder ved kompilering og opretter specifikke containere til framework-komponenter.

Ideen er, at klasserne Angiv, hvad du har brug for, men tag ikke ansvaret for at bygge det.Dette giver dig mulighed for nemt at skifte fra live-implementeringen til en testversion eller justere adfærd uden at omskrive halvdelen af ​​projektet. Derudover reducerer det dobbeltarbejde og skitserer tydeligt, hvordan hver del forbindes på ét sted.

Som generelle arkitekturregler er det tilrådeligt, at Indgangspunkter (aktiviteter, tjenester, modtagere) er ikke datakilderI stedet er de blot koordinatorer, der anmoder om de nødvendige oplysninger fra repository'et eller use casen. Det anbefales også at minimere afhængigheder af Android-klasser uden for UI-komponenter for at lette testningen.

Det er vigtigt at definere Klare ansvarsgrænser mellem moduler, undgå at blande netværkskode, caching, view binding og forretningslogik i samme klasseHvert modul bør kun vise det nødvendige, uden genveje, der afslører interne implementeringsdetaljer og kan blive til teknisk gæld i fremtiden.

Et andet tilbagevendende råd er Opfind ikke hjulet på ny: Stol på Jetpack-biblioteker og etablerede løsninger til standardopgaver (navigation, persistens, paginering osv.). Reserver din tid til det, der gør din app speciel, i stedet for at omskrive den samme infrastrukturkode igen og igen.

Når man designer brugergrænsefladen, er det tilrådeligt at vælge genanvendelige og sammensættelige komponenter, der kan omarrangeres for at tilpasse sig forskellige størrelser og retningerDu bør også sørge for at bevare grænsefladen under konfigurationsændringer, især på foldbare enheder og store skærme, hvor størrelsesændringer er hyppige.

Med hensyn til samtidighed skal hver type være ansvarlig for at udføre dine dyre opgaver til den rette tidsplanFor eksempel gennem coroutines og Flows. Den gyldne regel er, at API-kald skal være sikre fra hovedtråden, hvilket aflaster det tunge arbejde til baggrundstråde.

Endelig er det værd at bevare så mange relevante data som muligt lokalt, på en opdateret mådePå denne måde kan dine brugere fortsætte med at bruge appen, selv uden forbindelse eller med dårlig dækning, hvilket er særligt almindeligt i overbelastede områder eller med netværk af lav kvalitet.

God arkitektur giver meget konkrete fordele: Det forbedrer vedligeholdelsen, gør det nemmere for flere teams at arbejde på den samme kodebase, fremskynder onboarding af nye udviklere og gør appen nemmere at teste.Alt dette resulterer i færre fejl, hurtigere opdateringer og en mere stabil oplevelse for slutbrugeren.

Samlet set er det det, der giver dig mulighed for at mestre Androids virksomhedsfunktioner, forstå, hvordan arbejdsprofiler og dedikerede enheder fungerer, implementere sikker SSO med brugerdefinerede faner, anvende administrerede konfigurationer og anvende en moderne arkitektur med lagseparation, SSOT og DI. fra at lave simple apps til at bygge professionelle, robuste Android-løsninger, der er klar til ethvert virksomheds- eller forbrugermiljø.