Kuinka parantaa Android-kirjastoa

10 parhaita käytäntöjä ja vinkkejä

Jos olet kehittämässä android-kirjastoa (avointa lähdekoodia vai ei), on hyvä idea noudattaa joitain ohjeita varmistaaksesi korkea laatu ja yksinkertaistaaksesi käyttäjien ja yhteistyökumppaneiden elämää. Tässä on esimerkkejä suosittelemistani parhaista käytännöistä ja vinkkejä, joita voit seurata.

1. Resurssien etuliitteet

Jos joku käyttäjistä ohittaa vahingossa kirjastosi android-resurssin, se voi olla erittäin vaarallinen. Esimerkiksi he voivat luoda merkkijonoresurssin samalla nimellä, jonka määrititte kirjastossa.

Yksi tapa välttää tämä (tai ainakin vähentää nimiristiriitojen mahdollisuuksia) on antaa etuliite kaikille kirjastoresursseille.

Etuliite voi olla esimerkiksi kirjaston nimi tai paketin nimi. Sinun on lisättävä se kaikkiin seuraavien hakemistojen tiedostoihin

  • res / vedettävä
  • res / layout
  • res / valikko
  • res / xml
  • res / raaka

Lisää lisäksi etuliite näiden resurssityyppien nimeen

  • jono
  • taivutusmuodot
  • väri-
  • Dimen
  • julistaa-styleable
  • tyyli
  • bool

Voit myös ilmoittaa kirjaston etuliitteen build.gradle-sovelluksessa, jotta Android Studio voi tietää siitä.

android {
    resourcePrefix 'YOUR_PREFIX_'
}
Android Studio Extract Resource -valintaikkuna täydentää etuliitteen automaattisesti

2. Debug ja vapauta luokittelijat

Jos kirjastossasi on vianetsintäkoodi tai kehitysapuohjelmat, älä lisää niitä julkaisuartikkeliin (.aar). Voit käyttää luokittelijoita kahden erilaisen esineen luomiseen kirjastostasi rakennustyyppiesi mukaan:

  • vianetsintäartikkelin tulisi sisältää kaikki tuottava kirjastokoodisi sekä mahdolliset virheenkorjauskoodit tai apuohjelmat, joita käyttäjät käyttävät kehityksen aikana.
  • julkaisutuotteen tulisi sisältää vain kirjastosi koodi, joka sisällytetään tuotannon APK: han.

Jotta voit julkaista kaikki kirjastomuunnelmat, sinun on lisättävä seuraava kokoonpano kirjastoosi build.gradle

android {
    publicNonDefault totta
}

Sitten jaa koodi virheenkorjaus-, pää- tai julkaisuhakemistoihin tarpeidesi mukaan ja kun lataat kirjaston, sinulla on kaksi artefakttia

  • ARTIFACT_ID versiottoman debug.aar
  • ARTIFACT_ID versiottoman release.aar

Kirjaston käyttäjien tulee sisällyttää riippuvuutesi heidän tarpeensa mukaan. Esimerkiksi

debugCompile ('GROUP_ID: ARTIFACT_ID: VERSION: debug @ aar') {
    transitiivinen = totta;
}
releaseCompile ('GROUP_ID: ARTIFACT_ID: VERSION: release @ aar') {
    transitiivinen = totta;
}

3. Määritä versiointi

Käyttäjät ansaitsevat tietää, millaisia ​​muutoksia julkaisu sisältää, vain nopeasti katsomalla versionumeroasi.

Rikotteko yhteensopivuutta? Onko se vain laastariversio? Semanttisen versioinnin ohjeiden noudattaminen on hyvä idea kirjastoversioille.

Kun annetaan versionumero MAJOR.MINOR.PATCH, lisää:
MAJOR-versio, kun teet yhteensopimattomia sovellusliittymämuutoksia,
MINOR-versio, kun lisäät toimintoja taaksepäin-yhteensopivalla tavalla, ja
PATCH-versio, kun teet taaksepäin yhteensopivia virhekorjauksia.

Ehdotan, että valitset versiokaavion ja dokumentoit sen wikisi.

4. Julkisesti saatavilla olevat muistiinpanot

Käyttäjien on tiedettävä kaikki julkaisemiesi julkaisujen yksityiskohdat, mukaan lukien uudet ominaisuudet, parannukset, korjatut virheet, vanhentunut koodi ja siirtymisvaiheet.

Yksi tapa ratkaista tämä on muutosloki.

Muutosloki on tiedosto, joka sisältää kuratoidun, kronologisesti järjestetyn luettelon merkittävistä muutoksista projektin jokaisessa versiossa.

Sivusto keepachangelog.com määrittelee joitain hyödyllisiä tapoja kirjoittaa hyviä muutoslokkeja.

