Share
I mai annonserte Google den neste versjonen av Android-plattformen Android M. Mens det fortsatt er ukjent hva "M" står for (Marshmallow? Macaroon? Macadamia Nut Cookie?), Kan du allerede få hendene dine på Android M-utvikler forhåndsvisningen . Utvikler forhåndsvisning 2 ble utgitt bare noen dager siden.
I denne opplæringen ser vi på hvordan du kan konfigurere utviklingsmiljøet ditt og installere denne tidlige utgivelsen av Android M, før du utforsker noen av de nye funksjonene som er inkludert i denne utviklerens forhåndsvisning. Vi tar en titt på hvordan du kan bruke det nye Data Binding bibliotek for å kutte ned på boilerplate-koden, hvordan appen din kan dra nytte av Android Ms nye tillatelsesmodell, og hvordan Android's innebygde appkobling er satt til å bli kraftigere i Android M.
Selv om du kan utforske Android M-funksjoner i utviklerens forhåndsvisning, ikke glem at dette er en utvikling slipp ut det som leverer forhåndsvisning APIer, så du bør forvente betydelige endringer helt fram til den endelige SDK. Du kan heller ikke publisere noen apper som retter seg mot forhåndsvisning av M-utviklere til Google Play.
Siden denne utvikler forhåndsvisningen er et pågående arbeid, er det viktig at du holder utviklingsmiljøet oppdatert og alltid jobber med den nyeste versjonen av Android M-utvikler forhåndsvisning. For å være sikker på at du ikke går glipp av noen oppdateringer, vil du kanskje bokmerke Android Developers Blog, bli med i Android M Developer Community, og notere Googles (foreløpige) utgivelsesdatoer.
Hvis du vil begynne å eksperimentere med forhåndsvisning av Android M-utvikler forhåndsvisning, trenger du Android Studio 1.3 beta eller høyere.
Android Studio-teamet utgir oppdateringer via flere kanaler, stabil, beta, dev, og kanarifuglen kanal. Til tross for beta-taggen finner du Android Studio 1.3 beta på kanariekanalen.
For å koble til kanariekanalen:
På dette tidspunktet bør Android Studio spørre om du vil laste ned den nyeste kanaribyggingen. Klikk Oppdater og start på nytt. Hvis du ikke ser en dialogboks, kan du prøve å lukke Preferanser vindu ved å klikke Oppdater. Dette burde tvinge dialogboksen til å vises.
Deretter åpner du SDK Manager og laster ned:
Og det er det. Ditt utviklingsmiljø er nå Android M-klar.
I de neste avsnittene vil jeg dekke noen av de viktigste funksjonene som er introdusert i forhåndsvisnings-SDK, og vise deg hvordan du begynner å jobbe med disse funksjonene i dine egne Android M-prosjekter.
Hvis du vil opprette et Android M-prøveprosjekt og prøve noen av kodestykket for deg selv, må du bare opprette et nytt Android-prosjekt som normalt, men angi minimum SDK til MNC Android M (Preview).
Android M legger til data som er bindende for utviklerens verktøysett med utgivelsen av et dedikert datafindingsbibliotek. Dette nye databindingsbiblioteket setter ut for å minimere mengden kode du må skrive ved å la deg binde data direkte til bestemte visninger i layoutfilene dine.
Den beste måten å forstå hvordan data bindende fungerer, er å se det i aksjon. Så i stedet for å se på teorien bak data bindende, la oss bli sittende fast i noen kode.
For å gjøre data bindende tilgjengelig for prosjektet ditt, må du legge til databasebindingsavhengigheten til prosjektet ditt build.gradle fil. Åpne toppgraden Gradle Build-filen, og legg til følgende:
... avhengigheter classpath "com.android.tools.build:gradle:1.3.0-beta4" classpath "com.android.databinding: dataBinder: 1.0-rc0"
Du må også legge til datainnbindingstillegget til hver modul der du vil bruke datainnbinding. Åpne modulen din build.gradle fil og legg til følgende:
bruke plugin: 'com.android.application' gjelder plugin: 'com.android.databinding'
Med databiblioteket satt opp, la oss se på et grunnleggende eksempel på datainnbinding. Tenk deg at du har a Student klasse:
offentlig klasse Student public final String firstName; offentlig student (String firstName) this.firstName = firstName;
Du vil vise studentens fornavn i layoutfilen din. For å oppnå dette via datainnbinding, bruker du følgende i layoutfilen din:
Dette nye
Mellom disse koder, viser du alle variablene du vil binde til brukergrensesnittelementene dine.
Denne linjen med kode definerer en variabel, student i dette tilfellet, og beskriver en eiendom du kan bruke i layoutet ditt.
Etter avslutningen tag, kan du opprette resten av oppsettet som normalt, den eneste forskjellen er at du nå kan angi egenskapen til student til fornavn i layoutfilen din.
android: text = "@ student.firstName" />
Android Studio kan flagge opp noen feil til du bygger prosjektet ditt. Dette skyldes at databindingsbiblioteket må generere en klasse som inneholder bindingene fra layoutegenskapene og vet hvordan man tilordner verdier for bindingsuttrykkene. Denne filen genereres bare når du bygger prosjektet ditt, så åpne Bygge menyen og velg Lag prosjekt.
Android Studio bygger prosjektet ditt og genererer en ny klasse oppkalt etter layoutfilen din, med tillegg av bindende suffiks (f.eks., ActivityMainBinding).
For å gjøre dette bindende arbeidet, må du legge til bindende klassen til onCreate () Metode for hovedaktiviteten din:
Accentsconagua
@Override protected void onCreate (Bundle savedInstanceState) super.onCreate (savedInstanceState); ActivityMainBinding binding = DataBindingUtil.setContentView (dette, R.layout.main_activity); Student student = ny student ("Test"); binding.setStudent (student); Dette er et veldig enkelt data bindende eksempel. Når du bruker databiblioteket i dine egne prosjekter, er det vanligvis fornuftig å utdype dette grunnleggende eksemplet og gi dataobjektene muligheten til å oppdatere programmets brukergrensesnitt når egenskapen til datobjektet endres. For å se et eksempel på denne typen datainnbinding i handling, sjekk ut Googles offisielle datainnbinding Guide.
Vi lager alle mer personlig informasjon på våre smarttelefoner og nettbrett enn noen gang før, så det er fornuftig at Google gir brukerne økt kontroll over informasjonen mobilappene har tilgang til i Android M.
Frem til nå har Android-apper tatt en helt eller ikke-tilnærming til tillatelser. På installasjonstid krever apper alle tillatelsene de måtte kreve på forhånd, og brukere kan da enten godta eller avvise hele tillatelseslisten.
Android M introduserer en helt ny tillatelsesmodell som gir brukerne muligheten til å velge og velge hvilke tillatelser de gir hver app ved kjøring. I hovedsak krever apper tillatelser når og når de trenger dem, og brukeren kan enten godta eller nekte hver tillatelse.
Brukeren kan for eksempel la Facebook-appen få tilgang til sin plassering, men ikke enhetens mikrofon eller kamera. Brukere kan også tilbakekalle tidligere innvilgede tillatelser. Hvis de bestemmer seg for at de ikke lenger vil at Facebook skal kjenne sin plassering, kan de alltid tilbakekalle android.permission.ACCESS_FINE_LOCATION.
Den nye tillatelsesmodellen er gode nyheter for sikkerhetsbevisste Android-brukere, men hva betyr det for utviklere?
For det første støttes den nye tillatelsesmodellen bare på Android M. Selv om Android-operativsystemet faktisk gjør bakoverkompatibiliteten ganske enkel (som du ser om et minutt), er det avhengig av at appen din vet om den er installert på en enhet som kjører Android M eller en enhet som kjører en tidligere versjon av Android.
Å sjekke versjonen av Android kan høres greit ut, men denne ganske rutinemessige oppgaven blir litt mer forvirrende på grunn av utviklingsaktige naturen til Android M. For appen din for å sjekke om den er installert på forhåndsvisning av Android M-utvikler, må du bruk MNC-kodenavnet.
returnere "MNC" .equals (Build.VERSION.CODENAME);
Men i henhold til Googles kodeprøver, når API-en er ferdig, bør appen din bruke følgende i stedet:
returner Build.VERSION.SDK_INT == Build.VERSION_CODES.MNC;
Så bruk "MNC" .equals for nå, men vær ikke overrasket hvis dette endres på et tidspunkt før den endelige SDK-utgivelsen. Pass også på at du dobbeltsjekker dette stykke kode når den endelige Android M SDK-en ser ut.
Uansett hvilken versjon av Android enheten din slår på, erklærer du alle tillatelsene i manifestet ditt som normalt. Deretter, hvis appen din er installert på en enhet som kjører noe annet enn Android M, går det rett og slett tilbake til den gamle tillatelsesmodellen og ber om alle tillatelsene på installasjonstidspunktet.
Håndtering av tillatelsesforespørsler og svar på Android M er litt mer komplisert, men du erklærer fortsatt tillatelsene på nøyaktig samme måte, i manifestet ditt.
Den eneste ulempen er at hvis appen din bare krever tillatelse på Android M, bør du deklarere den ved hjelp av den nye
Tenk deg at appen din har bekreftet at den er installert på Android M, hvordan går det med å lage tillatelsesforespørsler og håndtere brukerresponser?
Dette er de forskjellige stadiene:
Context.checkSelfPermission (PERMISSION_NAME).Activity.requestPermissions (String [], int) metode. Når du ringer denne metoden, viser systemet en dialogboks hvor brukeren kan gi eller nekte tillatelsen. Du kan legge merke til at det ikke er mulig å legge til en String / @ StringRes for å forklare hvorfor du gjør denne forespørselen, så hvis det ikke er umiddelbart opplagt hvorfor din app trenger en bestemt tillatelse, vil du kanskje gi brukeren litt informasjon før du ringer requestPermissions.onRequestPermissionsResult (int, String [], int []) metode og overfører resultatet.onRequestPermissionsResult () data, din aktivitet må overstyre denne metoden:@Override public void onRequestPermissionsResult (int requestCode, Stringtillatelser [], int [] grantResults) switch (requestCode) tilfelle YOUR_REQUEST_CODE: hvis (grantResults [0] == PackageManager.PERMISSION_GRANTED) else returnere;
En ny tillatelsesmodell betyr nye beste praksis. Her er noen retningslinjer som kan hjelpe deg med å bruke Android Ms grunne tillatelsesinnstillinger mer effektivt.
Hver gang appen din gjør en forespørsel om tillatelse, gir du brukeren muligheten til å redusere appens funksjonalitet ved å nekte den forespørselen. Så du bør designe appen din for å gjøre så få tillatelsesforespørsler som mulig.
Du vil kanskje også vurdere om du kan oppnå de samme resultatene ved å instruere en annen app for å utføre oppgaven i spørsmålet med en hensikt. For eksempel, i stedet for å be om android.permission.CAMERA, du kan bruke en MediaStore.ACTION_IMAGE_CAPTURE hensikt.
Brukeren kan nekte noen (og til og med hver) tillatelsesforespørsel. Hvis dette skjer, vil du sørge for at appen din ikke fryser, krasjer, slutter å fungere eller deaktiverer funksjoner uten forklaring. Tross alt kan brukerne tro at det er noe fundamentalt galt med appen din, og kan til og med gi deg en negativ gjennomgang på Google Play som et resultat.
Håndtering av avslag grasiøst varierer avhengig av appen din, men det kan innebære ting som å returnere et tomt datasett, fjerne et alternativ fra appens meny eller vise en popup som forklarer at brukeren kan låse opp denne funksjonen ved å gi appen visse tillatelser.
Målet ditt er å levere en flott brukeropplevelse, uansett hvilke tillatelser brukeren velger å gi eller nekte. Dette betyr at du vil sørge for at appen din kan håndtere alle hendelser, og den eneste måten å gjøre dette på er gjennom testing.
Når du surfer på Internett, vil det ofte føre til en klikk ved å klikke på en kobling App Chooser dialog. Selv om dette er nyttig når du har flere apper som kan håndtere det koblede innholdet, er dette ekstra trinnet ofte ikke nødvendig, spesielt når du bare har en app som kan håndtere det aktuelle innholdet.
I den kommende M-utgivelsen får Android-innebygd appkobling en oppgradering som tar sikte på å fjerne dette ofte unødvendig App Chooser Trinn ved å automatisk knytte apper med webdomener.
For eksempel, tenk deg at du klikket en kobling til en Twitter-profil i Googles søkeresultater. I Android M kontrollerer systemet om noen av appene dine kan håndtere denne Twitter-nettadressen og har automatisk kobling aktivert. Android vil da starte den offisielle Twitter appen uten å vise App Chooser dialog (forutsatt at du har Twitter installert på enheten).
Dette er gode nyheter hvis du eier et webdomene som gjelder appen din. Når du har tilknyttet nettstedet ditt med søknaden din, når en bruker klikker en kobling til nettstedet ditt, starter operativsystemet automatisk appen din i stedet for å vise App Chooser dialog. Dette hjelper deg ikke bare med å levere en mer sømløs brukeropplevelse, men den holder brukeren tilbake til appen din, i stedet for å gi dem muligheten til å bruke en konkurrerende tredjepartsapp eller en nettleser.
For å etablere en kobling mellom appen din og et webdomene ditt, må du være vert for en JSON-fil på .Velkjente plassering på domenet ditt.
Hvis du vil at appen din skal håndtere koblingene knyttet til nettstedet ditt (mywebsite.com) automatisk, må du laste opp en JSON-fil til roten til mywebsite.com.
Her er et eksempel på innholdet og utformingen av a statement.json fil som sier Android skal alltid bruke appen din (myapp) for å vise innhold relatert til mywebsite.com:
http: //: /.well-known/statements.json ["relation": ["delegate_permission / common.handle_all_urls"], "mål": "namespace": "android_app", "package_name": " "," sha256_cert_fingerprints ": [" 6C: EC: C5: 0E: 34: AE ... EB: 0C: 9B "]]
De pakke nøkkel refererer til pakkenavnet du erklærte i appens manifest. Verdien av sha256_cert_fingerprints nøkkelen er det offentlige sertifikatfingeravtrykket (SHA256) av appens signeringssertifikat.
Vær oppmerksom på at denne JSON-filen er verifisert via HTTP-protokollen i den første versjonen av M-utvikler forhåndsvisning. I den endelige M-utgivelsen blir den verifisert over den krypterte HTTPS-protokollen. Igjen, dette er en av kjennskapene til å jobbe med en utvikler forhåndsvisning, og noe du vil holde øye med over påfølgende utgivelser.
Det siste trinnet er å fortelle Android-operativsystemet at det ikke trenger å spørre brukeren om bestemte typer koblinger. Dette betyr å legge til android: autoVerify = "true" attributt til hver
Når android: autoVerify Attributtet er til stede i appens manifest, Android-operativsystemet verifiserer disse koblingene når brukeren installerer appen din først. I hovedsak er en liste over unike vertsnavn samlet fra
Selvfølgelig, hvis denne bekreftelsen mislykkes, vil applinksadferd ikke være tilgjengelig for appen din. Men forutsatt at verifisering er vellykket, starter Android M automatisk appen din når brukeren klikker på en kobling som er relatert til webdomenet ditt.
I denne opplæringen har vi sett på hvordan appkobling, den nye tillatelsesmodellen og databindingsbiblioteket vil fungere i Android M. Vi har også sett hvordan du kan begynne å eksperimentere med disse nye funksjonene i dag ved å sette opp Android M utvikler forhåndsvisning i Android Studio 1.3 beta eller høyere.
For mer informasjon om Android M, sjekk ut Googles offisielle dokumentasjon. Her finner du mer informasjon om de nye funksjonene, en testguide og, hvis du vil ha litt praktisk erfaring med Android M fra brukerperspektivet, finner du systembilder som du kan blinke til Android-enheten din.
