Efektywny projekt dla automatycznej odświeżania aplikacji mobilnej

Question

Zostałem przedstawiony temu problemowi kilka dni temu. Wymagało to zaprojektowania aplikacji mobilnej, która wyświetla treści sportowe użytkownikowi (np. Piłka nożna). Aplikacja pozwoli użytkownikowi na subskrybowanie konkretnego zespołu. Na podstawie wyboru zespołu użytkownika aplikacje wyświetlają tylko treści powiązane z tym zespołem na ekranie głównym użytkownika. Oczywiście użytkownik ma możliwość wyświetlenia treści dla wszystkich zespołów (za pomocą opcji menu).

Szczególny nacisk położono na to, w jaki sposób treść na ekranie głównym użytkownika zostanie automatycznie odświeżona, a także aby uwzględnić fakt, że użytkownik (lub nie) nie zasubskrybował konkretnego zespołu.

na ostatnie pytanie, zasugerowałem 2 następujących rozwiązań:

1) Aplikacja może wysyłać małe żądania do serwera, który będzie zawierał jedynie identyfikator użytkownika, wybór zespołu użytkownika. Na podstawie wyboru zespołu w żądaniu wejściowym serwer zwróciłby tylko zawartość powiązaną z zespołem.

2) Jeśli objętość zawartości jest mniejsza, a liczba odrębnych zespołów jest niewielka, należy przesłać wszystkie informacje i pozwolić aplikacji wykonać niezbędne filtrowanie (oczywiście jest to mniej wydajne niż w przypadku numeru 1).

Udostępnianie tego na forum w celu uzyskania innych możliwych decyzji dotyczących projektu. Jeśli nie jest to właściwe forum, proszę odpowiedzieć w komentarzach, a ja opublikuję odpowiednie forum.

Dzięki

Answer 1

Zdecydowanie opcja 1).

Opracowaliśmy coś podobnego w innej branży, w której użytkownicy są zainteresowani uzyskaniem informacji o stanach różnych zasobów. Architektura wygląda tak:

1. Serwer przechowuje subskrypcje wszystkich użytkowników. To miejsce, gdzie możesz przechowywać rzeczy jak: SubscribedUserId, EventType (wygrana, utrata, numberOfPointsChanged wszyscy, niezależnie od przypadku może być), deliveryChannel (zgłoszenie http, email, powiadomienia Push dla telefonów komórkowych)
2. Ilekroć coś się dzieje z zasobem umieszczamy wiadomość w kolejce. Wiadomość zawiera takie rzeczy jak: teamEventIsFor, subscriberUser, deliveryChannel, deliveryAddress, etc ...
3. oddzielna usługa Windows (s) (taki, który obsługuje wszystkie deliveryTypes [email, http, Push] lub jeden dla każdy kanał) wykorzystują wiadomości w kolejce i dostarczają rzeczywistą treść użytkownikom. W twoim przypadku byłoby to dzięki powiadomieniom push.

Teraz, mając na uwadze, że powiadomienia wypychane nie są gwarantowane (chociaż ogólna cena dostawy jest dość dobra), możesz również wdrożyć pewien rodzaj zasobu http, w którym aplikacja mobilna może od czasu do czasu odpytywać sprawdź, czy są jakieś wiadomości dla tego konkretnego użytkownika (to opcjonalne).

Answer 2

Zasadniczo, jeśli chcesz zrobić system automatycznego odświeżania masz tylko dwie drogi:

1: wniosek (s) klienci wysyłają okresowo.To wystarczy, jeżeli:

1. Interwał odświeżania nie jest zbyt krótki
2. Nie oczekuj działanie aplikacji dla milionów ludzi
3. Computing wynik nie kosztują zbyt wiele

Można to zaimplementować za pomocą zwykłego użycia jakiegoś zapytania na serwerze po stronie bazy danych. Oczywiście, jeśli potrzebujesz więcej wydajności, możesz mieć kilka warstw pośrednich.

2: Pushing wynik z serwerów: to jest nieco trudniejsze do architektury prawidłowo, ale tutaj jest Somme dobre punkty:

• wysyłać tylko nowe dane do klientów
• Wydajność mądry To najlepszy

jednak limity są ważniejsze:

