"The code is joy and passion but it has a high degree of suffering"

Distribuire una libreria attraverso jcenter() – parte 2

Posted by on Ott 31, 2016 in Tutte | 0 comments

In questa seconda parte vi descriverò il processo di caricamento della libreria su http://jcenter.bintray.com.

Per prima cosa occorre creare un account su bintray.com e precisamente per i progetti open source andate su questa pagina:

https://bintray.com/signup/oss

account_bintray

Come vedete dall’immagine è possibile usare un account Github o un account Google o Twitter.
Create il vostro account e una volta effettuata la login aggiungete un repository.

addrepo

maven

Nella scheda di creazione del repo date un nome alla vostra libreria, lasciate la libreria come Public altrimenti sarete costretti a fare l’upgrade dell’ account e pagare il canone mensile.
Scegliete Maven come Type  e se volete inserite una licenza e una breve descrizione.

Cliccate su Create e in pochi secondi il repository è pronto.

repo

Per adesso è un repo completamente vuoto. Aggiungiamo un package, click su “Add New Package”

add_package

Scegliamo il Name, un tipo di licenza, se volete anche dei tag, il proprio sito e il percorso del repo git o qualsiasi altro sistema di versioning.

Sul sito di bintray abbiamo finito ma prima di passare ad Android Studio vi consiglio di copiare il codice API Key che ci servirà per caricare la libreria.

Selezioniamo il  nostro username in alto a destra e dal menu clicchiamo “Edit Profile” poi la voce API key e inseriamo la password.

Copiamo il codice API Key e mettiamolo da parte, ci servirà per autenticarci per  il caricamento della libreria

apikey

 

Adesso è arrivato il momento di caricare la libreria direttamente da Android Studio su jcenter().

Per prima cosa dobbiamo creare la libreria.  Create un progetto o in uno già esiste: File->New Module

 

newmodule

Poi selezioniamo Android Library

library

e nella finestra successiva diamo un nome alla libreria. Io l’ho chiamata snake.
Inserite magari per la prima volta una semplice classe cosi provate il funzionamento.

applylibrary

Dopo aver creato la libreria aprite il file build.gradle del modulo libreria, snake nel mio caso.
La prima differenza con un modulo normale è nel plugin applicato.
Una libreria non applica il plugin “com.android.application” ma “com.android.library”

Il passo successivo è applicare il plugin di bintray. Modifichiamo il file build.gradle del progetto (e non dei moduli).

Adesso aggiungiamo le informazioni per l’ autenticazione su bintray direttamente nel file local.properties

Ovviamente sostituite le XXX con i dati del vostro account, sia password che il codice API key che abbiamo messo da parte durante le precedenti procedure. Non modificate il path del vostro sdk, ho lasciato la prima riga per farvi capire dove aggiungere i dati.
Non preoccupatevi se inseriamo i dati dell’ account in chiaro, il file local.properties è inserito nella lista dei file da ignorare su .gitignore quindi non sarà mai incluso nel repository online ma rimarrà solo in locale.
Se non usate git preoccupatevi di non “pushare” online il file.

Infine modifichiamo il file builde.gradle del modulo libreria.

Sotto apply plugin: ‘com.android.library’ inseriamo

Cambiate bintrayName e gli altri dati in base al vostro repository che avete creato online.

Infine per poter caricare la libreria utilizziamo uno script. Lo script l’ho copiato tempo fa  direttamente da questo repo : https://raw.githubusercontent.com/nuuneoi/JCenter/master/installv1.gradle

Lo script è  anche presente in un repo che ho creato ad hoc.

Quindi aggiungiamo in fondo al file build.gradle della libreria

Vi mostro il file build.gradle della libreria di esempio snakelib:

https://raw.githubusercontent.com/giuseppesorce/snakelib/master/snakelib/build.gradle

Sincronizziamo e abbiamo finito.

Per poter caricare la libreria usiamo la linea di comando direttamente da Android Studio (la tab Terminal)  e scriviamo

Per windows

Per macos e linux

Al termine carichiamo la libreria e scriviamo:

Per windows

Per macos e linux

Se tutto è andato a buon fine dovremmo vedere la libreria nel sito di bintray.

bintray

Per poter usare la libreria in un progetto dobbiamo prima inserire il path del repo e poi la dipendenza.

Nel file build.gradle del modulo app o nel vostro modulo principale inseriamo:

Ovviamente sostituite nel repo il mio nome e la mia libreria con i vostri dati.

Poi inseriamo  la dipendenza:

Ci sono altri metodi per poter caricare una libreria su jscenter() anche direttamente da github o bitbucket.

