Kuidas oma Androidi teeki täiustada?

10 parimat tava ja näpunäidet

Kui arendate androidi teeki (avatud või mitte), on hea mõte järgida mõnda juhist, et tagada kõrge kvaliteet ning lihtsustada ka teie kasutajate ja kaastöötajate elu. Siin on mõned näited minu soovitatud parimatest tavadest ja ka näpunäited, mida saate järgida.

1. Ressursside eesliited

Kui mõni teie kasutaja alistab eksikombel teie teegi androidi ressursi, võib see olla väga ohtlik. Näiteks võiksid nad luua stringi ressursi sama nimega, mille määratlesite oma teegis.

Üks viis selle vältimiseks (või vähemalt nimekonflikti võimaluste vähendamiseks) on kõigile raamatukogu ressurssidele prefiksi määramine.

Prefiks võib olla näiteks teie teegi nimi või paketi nimi. Peaksite selle lisama kõigile järgmistes kataloogides olevatele failidele

  • res / joonistatav
  • res / paigutus
  • res / menüü
  • res / xml
  • res / toores

Lisaks lisage prefiks nende ressursitüüpide nimele

  • nöör
  • mitmused
  • värvi
  • mõõde
  • kuulutama stiilselt
  • stiil
  • loll

Samuti saate deklareerida oma raamatukogu eesliite oma ehituse.rakendusel, et Android Studio sellest teada saaks.

android {
    ressursi eesliide 'YOUR_PREFIX_'
}
Android Studio väljavõtete ressursi dialoog täidab teie eesliite automaatselt

2. Siluge ja vabastage klassifikaatorid

Kui teie teegis on silumiskood või arendusutiliidid, siis ärge lisage neid oma väljalaskeartiklisse (.aar). Klassifikaatorite abil saate genereerida oma raamatukogu kahe erineva eseme vastavalt teie ehitustüüpidele:

  • silumisartikkel peaks sisaldama kogu teie produktiivset teegi koodi, samuti silumiskoodi või utiliite, mida teie kasutajad arendamise ajal kasutavad.
  • vabastamise artefakt peaks sisaldama ainult teie teegi koodi, mis lisatakse tootmise APK-sse.

Kõigi raamatukoguvariantide avaldamiseks peate oma raamatukogu build.gradle lisama järgmise konfiguratsiooni

android {
    publicNonDefault tõene
}

Seejärel eraldage oma kood silumis-, pea- või väljaandmiskataloogides vastavalt teie vajadustele ja kui teek üles laadite, on teil kaks artefakti

  • ARTIFACT_ID-VERSION-debug.aar
  • ARTIFACT_ID-VERSION-release.aar

Teie raamatukogu kasutajad peaksid lisama teie sõltuvused vastavalt vajadusele. Näiteks

debugCompile ('GROUP_ID: ARTIFACT_ID: VERSION: debug @ aar') {
    transitiivne = tõene;
}
releaseCompile ('GROUP_ID: ARTIFACT_ID: VERSION: release @ aar') {
    transitiivne = tõene;
}

3. Määratlege versiooniskeem

Teie kasutajad väärivad teada saada, millised muudatused on väljalaskesse lisatud, lihtsalt vaadates kiiresti oma versiooninumbrit.

Kas rikute ühilduvust? Kas see on ainult plaastri versioon? Semantilise versiooni juhendite järgimine on teie raamatukogu versioonimiseks hea mõte.

Arvestades versiooninumbrit MAJOR.MINOR.PATCH, suurendage:
PÕHIVARASTUS, kui teete ühildamatuid API muudatusi,
MINOR versioon, kui lisate funktsioone tagurpidi ühilduval viisil, ja
PATCH-i versioon, kui teete tagurpidi ühilduvaid veaparandusi.

Soovitan teil valida versiooniskeem ja dokumenteerida see oma wiki.

4. Avalikult kättesaadavad väljaande märkused

Teie kasutajad peavad teadma iga teie avaldatud väljaande kõiki üksikasju, sealhulgas uusi funktsioone, parandusi, lahendatud vigu, aegunud koodi ja migreerimisetappe.

Üks viis selle lahendamiseks on muudatuste logi omamine.

Muudatuste logi on fail, mis sisaldab kureeritud ja kronoloogiliselt järjestatud nimekirja olulistest muudatustest projekti igas versioonis.

Sait keepachangelog.com määratleb kasulikke tavasid heade muudatuste logide kirjutamiseks.

