Ich habe zwei Implementierungen zum Synchronisieren von Daten zwischen dem Server und dem Client auf den meisten Apps gesehen. Dies setzt voraus, dass kein GCM eingerichtet ist:
Welche der oben genannten Optionen würden Sie in Ihrer App empfehlen und warum?
Antworten:
Hinweis: Synchronisierungsadapter werden asynchron ausgeführt. Sie sollten sie daher mit der Erwartung verwenden, dass sie Daten regelmäßig und effizient übertragen, jedoch nicht sofort. Wenn Sie Daten in Echtzeit übertragen müssen, sollten Sie dies in einer AsyncTask oder einem IntentService tun. - Quelle .
Wenn Sie eine Echtzeitübertragung benötigen, verwenden Sie grundsätzlich IntentService (die erste Option), andernfalls SyncAdapter. Ich bevorzuge einen IntentService, weil er sich anpassbarer anfühlt, aber ein trivialerer Ansatz wäre die Verwendung eines SyncAdapters.
Es hängt stark davon ab, welche Art von Synchronisierung Sie benötigen.
Wenn es sich bei Ihrer App um eine Nachrichten-App handelt, die jeden Tag zu einer bestimmten Zeit Beiträge veröffentlicht (z. B. täglich um 7.45 Uhr), führen Sie eine regelmäßige Aufgabe in einem Hintergrunddienst aus, z. B. um 8 Uhr.
zB : Drippler. Sie benachrichtigen mich jeden Tag einmal (gegen 18.30 Uhr). Ich glaube, sie verwenden eine periodische Aufgabe.
Wenn Ihre Datenübertragung durch eine Benutzeraktion ausgelöst wird, verwenden Sie einen Hintergrunddienst oder eine AsyncTask für die Datenübertragung.
zB : DropBox / Evernote. Sie werden synchronisiert, wenn ich mit der App interagiere.
Wenn Ihre App Instant Messaging / E-Mails / nicht regelmäßige wichtige Updates ausführt, benötigen Sie Push-Benachrichtigungen, da Sie den Benutzer sofort benachrichtigen möchten. Verwenden Sie für diesen Fall entweder GCM oder Parse. zB: WhatsApp / Google Chat. Da Sie explizit die Sie erwähnt nicht wollen , zu verwenden GCM, werde ich sagen , warum Sie sollten einen Standard - Push - Benachrichtigung - Provider statt Ihre eigene Schreibweise verwenden:
Push-Benachrichtigungen funktionieren sofort - es gibt nur eine sehr geringe Verzögerung (in der Größenordnung von Sekunden, selten Minuten). Wenn Sie dazu Ihre eigene Lösung / Bibliothek implementieren würden - in einem naiven Modell würden Sie den Server alle Sekunden, 5 Sekunden oder eine Minute anpingen, um den Status zu überprüfen. Dies ist sehr ineffizient, da die CPU (und damit der Akku), die Bandbreite auf dem Mobiltelefon und die Last auf Ihrem Server verbraucht werden. In GCM / Parse bleibt jedoch immer ein Port zum Server offen (siehe hier ). Dies ist der Standard und effizienteste Weg. Wenn 10 Apps GCM verwenden, benötigen Sie keine 10 offenen Verbindungen, sondern nur eine pro Gerät. Und Sie möchten wirklich keine eigene Lösung entwickeln, es sei denn, Sie haben einen gültigen Grund / Geld / Zeit dafür.
Hinweis zum Synchronisationsadapter : Der Synchronisationsadapter funktioniert in allen drei oben genannten Fällen einwandfrei. Wenn Sie das Kontrollkästchen " Synchronisierungsadapter ausführen" aktivieren , wird angezeigt, dass dies entweder von GCM oder Ihrem eigenen Mechanismus (Ereignisauslöser oder benutzerdefinierte Lösung) oder der Netzwerkverfügbarkeit (Ereignisauslöser) oder einem periodischen Ereignis abhängt. Alles in allem ist dies eine gute praktische Klasse, um Daten zu synchronisieren, ohne jedes Mal eine lange Liste von Initialisierungen durchführen zu müssen oder alle oben genannten Fälle an einem Ort zu implementieren.
Es gibt einen Aspekt von a SyncAdapter, der in den anderen Antworten nicht erwähnt wurde.
Das SyncAdapterMuster erfordert, dass Sie über eine bestimmte ContentProvider- Berechtigung verfügen , mit der Sie synchronisieren, und über einen bestimmten Kontotyp (siehe Authenticator ), der synchronisiert werden soll. Wenn Sie diese Komponenten nicht bereits in Ihrer Architektur haben (z. B. weil Sie anderen Apps Zugriff auf Ihre Daten gewähren oder Konten unterstützen müssen) SyncAdapter, verursacht dies einen erheblichen Implementierungsaufwand.
Wenn es um das Synchronisieren von Daten mit Konnektivität geht, möchten Sie auch skalieren können. Ich glaube, die empfohlene Vorgehensweise ist die Verwendung des Sync-Adapters.
Dies scheint auch der Fall zu sein, wenn Sie sich die Android-Trainingsanleitung ansehen: Erstellen eines Synchronisationsadapters
Die Synchronisierungsadapterkomponente in Ihrer App kapselt den Code für die Aufgaben, die Daten zwischen dem Gerät und einem Server übertragen. Basierend auf den von Ihnen in Ihrer App bereitgestellten Zeitplänen und Triggern führt das Synchronisationsadapter-Framework den Code in der Synchronisationsadapter-Komponente aus.
Synchronisierungsadapter sollten verwendet werden, es sei denn, Sie benötigen Echtzeitdaten, da sie die Datenübertragung anhand verschiedener Kriterien wie Datenänderungen, abgelaufene Zeit, Tageszeit usw. automatisieren. Sie zentralisieren alle Datenübertragungen, sodass die Datenübertragung in Verbindung mit erfolgt Datenübertragungen von anderen Apps, wodurch der Akkuverbrauch verringert wird.
Für sofortige Aufgaben können wir verwenden,
AsyncTask für Aufgaben mit kurzer Dauer kann 3-4 Sekunden betragen.
IntentService für lange laufende Aufgaben.
Da es sich um Design handelt, sollten wir die Verwaltung von SyncAdapters, das SyncResult-Objekt und die weiteren Vorgänge erwähnen.
Ich verwende tatsächlich einen SyncAdapter, um meiner Bibliothek mitzuteilen, dass sie IntentService-Webanrufe an meinen Server tätigen soll. Das Verwalten dieser "Synchronisierungs" -Operation ist schwierig.
Ein Ansatz, den ich jetzt verfolge, besteht darin, auf das SyncResult-Objekt vollständig zu verzichten und einfach einen Dienst zu verwenden, um die Ergebnisse jeder einzelnen "Synchronisierung" zu protokollieren.