Ecco il repo che ho usato per la libreria.

https://github.com/giuseppesorce/snakelib

Ho testato varie volte questo metodo e funziona molto bene. In pochi minuti è possibile distribuire la propria libreria come qualsiasi altra libreria opensource che usiamo nei nostri progetti.

 

 

 

 

Read More

Distribuire una libreria attraverso jcenter() – parte 1

Posted by on Ott 28, 2016 in Tutte | 0 comments

Distribuire una libreria attraverso jcenter() – parte 1

Nel precedente articolo ho descritto come creare un file .aar del proprio codice e condividerlo con altri sviluppatori. Il procedimento che ho scritto è molto veloce e vuole essere più un utilizzo pratico che una soluzione più robusta.
Non è adatto per librerie più corpose perchè per esempio per utilizzare il codice occorre importare tutte le dipendenze che utilizza la libreria.
Per utilizzare una libreria  open source in Android Studio, come ben  sapete,  basta una riga di codice nel file build.gradle,  cioè l’ import della dipendenza, ma da dove scarica la libreria Android Studio?
In questa seria di 3  articoli descriverò come utilizzare  jcenter() per distribuire la stessa libreria del precedente articolo. Una semplice classe che mostra una SnakeBar.

Per prima cosa è importante capire da dove effettua il download Android Studio.
Android Studio utilizza un Maven Repository Server che è stato definito nel file build.gradle del progetto. Apache Maven è un tool, una tecnologia per la distribuzione di progetti (java soprattutto) e build automation.
I due principali server utilizzati per la distribuzione di librerie sono:  jscenter e maven central.

jcenter è un repository maven ospitato da bintray.com mentre maven central è ospitato da sonatype.org. Sono entrambi ormai degli standard ma sono due siti, due repo diversi quindi è possibile che una libreria presente su jcenter() non sia presente su maven central. E’ anche possibile creare un proprio repository maven come ha fatto per esempio Fabric.

e la dipendenza è gestita come le altre

Esistono anche altri repository che gradle e Android Studio possono usare ma è talmente raro usare le librerie ospitate in questi repo che personalmente non ho mai avuto l’ occasione  di provarle nè le ho viste in altri progetti.

La scelta degli sviluppatori quindi si divide tra jcenter e maven central.
Android Studio (quindi google) aveva scelto inizialmente come repo principale maven central infatti tempo fa quando si creava un nuovo progetto nel file build.gradle  era presente:

Adesso invece è stato scelto jcenter e infatti possiamo vedere nel file build.gradle del progetto che il repo principale è cambiato:

Non ho mai usato maven central ma ho letto che è molto più complicato di jcenter e non è facile caricare le librerie (almeno non facile come su jcenter), anche il team di Android Studio ha scelto jcenter e leggendo su vari blog la scelta è stata effettuata per alcuni motivi:

  • jcenter rilascia la libreria attraverso  CDN che è un sistema di caricamento molto veloce.
  • jcenter è il più grande repository Java del mondo quindi, di conseguenza qualsiasi cosa disponibile su Maven Central teoricamente è disponibile anche su jcenter e non viceversa.
  • Caricare la nostra libreria su jcenter è molto più semplice e non occorre firmare nulla come succede su Maven Central.
  • Il sito di bintray.com mette a disposizione una UI molto più user friendly.

Prima di spiegare come caricare una libreria su jcenter è opportuno parlare di  come funziona l’ import delle dipendenze in gradle.

La stringa per importare la dipendenza è divisa in 3 parti:

In questo caso il group_id  è com.giuseppesorce , l’ artifact_id è snake (che il nome identificativo della libreria) e version  è 1.0.0. Il group_id definisce il nome del gruppo principale e per convenzione si usa il package name dello sviluppatore come per esempio:

com.square.picasso

mentre il nome della libreria è l’ artifact quindi:

compile ‘com.squareup.picasso:picasso:2.5.2′

Tra il group_id, l’ arrtifact e il numero di versione si inseriscono i due punti “:” .
Cosa succede quando inseriamo la dipendenza per esempio di Picasso ?
Semplicemente il plugin gradle di Android Studio farà una richiesta a jcenter con le informazioni del group_id, identificando lo sviluppatore,  l’ artifact, identificando la specifica libreria dello sviluppatore  e per finire richiedendo la versione indicata nell’ ultima parte della stringa della dipendenza.
Provate a visualizzare questo indirizzo sul browser:

http://jcenter.bintray.com/com/squareup/picasso/picasso/

