Wie wird mit der Bereitstellung von mobilen Apps mit weißer Beschriftung verfahren?

Question

Ich arbeite an einem Produkt, das in vielen verschiedenen Organisationen eingesetzt werden soll (Ideales Szenario, Dutzende). Jeder Einsatz des Systems (bestehend aus nativen Apps für iOS und Android) wird beinhaltet die folgende:

• Branding-spezifisch für die Organisation (dh eine neue Haut)
• Integration mit dem Authentifizierungssystem und Benutzerdatenbank des Unternehmens
• Einige benutzerdefinierten Funktionen auf die

Mit anderen Worten Bedürfnissen der Organisation abhängig, werden die Kernfunktionalität das gleiche für alle Einsätze bleiben, aber jede Instanz wird anders aussehen, in ein anderen Authentifizierungssysteme Haken und hav e bestimmte Funktionen aktiviert/deaktiviert.

Meine Frage: Was ist die beste Strategie wäre unser 2 Handy Codebases (iOS & Android), um für die Verwaltung von Doppelarbeit und vereinfachen den Bereitstellungsprozess zu minimieren?

Die drei Lösungen wir diskutieren sind:

1. eine Kern-Bibliothek erstellen, die auf allen Instanzen gemeinsam genutzt wird (als Teilprojekt/Bibliotheksprojekt oder ein git-Modul), und fügen Sie eine dünne Ebene oben mit dem Branding und allen Konfigurationsdetails.

2. Pflegen Sie einen Git-Zweig mit der Kernfunktionalität und erstellen Sie einen neuen Zweig für jede Implementierung, die den zusätzlichen Code enthält.

3. Tun Sie etwas völlig anderes, dass eine intelligentere Person auf Stackoverflow suggeriert.

Was klingt am besten für Sie? Vielen Dank im Voraus für jede Rückmeldung !!

Answer 1

Ein Ansatz, den ich betrachten würde, ist Abhängigkeit Injektion.

Wenn Sie auf Android ein Werkzeug zur Abhängigkeitsinjektion verwenden, z. B. Squares Dagger, können Sie einfach eine @Module Klasse erstellen, die Komponenten in Ihre Anwendung einfügt und einfügt. Auf diese Weise können Sie die Logik jedes White-Label-Clients als separate Komponenten verwalten, und zur Kompilierungszeit wird eine bestimmte Komponente über die Referenz in der Klasse ausgewählt.

Dies ist auch eine gute Möglichkeit, Ihre Anwendungen zu testen, und es kann eine Menge Standardcode vermeiden.

Es gibt gute Infos in den folgenden Gesprächen auch von Square gegeben:

Dagger: A Fast Dependency Injector for Android and Java

Engineering Elegance: The Secrets of Square's Stack

iOS ähnliche Frameworks hat, ein Objection zu sein.

Außerhalb der Box Optionen:

Ist es erforderlich, dass der mobile Client direkt auf die White-Label-Servern zu sprechen hat? Wenn nicht, sollten Sie Ihre eigenen Server als Proxy für die White-Label-Server in Betracht ziehen. Dies würde die gesamte Geschäftslogik auf Ihren Server verlagern und alle Ihre Kunden unterstützen.

Ich habe keine Erfahrung damit, aber eine vielversprechende Option ist J2ObjC, die bei Google entwickelt wird.

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

Wir sind in einer ähnlichen Situation sind (wir haben eine Plattform von White-Label-Anwendungen mit bekommen sowohl ein Android und iOS Code-Basis), und wir werden unsere nativen Codebases in einer C# -Implementierung werden übertragen. Wir werden MonoTouch/Mono for Android verwenden. Ich habe gerade angefangen, seit letzter Woche daran zu arbeiten (ich habe ein paar Fragen zu SO gestellt, um einige Mono-Grundlagen auszuarbeiten).

Dies ist effektiv Ihre Option 1, aber jede Plattform wird auf C# -Code aufbauen (mit der Möglichkeit, bei Bedarf mit einer "nativen" Codebasis zu interagieren).

Mono sollte es uns ermöglichen, irgendwo zwischen 30-50% des Codes zwischen Plattformen (derzeit iOS & Android, in der Zukunft vielleicht Windows Phone) zu teilen. Von der kleinen Erfahrung, die ich hatte, scheint die Leistung gut zu sein (denken Sie daran: viele Leute benutzen auch MonoGame, um high-performance games zu erstellen und ich denke, dass Unity auch Mono für 3D-Spiele verwendet). Für mich persönlich ist das ein Mehrwert. Ich würde immer noch gerne Spiele irgendwann machen und einige grundlegende Erfahrungen mit dem Mono-Framework für "seriöse" Apps werden die Grenze für die Nutzung des MonoGame-Frameworks für Spiele-Apps senken.

Das Schöne an diesem Setup ist, dass Sie den gesamten Code (Android, iOS, Windows Phone) in 1 Lösung behalten können. Erstellen Sie ein zentrales "Bibliothek" -Projekt (Modelle, Serviceaufrufe usw.) und erstellen Sie für jede Plattform ein anderes Projekt. Die spezifischen Plattformprojekte haben jeweils geeignete UIs mit einer echten nativen Erfahrung.

Für einen Eindruck, wie Multiplattform-Apps mit Mono, read a small introduction here erstellt werden.

Answer 3

Wenn Sie nicht auf nativen Verwendung GUI abhängig Unity3d, Ihr eigenes Unity-Paket machen mit allen wichtigen Funktionen (und entwickeln sie als einziger App für alle Plattformen), für jeden Einsatz App müssen Sie neues Unity-Projekt machen und Importieren Sie dieses Paket, anpassen Sie es (möglicherweise durch Ressourcen ersetzen und Configs bearbeiten). (Wenn Sie die Kernfunktionalität aktualisieren müssen, müssen Sie einfach die neue Version des Kernpakets erneut in das ausgelieferte Projekt importieren).

Oder nutzen Sie Ihre Option 1:

1. C++ Kernbibliothek
2. Ressourcenpaket, das individuell sein kann für alle Anwendungen ist (möglicherweise autorizations & Module configs auch hier)
3. native UI Realisierung für alle Plattformen Android-Java, iOs-Objective-C