Jos käytät GitHub Issues -tapahtumien seurantaa, voit tarkastella tätä muutoslokigeneraattoria, joka automatisoi tiedoston pitämisen aina ajan tasalla.

Suosittelen myös käyttämään Github-julkaisuja ja sisällyttämään muutosloki osaksi jokaisen luomaasi julkaisun kuvausta. Voit esimerkiksi katsoa osoitteessa https://github.com/maxirosson/jdroid/releases

5. Julkaise Maven Central / Jcenter -varastoissa

Jos julkaiset kaikki kirjastosi esineet Maven Central- tai Jcenter-arkistoihin, yksinkertaistat käyttäjien määrityksiä. koska heidän ei tarvitse lisätä mukautettuja arkistoja build.gradle-tiedostoihinsa.

Voit lukea lisää julkaisemisesta Maven Central -palvelussa täältä, mutta ota huomioon, että sinun on oltava riippuvuutesi ryhmätunnuksena valitsemasi verkkotunnuksen omistaja.

Jälkimmäiset vinkit toimivat sekä avoimen lähdekoodin että yksityisissä kirjastoissa. Tässä on joitain lisävinkkejä, jotka toimivat yksinomaan avoimen lähdekoodin kirjastoille.

6. Lukeminen README-ohjelmaan

Jos käytät kirjastokoodisi GitHub-sovellusta, voit lisätä siihen tiedoston .github / CONTRIBUTING.md ja siihen liittyvät ohjeet. Sitten aina, kun avustaja avaa vetopyynnön tai luo ongelman, hän näkee ohjeistiedostosi.

Asiakirja-asiakirjat sisältävät yksityiskohdat siitä, kuinka projektin ylläpitäjä haluaisi nähdä korjaustiedostoja tai ominaisuuksia. Tähän voi kuulua kirjoitettavia testejä, koodisyntaktityyliä tai alueita, joihin korjaustiedostoihin keskittyä.

Voit nähdä esimerkin täältä ja saada lisätietoja täältä.

7. Git-haara & tunnisteet -käytäntö

On niin tärkeää, että määrittelet ja julkistat git-haarautumis- ja tunnistestrategian, jotta yhteistyökumppanisi tietävät paremmin, missä työskennellä. Esimerkiksi, se ilmoittaa heille, mikä haara on kirjastosi vakain versio ja missä on uusin huipputekninen versio.

8. Julkinen jatkuva integraatio

Jos sinulla on julkinen jatkuva integrointityökalu, kirjaston käyttäjät ja avustajat tietävät haaroidesi vakaudesta.

Travis on erinomainen jatkuva integrointityökalu ja ilmainen avoimen lähdekoodin projekteille. Se on integroitu myös Githubin vetopyyntömekanismiin, ja voit lisätä Travis-tunnuksen oksanrakennuksen tilaan README-tiedostoosi

[! [Rakennustila] (https://api.travis-ci.org/REPO_OWNER/REPO_NAME.svg?branch=master)] (https://travis-ci.org/REPO_OWNER/REPO_NAME)
Travis rakentaa tilamerkki

9. Julkisen lehden seurantalaite

Hyvä idea yhteistyön edistämiseksi on julkisen julkaisun seuranta, jonka avulla käyttäjät ja yhteistyökumppanit voivat ladata virheitä, ominaisuuspyyntöjä tai parannuksia.

Jos käytät GitHubia git-arkistona, GitHub Issues on hyvä alku. Jos projekti on iso tai monimutkaisempi, tarvitset ehkä kehittyneempää työkalua, kuten Jira o Redmine.

10. Julkaise lähteet

Älä unohda julkaista lähdekoodiasi riippuvuussäilytysvarastoissasi (ts. Maven Central tai Jcenter). Tämä hyvä käytäntö auttaa käyttäjän IDE: tä lataamaan lähteet automaattisesti. Tämä on erittäin hyödyllistä, jotta lisätään kirjaston sisäpiirien ymmärrystä ja rohkaistaan ​​myös sen oikeaa käyttöä.

Kun lisäät nämä rivit build.gradle-sovellukseen, lähteet lähetetään automaattisesti osana uploadArchives-ohjausohjelmaa.

tehtävä ('androidSourcesJar', tyyppi: Jar) {
   luokitin = 'lähteet'
   from android.sourceSets.main.java.sourceFiles, android.sourceSets.debug.java.sourceFiles
}

esineitä {
   arkistot project.tasks.androidSourcesJar
}

Piditkö tästä tarinasta?
Ole hyvä ja suosittele (napsauttamalla taputtaa painiketta ) tai jaa tarina, jotta muut ihmiset voivat lukea sen! Voit myös lahjoittaa (napsauttamalla seuraavaa Lahjoita-painiketta) ja auttaa minua jatkamaan kirjoittamista. Kiitos!

Kutsun sinut pelaamaan aivan uutta android-peliä Geo Seeker. https://geoseekergame.com