22

Rozwijam system czatowy dla stron internetowych, Androida i iOS. Przeprowadzając moje badania odkryłem różnice w sposobie obsługi GCM i APNS w powiadomieniach push.Powiadomienia push lub Socket.io ?, lub oba?

Jeśli wyślę powiadomienie push do urządzenia z systemem Android za pomocą GCM, urządzenie może zdecydować, czy powiadamia o tym użytkownika, lub czy nie jest to konieczne, nie informuje użytkownika. Może to być po prostu aktualizacja danych, której użytkownik nie musi otrzymywać. Z drugiej strony, jeśli wyślę powiadomienie push do urządzenia iOS za pośrednictwem APNS, urządzenie nie będzie mogło zdecydować, czy wyświetlić powiadomienie, czy nie, powiadomienie musi zostać wyświetlone. Ponadto, gdy urządzenie iOS otrzymuje powiadomienie, dane powiadomienia muszą zawierać ciąg znaków, który zostanie wyświetlony użytkownikowi. W systemie Android urządzenie może wygenerować ten ciąg.

Tak więc chciałem stworzyć system działający w ten sam sposób zarówno dla systemu iOS, jak i Androida, a także dla strony internetowej (opartej na interfejsie API). Tak było, gdy znalazłem Socket.io. Socket.io daje mi swobodę wysyłania danych do urządzenia (bez względu na to, czy jest to system iOS czy Android), dzięki czemu urządzenie decyduje, czy wyświetlić zmiany, czy też nie (może to być aktualizacja użytkownika, nowa wiadomość, zaproszenie lub wiele innych "zdarzeń"). Ale robiąc moje badania znalazłem kilka wad dotyczących używania Socket.io. Urządzenie musi być podłączone do gniazda tak, aby informacje przepływały między klientem a serwerem, ale smartfon w świecie rzeczywistym łączy się i rozłącza cały czas z różnymi sieciami, co powoduje przerwanie połączenia z gniazdem. Ponadto, mając otwarte połączenie, w tle znajduje się ping pong pomiędzy serwerem a klientem, aby sprawdzić, czy połączenie jest nadal otwarte, a to kończy się na zużywaniu megas (w moim kraju płacimy za każdy mega, którego używamy , nie mamy jeszcze stawki ryczałtowej), a także żywotność baterii. Nie wiem na pewno, czy to zużycie jest znaczące czy nie.

Po stronie internetowej musi działać z Socket.io, więc nie stanowi to żadnego problemu.

Wreszcie, znając plusy i minusy obu alternatyw, stwierdziłem, że mogę połączyć obie opcje, co może okazać się najlepszą opcją. Na przykład, gdy aplikacja jest otwarta, używa Socket.io, a gdy jest zamknięta, korzysta z APNS lub GCM (w zależności od systemu operacyjnego urządzenia). Ale czy to dobra praktyka? A może lepiej będzie trzymać tylko jedno rozwiązanie zamiast mieszać je i dlaczego?

Bardzo dziękuję za poświęcenie czasu na przeczytanie tego, a nawet więcej za udzielenie odpowiedzi.

+2

To jest świetne pytanie, ponieważ tutaj musi być równowaga. Zainteresowałem się po przeczytaniu tego, ponieważ teraz buduję powiadomienia w aplikacji. Będę używał node.js socket.io, aby najpierw wykryć, czy są one online. Jeśli tak, użyj socket.io, aby powiadomić, a następnie użyj powiadomień dla Androida/ios. Dzięki! –

+0

@PDK skończyłeś używać obu? – ralphgabb

+1

@ralphspoon Musiałem użyć obu, jest najlepszym sposobem, jeśli chcesz zrobić to, co trzeba. Ale na koniec, bałagan obsługiwał system, więc w końcu przeprowadziłem się do Firebase. – PDK

Odpowiedz

8

Podałeś dokładnie wszystkie za i przeciw. Korzystanie z obu zapewni więcej pracy w zakresie konserwacji, a także większą złożoność, ale zapewni elastyczność, której szukasz. Sprowadzi się to do twoich wymagań.

Prawdopodobnie będzie również problematyczne, że otwarcie połączenia socket.io w procesie w tle iOS będzie kłopotliwe. iOS jest znacznie bardziej restrykcyjny w zadaniach, które mogą działać w tle niż Android.

+0

Dzięki za odpowiedź, dobrze jest usłyszeć, że zmierzam we właściwym kierunku. – PDK