488 Dio IV. Ajax za primjer
botove, i poziva server, koji će dinamički kreirati podatke odgovora na osnovu poslane vrijednosti stringa upita. Prvi parametar funkcije LoaciXMLXSLTDoc () je URL PHP stranice koja generiše XML dokument, spojen sa nizom upita koji se odnosi na vrijednosti polja HTML obrasca O. Drugi parametar je naziv XSLT © datoteka koja se koristi u transformaciji XML podataka. Treći parametar koji zahtijeva funkcija LoadXMLXSLTDoc () je identifikator za div element u koji se postavljaju rezultati pretraživanja. Identifikator je ime niza izlaznog elementa, a ne referenca objekta; u ovom slučaju, niz "rezultati" se koristi kao identifikator.
U sljedećem koraku koristimo DOM metode za dodavanje indikatorske slike na web stranicu. Kreira se element image © i postavlja se atribut izvora slike O. Ovaj kreirani element se dodaje elementu rezultata © div. Na ovaj način, kada se naša funkcija pozove iz obrasca za obradu događaja onsubmit, datoteka slike se postavlja na stranicu. Općenito, važno je da korisnik kreira vizualnu povratnu informaciju — poruku ili sliku — koja ukazuje da je obrada u toku. Ovo sprečava korisnika da više puta klikne na dugme za hendikep misleći da se ništa ne dešava (zapamtite, Ajax proces je "nevidljiv").
Posljednja faza je poziv funkcije LoadXMLXSLTDoc () ®, koja pokreće proces slanja informacija serveru. Funkcija LoadXMLXSLTDoc (), opisana u Odjeljku 12.4, upravlja pozivom ContentLoader () objekta, koji zahtijeva dokumente od servera. Određivanjem izlazne pozicije kao parametra (umjesto tvrdo kodirane vrijednosti u funkciji LoadXMLXSLTDoc ()), možemo ponovo koristiti funkciju na istoj stranici bez potrebe za višestrukim procedurama ili if naredbama za razdvajanje funkcionalnosti. Stoga rezultate različitih upita za pretraživanje preusmjeravamo na različite dijelove stranice. Međutim, prije nego što sve to učinimo, pogledajmo kako kreirati XML i XSLT dokumente na serveru.
12.3. Šifra serverske strane: PHP
V u ovom dijelu ćemo kreirati dinamiku projekta XML dokument koji koristi PHP - popularni jezik otvorenog koda (kao što znate, Ajax framework je kompatibilan sa bilo kojim jezikom ili platformom na strani servera). XML dokument se generira dinamički iz skupa rezultata primljenog kao odgovor na zahtjev klijenta bazi podataka. Osim toga, pokazat ćemo vam kako da kreirate statički XSLT dokument koji se nalazi na serveru i preuzima svaki put kada se zatraži dinamička datoteka. Oba ova dokumenta se vraćaju klijentu nezavisno kada se objekt ContentLoader zahteva u dva odvojena zahteva (Listing 12.7). XSLT kod transformiše naš dinamički XML dokument na strani klijenta i kreira HTML tabelu koja se prikazuje korisniku.
Poglavlje 12 Live Search koristeći XSLT 489
12.3.1. Kreiranje XML dokumenta
Pošto koristimo XSLT, potreban nam je strukturirani XML dokument, koji je jednostavan zapis informacija tako da XSL datoteka može izvršiti standardnu transformaciju. U ovom projektu ćemo kreirati dinamički XML fajl kada klijent zatraži PHP fajl.
Razvoj XML strukture
Prije nego počnemo kreirati XML datoteku, potrebno je da kreiramo predložak za nju. Ovaj šablon bi trebao odražavati strukturu podataka koje je vratila pretraga. U odabranoj formulaciji problema (telefonski imenik) vratit ćemo naziv kompanije, ime kontakta, državu i broj telefona. Listing 12.3 prikazuje osnovni XML predložak sa četiri polja.
Listing 12.3. Osnovni XML fajl
Prva stavka je imenik. Sljedeći je element unosa koji sadrži podelemente sa svim detaljima koji su povezani sa svim kontakt brojevima koji se nalaze u zahtjevu. Ako imamo pet rezultata, biće pet ulaznih elemenata u XML dokumentu. Naziv kompanije pojavljuje se u elementu kompanije. Dodatno smo dodali ime kontakt osobe, naziv zemlje i broj telefona. Nismo ograničeni samo na navedena polja; polja se mogu dodati ili ukloniti u zavisnosti od toga koje informacije treba da budu prikazane.
Ako se ne pronađu rezultati, umjesto prikazivanja poruke upozorenja, možete kreirati stavku koja prikazuje ove informacije korisniku. STO će nam olakšati vraćanje rezultata korisniku i neće zahtijevati dodatni kod na strani klijenta aplikacije. Kôd u Listingu 12.4 je skoro identičan kodu u Listingu 12.3, ali ovog puta ubacujemo tekst u XML elemente koje želimo prikazati korisniku da signaliziramo da rezultati nisu pronađeni.
Listing 12.4. XML fajl bez rezultata
// O Umjesto naziva kompanije, prikazuje se "No R e s u l t s".
490 Dio IV. Ajax u primjerima
// © "N / A" se prikazuje za preostale margine
Sa ovim kodom korisniku prikazujemo jednu liniju koja označava da tražena informacija nedostaje. Deskriptor kompanija O prikazuje informacije koje ukazuju da nema rezultata. Drugi deskriptori 0 govore korisniku da nema informacija. Ako ne želimo da prikažemo tekst "N/A" ("nije dostupno"), umjesto toga možemo dodati razmak bez prekida koji će prikazati ćelije tabele. Da nismo dodali nikakve informacije, ćelije u tabeli se ne bi pojavile.
Kao što vidite, XML format ima vrlo jednostavnu strukturu. Da je ova XML datoteka statična, korisniku bi bilo relativno lako dodati novog pretplatnika na fajl. Pošto se generiše dinamički, potrebna nam je petlja koja generiše XML dokument preko skupa rezultata.
Kreiranje dinamičkog XML dokumenta
Kao i uvijek, kreiramo XML dokument na serveru. Pridržavajući se politike korišćenja različitih primera na strani servera u primerima, kod na strani servera za ovo poglavlje je napisan u PHP-u. Podsjećamo, Ajax infrastruktura se može izgraditi korištenjem bilo kojeg jezika na strani servera, a mi ćemo samo opisati kako se implementira kod na strani servera bez ulaženja u detalje. Dakle, Listing 12.5 pokazuje kod za pozadinu aplikacije. Kôd uzima parametar stringa upita i generira mnogo rezultata upita baze podataka. Zatim prolazimo kroz skup rezultata, kreirajući XML element koristeći predložak u Listingu 12.4 za svaki telefonski broj primljen kao odgovor na zahtjev.
Listing 12.5. PhoneXML.php skripta: Generirajte XML dokument na serveru
// O Deklarirajte MIME tip zaglavlje ("Tip sadržaja: tekst / xml"); eho ("\ n ");
// © Povežite se na bazu podataka
$ db = mysql__connect ("localhost", "ajax", "action"); rnysql_select_db ("ajax", $ db);
$ rezultat = mysql_query ("SELECT *
FROM Contacts WHERE Ime kontakta poput "%". // © Popunite zahtjev
$ _GET ["q"]. "%" ", $ Db);?>
// O Provjerite rezultate
if ($ myrow = mysgl_fetch_array ($ rezultat)) (uradi (
// © Prođite kroz više rezultata
Poglavlje 12. Pretraživanje uživo sa XSLT 491
) while ($ myrow - mysql_fetch_array ($ rezultat)); ) drugo (
Koristeći XSLT, naš XML fajl se može konvertovati u prelepu HTML tabelu sa nekoliko linija koda. XSLT dokument omogućava podudaranje uzoraka ako je potrebno za prikaz podataka u bilo kojem traženom formatu. Kada se uporedi sa šablonom, struktura šablona se koristi za prikaz podataka. U ovom slučaju idemo kroz čvorove stabla 492 Dio IV. Ajax za primjer wa izvor koristeći XSLT. XSLT dokument uzima strukturiranu XML datoteku i pretvara je u format koji je jednostavan za pregled, ažuriranje i izmjenu. U našem slučaju, XSLT dokument je definiran statički. XSLT struktura XSLT transformacija sadrži pravila za prevođenje izvornog stabla u odredišno stablo. Cijeli XSLT proces je strukturirano podudaranje uzoraka. Kada se elementi izvornog stabla podudaraju sa datom strukturom, ciljno stablo se kreira prema predlošku dokumenta. Struktura ciljnog stabla ne mora biti povezana sa strukturom izvornog stabla. Stoga se originalni XML fajl može konvertovati u bilo koji format koji želite. Nije potrebno koristiti samo tabelarni prikaz skupa podataka. XSLT transformacija se naziva stylesheet jer definira stil odredišnog stabla. Tablica stilova sadrži pravila predloška iz dva dijela. Prvi dio je struktura uzorka s kojom se uspoređuju čvorovi izvornog stabla. Kada pronađe podudaranje, XSLT procesor koristi drugi dio, predložak koji sadrži deskriptore za izgradnju izvornog stabla. Kreiranje XSLT dokumenta Relativno je lako generisati XSLT transformaciju za ovaj projekat. Pošto ćemo dobiti tabelu, nije potrebno fensi uparivanje uzoraka; jednostavno ćemo uzastopno koračati kroz sve čvorove elemenata izvornog stabla. U nastavku ćemo razviti šablon koji formira HTML tabelu sa četiri kolone. Odgovarajući XSLT fajl za ovaj projekat je prikazan u Listingu 12.6. i Listing 12.6. XSLT fajl "ISO-8859-l"?> //
O Postavite XML verziju i kodiranje //
© Postavite XSLT imenski prostor"http://www.w3.org/1999/XSL/Transform"> //
© Postavite pravila šablona //
O Dodajte element tabele // © Kreirajte naslovnu liniju Poglavlje 12 Live Search koristeći XSLT 493 // 0 Uzastopno proći kroz elemente telefonskog imenika select = "imenik / unos"> // © Formatirajte izlaz Kada kreirate XSLT transformaciju, morate navesti kodiranje i XML verziju O, te specificirati XSLT © imenski prostor. Imenski prostor definira pravila i specifikacije sa kojima dokument mora biti usklađen. Elementi u XML imenskom prostoru prepoznaju se u izvornom dokumentu, ali ne prepoznaju u dokumentu rezultata. Svi naši elementi u XSLT imenskom prostoru imaju prefiks xsl. Zatim možete uspostaviti pravilo predloška - potražite strukturu / © koja odgovara cijelom dokumentu. Sada možemo početi kreirati šablon za tabelu koja prikazuje naše rezultate. Dodamo deskriptor tabele O koji se preslikava na identifikator tabele. Zatim se unosi red zaglavlja tabele (C), koji sadrži nazive kolona koji ukazuju korisniku koje informacije tabela sadrži. Uzastopno prolazeći kroz skup čvorova izvornog stabla, dobijamo preostale redove tabele. U ovom slučaju se koristi for-each © petlja, koja u procesu obrade unosa daje čvorove koji se nalaze u imeniku / unosu. Budući da uzastopno hodamo kroz stablo dokumenta, moramo odabrati vrijednosti stupaca. Za odabir vrijednosti iz čvorova, operator value-of se koristi za dohvat vrijednosti XML elementa i dodavanje u izlazni tok transformacije. Da navedemo XML element čiji tekst želimo da dohvatimo, koristimo atribut select sa imenom elementa. Sada kada ste dovršili svoju XSLT datoteku i generirali kod za dinamičko generiranje XML dokumenta, možete dovršiti svoj JavaScript kod i vidjeti kako kombinacija XSLT transformacije sa strukturiranom XML datotekom stvara tablicu laku za pregled. U sljedećem koraku, vraćamo se na stranu klijenta i preuzimamo datoteke koje smo upravo kreirali pomoću HTTP odgovora. Mnogo modernog aplikacije za mobilne platforme(iOS, Android, itd.) radi u tandemu sa serverom. Aplikacija sa zastarjelim podacima gubi svoju korisnost. Stoga je važno osigurati da podaci od servera do uređaja budu ažurirani. Ovo se odnosi na vanmrežne aplikacije koje bi trebale raditi bez interneta. Za potpuno online aplikacije koje ne rade (ili su beskorisne) bez interneta (na primjer, Foursquare, Facebook) postoje specifičnosti koje su izvan okvira ovog članka. Na primjeru jedne od naših offline aplikacija reći ću vam koje smo pristupe koristili za sinhronizaciju podataka. U prvim verzijama razvili smo jednostavne algoritme i u budućnosti smo ih iskustvom poboljšali. U članku je predstavljen sličan slijed - od jednostavnih očiglednih praksi do složenijih. Treba pojasniti da se članak bavi prijenosom podataka samo u jednom smjeru: od servera do uređaja. Ovdje je server izvor podataka. Kao primjer, razmotrit ćemo prijenos imenika posuđa (“posuđe”) na uređaj. Pretpostavit ćemo da uređaj šalje zahtjev za url „/servis / jela / ažuriranje“, razmjena se vrši putem http protokola u JSON formatu ( www.json.org). Server ima tabelu “jela” sa sljedećim poljima: id (identifikator zapisa), naziv (ime jela), ažurirano (onog trenutka kada je jelo ažurirano, bolje je odmah napraviti podršku za vremensku zonu, “GGGG-MM -DDThh: mm: ssTZD”, na primjer, “1997 -07-16T19: 20: 30 + 01: 00 ”), is_deleted (znak izbrisanog zapisa). Napomena u vezi prisustva posljednjeg polja. Podrazumevano, njegova vrijednost je 0. U aplikaciji u kojoj su entiteti sinkronizirani između klijenta i servera, ne preporučuje se fizički brisanje podataka sa servera (da bi se izbjegle greške). Stoga je is_deleted = 1 postavljen za obrisane jela. Kada entitet sa is_deleted = 1 stigne na uređaj, on se briše sa uređaja. Uz bilo koji pristup, koji će biti razmotren u nastavku, server vraća niz objekata na JSON uređaje (može biti prazan): [ Primjer odgovora servera: [ naziv: "Riblja juha", ažurirano: "2013-08-02 07:05:19", Ovo je najlakši način. Uređaj traži listu jela od servera, a server šalje cijelu listu. Svaki put dođe cijela lista. Nije sortirano. Primjer zahtjeva: null, ili “()” Prednosti: Nedostaci: Područje primjene: Uređaj traži listu jela, ažuriranu iz prethodne sinhronizacije. Lista dolazi sortirana prema "ažurirano" uzlaznim redoslijedom (opcionalno, ali zgodno). Uređaj pohranjuje vrijednost “ažurirano” za posljednje poslano jelo i, na sljedeći zahtjev, šalje ga serveru u parametru “lastUpdated”. Server šalje listu jela koja su novija od “lastUpdated” (ažurirano> zadnje ažurirano). Na prvi zahtjev serveru “lastUpdated” = null. Primjer zahtjeva: (zadnje ažurirano: “2013-01-01 00:00:00”) Na dijagramu: “last_updated” je vrijednost koja je pohranjena na uređaju. Obično se na uređaju kreira posebna tabela za pohranjivanje ovih "last_updated" vrijednosti za svaki entitet (jelo, grad, organizaciju, itd.) Ovaj pristup je prikladan za sinkronizaciju jednostavnih linearnih lista gdje su pravila dolaska ista za sve uređaje. Za selektivniju sinhronizaciju, pogledajte “Pristup 5: Sinhronizirajte sa znanjem o tome šta je već na uređaju”. Ovaj pristup obično pokriva većinu potreba. Na uređaj stižu samo novi podaci, možete ih sinhronizirati barem svake minute - promet će biti mali. Međutim, postoje problemi povezani s ograničenjima mobilnih uređaja. To su memorija i procesor. Mobilni uređaji nemaju dovoljno RAM-a. Ako u direktoriju ima 3000 jela, onda raščlanjivanje velikog json stringa sa servera u objekte na uređaju može uzrokovati nedostatak memorije. U tom slučaju, aplikacija će se ili srušiti ili neće sačuvati ovih 3000 jela. Ali čak i ako je uređaj bio u stanju da probavi takav niz, tada će performanse aplikacije u trenucima sinhronizacije u pozadini biti niske (zaostajanje sučelja, ne glatko pomicanje, itd.) Stoga je potrebno zatražiti listu u manjim porcijama. Da bi to učinio, uređaj prosljeđuje još jedan parametar („iznos“), koji određuje veličinu porcije. Lista se mora poslati sortirana prema "ažuriranom" polju uzlaznim redoslijedom. Uređaj, slično prethodnom pristupu, pamti “ažuriranu” vrijednost posljednjeg poslanog entiteta i prosljeđuje je u polje “lastUpdated”. Ako je server poslao potpuno isti broj entiteta, tada uređaj nastavlja sinhronizaciju i ponovo šalje zahtjev, ali sa ažuriranim „lastUpdated“. Ako je server poslao manje entiteta, to znači da nema više novih podataka i sinhronizacija se završava. Na dijagramu: “last_updated” i “amount” su vrijednosti koje su pohranjene u mobilna aplikacija... “Last_item” - posljednji entitet (jedilo) poslan sa servera. Sljedeća lista će biti zatražena novija od ove vrijednosti. Primjer zahtjeva: (zadnje ažurirano: “2013-01-01 00:00:00”, iznos: 100) Prednosti: Nedostaci: U prethodnom pristupu, moguće je da ako tabela sadrži 250 jela sa istim "ažuriranim" (na primjer, "2013-01-10 12:34:56") i veličina porcije je 100, tada samo prvih 100 zapisi će doći. Preostalih 150 će biti teško isečeno (ažurirano> zadnje ažurirano). Zašto će se ovo dogoditi? Kada se zatraži prvih 100 zapisa, lastAžurirano će biti postavljeno na “2013-01-10 12:34:56”, a sljedeći zahtjev će imati uslov (ažurirano> “2013-01-10 12:34:56”). Čak ni ublažavanje uslova (ažurirano> = “2013-01-10 12:34:56”) neće pomoći, jer će uređaj tada beskrajno tražiti prvih 100 zapisa. Situacija sa istim "ažuriranim" nije tako rijetka. Na primjer, prilikom uvoza podataka iz tekstualne datoteke, polje “ažurirano” je postavljeno na SADA (). Može potrajati manje od jedne sekunde za uvoz datoteke sa hiljadama redova. Također se može dogoditi da će cijeli direktorij imati isto "ažurirano". Da biste to popravili, trebate koristiti neko polje za jelo koje bi bilo jedinstveno barem u jednom trenutku ("ažurirano"). Polje “id” je jedinstveno u cijeloj tablici, tako da ga trebate dodatno koristiti u sinhronizaciji. Dakle, implementacija ovog pristupa izgleda ovako. Server vraća listu sortiranu po „ažurirano“ i „id“, a uređaji traže podatke koristeći „lastUpdated“ i novi parametar „lastId“. Na serveru je uslov odabira složeniji: ((ažurirano> posljednje ažurirano) ILI (ažurirano = posljednje ažurirano i id> lastId)). Na dijagramu: “last_updated”, “last_id” i “amount” su vrijednosti koje su pohranjene u mobilnoj aplikaciji. “Last_item” - posljednji entitet (jedilo) poslan sa servera. Sljedeća lista će biti zatražena novija od ove vrijednosti. Dosadašnji pristupi ne uzimaju u obzir činjenicu da server zapravo ne zna koliko su uspješno podaci pohranjeni na uređaju. Uređaj jednostavno nije mogao sačuvati neke podatke zbog neobjašnjivih grešaka. Stoga bi bilo lijepo da od uređaja dobijete potvrdu da je sva (ili ne sva) jela sačuvana. Osim toga, korisnik aplikacije može konfigurirati aplikaciju na način da mu je potreban samo dio podataka. Na primjer, korisnik želi sinkronizirati jela iz samo 2 grada od 10. Ovo se ne može postići korištenjem gore opisanih sinhronizacija. Ideja koja stoji iza pristupa je sljedeća. Server pohranjuje (u posebnoj tabeli “stored_item_list”) informacije o tome koja jela se nalaze na uređaju. To bi mogla biti samo lista "id - updated" parova. Ova tabela sadrži sve liste "id - ažuriranih" parova antena za sve uređaje. Uređaj šalje informacije o jelima dostupnim na uređaju (lista parova „id - updated“) na server zajedno sa zahtjevom za sinhronizaciju. Kada se to zatraži, server provjerava koja jela treba biti na uređaju, a koja sada. Razlika se zatim šalje na uređaj. Kako server određuje koje posuđe treba biti na uređaju? U najjednostavnijem slučaju, server postavlja zahtjev koji će vratiti listu "id - updated" parova svih jela (na primjer, SELECT id, updated FROM dishes). Na dijagramu, to se radi metodom "WhatShouldBeOnDeviceMethod ()". Ovo je nedostatak pristupa - server mora izračunati (ponekad pravi teške sql upite) šta bi trebalo biti na uređaju. Kako server određuje koje posuđe ima na uređaju? On pravi upit prema tabeli "stored_item_list" za ovaj uređaj i dobija listu "id - updated" parova. Analizom ove dvije liste server odlučuje šta treba poslati na uređaj, a šta obrisati. Na dijagramu, ovo je “delta_item_list”. Dakle, zahtjev ne sadrži “lastUpdated” i “lastId”, njihov zadatak obavljaju parovi “id - updated”. Kako server zna za posuđe koje je dostupno na uređaju? U zahtjevu prema serveru dodaje se novi parametar “items” koji sadrži listu id-a jela koja su poslana uređaju u posljednjoj sinhronizaciji (“device_last_stored_item_list”). Naravno, možete poslati listu id-a svih jela koja se nalaze na uređaju, a ne komplicirati algoritam. Ali ako na uređaju ima 3000 jela i svi se šalju svaki put, onda će troškovi prometa biti vrlo visoki. U velikoj većini sinhronizacija, parametar “items” će biti prazan. Server mora stalno ažurirati “stored_item_list” podacima koji su došli sa uređaja u parametru “items”. Trebali biste implementirati mehanizam za brisanje podataka servera u stored_item_list. Na primjer, nakon ponovnog instaliranja aplikacije na uređaj, server će pretpostaviti da je uređaj još uvijek ažuriran. Stoga, prilikom instaliranja aplikacije, uređaj mora na neki način obavijestiti server kako bi izbrisao stored_item_list za ovaj uređaj. U našoj aplikaciji šaljemo dodatni parametar “clearCache” = 1 u ovom slučaju. Tabela sažetka karakteristika ovih pristupa: “Ispravnost podataka na uređaju” je vjerovatnoća da uređaj sadrži sve podatke koje je poslao server. U slučaju pristupa #1 i #5, postoji 100% sigurnost da uređaj ima sve podatke koji su mu potrebni. U drugim slučajevima takva garancija ne postoji. To ne znači da se drugi pristupi ne mogu koristiti. Samo ako se dio podataka izgubi na uređaju, onda to neće biti moguće popraviti sa servera (a još više saznati o tome na strani servera). Možda će, u prisustvu neograničenih internet tarifa i besplatnog wifi-a, problem ograničavanja prometa koji generiše mobilna aplikacija postati manje relevantan. Ali dok morate ići na razne trikove, smislite pametnije pristupe koji mogu smanjiti troškove mreže i povećati performanse aplikacija. Ne radi uvijek. Ponekad je „što jednostavnije, to bolje“, u zavisnosti od situacije. Nadajmo se da iz ovog članka možete odabrati pristup koji vam dobro dođe. Postoji iznenađujuće malo opisa sinhronizacije servera na Internetu i mobilnih uređaja... Štoviše, postoji mnogo aplikacija koje rade prema ovoj shemi. Za zainteresovane par linkova. BACKUP Zašto su vam potrebne sigurnosne kopije na mobilnoj platformi Stručnjaci znaju koliko su ponekad nepouzdane mobilne aplikacije na 1C: greške se mogu pojaviti u bilo kojem trenutku, zbog čega će se baza korisnika jednostavno srušiti. Istovremeno, suočeni smo s nepouzdanošću samih uređaja: mogu se pokvariti, izgubiti, ukrasti, a korisnici žele zadržati svoje podatke. I do verzije 8.3.9 nismo imali mehanizam platforme za spremanje sigurnosne kopije. Pošto korisnici ranije nisu imali dugme "sačuvaj kopiju", programeri Boss aplikacije morali su da naprave sopstvene rezervne kopije. Kako smo to uradili? Podatke baze podataka spremamo u obliku XML-a. Preporučljivo je ponuditi korisniku nekoliko opcija za pohranjivanje kopija - prije svega, to je zgodno za kupce, oni mogu odabrati najbolju opciju za sebe: prenijeti u oblak, poslati na svoju poštu, spremiti na uređaj. Time se programeri dodatno osiguravaju. Ako je nešto pošlo po zlu, a mehanizam za kreiranje kopija na Google Drive-u ili Yandex Drive-u iznenada se pokvario, uvijek možete reći korisniku da se programer trenutno bavi greškom, ali za sada može sačuvati podatke na alternativni način. I korisnici su zadovoljni jer mogu biti sigurni u svoje podatke. Neophodno moraju se fokusirati na usluge u oblaku, jer ako je uređaj izgubljen ili pokvaren, a korisnik je sačuvao kopiju na istom uređaju, tada će podaci biti izgubljeni. Takođe i mi obavezno podsjetite korisnika na potrebu kreiranja sigurnosne kopije. Kako zadržati kopije ako se konfiguracija promijeni?
Kada govorimo o masovnom rješenju, o aplikaciji koja se stalno mijenja, razvija i usavršava, mora se uzeti u obzir i ponašanje korisnika. Korisnik će možda htjeti vratiti rezervnu kopiju sačuvanu u staroj verziji aplikacije, koja nije sadržavala nikakve detalje. I tada se postavlja zadatak: pročitati podatke, zatim popuniti podatke prema logici ažuriranja iz stare verzije aplikacije. Kako uraditi? Osim podataka, sačuvajte i samu strukturu podataka kako biste kasnije znali kako je čitati. Postoji nekoliko opcija za pohranjivanje ove strukture podataka, uključujući i da se može pohraniti u samoj konfiguraciji. To jest, svaki put kada se objavi nova verzija, zadržite strukturu metapodataka prethodne verzije u izgledu u konfiguraciji. Ne zaboravite da u mobilnoj aplikaciji konfiguracija ne bi trebala rasti tek tako, treba cijeniti mjesto u njoj, treba je učiniti što kompaktnijom. Ali aplikacija se razvija, a takvih će izgleda biti mnogo, a vremenom će ih postajati sve više. Stoga je u slučaju mobilne aplikacije poželjniji drugi način - spremite strukturu metapodataka direktno u datoteku podataka... Na izlazu dobijamo takav fajl u koji prvo pohranjujemo neke pomoćne podatke - verziju konfiguracije, konfiguracionu šemu, granice sekvence, a nakon toga upisujemo korisničke podatke u XML formatu. Štaviše, u odeljku "Pomoćni podaci" datoteke možete pohraniti i druge važne podatke koji iz nekog razloga nisu mogli biti upisani u XML. Uzimamo šemu podataka koju smo sačuvali u datoteci i na osnovu nje gradimo XDTO paket za čitanje datoteke. Sličan objekat kreiramo u bazi podataka, popunjavamo ga, vršimo dopunsku obradu prilikom ažuriranja i spremamo već gotov objekat u bazu podataka. Ispod na slici možete vidjeti savjet kako lijepo napisati XDTO model ovih konfiguracija. Kompanija koja je izdala Boss aplikaciju eksperimentisala je sa ovim, pronašla nekoliko načina, ali se odlučila na ovu opciju za snimanje šeme metapodataka. Kada otvorite samu datoteku podataka, možete vidjeti uobičajeni strukturirani XML, čitljiv, koji navodi sve metapodatke aplikacije. // Napišite konfiguracijsku šemu ModelXDTO = FactoryXDTO.ExportModelsXDTO ("http://v8.1c.ru/8.1/data/enterprise/current-config"); XDTO Factory.WriteXML (UploadFile, XDTO model); // Čitanje konfiguracijske sheme Model XDTO = Factory XDTO Čitaj XML (Pročitaj XML, Factory XDTO. Tip ("http://v8.1c.ru/8.1/xdto", "Model")); UnloadFactory = Novi XDTOFactory (XDTOModel); Da bismo zaštitili korisnika, neophodno je ponovo ga pitati da li treba da vrati rezervnu kopiju. Možda je samo eksperimentirao i klikao na sva dugmad u aplikaciji :) A sada su trenutni podaci možda izgubljeni. Stoga, prilikom izvođenja potencijalno "opasnih" radnji, uvijek preciziramo da li on to zaista želi i kako to treba učiniti. Korisnik mora biti svjestan svojih radnji. Mora postojati mehanizam za pravljenje rezervnih kopija kada govorimo o autonomnom rješenju, kada korisnik ima sve podatke pohranjene isključivo na mobilnom uređaju: korisnik može izgubiti svoj uređaj, a onda će podaci biti izgubljeni. I, čini se, ako aplikacija ne radi autonomno, već je povezana sa centralnim serverom, onda korisnik ne bi trebao imati takav problem, jer ako se uređaj izgubi, on će se spojiti na server, primiti sve svoje podatke ponovo sa servera i sve će biti ok. Međutim, korisnici ne koriste uvijek sigurnosne kopije na način na koji očekujemo :) Vrlo često ih koriste da jednostavno "vrate" podatke nazad. Ovo je zaista vrlo čudno ponašanje, ali korisnici mobilnih aplikacija su previše lijeni da shvate gdje bi mogli pogriješiti prilikom unosa podataka, te jednostavno vraćaju podatke i ponovo unose podatke za tekući dan. Nakon analize statistike rada sa Boss aplikacijom, shvatili smo da je to normalna praksa i da je ovakvo ponašanje korisnika češće nego što smo očekivali. A ako koristite sinkronizaciju s drugim uređajima, onda morate to riješiti. Ovdje postoji nekoliko rješenja: Ima tu još jedna stvar. Do sada smo sami čuvali rezervne kopije, kontrolisali ceo proces, hvatali radnje korisnika direktno u kodu kada je pritisnuo dugme "sačuvaj kopiju". Sve ovo se može kasnije obraditi. U platformi 8.3.9 postalo je moguće sačuvati sigurnosne kopije upravo pomoću platforme. A korisnik to radi bez našeg znanja. Ako se koristi sinkronizacija sa centralnom bazom podataka, onda se takav scenarij mora riješiti. Moramo nekako saznati na našem serveru da je korisnik obnovio prethodno sačuvanu kopiju i moramo mu dati neko rješenje. Ne možemo priuštiti da podaci nisu sinhronizirani. RAZMJENA Kada govorimo o privatnom rješenju na mobilnoj platformi, obično imamo kupca koji, na primjer, želi koristiti mobilnu platformu za svoje prodajne agente, i to tako da razmjenjuju podatke sa centralnom bazom podataka. Ovdje je sve jednostavno: jedna baza podataka, nekoliko uređaja, podignete server, uspostavite komunikaciju s njim. Dakle, problem razmjene između uređaja je lako riješiti. Ali ako govorimo o masovnoj aplikaciji, gdje postoji mnogo baza podataka, od kojih svaka ima vrlo veliki broj korisnika, situacija postaje složenija. Korisnici su preuzeli aplikaciju sa tržišta i žele da se međusobno sinhronizuju. Na primjer, muž je preuzeo aplikaciju za računovodstvo ličnih finansija, a sada želi da se i njegova žena poveže, a oni zajedno rade u istoj aplikaciji. Mnogo je korisnika, aplikacija se razvija, raste, a postoji i potreba za velikim, velikim brojem baza podataka. Kako sve ovo organizovati? Korisnici neće lično kontaktirati programere kako bi kreirali zasebnu bazu podataka za njih i omogućili sinhronizaciju. Žele da pritisnu dugme i da to odmah proradi. U istom trenutku. Kako dalje? Tu u pomoć dolazi mehanizam dijeljenja podataka. Omogućava vam da organizirate jednu bazu podataka, gdje postoji jedna zajednička konfiguracija, ali u isto vrijeme, neograničen broj korisničkih baza je pohranjen unutar jedne zajedničke baze podataka. Najbolji dio je što možete dodavati korisnike dinamički, programski, bez našeg sudjelovanja. U stvarnosti, korisnici jednostavno kliknu na dugme "registriraj se na server" i sve se dešava samo od sebe: za njega se kreira lična baza podataka na serveru i on odmah može da počne da radi u njoj. Kako uraditi? Prvo i najjednostavnije rješenje je da napišete svoju bazu servera sa ovim mehanizmom. Kada je naša kompanija počela da pravi Boss aplikaciju i razmenjuje u njoj, u prvoj verziji smo uradili upravo to: napisali smo serversku bazu podataka sa mehanizmom deljenja podataka. Sve je radilo, pogotovo jer nije bilo ništa komplikovano - osnovni separator je uobičajeni rekvizit. Ali onda smo shvatili da ponovo izmišljamo točak :) U stvari, postoji gotovo rešenje, a ono je već uzelo u obzir tačke o kojima još nismo ni razmišljali. Ovo je 1C: Fresh. Ovdje je osmišljena skalabilnost servisa: šta učiniti kada će biti puno podataka i baza podataka, kako rasti uz sve to. Postoji poenta u stvaranju rezervnih kopija područja podataka: to jest, mi ne pravimo samo rezervnu kopiju jedne zajedničke baze podataka, mi pravimo kopije određenog korisnika. Štaviše, mehanizam je takav da se kopije prave samo kada su zaista potrebne. Ako korisnik nije ušao u bazu podataka nedelju dana, onda ga ne kopiramo, jer se tu ništa nije promenilo. Još jedna Fresh karakteristika je da servis implementira mehanizam za smanjenje opterećenja na serveru, što je vrlo važno kada imate puno baza podataka. Generalno, Fresh je za nas nešto novo i zanimljivo. Malo po malo pokušavamo to shvatiti, ali uglavnom smo zadovoljni njegovim radom. Prijenos podataka. Kako to implementirati za razmjenu između uređaja
Platforma pruža dva mehanizma - SOAP i http usluge. Postoje nijanse kako pristupiti ovim uslugama kada je uključen mehanizam dijeljenja podataka. Konkretno, morate dodati parametre koji ukazuju na određeni broj područja kojem pristupate, jer platforma ne može odrediti kojoj bazi podataka pristupiti po korisničkom imenu. Osim toga, jedan te isti korisnik može raditi sa više baza podataka unutar jedne baze podataka (vidi sliku). Što se tiče usluga, aplikacija Boss implementira trenutnu razmjenu: jedan korisnik unosi podatke, a drugi ih prima. Korisnici mobilnih aplikacija navikli su na činjenicu da se sve događa trenutno, pa smo razmišljali koji servis je bolje koristiti - SOAP ili http. Brzina veze je odigrala ključnu ulogu. U http-u je brzina veze mnogo veća, a pri povezivanju preko SOAP-a dobijamo opis servisa koji je težak i dugo se učitava. Platforma ima način da pohrani opis usluge, ali zbog parametara koje dodajemo dinamički, ne možemo koristiti WS reference. Osim toga, pristup http uslugama je praktičniji i fleksibilniji prema našem iskustvu. Dakle, naš cilj je da implementiramo razmjenu u realnom vremenu. Odnosno, trudimo se da korisnik ne mora negdje otići, kliknuti na dugme, razmisliti o tome koliko su njegovi podaci relevantni, da li treba da ih ažurira... Podaci uvijek trebaju biti relevantni za korisnike. Toliko su navikli da rade u instant messengerima - jedan šalje podatke, drugi ih odmah prima. Sve se dešava trenutno. Isto važi i za aplikacije vezane za poslovanje: jedan prodavac je izdao prodaju, drugi mora odmah sagledati trenutnu situaciju bez preduzimanja ikakvih radnji. Stoga, Boss aplikacija koristi pozadinske poslove za razmjenu. Nakon što se svaki podatak upiše u bazu podataka, pokreće se pozadinski posao koji pokreće razmjenu. Prvi dio je slanje podataka na server. Tada drugi uređaji moraju znati da postoje novi podaci. Za to koristimo PUSH obavijesti. Ova shema već radi i radi dovoljno brzo. Ali htjeli smo to još brže, jer radimo u realnom vremenu i obično imamo malo podataka. Imamo mali XML, ali u isto vrijeme šaljemo poruku sa ovim podacima sa prvog uređaja na server, server šalje PUSH na drugi uređaj, a onda drugi uređaj, nakon što primi PUSH, inicira razmjenu sa svoje strane, obraća se serveru i traži podatke, prima te podatke i zatim šalje odgovor da su podaci primljeni. Ovo je dosta vremena, ali sami podaci su bili vrlo mali. Razmišljali smo o tome kako se ovaj proces može ubrzati. Da bismo to učinili, shvatili smo šta PUSH sadrži, kako se još može koristiti. Ispostavilo se da PUSH sadrži polja kao što su podaci i tekst. Dokumentacija za iOS i Android sadrži ograničenja na veličinu PUSH poruka, ali nam se to činilo nedovoljno i htjeli smo to empirijski otkriti. I provjerili smo da je zbir važećih znakova 981 karakter za iOS, a 3832 karaktera za Android. U potonjem slučaju, sasvim je moguće koristiti ograničenje; jedan ili više osnovnih objekata može se ugurati u takav volumen. A onda su programeri kompanije malo promijenili shemu. Kada nema puno podataka, šaljemo ih sa jednog uređaja, primamo ih na server, tu pakujemo u PUSH i šaljemo direktno na drugi uređaj u njemu. Šema je postala kraća, a razmjena se počela odvijati još brže :) Važna stvar upotrebe PUSH-a je da ne nervirate korisnike.
Vrlo je lako riješiti se ove situacije: samo nemojte slati puno PUSH poruka korisniku :) Ako on sada radi u aplikaciji, možete poslati puno poruka. Kada platforma radi, korisnik ne vidi PUSH, sve se dešava automatski za njega. Ali kada se aplikacija zatvori, klijent ima puno nepročitanih poruka. Stoga, ni u kom slučaju se sljedeći PUSH ne smije slati dok se od uređaja ne dobije odgovor da je aplikacija pokrenuta, aktivna i da je prethodni PUSH već obrađen. Još jedna nijansa razmjene je rad putem weba. Moramo maksimalno iskoristiti asinhroniju. Ne možete raditi kao i obično - napišite kod - pozovite funkciju - pričekajte da se izvrši - dobijete odgovor - i sve je ok. Ako radite preko weba, i dalje ćete se suočavati s određenim ograničenjima, na primjer, nestabilnim internetom, aktiviranim timeoutima pri obavljanju dugotrajnih operacija. Stoga je potrebno unaprijed razmisliti o arhitekturi. Pogledajmo primjer registracije uređaja, šta se dešava u aplikaciji kada se korisnik želi registrirati. Neko vrijeme vodi evidenciju, unio je dosta podataka, ali onda želi da prodavac radi i sa ovom bazom podataka. Korisnik klikne na dugme "registriraj". U početku je sve bilo vrlo jednostavno: uzeli su njegove podatke, snimili ih na server i, molim vas, možete raditi i povezivati korisnike. Ali onda smo došli u situaciju da su za neke korisnike baze podataka na uređaju do trenutka registracije već uvelike porasle. I ova šema više nije funkcionirala od tada dok se cijela baza podataka snimala na serveru, došlo je do prekida veze ili je jednostavno prekinut internet. Stoga smo jedan sinhroni poziv zamijenili mnogim kratkim. Sada se podaci dijele umjesto da se prenose odjednom. Ne čekamo ni na koji način da server obradi i snimi podatke. Poslali smo podatke, dobili odgovor da su podaci primljeni, prekinuli vezu. Periodično je potrebno da anketirate server, šta se tamo dešava i kako, a u međuvremenu na serveru se pokreće pozadinski posao koji beleži primljene podatke. Na ovaj način dobijamo dosta poziva servera, ali imamo garanciju da će sve proći kako treba. A ni vremensko ograničenje ni nestabilnost interneta neće vas spriječiti da sve podatke prenesete na server. AŽURIRANJA Razmjena između uređaja s različitim verzijama aplikacije
Budući da je riječ o masovnoj aplikaciji koja izlazi na tržišta, moramo uzeti u obzir neke od karakteristika procesa ažuriranja i razmjene podataka. Ako ste izdali aplikaciju za jedno preduzeće i odlučili da je ažurirate, onda obično samo date komandu da svi zaposleni zajedno instaliraju novu aplikaciju. To se ne može učiniti sa korisnicima koji su preuzeli aplikaciju sa tržišta. Uopšte im ne možete govoriti šta da rade. Na primjer, oni rade u aplikaciji i ne žele je ažurirati ni sada ni ikada. Nemaju automatsko ažuriranje, tako da je prilično česta situacija kada je više uređaja povezano na centralnu bazu, a svi su u različitim verzijama. Drugi razlog za ovaj fenomen je vrijeme objavljivanja na tržištima: različito je za iOS i Android. Često implementiramo ključne stvari, na primjer, popravljamo kritične greške, i ne želimo čekati da iOS provjeri novu verziju dvije sedmice, želimo barem samo za Android, ali želimo da objavimo ažuriranje odmah. Nemamo pravo komandovati korisnicima. Ako žele, ažuriraju se, a ako ne, ne rade ništa. Na slici je prikazan omjer instaliranja Boss aplikacije prema verzijama u GooglePlay-u, kao i statistika sa našeg servera - stvarni omjer verzija aplikacija koje su instalirane na uređajima koji su razmjenjivali podatke sa serverom tokom prošle sedmice. Evo kompleta za rad. To su različite verzije i različiti metapodaci. A mi treba da organizujemo normalnu razmenu u isto vreme :) Programeri se suočavaju sa sljedećim zadacima: Kako smo to uradili? 1. Koristimo 2 plana zamjene na serveru. Prvi je za dijeljenje između uređaja, a drugi za ažuriranja. Na primjer, poslali smo priručnik korisniku, ali on nema mjerne jedinice, odnosno nepotpune podatke. Moramo zapamtiti ovo. A kada bude ažuriran, moramo mu poslati sve informacije koje nije imao. Tome služi drugi plan razmjene. 2. Za pisanje i čitanje objekata koristimo isti mehanizam koji se koristi za sigurnosne kopije, odnosno spremamo verziju metapodataka. U ovom slučaju, mi radimo sa serverom i možemo sebi priuštiti da dodamo sve što želimo direktno u konfiguraciju, tako da jednostavno dodajemo šeme metapodataka u konfiguraciju u obliku izgleda kako se aplikacija razvija. Kako pratiti velike greške tokom razmjene i na serveru
Prvo, morate kontrolirati dostupnost samog servera. Ovo se dešava serverima - oni padaju. Nismo izmislili ništa posebno za praćenje, već smo jednostavno pronašli bota u telegramu koji vrišti ako nešto nije u redu. Svaki minut proverava performanse servera, a ako server odjednom postane nedostupan, počne da vrišti, administratori to vide i pokreću server. Također prikupljamo dnevnik grešaka iz dnevnika. Takođe ništa natprirodno - samo prikupljamo dnevnik grešaka svaka tri sata, šaljemo ih poštom i povremeno ih pregledavamo. Ovo pomaže da se sagledaju uobičajeni problemi i neke vrste izuzetnih situacija. Nije teško pročitati svoju poštu, pronaći i brzo ispraviti greške. Ali ovo vam omogućava da brzo identificirate i riješite probleme koji mogu rasti s rastom baza podataka. Još jedna važna stvar - svakako dajte korisniku priliku da se "žali". To poboljšava naš status u njihovim očima i spašava nas. Ima korisnika, kako ih mi zovemo, "histeričara" koji na najmanju grešku počnu da nam šalju gomilu poruka poštom da ništa ne radi, baza podataka se ne učitava, sve je užasno loše. Ali ponekad nas zaista spasu, jer ponekad nađu takve bube koje drugi nekim čudom nisu našli, ozbiljne bube. Korisnik se ne može uplašiti. Ne zastrašujuće poruke, ništa drugo. Treba im sve lijepo objasniti i ponuditi da se žale. I obećavamo da ćemo sve riješiti. Tada su korisnici sretni, jer vide da su zbrinuti, i odmah vjeruju da će im se pomoći :) Ovaj članak je napisan na osnovu rezultata izvještaja pročitanog na INFOSTART EVENT 2016 DEVELOPER konferenciji. Više članaka možete pročitati. 2020. pozivamo sve da učestvuju u 7 regionalnih susreta, kao i na jubilarnom INFOSTART EVENT 2020 u Moskvi. Offline u prošlosti, biti Online danas je neophodno. Barem za moderni poslovni svijet. Prezentacije proizvoda i usluga brenda, online naručivanje i dostava, održavanje baze kupaca, komunikacija sa kupcima i još mnogo toga - sve je to jednostavno nemoguće bez prisustva na Internetu. Ako vam je potrebna aplikacija, morate imati i Front-end (web sučelje) i Back-End (pozadinu vaše aplikacije). A ako želite da možete uređivati sadržaj svoje aplikacije bez uključivanja programera, potreban vam je dobar admin panel. Dok je Front-end u prostoru mobilnih aplikacija izgrađen korištenjem tehnologija kao što su X-Code i Java, Back-end, gdje će se skladištiti baza podataka i sva logika aplikacije, zahtijeva profesionalno poznavanje programskog jezika na strani servera. Dobar primjer je PHP, koji je vjerovatno najpopularniji programski jezik koji se koristi za gotovo svaki razvoj na strani servera. Ovo je neprikosnoveni lider. Postoji mnogo upotreba za PHP: statične i dinamičke web stranice + prilagođeni sistemi za upravljanje sadržajem, društveni mediji, specijalizovani CRM sistemi, softver za e-trgovinu i još mnogo toga. Naravno, postoje besplatni ili jeftini serverski dijelovi i kontrolne ploče. Međutim, u mnogim slučajevima ne pružaju potreban nivo pogodnosti, prilagođavanja i nadogradnje. Naši programeri rade sa tehnologijama kako bi implementirali širok spektar rješenja za različite poslovne ciljeve, potrebe i zahtjeve. Analiziramo sistemske zahtjeve za svaki projekat pojedinačno i koristimo različite specijalizovane serverske softvere za optimalne performanse vaše mobilne aplikacije. Ako tražite tim koji vas može dovesti do najpametnijeg i najisplativijeg rješenja za izgradnju aplikacije od nule ili ponovnu izgradnju postojeće za savršeno korisničko iskustvo, ne morate više tražiti. Appsmob je spreman pomoći vam da pronađete najbolje rješenje za vas.12.3.2. Kreiranje XSLT dokumenta
Kompanija Kontakt Država Telefon
Opće odredbe za sve pristupe
(id:
]
(id: 5625, naziv: "Hleb", ažurirano: "2013-01-06 06:23:12", je izbrisano: 0),
(id: 23, naziv: "Kuhani griz", ažurirano: "2013-02-01 14:44:21", je izbrisano: 0), (Principi ažuriranja podataka na uređaju
Pristup 1: Sve je uvijek sinhronizirano
Pristup 2: sinhronizirajte samo ažurirano
Pristup 3: Sinhronizacija u serijama
Pristup 4: Ispravno vrijeme serije
Pristup 5: Sinhronizirajte se sa znanjem o onome što je već na uređaju
Zaključak
№
Pristup
Obim saobraćaja(5 - veliki)
Intenzitet rada(5 - visoka)
Upotreba memorije uređaja(5 - visoka)
Ispravnost podataka na uređaju(5 - visoka)
Možete odabrati određeni uređaj
1
Sve je uvek sinhronizovano
5
1
5
5
br
2
Samo ažurirani
1
2
5
3
br
3
Sinhronizacija u serijama
1
3
1
3
br
4
Ispravna sinhronizacija u serijama
1
3
1
3
br
5
Sinhronizacija sa znanjem o tome šta je već na uređaju
2
5
2
5
Da