• Podnośniki stracił z połączeniami jest nieco trudniejsze.
• Musisz przechwytywać wszystkie zdarzenia, które aktualizują dane, aby przekazać odświeżenie do klientów.

Ale ponieważ istnieje więcej niż ty, że trzeba to rozwiązanie architure istnieje: jest tu taki, który pasuje najlepiej do ciebie w Javaworld:

JMS: Java Message Service, który jest Message Oriented Middleware (MAMA).

JMS to specyfikacja z inną implementacją, personnaly, którą wybrałbym dla activeMQ, czyli Apache. Tutaj jest wątek o tym: Which JMS implementation do you use?

Jeśli nie/nie może używać JMS wtedy tylko o tym pamiętać: Messare-Oriented Middleware-. Google, które powinno ci pomóc znaleźć to, czego potrzebujesz.

Answer 3

Masz trzecią opcję:

3) Postępować publikowania-subskrybowania wzór.

Aby zaimplementować to, można użyć systemu, takiego jak Amazon Simple Notification Service (SNS). Najpierw musisz skonfigurować aplikację platformy zawierającą klucz API (dla Androida) lub klucz prywatny i certyfikat APNS (dla systemu iOS).

Gdy użytkownik uruchamia aplikację po raz pierwszy, aplikacja poprosi użytkownika o autoryzację dostępu powiadomień push, skontaktuj się z serwerem i wyślij token (który służy do rejestracji punktu końcowego w aplikacji platformy SNS).

Umożliwia to wysyłanie powiadomień push do aplikacji uruchomionej na urządzeniu użytkownika (która może być obsługiwana w trybie cichym lub wyświetlana jako powiadomienie w czasie rzeczywistym o dostępności nowych danych).

Następnie można ustawić tematy dla każdego zespołu, które dany użytkownik może wybrać, aby zapisać się. Gdy użytkownik wybierze zespół, aplikacja wysyła żądanie do serwera, aby zasubskrybować temat, który przekazujesz do AWS przy użyciu interfejsu API. Jeśli użytkownik chce zrezygnować z subskrypcji, ponownie przesyła to żądanie do AWS.

Umożliwia to wysyłanie aktualizacji dla każdego zespołu do odpowiedniego tematu i dystrybuowanie tych informacji - tylko użytkownikom, którzy subskrybują, skalowalnie iw czasie rzeczywistym. Twój serwer będzie musiał tylko raz pingować temat, a AWS będzie obsługiwać dostarczanie do każdego użytkownika.

Oczywiście trzeba będzie zaimplementować logikę, aby obsługiwać powiadomienia, subskrybować, rejestrować itp., Ale umożliwia to użytkownikom otrzymywanie aktualizacji w czasie rzeczywistym.

przeglądając opcje:

1) łatwiejszych do zrealizowania i prawdopodobnie niezbędne dla nowych instalacji, które nie zostały jeszcze zarejestrowane. Będziesz potrzebował tego w taki czy inny sposób, więc polecam najpierw wdrożyć tę metodę. Twoje serwery będą obciążone proporcjonalnie do użytkowników, więc warto rozważyć opcję 3) podczas skalowania (i korzystania z pamięci podręcznej HTTP, takiej jak lakier lub kałamarnica, aby zminimalizować obciążenie komputera i bazy danych).

2) To nie jest konieczne nadawać te informacje wszystkim użytkownikom, ale skutecznie publikuje-subskrybuj z jednym tematem (wszyscy użytkownicy). Bardziej wydajne byłoby powiadamianie tylko użytkowników, którym zależy.

3) Jest to najbardziej skalowalna opcja i ma dodatkową zaletę bycia w czasie rzeczywistym. Będziesz mógł powiadomić użytkownika o aktualizacji, nawet jeśli nie używają jej w tym czasie. W ramach architektury subskrypcji publikacyjnej będziemy mogli powiadomić tylko tych użytkowników, których dotyczą dane, a po aktualizacji można ustawić wartość limitu czasu, która uniemożliwi aktualizację użytkownika z serwera do czasu XX. W ten sposób, jeśli aktualizacje są częstsze niż wartość limitu czasu, użytkownicy nigdy nie będą musieli uderzać serwera.