Come vedete il browser vi mostrerà tutte le versioni di Picasso presenti nel repository e se provate ad aprire una cartella per esempio la 2.5.2 troverete tutti i file che gradle scaricherà per far funzionare la libreria Picasso.

Per questa prima parte è tutto.

 

 

 

Read More

Utilizzo pratico delle librerie .aar

Posted by on Ott 20, 2016 in Tutte | 0 comments

Riprendo dopo un po di tempo a scrivere su questo blog, come sempre il lavoro e altro mi tengono molto occupato.
Sicuramente ci saranno decine di guide, come questa che vi illustro oggi e anche  migliori, ma voglio lo stesso parlarvi della mia esperienza con le librerie aar e come a volte le uso per distribuire codice. Non è il metodo migliore ma è molto veloce e pratico.
L’ argomento, il  format .aar,  è vasto ma mi limiterò solo a mostrare un caso pratico cioè come utilizzare un file .aar per distribuire velocemente una libreria .

Non so se anche voi avete la  necessità  inviare ad altri (aziende o altri sviluppatori)  del codice o delle librerie scritte da voi. Uno dei metodi che a volte uso per l’ invio di questo codice è l’ utilizzo del formato aar.
Il formato aar è un bundle, un binario che contiene sia codice che risorse. Il codice è compilato come classes.dex quindi il codice non sotto forma di classi java ma come  compilato dex con tutti i vantaggi del caso.
E’ molto simile ad un file apk ma è utilizzato per distribuire le Android Library Project.

Come ho scritto è un metodo pratico e senza dubbio creare una libreria come artifact e pubblicare la libreria su un serve come jscenter() o maven centrale è la scelta migliore per distribuire codice ma questo è una possibilità più veloce e pratica con i suoi pro e contro.

Gli step da seguire sembrano tanti ma vi assicuro che sono semplici e veloci.

Per prima cosa abbiamo bisogno di un progetto Android Studio. Ne possiamo creare uno nuovo o utilizzarne uno già creato.
Con il progetto aperto selezioniamo:

File->New Module…

lib_aar1

Scegliamo Android Library dalla lista che ci propone Android Studio, diamo un nome alla nostra libreria e selezioniamo il minSdk.

select_library

Vedremo la nostra libreria come modulo e possiamo cosi inserire il codice che vogliamo. Io ho creato una classe con  un metodo statico che crea una semplice SnackBar.

Adesso abbiamo bisogno della visualizzazione Project del nostro progetto.

projects

Per creare la nostra libreria in formato aar andiamo nei Gradle tasks: clicchiamo Gradle nei pannelli laterali (a destra) e apriamo i task relativi alla nostra libreria e facciamo doppio click su assembleRelease

tasks

La nostra libreria è pronta. Nella visualizzazione Project apriamo la cartella (tua libreria)/build/outputs/ e vedremo 2 file .aar, la versione debug e release della nostra libreria.

output

Tasto destro del mouse sulla cartella o sul file della libreria e selezioniamo  su mac “Reveal in Finder” su windows dovrebbe essere “Show in explorer” 🙂

Bene abbiamo finito, ora tutto il vostro codice è dentro la libreria che  in questo caso si chiama : myfirstlib-release.aar.

Per poter usare la libreria dobbiamo importarla in un  progetto. Inseriamo la libreria nella cartella libs dentro il nostro modulo principale  dentro app in questo caso.

libs

Per importare la libreria modifichiamo o il file build.gradle del modulo app (quindi la libreria sarà disponibile solo per il modulo app) o build.gradle di tutto il progetto ( la libreria sarà disponibile per tutti moduli del nostro progetto).

Per il nostro modulo modifichiamo il file build.gradle e aggiungiamo dentro il tag android:

Ora importiamo la libreria aggiungendo la dipendenza:

Sincronizziamo il progetto e cosi possiamo utilizzare il codice della libreria.

Per rendere disponibile la libreria per tutti i moduli del progetto aggiungiamo nel file build.gradle del progetto:

La procedura mi sembra molto semplice ma vi metto a disposizione anche i due  progetti che ho usato.

Libreria https://github.com/giuseppesorce/mylibrary

Progetto https://github.com/giuseppesorce/applib

Ho pubblicato la libreria in jcenter il Maven repository usato da Google.

Potete provare ad inserire nel file build.gradle della vostra app

La pubblicazione della libreria in un repo maven ha il vantaggio di non importare le dipendenze che utilizza la libreria più ovviamente tutti i vantaggi di una libreria online.

 

 

 

 

 

 

 

 

 

 

 

 

 

Read More

Tips and tricks: velocizzare gradle e ridurre gli apk parte 2

