Come decidere quale libreria usare?

Question

Come decidere quale libreria usare?

#1 da (3 voti)
#2 da (2 voti)

3

Mi trovo di fronte alla domanda su quale libreria usare in un'app per Android. Per ragioni di generalità e obiettività, eviterò di menzionare ciò che effettivamente fanno le biblioteche. Ho ridotto il campo a tre opzioni in base ai criteri indicati nella descrizione di ciascuno.

La mia domanda non è quale libreria è "migliore" per questa o altre situazioni. Piuttosto, sono interessato ai tuoi approfondimenti su quali altri criteri potrei applicare alla mia decisione o su qualsiasi altra cosa che potrei non aver considerato.

Qualunque cosa scelga, sarò bloccato con esso. I paradigmi delle due librerie sono abbastanza diversi da non pensare che sarebbe pratico racchiuderli in un'API comune e passare da uno all'altro in seguito.

Opzione 1: il vecchio standby

Il bello: ho usato questa libreria in altre app e mi sento abbastanza a mio agio. Il Javadoc è completo. Il barattolo ha solo 95 KB.

Il male: Google ha recentemente disapprovato l'intera API da cui dipende questa libreria. Questa API è open source e ancora supportata dagli sviluppatori originali , ma la deprecazione di Google indica che prevede di rimuoverla dalla libreria standard di Android. Lo sviluppatore della libreria che sto usando ha annunciato di voler imporre l'API di terze parti e inserirle nella sua libreria per proteggerne l'eventuale rimozione da Android. Napkin math dice che questo ingigantirà la libreria almeno di 1 MB, e forse il doppio, dal momento che non so esattamente da quali librerie dipenda.

Opzione n. 2: la nuova soluzione lucida

Il bello: questa libreria ha molte più funzionalità di quella che ho usato e sostituisce altri 163 KB di altre librerie (258 KB totali).

Il male: niente Javadoc. Normalmente lo considererei un rompicapo istantaneo, ma ho le spalle al muro. Senza una documentazione adeguata, mi aspetto che costasse almeno una settimana o due per mettersi a proprio agio. Pesa a 573 KB, più un altro 216 KB per un'astrazione opzionale di livello superiore. Quindi tre volte la dimensione di ciò che sta sostituendo, ma potenzialmente un terzo della dimensione futura di ciò che sta sostituendo.

Opzione n. 3: tira il mio

Il bello: sarebbe basato sull'API che Google sta mantenendo, quindi sarebbe molto piccolo. Ci sarebbe Javadoc. Altri sviluppatori potrebbero trovarsi di fronte a questo stesso dilemma, quindi la mia API potrebbe diventare un prodotto a sé stante.

Il male: non sarebbe così ricco di funzionalità come l'opzione # 1, figuriamoci l'opzione # 2. Mi costerebbe almeno due settimane per scrivere.

libraries third-party-libraries

posta Kevin Krumwiede 29.04.2015 - 01:35

fonte

2 risposte

Leggi altre domande sui tag libraries third-party-libraries

Failover per lavori ad alta frequenza iteratori complessi in C

score 3 · Answer 1

Opzione 1: il vecchio standby

Le cose deprecate non dovrebbero mai essere usate se esiste un'altra opzione. Eventuali librerie create usando questa libreria deprecata saranno tecnicamente deprecate. Quindi il tuo prodotto sarebbe stato deprecato prima ancora che fosse finito.

È stato ritirato per un motivo. In genere, la ragione è che c'è qualcosa di meglio in ogni aspetto, e dovresti usarlo.

Opzione n. 2: la nuova soluzione lucida

Sembra che questo sia il qualcosa di meglio. Penso che dovresti mordere il proiettile e scalare quella curva di apprendimento. Ciò consente a qualcun altro di fare il grande lavoro per crearlo, aggiornarlo e mantenerlo. Non lo vuoi nel tuo piatto.

Opzione n. 3: tira il mio

Probabilmente è quello che farei (nonostante il mio stesso consiglio). Fa esattamente quello che vuoi con zero overhead. Sai esattamente come funziona. Ma ... devi farlo. Realizzarlo richiederà probabilmente più tempo dell'apprendimento # 2. Non reinventare la ruota.

Riepilogo

Penso che il # 1 e qualsiasi cosa deprecata dovrebbero essere evitati come la peste. # 3 suona il più attraente, ma vorrei raccomandare il # 2.

score 2 · Answer 2

Solo tu sai quali sono le tue risorse: tempo, mal di testa associati, ecc. Tuttavia, questo è l'approccio che sostengo nel caso generale:

Evita le API deprecate a meno che non ci siano altre alternative e non se ne andranno presto. Potrei nominare diverse API deprecate o altrimenti sfavorite che sono state sedute per circa 10 anni senza piani di rimozione. Android è molto più incline a quelle API deprecate che vanno via, quindi in questo caso evitali come la peste.
A meno che lo spazio non sia davvero un premio (incorporato), perché preoccuparsi a meno che una libreria non sia scandalosamente enorme, come 100 MB? Per inciso, vorrei che ci fosse un modo semplice per sfoltire le librerie in Java / Dalvik come fanno i linker C e C ++.
Preferisci utilizzare un'API integrata quando disponibile: in caso contrario, preferisci utilizzare una libreria di terze parti (preferibilmente libera / open source) se è attivamente mantenuta . Abandonware non aiuta nessuno. Infine, come ultima risorsa, tira il tuo. Lo aprivo e lo mantenevo, che aiuta gli altri e restituisce alla comunità.