Slik lager du din Android App-kode for publisering i Google Play-butikken

På dette tidspunktet er du sannsynligvis lei av å se på din egen app. Du har skrevet den grunnleggende Android-appen, testet appen, fikset feilene, testet igjen, lagt til funksjoner, gjort mer testing, holdt opp sent på kvelden og gjort enda mer testing. Men hvis du planlegger å publisere din app, er det ett råd: Når du er ferdig med testing, test litt mer.

Spør deg selv hvilke sekvenser av knapper du unngikk å klikke når du gjorde din "grundige" test. Deretter mønstre motet til å klikke på knappene og bruk widgets i de merkelige sekvensene. Og mens du er i det, vipp enheten i sidelengs, vri enheten opp ned, hold enheten over hodet ditt, og prøv å bruke appen. Hvis enheten din er en telefon, må du avbryte appen med et innkommende anrop.

Er du ferdig med testing? Ikke ennå. Få vennene dine til å teste appen på enhetene sine. Uansett hva du gjør, ikke gi dem noen andre instruksjoner enn instruksjonene du har tenkt å publisere. Enda bedre, ikke engang gi dem instruksjonene du har tenkt å publisere. (Noen brukere vil ikke lese disse instruksjonene uansett.) Spør vennene dine om deres erfaringer som kjører appen din. Hvis du føler at vennene dine er for høflige, trykker du på dem for flere detaljer.

Un-testing av appen

Når du tester en app, finner du funksjoner som ikke fungerer helt. Du sjekker loggene, og du legger sannsynligvis til kode for å hjelpe deg med å diagnostisere problemer. Når du forbereder deg på å publisere appen din, fjerner du unødvendig diagnostisk kode, fjerner ekstra loggingsopplysninger, og fjerner hvilken som helst annen kode hvis formål er å ha nytte av utvikleren i stedet for brukeren.

Når du utvikler appen din, kan du ha opprettet noen testdata. (Er det en ande som heter "Donald" i appens kontaktliste?) Hvis du har opprettet testdata, slett du dataene fra appen din.

Sjekk prosjektets AndroidManifest. xml-fil. Hvis elementet har en android: debuggable = "true" attributt, fjern det attributtet. (Egenskapens standardverdi er feil.)

Velge Android-versjoner

Når du oppretter et nytt prosjekt, ber Android Studio deg om en Minimum SDK-versjon. Ditt prosjekt er bygget. gradle-filen beholder en rekord av ditt valg i sitt minSdkVersion-felt. Du kan endre dette nummeret ved å redigere bygningen. gradle fil.

Dette minSdkVersion-nummeret er viktig fordi det ikke skal være for lavt eller for høyt.

• Hvis minSdkVersion-nummeret er for lavt, bruker appen ikke funksjoner fra nyere Android-versjoner.

  Hvis appen din er veldig enkel, er dette greit. Men hvis appen gjør noe som ser annerledes ut i nyere Android-versjoner, kan appens vintageutseende slå av brukerne.

• Hvis minSdkVersion-nummeret er for høyt, vil Play-butikken ikke tilby appen din til brukere med eldre enheter.

  Faktisk, hvis appens minSdkVersion er 21, ser en bruker som besøker Play-butikken på en KitKat-enhet, ikke engang appen din. (Du har kanskje allerede oppdaget feilmeldingen INSTALL_FAILED_OLDER_SDK. Android Studio kan ikke installere en app på emulatoren som du valgte fordi emulatorens SDK-versjon er lavere enn appens minSdkVersion.)

  Du vil ikke eliminere brukere enkelt fordi de ikke har de nyeste og beste Android-enhetene. For å nå flere brukere, hold minSdkVersion fra å være for høy. Hvis appen din ikke bruker noen funksjoner som ble introdusert etter API nivå 11, sett du minSdkLevel til 11.

Prøv å kjøre appen din på emulatorer med mange API-nivåer. Når du går i trøbbel (si på en emulator med API nivå 10) sett prosjektets minSdkLevel til noe høyere enn det plagsomme nivået.

Når du lager et nytt prosjekt, inneholder dialogboksen Target Android Devices en Hjelp meg Velg-kobling. Når du klikker denne koblingen, ser du et diagram som viser prosentandelen enheter som kjører Lollipop, KitKat, Jelly Bean og andre Android-versjoner. Dette klikkbare diagrammet beskriver funksjonene i hver Android-versjon, og (viktigst) viser prosentandelen enheter som kjører hver versjon. Med informasjon fra dette diagrammet kan du velge det beste kompromisset mellom de nyeste funksjonene og det bredeste brukergruppen.

Android's støttebiblioteker tillater enheter med eldre Android-versjoner for å utnytte nyere Android-funksjoner.

Angi appens egen versjonskode og versjonens navn

Når du oppretter et nytt prosjekt, plasserer Android Studio noen standardattributter i byggingen din. gradle fil. Disse attributter inkluderer feltene VersionCode og VersionName:

defaultConfig {… versionCode 1 versionName "1. 0 "}

Versjonskoden må være et heltall, og appens kodenumre må øke over tid. Hvis din første publiserte versjon for eksempel har versjonskode 42, må den andre publiserte versjonen ha en versjonskode høyere enn 42.

Brukere ser aldri versjonskoden. I stedet ser brukerne navnet på appen din. Du kan bruke hvilken som helst streng for appens versionsnavn. Mange utviklere bruker den store utgivelsen. moll-frigivelse. punktsystem. For eksempel kan et typisk versjonnavn være 1. 2. 2. Men det er ingen begrensninger. Android har alle dessert navnene, og Apple pleide å bruke jungelkatt navn, slik at du kan legge til noe som

versionName "sea squirt"

til min build. gradle fil. (Se opp!)

Hvis du har tenkt å publisere på Amazon Appstore, må du ikke bruke setninger som sea squirt for versionName. Amazon Appstore insisterer på en versjonnavn på opptil fem heltall atskilt fra hverandre av prikker.For eksempel versjonnavn verdier som 2. 30 og 1. 2. 0. 325. 0 fungerer helt fint.

Velge et pakkenavn

Hver Android-app har sitt eget pakkenavn. Så, hvis din første publiserte app er i com. eksempel. earnmeamion pakke, sett din andre app i et com. eksempel. secondtimeisacharm pakke.

Ditt pakkenavn skal hjelpe deg med å identifisere deg eller din bedrift. Hvis du har et domenenavn, starter pakkenavnet med domenenavnets deler reversert!