W przeszłości był offline, a dziś jest koniecznością. Przynajmniej dla współczesnego świata biznesu. Prezentacje produktów i usług marki, zamawianie i dostawa online, utrzymywanie bazy klientów, komunikacja z klientami i wiele więcej - wszystko to jest po prostu niemożliwe bez obecności w Internecie. Jeśli potrzebujesz aplikacji, musisz mieć zarówno Front-end (interfejs internetowy), jak i Back-End (zaplecze aplikacji). A jeśli chcesz mieć możliwość edycji zawartości swojej aplikacji bez udziału programistów, potrzebujesz dobrego panelu administracyjnego.
Podczas gdy Front-end w aplikacjach mobilnych jest tworzony przy użyciu technologii takich jak X-Code i Java, Back-end, w którym będzie przechowywana baza danych i cała logika aplikacji, wymaga profesjonalnej znajomości języka programowania po stronie serwera. Dobrym przykładem jest PHP, który jest prawdopodobnie najpopularniejszym językiem programowania używanym w prawie każdym programowaniu po stronie serwera. To niekwestionowany lider.
PHP ma wiele zastosowań: statyczne i dynamiczne strony internetowe + niestandardowe systemy zarządzania treścią, media społecznościowe, specjalistyczne systemy CRM, oprogramowanie e-commerce i wiele innych. Oczywiście są darmowe lub tanie części do serwerów i paneli sterowania. Jednak w wielu przypadkach nie zapewniają one wymaganego poziomu wygody, możliwości dostosowywania i aktualizacji.
Nasi programiści pracują z technologiami, aby wdrażać szeroką gamę rozwiązań dla różnych celów biznesowych, potrzeb i wymagań. Analizujemy wymagania systemowe dla każdego projektu indywidualnie i stosujemy różne specjalistyczne oprogramowanie serwerowe w celu optymalnego działania Twojej aplikacji mobilnej.
Jeśli szukasz zespołu, który poprowadzi Cię do najmądrzejszego i najbardziej opłacalnego rozwiązania do tworzenia aplikacji od podstaw lub przebudowy istniejącej w celu zapewnienia doskonałego doświadczenia użytkownika, nie musisz już szukać. Appsmob jest gotowy, aby pomóc Ci znaleźć najlepsze rozwiązanie dla Ciebie.
Rozwój aplikacji po stronie serwera
Wprowadzenie
Obecność w Internecie stała się koniecznością dla dzisiejszych firm. Bez tego niemożliwe jest zbudowanie pełnoprawnej interakcji z klientami. Często, aby rozwiązać taki problem, uciekają się do tworzenia aplikacji klient-serwer. Każdy z nich składa się ze strony klienta i zaplecza. Ostatni termin odnosi się do strony serwera aplikacji. Jeśli w przyszłości zajdzie potrzeba samodzielnej zmiany zawartości programu mobilnego, to Back-end powinien być stworzony w szczególnie wysokiej jakości. Appomart gwarantuje wykonanie powierzonych zadań zgodnie z wymaganiami. Dlatego zlecając tworzenie aplikacji serwerowych możesz być pewien prawidłowego wyniku.
Do czego służy zaplecze?
Tworzenie aplikacji klient-serwer obejmuje dwie części. Pierwszy, Front-end, akceptuje żądania od użytkowników. Jest to widoczne z ekranów urządzeń mobilnych klientów. Druga aplikacja serwerowa przetwarza otrzymane żądania i pełni rolę panelu administracyjnego. Tutaj przechowywane są bazy danych, logika programu. Bez tego żadna aplikacja typu klient-serwer nie będzie działać. W rzeczywistości Back-end jest sercem programu. To inteligencja odpowiada za przetwarzanie żądań klientów, szybkość aplikacji. Dlatego ważne jest, aby architektura aplikacji serwerowej była przemyślana w najdrobniejszych szczegółach, tak aby nawet mocno obciążone usługi działały sprawnie i szybko.
Jak wybrać język programowania?
Podczas przygotowywania zlecenia technicznego (części dokumentacji roboczej do projektu) architekt projektuje system bazodanowy i łącza, opisuje obiekty i ich właściwości, a także opracowuje niezbędne metody serwerowe (żądania, które będą „wykorzystywane” przez aplikacje mobilne odwołujące się do serwera).
Znaczenie dokumentacji i porzuconych projektów
Do Appomart często zwracają się klienci, którzy z różnych powodów zostali porzuceni przez innych kontrahentów. A my bierzemy czyjś, czasem nawet nieprawidłowo działający projekt, przeprowadzamy jego audyt, a następnie weryfikujemy i wspieramy. W trakcie badania kodu źródłowego i materiałów otrzymanych od klienta mamy do czynienia z faktem, że wielu programistów celowo nie dokumentuje metod serwerowych w celu związania klienta ze sobą, ze względu na niewspółmierne koszty pracy przeniesienia projektu do obsługi innego dewelopera, ze względu na brak dokumentacji po stronie serwera a czasami tylko z powodu braku profesjonalizmu. Fakt ten jest niestety nie tylko smutny, ale i powszechny. Klient w tym przypadku musi zapłacić za opracowanie dokumentacji do istniejącego projektu, a także za audyt kodu źródłowego, zanim będzie można ocenić wydajność, wygodę i celowość wsparcia projektu. Pracownicy Appomart zawsze utrzymują elektroniczną dokumentację metod zaplecza w formacie obsługiwanym przez Postman i Swagger do wykorzystania w przyszłości.
Jak sprawdzić wykonawcę przed podpisaniem umowy?
Zachęcamy do starannego wyboru wykonawcy i skupienia się nie tylko na kuszącej cenie, ale także na liście dokumentów, które otrzymasz wraz z projektem, a także na warunkach przeniesienia kodu źródłowego, a także objęcie kodu komentarzami, schematy bazodanowe (czy to Mongo DB czy MySQL ). Kluczem do sukcesu z reguły staje się kompetentna dokumentacja robocza, która jasno wskazuje wymagania dotyczące materiałów przekazanych Tobie po zakończeniu każdego etapu pracy.
Funkcje programistyczne
PHP po stronie serwera
Tworzenie aplikacji po stronie serwera (nie mylić z serwerami jako „sprzętem” czy komputerami, bo mówimy o stronie oprogramowania) wymaga określonych umiejętności zawodowych i znajomości języka programowania, który jest używany po stronie serwera. Jeśli spojrzysz na przykłady aplikacji klient-serwer, zobaczysz, że PHP jest popularne. Jest niekwestionowanym liderem w tworzeniu aplikacji serwerowych. Ponad połowa witryn na świecie jest napisana w tym języku w takiej czy innej konfiguracji. PHP jest łatwe w tworzeniu i utrzymaniu, a istnieją specjalne ramy przyspieszające rozwój PHP.
Struktura
Framework (platforma programowa) - służy do organizowania i zwiększania poziomów abstrakcji, co czyni projekt bardziej elastycznym i skalowalnym. Należy jednak rozumieć, że ramy muszą być wybrane poprawnie, na podstawie dogłębnej analizy dokumentacji roboczej projektu, bez której niemożliwe jest opracowanie produktu wysokiej jakości.
Delphi, JAVA, Python
Istnieją inne języki, które są używane do tworzenia zaplecza. Dlatego aplikacje serwerowe tworzone w środowisku Delphi są szeroko rozpowszechnione. Z jego pomocą program otrzymuje ulepszone debugowanie, łatwo jest też tworzyć unikalne programy w środowisku, zapewniona jest kreacja wizualna, która umożliwia stworzenie pięknego, zrozumiałego i wygodnego interfejsu. Popularność zyskały również aplikacje serwerowe Java. Można je łatwo uzupełnić, łatwo wykonać na dowolnej platformie i mają przyzwoity poziom bezpieczeństwa. Python to kolejny popularny język. Z jego pomocą aplikacje serwerowe powstają szybko, prosto, bez poważnych kosztów.
Rozpowszechnianie się
Tworzenie aplikacji klient-serwer jest pożądane w środowisku korporacyjnym. Często takie programy są wykorzystywane do grup roboczych lub tworzenia systemów informatycznych w przedsiębiorstwie. Zdecydowana większość aplikacji mobilnych do utrzymywania komunikacji z klientem również ma podobną architekturę. Popularność wynika z faktu, że wykorzystanie możliwości serwera pozwala zapewnić kontrolę i integralność systemu, przy jednoczesnym zmniejszeniu obciążenia sieci.
Stworzymy aplikację klient-serwer na Androida, iOS w wysokiej jakości i na czas
Rozwój pod klucz
Programiści Appomart są doświadczeni i wykwalifikowani do obsługi zadań na różnych poziomach. Równie dobrze radzimy sobie z wdrażaniem portali społecznościowych, intensywnymi projektami biznesowymi czy oprogramowaniem dla małych startupów. W razie potrzeby stworzymy kliencką część aplikacji z systemem Android, iOS zgodnie z istniejącymi potrzebami i wymaganiami.
Back-end w Appomart
Nasi programiści pracują z różnymi technologiami i robią to równie dobrze. W Appomart możesz zamówić aplikację klient-serwer w Javie, PHP i Node.JS. Wymagania systemowe są analizowane indywidualnie dla każdego projektu, aby zapewnić optymalne działanie programu. Stwórzmy od podstaw aplikację klient-serwer w językach Java, PHP i Node.JS lub weźmy istniejącą do obsługi ulepszeń i aktualizacji. Jeśli jesteś zainteresowany opracowaniem nowej części serwerowej lub wsparciem już istniejącej - zostaw prośbę o szczegółową kalkulację kosztów pracy i możliwości współpracy.
Wadą klientów mobilnych jest serwer.
Dodatkowe wymagania zależą od specyfiki aplikacji:
skalowalność serwera - dla SaaS, aplikacji społecznościowych, gdzie w idealnym przypadku spodziewany jest duży przepływ odwiedzających, warunek ten jest obowiązkowy. W przypadku aplikacji biznesowych, w których istnieją ograniczenia dotyczące liczby użytkowników lub przewidywana liczba użytkowników, ta właściwość nie jest wymagana;
interaktywność: szereg aplikacji należy wyposażyć w mechanizm powiadamiania - poinformuj aplikację (użytkownika) o wystąpieniu określonych zdarzeń, wyślij wiadomość do użytkownika. Majątek ten powinien posiadać np. Centrala telefoniczna lub automatyczny dyspozytor taksówek.
otwarte API: zakłada się, że zewnętrzni programiści mogą korzystać z funkcjonalności systemu za pośrednictwem udokumentowanego protokołu. W końcu klient może być aplikacją mobilną lub zewnętrzną aplikacją serwerową.
inne wymagania ...
Komenda
W idealnym przypadku skład zespołu projektowego ds. Rozwoju systemu mógłby wyglądać następująco:kierownik projektu: zarządza projektem, kontroluje go, współpracuje bezpośrednio z klientem;
programista aplikacji serwerowych: opracowuje serwer logiki biznesowej, bazę danych, protokół sieciowy;
programista aplikacji administratora: opracowuje aplikację internetową, interfejs użytkownika do konfigurowania i zarządzania aplikacją serwerową;
programista aplikacji klienckich na Androida;
Programista aplikacji klienckich iOS;
programista aplikacji klienckich na ...
tester: testuje aplikację administratora i aplikacje klienckie.
Uważny czytelnik zauważy, że pisząc aplikację serwerową z interfejsem graficznym, na przykład w HTML5, można zaoszczędzić pieniądze. W tym przypadku tworzenie aplikacji klienckich nie jest wymagane - przeglądarka zapewnia interfejs użytkownika. Ten artykuł nie dotyczy takiego przypadku, dotyczy tworzenia „natywnych” (natywnych) aplikacji na urządzenia mobilne.
Pracowałem w zespole z pełnym personelem, ale będę realistą - nie zawsze zasoby ludzkie i budżet pozwalają na takie zgromadzenie. Czasami role trzeba łączyć: kierownik projektu + programista aplikacji serwerowej, programista aplikacji klienckiej + tester.
Technologie, narzędzia, biblioteki
Aby opracować serwer dla klientów mobilnych, zwykle używam następującego zestawu „bezpłatnych” technologii:Apache Tomcat to kontener serwletów;
MySQL - DBMS;
Subversion to system kontroli wersji;
Maven - framework do automatyzacji kompilacji projektów;
JUnit - zapewni;
Apache Log4j - biblioteka logowania;
Jenkins - system ciągłej integracji;
Hibernate - ORM (ustawienia, konfiguracja we właściwościach, pliki xml i adnotacje);
hibernate-generic-dao - implementacja DAO od Google, implementuje podstawowe metody pracy z danymi bazy danych, upraszcza implementację filtrowania i sortowania w metodach;
- implementacja uwierzytelniania i autoryzacji (bezpieczeństwo), kontener usług i beanów (konfiguracja w plikach xml oraz w adnotacjach), używamy również przy tworzeniu testów.
W zależności od specyfiki systemu i wymagań stawianych mu stosuję jedną z 2 opcji implementacji protokołu wymiany danych.
Gdy wymagana jest wieloplatformowość, szybkość, prostota, wydajność, skalowalność, otwarte API, wybieram Jersey - implementację usług REST Web Services (RESTful Web Services). Ta biblioteka umożliwia korzystanie z serializacji danych JSON i / lub XML. Konfiguracja REST odbywa się za pomocą adnotacji. Do wymiany z urządzeniami mobilnymi przyjęto format JSON ze względu na to, że ma prostszą implementację po stronie klienta (z tego powodu nie korzystamy z „klasycznych” serwisów WWW), generowany jest mniejszy ruch. Jersey umożliwia dostrojenie się do najbardziej odpowiedniego „wyglądu” formatu JSON.
W przeciwnym razie, jeśli potrzebujesz wieloplatformowości, wysokiej wydajności, prostoty, wydajności, interaktywności, to biorę
Apache MINA to framework do budowy aplikacji sieciowych,
Google protobuf to biblioteka do kodowania i dekodowania danych strukturalnych. Strukturę danych określają pliki nagłówkowe * .proto, kompilator generuje z nich klasy Java (istnieje również możliwość generowania dla innych języków programowania: C ++, Objective-C itp., Co zapewnia właściwość międzyplatformową);
java.util.concurrent - używamy standardowego pakietu.
Tę opcję można skalować, ale należy to określić na etapie projektowania na poziomie architektury, biorąc pod uwagę logikę biznesową.
Rozważmy hipotetyczne zadanie na przykładzie doboru technologii do prawdziwej usługi SaaS - „Aukcja usług„ Auknem ”, która pozwala ludziom złożyć zamówienie na wykonanie wymaganych usług lub robót, a organizacje z kolei pozostawiają im swoje propozycje. Domyślnie przyjmujemy wszystkie podstawowe wymagania. W związku z tym, że rejestracja w tym systemie jest bezpłatna i bezpłatna, zdecydowanie konieczne jest dodanie do nich skalowalności. A co z interaktywnością? Byłoby wspaniale informować wykonawców (wykonawców) o powstaniu nowych zamówień, a także informować klientów o ofertach otrzymanych w tym samym momencie w aplikacji, a nie tylko drogą mailową. Na tej podstawie podejmujemy się wdrożenia Apache MINA, Google protobuf. Patrzymy na następną właściwość - otwarte API. Usługa jest publicznie dostępna, załóżmy więc, że integracją z nią mogą być zainteresowani zewnętrzni programiści. Czekać! Nie takie proste. Protokół oparty na Apache MINA jest dość zależny od implementacji, a integracja bez znajomości niuansów w żadnym wypadku nie jest przejrzysta. W takiej sytuacji będziesz musiał zważyć, który czynnik jest ważniejszy i dokonać wyboru.
Wniosek
Chciałbym wiedzieć, z jakich technologii, bibliotek korzystaliście przy tworzeniu serwera na urządzenia mobilne lub podobne systemy? Wszystko się zmienia, nic nie trwa wiecznie, na każdym poziomie są alternatywy z własnymi zaletami i wadami: MySQL -Wiele z nowoczesnych aplikacje na platformy mobilne (iOS, Android itp.) działa w tandemie z serwerem. Aplikacja z nieaktualnymi danymi traci swoją użyteczność. Dlatego ważne jest, aby zapewnić ciągłą aktualizację danych z serwera do urządzenia. Dotyczy to aplikacji offline, które powinny działać bez internetu. W przypadku aplikacji całkowicie online, które nie działają (lub są bezużyteczne) bez Internetu (na przykład Foursquare, Facebook), istnieją specyfiki, które wykraczają poza zakres tego artykułu.
Na przykładzie jednej z naszych aplikacji offline opowiem Ci, jakie podejścia zastosowaliśmy do synchronizacji danych. W pierwszych wersjach rozwinęliśmy się proste algorytmy, aw przyszłości wraz z doświadczeniem ulepszyliśmy je. Podobna kolejność została przedstawiona w artykule - od prostych oczywistych praktyk do bardziej złożonych.
Należy wyjaśnić, że artykuł dotyczy przesyłania danych tylko w jednym kierunku: z serwera do urządzenia. Tutaj serwer jest źródłem danych.
Przepisy ogólne dla wszystkich podejść
Na przykład rozważymy przeniesienie katalogu „potrawy” na urządzenie. Przyjmiemy, że urządzenie zgłasza żądanie adresu url „/ serwis / dania / aktualizacja”, wymiana odbywa się poprzez protokół http w formacie JSON ( www.json.org). Serwer posiada tabelę „dania” z następującymi polami: id (identyfikator rekordu), nazwa (nazwa dania), zaktualizowana (w momencie aktualizacji potrawy lepiej jest od razu obsługiwać strefę czasową, „RRRR-MM-DDTgg: mm: ssTZD”, na przykład „1997 -07-16T19: 20: 30 + 01: 00 ”), is_deleted (znak usuniętego wpisu).
Uwaga dotycząca obecności ostatniego pola. Domyślnie jego wartość wynosi 0. W aplikacji, w której jednostki są synchronizowane między klientem a serwerem, nie zaleca się fizycznego usuwania danych z serwera (aby uniknąć błędów). Dlatego dla usuniętych potraw ustawiana jest is_deleted \u003d 1. Gdy jednostka z is_deleted \u003d 1 dociera do urządzenia, jest usuwana z urządzenia.
W każdym podejściu, które zostanie rozważone poniżej, serwer zwraca tablicę obiektów do urządzeń JSON (może być pusta):
[
(ID:
]
Przykład odpowiedzi serwera:
[
(id: 5625, nazwa: „Chleb”, aktualizacja: „2013-01-06 06:23:12”, isDeleted: 0),
(id: 23, nazwa: „Gotowana semolina”, aktualizacja: „2013-02-01 14:44:21”, isDeleted: 0), (
nazwa: "Zupa rybna",
aktualizacja: "2013-08-02 07:05:19",
Zasady aktualizacji danych na urządzeniu
- Jeśli przybył element znajdujący się na urządzeniu i maDeleted \u003d 0, jest aktualizowany
- Jeśli przyszedł element, którego nie ma na urządzeniu i maDeleted \u003d 0, to jest dodawany
- Jeśli przyszedł element znajdujący się na urządzeniu i maDeleted \u003d 1, to jest usuwany
- Jeśli przybył element, którego nie ma na urządzeniu i maDeleted \u003d 1, nic nie jest wykonywane
Podejście 1: Zawsze synchronizuj wszystko
To najłatwiejsza metoda. Urządzenie żąda listy potraw z serwera, a serwer wysyła całą listę. Za każdym razem pojawia się cała lista. Niesortowane.
Przykładowe żądanie: null lub „()”
Zalety:
- logika na serwerze jest prosta - zawsze dajemy z siebie wszystko
- logika na urządzeniu jest prosta - zawsze wszystko nadpisujemy
Niedogodności:
- jeśli często żądasz listy (co 10 minut), ruch internetowy będzie duży
- jeśli lista jest wymagana rzadko (raz dziennie), istotność danych zostanie naruszona
Obszar zastosowań:
- do zastosowań o małym natężeniu ruchu
- transmisja bardzo rzadko zmieniających się danych (lista miast, kategorie)
- przeniesienie ustawień aplikacji
- na początku realizacji projektu pierwszego prototypu aplikacji mobilnej
Podejście 2: synchronizuj tylko zaktualizowane
Urządzenie żąda listy potraw zaktualizowanej z poprzedniej synchronizacji. Lista jest posortowana według „zaktualizowanych” w porządku rosnącym (opcjonalne, ale wygodne). Urządzenie zapamiętuje wartość „updated” dla ostatnio wysłanej anteny i przy kolejnym żądaniu wysyła ją do serwera w parametrze „lastUpdated”. Serwer wysyła listę potraw, które są nowsze niż „lastUpdated” (updated\u003e lastUpdated). Przy pierwszym żądaniu do serwera „lastUpdated” \u003d null.
Przykładowe żądanie: (lastUpdated: „2013-01-01 00:00:00”)
Na schemacie: „last_updated” to wartość, która jest przechowywana na urządzeniu. Zwykle na urządzeniu tworzona jest osobna tabela do przechowywania tych „ostatnich_aktualizowanych” wartości dla każdej jednostki (dania, miasta, organizacji itp.)
To podejście jest odpowiednie do synchronizowania prostych list liniowych, w których reguły przybycia są takie same dla wszystkich urządzeń. Aby uzyskać bardziej selektywną synchronizację, zobacz „Podejście 5: Synchronizuj ze znajomością tego, co jest już na urządzeniu”.
Takie podejście zwykle pokrywa większość potrzeb. Do urządzenia docierają tylko nowe dane, synchronizację można przeprowadzić przynajmniej co minutę - ruch będzie niewielki. Istnieją jednak problemy związane z ograniczeniami urządzeń mobilnych. Są to pamięć i procesor.
Podejście 3: Synchronizuj partiami
Na urządzeniach mobilnych brakuje pamięci RAM. Jeśli w katalogu znajduje się 3000 potraw, analiza dużego ciągu json z serwera na obiekty na urządzeniu może spowodować brak pamięci. W takim przypadku aplikacja ulegnie awarii lub nie zapisze tych 3000 potraw. Ale nawet gdyby urządzenie potrafiło przetrawić taki ciąg, to wydajność aplikacji w momentach synchronizacji w tle będzie niska (opóźnienia interfejsu, nie płynne przewijanie itp.) Dlatego konieczne jest żądanie listy w mniejszych porcjach.
W tym celu urządzenie przekazuje kolejny parametr („kwota”), który określa wielkość porcji. Listę należy przesłać posortowaną według pola „zaktualizowane” w kolejności rosnącej. Urządzenie, podobnie jak w poprzednim podejściu, zapamiętuje „zaktualizowaną” wartość ostatnio wysłanej jednostki i przekazuje ją do pola „lastUpdated”. Jeśli serwer wysłał dokładnie taką samą liczbę obiektów, urządzenie kontynuuje synchronizację i ponownie wysyła żądanie, ale ze zaktualizowaną wartością „lastUpdated”. Jeśli serwer wysłał mniej jednostek, oznacza to, że nie ma więcej nowych danych i synchronizacja się kończy.
Na diagramie: „last_updated” i „amount” to wartości, które są przechowywane mobilna aplikacja ... „Last_item” - ostatnia jednostka (antena) wysłana z serwera. Jest nowsza niż ta wartość, że zostanie zażądana następna lista.
Przykładowe żądanie: (lastUpdated: „2013-01-01 00:00:00”, kwota: 100)
Zalety:
- Urządzenie otrzymuje tyle danych, ile jest w stanie przetworzyć w danym momencie. Wielkość porcji określana jest na podstawie testów praktycznych. Proste jednostki mogą być synchronizowane do 1000 na raz. Ale zdarza się również, że jednostki z dużą liczbą pól i złożoną logiką przetwarzania pamięci są synchronizowane zwykle nie więcej niż 5 sztuk.
Niedogodności:
- Jeśli jest 250 potraw z taką samą aktualizacją, to przy ilości \u003d 100, ostatnich 150 nie zostanie wysłanych do urządzeń. Ta sytuacja jest całkiem realna i została opisana w poniższym podejściu.
Podejście 4: Prawidłowe terminy dostaw
W poprzednim podejściu możliwe jest, że jeśli w tabeli jest 250 potraw z tymi samymi „zaktualizowanymi” (na przykład „2013-01-10 12:34:56”), a wielkość porcji wynosi 100, to pojawi się tylko pierwszych 100 rekordów. Pozostałe 150 zostanie trwale przyciętych (zaktualizowane\u003e lastUpdated). Dlaczego tak się stało? Po zażądaniu pierwszych 100 rekordów parametr lastUpdated zostanie ustawiony na „2013-01-10 12:34:56”, a następne żądanie będzie miało warunek (zaktualizowane\u003e „2013-01-10 12:34:56”). Nawet złagodzenie stanu (aktualizacja\u003e \u003d „2013-01-10 12:34:56”) nie pomoże, ponieważ urządzenie będzie wtedy bez końca prosić o pierwsze 100 rekordów.
Sytuacja z tym samym „zaktualizowanym” nie jest tak rzadka. Na przykład podczas importowania danych z pliku tekstowego pole „zaktualizowane” zostało ustawione na TERAZ (). Import pliku z tysiącami wierszy może zająć mniej niż sekundę. Może się również zdarzyć, że cały katalog będzie miał ten sam „zaktualizowany”.
Aby to naprawić, musisz użyć jakiegoś pola anteny, które byłoby unikalne przynajmniej w ciągu jednej chwili („zaktualizowane”). Pole „id” jest unikalne w całej tabeli, dlatego należy go dodatkowo używać podczas synchronizacji.
Tak więc realizacja tego podejścia wygląda następująco. Serwer zwraca listę posortowaną według „updated” i „id”, a urządzenia żądają danych przy użyciu „lastUpdated” i nowego parametru „lastId”. Na serwerze warunek wyboru jest bardziej skomplikowany: ((updated\u003e lastUpdated) OR (updated \u003d lastUpdated i id\u003e lastId)).
Na diagramie: „last_updated”, „last_id” i „amount” to wartości, które są przechowywane w aplikacji mobilnej. „Last_item” - ostatnia jednostka (antena) wysłana z serwera. Jest nowsza niż ta wartość, że zostanie zażądana następna lista.
Podejście 5: Synchronizuj ze znajomością tego, co jest już na urządzeniu
Poprzednie podejścia nie uwzględniają faktu, że serwer tak naprawdę nie wie, jak skutecznie dane zostały zapisane na urządzeniu. Urządzenie po prostu nie mogło zapisać niektórych danych z powodu niewyjaśnionych błędów. Dlatego miło byłoby otrzymać potwierdzenie z urządzenia, że \u200b\u200bwszystkie (lub nie wszystkie) naczynia zostały zakonserwowane.
Ponadto użytkownik aplikacji może dostosować aplikację tak, aby potrzebowała tylko części danych. Na przykład użytkownik chce synchronizować potrawy tylko z 2 miast na 10. Nie można tego osiągnąć za pomocą synchronizacji opisanych powyżej.
Idea tego podejścia jest następująca. Serwer przechowuje (w osobnej tabeli „managed_item_list”) informacje o tym, jakie potrawy znajdują się na urządzeniu. Może to być po prostu lista par „zaktualizowany identyfikator”. Ta tabela zawiera wszystkie listy par talerzy ze zaktualizowanymi identyfikatorami dla wszystkich urządzeń.
Urządzenie wysyła do serwera informacje o potrawach dostępnych na urządzeniu (lista par „zaktualizowane id”) wraz z żądaniem synchronizacji. Na żądanie serwer sprawdza, które naczynia powinny znajdować się na urządzeniu, a które są teraz. Różnica jest następnie wysyłana do urządzenia.
W jaki sposób serwer ustala, które potrawy powinny znajdować się na urządzeniu? W najprostszym przypadku serwer wysyła żądanie, które zwróci listę par „zaktualizowanych id” wszystkich potraw (np. SELECT id, zaktualizowane z potraw). Na diagramie jest to realizowane za pomocą metody „WhatShouldBeOnDeviceMethod ()”. Jest to wada tego podejścia - serwer musi obliczyć (czasami wykonując ciężkie zapytania sql), co powinno znajdować się na urządzeniu.
W jaki sposób serwer określa, które potrawy znajdują się na urządzeniu? Wysyła zapytanie do tabeli „storage_item_list” dla tego urządzenia i pobiera listę par „id - updated”.
Analizując te dwie listy, serwer decyduje, co należy przesłać do urządzenia, a co usunąć. Na diagramie jest to „delta_item_list”. Dlatego żądanie nie zawiera „lastUpdated” i „lastId”, ich zadanie jest realizowane przez pary „id - updated”.
Skąd serwer wie o potrawach dostępnych na urządzeniu? W zapytaniu do serwera dodawany jest nowy parametr „items”, który zawiera listę id potraw, które zostały wysłane do urządzenia podczas ostatniej synchronizacji („device_last_stored_item_list”). Oczywiście możesz przesłać listę identyfikatorów wszystkich potraw znajdujących się na urządzeniu i nie komplikować algorytmu. Ale jeśli na urządzeniu jest 3000 potraw i wszystkie są wysyłane za każdym razem, koszty ruchu będą bardzo wysokie. W zdecydowanej większości synchronizacji parametr „items” będzie pusty.
Serwer musi stale aktualizować swoją „listę_zapisanych_elementów” danymi, które pochodzą z urządzenia w parametrze „pozycje”.
Zaimplementuj mechanizm czyszczenia danych serwera w plikach storage_item_list. Na przykład po ponownej instalacji aplikacji na urządzeniu serwer przyjmie, że urządzenie jest nadal aktualne. Dlatego podczas instalowania aplikacji urządzenie musi w jakiś sposób poinformować serwer, aby wyczyścił zapisaną listę elementów z listy elementów dla tego urządzenia. W naszej aplikacji wysyłamy w tym przypadku dodatkowy parametr „clearCache” \u003d 1.
Wniosek
Tabela podsumowująca charakterystykę tych podejść:
| № | Podejście | Natężenie ruchu(5 - duży) | Pracochłonność rozwoju(5 - wysoki) | Wykorzystanie pamięci urządzenia(5 - wysoki) | Poprawność danych na urządzeniu(5 - wysoki) | Możesz wybrać konkretne urządzenie |
| 1 | Wszystko jest zawsze zsynchronizowane | 5 | 1 | 5 | 5 | nie |
| 2 | Tylko zaktualizowany | 1 | 2 | 5 | 3 | nie |
| 3 | Synchronizacja partiami | 1 | 3 | 1 | 3 | nie |
| 4 | Poprawna synchronizacja w partiach | 1 | 3 | 1 | 3 | nie |
| 5 | Synchronizacja ze znajomością tego, co już jest na urządzeniu | 2 | 5 | 2 | 5 | tak |
„Poprawność danych na urządzeniu” to prawdopodobieństwo, że urządzenie zawiera wszystkie dane, które zostały przesłane przez serwer. W przypadku podejść nr 1 i nr 5 istnieje 100% pewność, że urządzenie posiada wszystkie potrzebne dane. W innych przypadkach nie ma takiej gwarancji. Nie oznacza to, że nie można zastosować innych podejść. Tyle, że jeśli część danych zostanie utracona na urządzeniu, to nie będzie można tego naprawić z serwera (a tym bardziej, aby dowiedzieć się o tym po stronie serwera).
Być może w obecności nieograniczonych taryf internetowych i bezpłatnego Wi-Fi problem ograniczenia ruchu generowanego przez aplikację mobilną stanie się mniej istotny. Ale chociaż musisz posługiwać się różnymi sztuczkami, wymyśl inteligentniejsze podejście, które może obniżyć koszty sieci i zwiększyć wydajność aplikacji. To nie zawsze działa. Czasami jest to „im prostsze, tym lepsze”, w zależności od sytuacji. Mamy nadzieję, że z tego artykułu możesz wybrać podejście, które będzie przydatne.
Zaskakująco mało jest opisów synchronizacji serwerów w Internecie i urządzenia mobilne ... Ponadto istnieje wiele aplikacji, które działają zgodnie z tym schematem. Dla zainteresowanych kilka linków.
Nasza firma oferuje usługi tworzenia strony serwerowej mobilnych aplikacji biznesowych oraz usług internetowych dla klientów działających w środowiskach o dużym obciążeniu. Przy opracowywaniu każdego projektu staramy się zastosować indywidualne podejście tak, aby powstały produkt stał się najbardziej optymalnym rozwiązaniem do konkretnych celów klienta.
Jeśli korzystasz ze złożonej aplikacji, która przechowuje i / lub przetwarza dane na serwerze, to za nią stoi Back-end - pakiet oprogramowania hostowany na serwerze WWW i pracujący z aplikacją, która w tym przypadku nazywa się Front-end. Aplikacja znajdująca się na serwerze może pracować jednocześnie z dużą liczbą klientów, co narzuca wymagania dotyczące dużej szybkości i bezpieczeństwa jej działania.
Strona serwera aplikacji jest często napisana w PHP, który jest najpopularniejszym językiem dla takich rozwiązań. Aby zaimplementować proste zadania serwera, można użyć standardowych systemów, ale w przypadku bardziej szczegółowych trzeba już opracować własne rozwiązanie lub dodatki do standardowych systemów.
Zasady tworzenia serwerów dla aplikacji mobilnej
Nasi programiści pracują z technologiami, które pozwalają nam wdrażać szeroką gamę rozwiązań dla każdego, nawet bardzo dużego obciążenia pracą i różnych obszarów. Tworzymy również osobne rozwiązania serwerowe do indywidualnych zadań.
Kontrola organizacyjna
Każdy projekt tworzony jest przez odrębną grupę specjalistów odpowiedzialnych za wszystkie etapy realizacji i terminową realizację projektu.
Programowanie
Projekt architektury serwera to najważniejszy krok w procesie tworzenia baz danych i formułowania niezbędnych algorytmów.
Testowanie
Część oprogramowania powinna działać bez błędów i awarii. Za to odpowiadają testerzy, którzy testują system.
Pomoc techniczna
Nasi pracownicy zapewniają pełną obsługę techniczną programów, co pozwala na szybkie usuwanie braków i dokonywanie aktualizacji.
Funkcje programistyczne
Aby kompetentnie rozwijać stronę serwerową aplikacji, wymagane są określone umiejętności i znajomość języka programowania używanego na serwerze. Jak pokazuje praktyka, aplikacje klient-serwer są tworzone w PHP. Jest niekwestionowanym liderem w tej dziedzinie. Ponad połowa stron internetowych na świecie jest napisana w PHP, co jest wygodne w rozwoju i obsłudze.
Struktura
Ta platforma oprogramowania umożliwia zwiększenie skalowalności i elastyczności projektu. Niemniej jednak ramy muszą być wybrane tak poprawnie, jak to możliwe, dlatego wymagana jest dogłębna analiza dokumentacji roboczej projektu, która następnie pomoże opracować produkt wysokiej jakości.
Istnieją inne języki używane do tworzenia zaplecza. Na przykład popularne są aplikacje serwerowe utworzone w środowisku Delphi. Dzięki temu program poprawił debugowanie. Ponadto łatwiej jest w nim tworzyć unikalne programy, zapewnia kreację wizualną. Wszystko to pozwala stworzyć przejrzysty i wygodny interfejs.
Aplikacje serwerowe Java są nie mniej popularne. Można je bez problemu uzupełniać, łatwo wykonywać na różnych platformach i charakteryzują się wysokim poziomem bezpieczeństwa.
Inny powszechnie używany język. Pomaga tworzyć aplikacje serwerowe łatwo, szybko i niedrogo.
Prawie wszystkie nowoczesne firmy mają własne wirtualne biura. Witryna może być wizytówką, portalem lub katalogiem internetowym z możliwością składania zamówień.
Procesy biznesowe w tym przypadku zależą od serwerów WWW, a mianowicie ich odporności na ataki, próby włamania i zewnętrzne negatywne wpływy, a także wydajność wystarczającą dla wielu jednocześnie akceptowanych żądań.
Etapy rozwoju usług internetowych
Tworząc aplikacje dla różnych segmentów rynku, organizujemy naszą pracę według jednej zasady - cały proces dzielimy na osobne etapy, których przebieg i wyniki są raportowane klientom. W ten sposób serwer dla aplikacji mobilnej jest rozwijany w podobny sposób.
1. Opracowanie pomysłu
Do 2 tygodni
Na tym etapie powstaje fundament, który daje wyobrażenie o tym, co zostanie położone i w jakim kierunku będzie się rozwijać.
2. Ocena projektu
2-3 tygodnie
Nasi specjaliści oceniają czas i koszt prac, a następnie sporządzana jest wstępna propozycja zagospodarowania.
3. Zakres zadań i umowa
Do 2 tygodni
Po omówieniu z klientem wszystkich niuansów procesu i sporządzeniu szczegółowej specyfikacji technicznej zostaje przygotowana i podpisana umowa.
4. Rozwój interfejsu
2-3 tygodnie
Projektanci są zaangażowani w tworzenie interfejsów wymaganych do pisania modułów oprogramowania.
6. Testowanie
2-3 tygodnie
Kompleksowe sprawdzenie powstałego rozwiązania programowego przeprowadzane jest przez testerów przy użyciu zestawu odpowiednich narzędzi.
7. Zakończenie projektu
Do 2 tygodni
W ustalonym terminie klient otrzymuje gotowy, dokładnie przetestowany serwis internetowy.
nasz zespół
Analizując działalność handlową i potrzeby naszych klientów, tworzymy produkty z życia wzięte, które pomagają rozwiązywać różnorodne problemy biznesowe. Zastosowanie nowoczesnych technologii daje szerokie możliwości implementacji oprogramowania serwerowego, co gwarantuje wysoką wydajność odpowiednich aplikacji mobilnych. Nasz zespół reprezentują:
Menadżerowie projektu
Pracownicy ci współpracują zarówno z klientami, jak i programistami, zapewniając komunikację między nimi. Kontrolują realizację zarówno zaplanowanych już działań, jak i niezbędnych usprawnień.
Projektanci
W swojej pracy nasi specjaliści uwzględniają wymagania dotyczące budowy interfejsów dla systemów operacyjnych iOS i Android, dzięki czemu wydane aplikacje działają poprawnie na różnych urządzeniach.
Deweloperzy
W celu optymalizacji wydajności aplikacji mobilnych programiści analizują ich wymagania systemowe i tworzą specjalistyczne oprogramowanie serwerowe.
Testerzy
Dokładne testy to gwarancja jakości gotowego produktu oraz gwarancja bezpieczeństwa przechowywanych i przetwarzanych danych. Specjaliści ci używają różnorodnych narzędzi i skutecznej metodologii.
Jakie usługi tworzymy
Niezależnie od tego, czy jest osadzona w witrynie oprogramowania, czy w samodzielnym programie, usługa internetowa służy do wykonywania zadań związanych z reklamą, analizą, planowaniem i promocją biznesu. W związku z tym należy zdecydować, jaki rodzaj zasobu będzie optymalnym rozwiązaniem.
Projekty informacyjne
Zaprojektowany, aby pomieścić różnorodne treści.
Witryny tematyczne
Prawie wszystkie ich strony poświęcone są jednemu tematowi. Popyt na nie jest nadal dość wysoki.
Witryny informacyjne
Informuje o różnych wiadomościach z jednego lub kilku tematów, odzwierciedlających główne obszary życia.
Blogi
Popularność tych zasobów stale rośnie. Podobnie jak serwisy informacyjne, przekazują tę lub inną informację społeczności internetowej, ale w tym przypadku autorzy wyrażają swoją osobistą opinię.
Projekty społeczne
Należą do nich specjalistyczne społeczności. sieci, społeczności, fora itp.
Fora
Stworzony, aby omawiać różne wiadomości, towary / usługi itp. Mogą być zarówno wąsko ukierunkowane, jak i różnorodne.
Portale społecznościowe
Te zasoby mają wielomilionową publiczność. Ich głównym zadaniem jest zapewnienie internautom możliwości komunikowania się online za pomocą wiadomości tekstowych / głosowych oraz komunikacji wideo.
Różne usługi internetowe
Rozpowszechnione dzisiaj, są podzielone na kilka typów.
Katalogi
usługi pocztowe
Zapewnij użytkownikom wszystkie funkcje i zalety poczty e-mail, w tym przeglądanie, wysyłanie, edytowanie listów i dokumentów itp.
Wyszukiwarki
Służą do wyszukiwania witryn i różnych informacji na temat niektórych żądań.
Tablice ogłoszeń
Są to zasoby internetowe, w których internauci publikują reklamy dotyczące sprzedaży i zakupu oraz usług na różne tematy.
Witryny hostingowe
Przeznaczony do tymczasowego przechowywania plików. Niektóre z nich zapewniają możliwość przeglądania danych przed pobraniem.
Często Zadawane Pytania
Poniżej przedstawiamy odpowiedzi na pytania, które często zadają nam nasi specjaliści. Jeśli nie znajdziesz tutaj interesujących Cię informacji, zadaj w tym miejscu swoje pytanie formularz i na pewno na nie odpowiemy.
Jak długo trwa budowa aplikacji i serwera WWW?
Średnio ta praca trwa od 9 do 20 tygodni. Wszystko zależy od złożoności wykonywanego zadania.
