Come gestire la distribuzione di app per dispositivi mobili con piattaforma bianca?

Question

Sto lavorando a un prodotto che verrà distribuito a molte organizzazioni diverse (scenario ideale, decine). Ogni implementazione del sistema (composto da applicazioni native per iOS e Android) coinvolgerà la seguente:

• Branding specifiche per l'organizzazione (vale a dire una nuova pelle)
• integrazione con il sistema di autenticazione e utente del database dell'organizzazione
• Alcune funzioni personalizzate a seconda delle esigenze dell'organizzazione

In altre parole, le funzionalità di base rimarrà la stessa in tutte le distribuzioni, ma ogni istanza avrà un aspetto diverso, gancio in un diverso sistemi di autenticazione, e hav e alcune funzionalità abilitate/disabilitate.

La mia domanda: Quale sarebbe la migliore strategia per la gestione delle nostre basi di codice 2 mobili (iOS & Android) al fine di minimizzare le duplicazioni e semplificare il processo di distribuzione?

Le tre soluzioni che stiamo discutendo sono:

1. Creare una libreria di base che viene condiviso tra tutte le istanze (come progetto sotto-progetto/biblioteca, o un modulo git), e aggiungere un sottile strato in alto con il marchio e tutti i dettagli di configurazione.

2. Mantenere un ramo Git con la funzionalità di base e creare un nuovo ramo per ogni distribuzione che contiene il codice aggiuntivo.

3. Fai qualcosa di completamente diverso che suggerisca una persona più intelligente sullo stackoverflow.

Quale suona meglio per te? Grazie in anticipo per qualsiasi feedback!!

Answer 1

Un approccio che prenderei in considerazione è l'iniezione di dipendenza .

Su Android, se si utilizza uno strumento di immissione delle dipendenze come Square Dagger, è sufficiente creare una classe @Module che fornisce e introduce i componenti nell'applicazione. In questo modo, è possibile mantenere la logica di ciascun client white-label come componenti separati e, in fase di compilazione, un componente specifico verrà selezionato tramite il riferimento nella classe @Module.

Questo è anche un ottimo modo per testare le vostre applicazioni e può evitare un sacco di codice boilerplate.

C'è grande informazioni nei seguenti discorsi tenuti anche da Square:

Dagger: A Fast Dependency Injector for Android and Java

Engineering Elegance: The Secrets of Square's Stack

iOS ha strutture simili, uno dei quali Objection.

fuori le opzioni di dialogo:

Si tratta di un requisito che il client mobile deve parlare direttamente ai server del white label? In caso contrario, si consiglia di considerare l'utilizzo dei propri server come proxy per i server della white label. Ciò sposterebbe tutta la logica di business sul tuo server, supportando tutti i tuoi clienti.

Non ho alcuna esperienza con questo, ma un'opzione apparentemente promettente è J2ObjC, che è in fase di sviluppo presso Google.

J2ObjC is an open-source command-line tool from Google that translates 
Java code to Objective-C for the iOS (iPhone/iPad) platform. This tool 
enables Java code to be part of an iOS application's build, as no editing 
of the generated files is necessary. The goal is to write an app's non-UI 
code (such as data access, or application logic) in Java, which is then 
shared by web apps (using GWT), Android apps, and iOS apps. 

Answer 2

Siamo in una situazione simile (Abbiamo una piattaforma di applicazioni Whitelabel sia con una base di codice Android e iOS) e saremo trasferire le nostre basi di codice nativo per un'implementazione C#. Faremo uso di MonoTouch/Mono for Android. In realtà ho appena iniziato a lavorare su questo dalla scorsa settimana (ho fatto alcune domande su SO per capire alcuni nozioni di base Mono).

Questa è effettivamente la tua opzione 1, ma ogni piattaforma sarà costruita sul codice C# (con possibilità di interagire con una base di codici "nativa" se necessario).

Mono dovrebbe consentire di condividere da qualche parte tra il 30-50% del codice tra piattaforme (attualmente iOS & Android, in futuro forse Windows Phone). Dalla piccola esperienza che ho avuto, sembra che le prestazioni siano buone (ricorda: molte persone usano anche MonoGame per creare high-performance games e penso che Unity utilizzi anche Mono per i giochi 3D). Per me personalmente questo è un valore aggiunto. Mi piacerebbe ancora creare dei giochi un giorno e alcune esperienze di base con il framework Mono per app "gravi" abbasseranno la barriera per utilizzare il framework MonoGame per le app di gioco.

La cosa bella di questa configurazione è che è possibile mantenere tutto il codice (Android, iOS, Windows Phone) in 1 soluzione. Creare un progetto "biblioteca" di base (modelli, chiamate di servizio, ecc.) E creare un altro progetto per ciascuna piattaforma. I progetti specifici della piattaforma avranno ciascuno delle interfacce utente appropriate con una vera esperienza nativa.

Per un'impressione su come creare app multipiattaforma con Mono, read a small introduction here.

Answer 3

Se non si dipende da uso GUI nativa Unity3d, fare il vostro proprio l'Unità Pacchetto con tutte le funzionalità principali (e svilupparla come singola applicazione per tutte le piattaforme), per qualsiasi applicazione di distribuzione che si dovrà fare nuovo progetto l'Unità e la importa questo pacchetto, personalizzalo (potrebbe essere sostituito da risorse e modifica configurazioni). (se è necessario aggiornare la funzionalità di base, sarà necessario importare semplicemente la nuova versione del pacchetto principale di nuovo nel progetto consegnato).

Oppure utilizzare l'opzione 1:

1. libreria di base C++
2. pacchetto di risorse che è può essere individuale per tutte le applicazioni (potrebbe essere le autorizzazioni dell'utente & moduli configurazioni essere anche qui)
3. nativo realizzazione dell'interfaccia utente per tutte le piattaforme Android-Java, iOs-Objective-C