Gradle Flavors vs. App Projects

2

Ho ereditato un progetto piuttosto grande e vecchio con un piccolo debito tecnico che è ancora in fase di sviluppo attivo. Un paio di mesi fa abbiamo fatto il salto da Eclipse + Ant ad Android Studio + Gradle. Non ho molta esperienza con Gradle ora e ho avuto molto meno allora, quindi un collega (che sta anche lavorando al progetto ora) mi ha aiutato con il porting.

Il progetto è in realtà 4 app con un paio di librerie parzialmente condivise; per esempio app1 e app2 usano library1, mentre app3 e app4 usano library2 che dipende da library1; e app1 e app3 (ma non 2 e 4) usano library3, ecc. All'inizio app1 e -2 erano praticamente la stessa app con differenze minori (skin), stessa con app3 e -4; gran parte della logica di business è la stessa in tutte e 4 le app, ma nel tempo la funzionalità (livello e caratteristiche dell'interfaccia utente - eccetto la logica aziendale) ha cominciato a divergere sempre di più e oggi ci sono tante differenze quante sono comuni.

Il mio collega ha esercitato pressioni graduali perché questo è il modo in cui è fatto con gradle , ma sono sempre stato scettico: quelli non sono semplici pagati + versioni non pagate o la stessa app con skin differenti 'sta crescendo ulteriormente a parte con ogni mese. Al giorno d'oggi, una funzionalità viene raramente implementata in tutte e quattro le app; di solito solo in uno o due di essi.

In passato, molte funzionalità dell'app-X sono state incorporate nelle librerie con condizionali, che è icky (porta al codice spaghetti), mentre ora provo a spostare le app X solo funzionalità nel sapore di alto livello. Il problema che sto incontrando è che l'IDE e molti strumenti non funzionano bene con gli aromi quando si tratta di analisi e refactoring del codice. Android Lint segna le risorse utilizzate da un diverso sapore in quanto la ricerca inutilizzata, l'utilizzo e la maggior parte degli strumenti di refactoring non funzionano bene oltre i limiti dell'aroma, ... - Sto cambiando un metodo in una libreria condivisa e i sapori inattivi si interrompono senza Protesta contro l'IDE - a meno che non cambi manualmente aromi (o, in pratica, jenkins mi informa di build falliti). Il refactoring è praticamente impossibile al momento, il che non aiuta affatto il debito.

Quindi sto pensando di passare a diversi moduli di app all'interno dello stesso progetto; il mio collega protesta perché è così che è fatto in Eclipse ma non in Android Studio + Gradle e io non sono "averlo" - ma questo è praticamente il suo unico punto.

In realtà non lo capisco o il mio collega abusa del sistema di sapori per qualcosa per cui non è stato progettato? Ci sono dei lati negativi o delle trappole nell'utilizzo di moduli app di alto livello al posto dei sapori?

    
posta stefs 18.08.2015 - 15:47
fonte

0 risposte

Leggi altre domande sui tag