Posted by on Ott 16, 2015 in Tutte | 0 comments

Tips and tricks: velocizzare gradle e ridurre gli apk parte 2

Nella prima parte dell’ articolo vi ho parlato di proguard, un tool che oltre ad “obscurare” il codice può ridurre un apk anche del 35% o più. In questa seconda parte vi elencherò altre tecniche per mettere a dieta l’ apk.
Da pochi giorni Google ha aumentato il peso massimo di un apk per il Play Store portandolo a  100mb, ma è importante che la nostra applicazione non sia molto pesante perchè può essere un deterrente al download e ai successivi aggiornamenti.

Lint

Uno strumento che ci permette di ottimizzare il codice è senza dubbio Lint. Lint è un tool che analizza il codice sia java che xml e crea un report con:

  • risorse non utilizzate
  • tag xml non utilizzati e non chiusi correttamente
  • variabili non utilizzate
  • import di package non utilizzati

L’ elenco è molto vasto e soprattutto l’ individuazione delle risorse non utilizzate ci permette di risparmiare kb inutili. Il sistema di building di Android non prevede il filtro delle risorse non utilizzate. Se in un nostro progetto inseriamo in una delle cartelle drawable o in asset un’ immagine di 10 mb anche se nè da xml nè da codice la utilizziamo  il file  apk conterrà ugualmente l’ immagine facendo aumentare il peso finale.
E’ normale che durante lo sviluppo il designer (o il project manager) cambi idea su icone, layout  e spesso non si ha il tempo ne l’ opportunità di cancellare le vecchie risorse. Font, icone, png di background, layout, tutte risorse che incrementano i kb della release finale.

Lint è facile da usare. E’ già attivo durante lo sviluppo, Android Studio per esempio ci mostra sempre se una variabile o una classe non sono utilizzate. Per avere una visione di insieme possiamo utilizzare Lint da interfaccia: Analyze-> Inspect Code

inspect

Nella successiva schermata possiamo scegliere il modulo app cosi che Lint analizzi solo il nostro codice e non il codice di altri moduli, librerie.

moduloapp

Il risultato è visibile in basso e basta cliccare sulla voce per aprire il file e modificare come consiglia Lint.

report

Possiamo utilizzare Lint anche da riga di comando se preferite:

E’ possibile creare anche un report in formato html:

Gradle shrinking

Lint è utile ma crea degli alert e un report, poi è compito dello sviluppatore sistemare secondo indicazione o eliminare le risorse non utilizzate.
Gradle  permette, con poche istruzioni, di ridurre il nostro apk in automatico. Aggiungiamo e settiamo a true la proprietà shrinkResources

Con una sola riga, in automatico, saranno eliminate le risorse non utilizzate. La proprietà shrinkResources richiede soltanto che proguard sia attivato con minifyEnabled true
Uno dei problemi dell’ eliminazione delle risorse inutilizzate in automatico è che il tool potrebbe rimuovere risorse che vengono usate in maniera dinamica. Per prevenire questo possiamo definire un’ eccezione. Creiamo un file xml nella cartella res/raw. Il nome del file deve essere keep.xml. Il contenuto:

Quando usate proguard e/o shrinkResources è importante ricontrollare il funzionamento dell’ applicazione. I tool automatici fanno miracoli ma è sempre meglio controllare e testare prima della pubblicazione sul play store.

Possiamo ridurre il nostro apk anche “manualmente” cioè configurando Gradle in modo tale da eliminare quello che non ci serve o che non ci serve per quella release.

Per esempio possiamo mantenere solo alcune lingue o solo alcune risoluzioni:

In questo caso se avessimo più lingue, magari lingue asiatiche come il cinese, con resConfigs manteniamo solo le lingue inglese ed italiano. Anche per le varianti di risoluzioni/densità possiamo mantenerne solo alcune.

Un accorgimento semplice ma molto utile può essere usato nelle dipendenze. Per esempio invece di  inserire la dipendenza di tutto il  play service:

 importiamo solo i servizi che ci servono; per esempio

L’ import delle dipendenze è  selettivo; importeremo solo maps e wearable: cosi da escludere gli altri servizi di google non necessari al nostro progetto.

Non esiste la ricetta magica ma con un po di configurazioni, ottimizzazioni e prove possiamo ridurre il peso dell’ apk. Oltre a Proguard, Lint, Gradle è importante utilizzare immagini già ottimizzate e immagini in formato png. Utilizzate anche le 9-patches per sfondi e pulsanti, riducono di tanto l’ utilizzo di grosse png “ripetitive”.

 

Read More