Kui kasutate väljapanekute jälgijana GitHubi väljaandeid, võite vaadata seda muudatuste logi generaatorit, mis automatiseerib selle faili alati ajakohastamise protsessi.

Samuti soovitan teil kasutada Githubi väljaandeid ja lisada muudatuste logi osana iga teie loodava väljaande kirjeldusest. Näiteks võite vaadata aadressi https://github.com/maxirosson/jdroid/releases

5. Avaldage Maven Central / Jcenteri hoidlates

Kui avaldate kõik oma raamatukogu artefaktid Maven Centrali või Jcenteri hoidlates, lihtsustate kasutajate konfigureerimist; kuna nad ei pea oma build.gradle'i failidesse lisama kohandatud hoidlaid.

Lisateavet Maven Centralis avaldamise kohta saate lugeda siit, kuid võtke arvesse, et oma sõltuvuste jaoks peate grupi ID-na valitud domeeni omanik olema teie.

Viimane näpunäide töötab nii avatud lähtekoodiga kui ka eraraamatukogude jaoks. Siin on mõned täiendavad näpunäited, mis toimivad eranditult avatud lähtekoodiga raamatukogude jaoks.

6. README toetamine

Kui kasutate oma raamatukogu koodi hostimiseks GitHubi, saate lisada kaastööde juhistega faili .github / CONTRIBUTING.md. Siis, kui kaastöötaja avab tõmbamistaotluse või loob probleemi, näevad nad teie juhiste faili.

Kaasdokumendid kirjeldavad üksikasju selle kohta, kuidas projekti hooldaja sooviks näha plaastreid või funktsioone. See võib hõlmata kirjutatavaid teste, koodisüntaksi stiili või alasid, millele plaastritele keskenduda.

Näidet leiate siit ja lisateavet leiate siit.

7. Git hargnemise ja siltide tava

On nii oluline, et määratleksite ja avalikustaksite oma hargnemise ja sildistamise strateegia, et teie kaastöötajad saaksid paremini teada, kus töötada. Näiteks annab see neile teada, milline haru on teie teegi stabiilsem versioon ja kus on selle uusim tipptasemel versioon.

8. Avalik pidev integratsioon

Pideva avaliku integratsiooni tööriista omamine annab teie raamatukogu kasutajatele ja kaastöötajatele teada teie harude stabiilsusest.

Travis on suurepärane pideva integreerimise tööriist ja see on avatud lähtekoodiga projektide jaoks tasuta. See on integreeritud ka Githubi tõmbetaotluste mehhanismiga ja saate oma README-faili lisada haruehituse olekuga Travise märgi

[! [Ehituse olek] (https://api.travis-ci.org/REPO_OWNER/REPO_NAME.svg?branch=master)] (https://travis-ci.org/REPO_OWNER/REPO_NAME)
Travise ehituse oleku märk

9. Avalike väljaannete jälgija

Koostöö edendamiseks on tore idee avalike teemade jälgija, mis laseb teie kasutajatel ja kaastöötajatel vigu, funktsioonitaotlusi või parandusi üles laadida.

Kui kasutate GitHubit git-hoidlana, on GitHub Issues hea algus. Kui teie projekt on suur või keerulisem, vajate võib-olla keerukamat tööriista nagu Jira o Redmine.

10. Avalda allikaid

Ärge unustage oma lähtekoodi avaldamist sõltuvuste hoidlas (nt Maven Central või Jcenter). See hea tava aitab teie kasutaja IDE-l automaatselt allikaid laadida. See on väga kasulik, et suurendada teie raamatukogu sisemiste asjade mõistmist ja julgustada ka selle õiget kasutamist.

Nende ridade lisamisel oma build.gradle laaditakse teie allikad automaatselt üles faili uploadArchives haruharjutuse osana.

ülesanne ('androidSourcesJar', tüüp: Jar) {
   klassifikaator = 'allikad'
   saidilt android.sourceSets.main.java.sourceFiles ja android.sourceSets.debug.java.sourceFiles
}

esemeid {
   arhiiv project.tasks.androidSourcesJar
}

Kas teile see lugu meeldis?
Palun soovitage (klõpsates nupul lap) või jagage seda lugu, et teised inimesed saaksid seda lugeda! Samuti saate annetada (klõpsates järgmisel nupul Anneta) ja aidata mul kirjutamist jätkata. Aitäh!

Kutsun teid üles mängima minu uhiuut androidmängu Geo Seeker. https://geoseekergame.com