Help: validare idee tampita

[AdrianB1]

M-a intrebat cineva cat de complicat e sa faci o aplicatie pe telefonul mobil care sa trimita pozitia citita din GPS o data la X minute undeva intr-o baza de date si i-am zis ca teoretic e banal, asa ca a revenit cu intrebari concrete despre cum se face pentru care i-am dat niste raspunsuri aparent corecte, dar mi-a venit si o idee aparent tampita de a simplifica lucrurile si sunt curios ce pareri aveti. Constrangerile suplimentare fata de intrebarea originala sunt cauza ideii

Constrangeri si idei:

1. Au ceva experienta interna cu Visual Studio si Visual Basic/C#, dar nimic pentru Android; ar prefera sa faca aplicatia pentru Android in Visual Ceva cu Xamarin. E o idee buna sau sa incerce sa scrie alea 10 linii de cod in ceva nativ pentru Android? Sunt mai mult de vreo 10-20 linii de cod, ca ordin de marime?

2. Baza de date e in spatele unui firewall si nu ar vrea sa deschida un port in firewall pentru niste telefoane de pe Internet care sa scrie direct acolo, in schimb exista web servere publicate spre internet. Aici vine ideea mea tampita: in loc sa incerce sa scrie intr-o baza alea 4-5 campuri (ID telefon sau user, longitudine, latitudine, suma de control) aplicatia sa incerce sa deschida o pagina de web cu un query cu acesti parametri, iar pagina sa returneze ori eroare daca suma de control nu se potriveste, ori o confirmare sau un alt cod de control. Cum ajunge informatia in baza de date? Simplu: serverul de web scrie log-ul in baza de date. Asta inseamna ca nici un telefon nu are acces la baza, iar un DDOS la web server e probabil singurul risc asumat. Cum suna asta?

3. Mai departe ar vrea sa afiseze intr-o pagina de web printre altele adresa curenta si ETA pana la destinatie. Adresa curenta se poate afla prin serviciul de geolocatie de la Google, nu e nevoie de prea mare precizie. Are cineva experienta cu acest serviciu? Nu prea e clara licentierea. Apoi, ETA pana la destinatie se poate afla tot cu un serviciu Google care da o estimare de navigare auto din locatia x (curenta) la locatia y (destinatia, cunoscuta), dar iarasi nu am idee cat de bine merge serviciul si care e licentierea. A intrebat un coleg la Google, aia i-au dat un contact la un service provider din Romania, aia i-au dat un raspuns ca fac ei tot sistemul pentru $$$$, dar nici o informatie despre cat costa (daca) folosirea API-ului respectiv. Cica ar fi gratuit pana la vreo 1000 sau 5000 de apeluri pe zi, apoi ... suna un prieten si cere pret. Stie cineva mai mult decat atat?

 

[miahi]

1. De obicei se adună mai mult de 20 de linii de cod, pentru că trebuie să descrii și interfețe, timere, permisiuni, servicii care să ruleze în background care să nu-ți termine bateria în 3 ore și tot felul de alte chestii. În principal merge cu copy/paste de pe net, ex: Tutorial GPS cu Xamarin, tutorial video și tot așa. Ideea cu Xamarin e că poți scrie C# și traduce el în ce vrei (rezultând cât de cât portabilitate iOS/Android/WinPhone dacă nu ai nevoie de suport low level pentru ceva), downside că va trebui să vezi cum se face ceva specific în Xamarin.

2. Nu expune nimeni (normal la cap) baze de date direct pe net. Pui un serviciu simplu în față, preferabil cu ceva securitate (și basic auth e mai bine decât deloc). Cum îl faci depinde de DB, de server și cunoștințe, în principal o aplicație care să ia un json și să-l scuipe în DB și să zică dacă a reușit nu ia mai mult de o oră. Dar trebuie să ai un server și să-l întreții. Adunatul logurilor de server (nestructurat) în DB poate să însemne mult garbage și mai multă muncă la parsat datele utile.

3. API-ul google maps e limitat după tipul de serviciu:
- Directions 2500 afișări/zi (asta dacă vrei traseu complet)
- Distance 2500 elemente/zi (ăsta îi va trebui), unde elemente = Each query sent to the Google Maps Distance Matrix API is limited by the number of allowed elements, where the number of origins times the number of destinations defines the number of elements. Nu mi-e prea clar ce înseamnă asta.
- hartă 25000 afișări/zi
După ce treci de prag ai pachete de 1000 la $0.5.
Vezi aici detalii https://developers.google.com/maps/pricing-and-plans/

Ideea e să nu expui pe net ceea ce nu e nevoie (ca să nu consumi în plus), pui o autentificare înainte. Google RO se fac că plouă cu ce încasează irlandezii (la toate serviciile oferite), ca să nu plătească impozite local.

Există soluții de hărți "free" folosind OSM, dar cam trebuie să-ți implementezi tu o parte importantă (OSM îți oferă doar hărțile), nu e mai ieftin nici pe termen lung pentru aplicație care nu e expusă pe web pentru toți.


Nu mi-e clar cât de complicată era soluția inițială, pentru că asta e soluția "uzuală" de adunat date.

 

[AdrianB1]

1. Din motivul 2b) tocmai e de preferat sa fie usor de pus si pe Windows Phone si iPhone, la nevoie. Aplicatia in principiu nu are nevoie de interfata pentru ca in timpul rularii nu afiseaza nimic, poate doar un buton de inchis aplicatia pe undeva. Daca trimite o pozitie o data la 5 minute chiar mananca bateria?

2. Logurile de IIS (server care deja exista) in format W3C (structurat) ar fi in teorie suficiente pentru datele de colectat, iar la acel URL care raspunde doar cu eroare (daca pagina e cazuta sau inexistenta), cu nimic (daca serverul e cazut) sau cu un numar (suma de control a confirmarii) nu e public, adica nimeni nu stie ca exista si URL-ul folosit nu e catre root. Ma gandeam sa renunte la autentificare din 2 motive:
a) oricum in log se aduna orice cerere HTTP, si alea valide si alea invalide
b) oamenii vor sa puna la nevoie aplicatia pe mai multe telefoane fara sa configureze mai nimic la ele, mai ales autentificare, cel mult numarul masinii in care e telefonul. Aplicatia e ca sa vada un client al unui transportator unde e camionul care ii aduce marfa in cateva locatii predefinite si, in functie de locatie, ora estimata la care ajunge ca sa pregateasca descarcarea. Camioanele nu sunt intotdeauna aceleasi, ideea era sa fie o aplicatie simpla de tot care la prima rulare sa intrebe numarul masinii si atat, mai departe sa trimita de pe acelasi telefon asociat acelui camion (nu se schimba intre ei).

3. Pai sa zicem 20 de camioane pe zi cu rapoarte la 5 minute, 240 de rapoarte pe ora. Poate s-ar incadra in limita de 2500, altfel pot da rapoartele si o data la 15 minute, ca nu e atat de grav, si atunci cu 80 de apeluri pe ora acopera mai mult de 24 de ore pe zi Daca vor mai multe nu e o problema de pret, ci de costul birocratiei unei facturi de 2-3$. Nu e nevoie de directions, doar de locatie (si asta vine direct din GPS ca si coordonate), adresa aproximativa (autostrada A1 km 80 e mult prea precis ) si de distanta si durata pana la destinatie. Nu e folosit sistemul pentru rute, ci pentru a sti cu aproximatie de 15 minute cand ajunge camionul la descarcat.

 

[miahi]

1. Dacă e prost făcută aplicația, mănâncă baterie și dacă trimiți o dată pe oră . Se văd câteva probleme interesante, pentru că ai mai mulți pași: 1. Pornesc GPS 2. Iau locație 3. Opresc GPS 4. Trimit la server. Ce se întâmplă dacă telefonul nu reușește un fix? Trebuie un timeout, poate și retry, poate te mulțumești cu coarse location după câteva retry-uri. Ce se întâmplă dacă nu poate să trimită la server? Trebuie un timeout, poate și retry, poate stochezi local și trimiți bulk când merge netul. Dacă astea nu-s limitate poți să te trezești că doar a frecat GPS-ul timp de 12 ore continuu pentru că mașina e într-un loc izolat și nu obține fix. Ce se întâmplă dacă încurci pașii și faci 4 înaintea lui 3? Ții resursa pornită degeaba. Bine, dacă telefonul stă tot timpul în camion și alimentat nu e foarte grav, altfel e mai complicat.

2. Asta cu securitatea prin obscuritate nu e chiar ce aș folosi (măcar un checksum în cerere în cazul ăsta, ca un fel de autorizare), dar poate am eu prea mulți pitici.
Faptul că pagina răspunde cu un mesaj specific dacă a fost sau nu ok cererea înseamnă că ai deja datele parsate și verificate - nu mai e mult până a le scrie "curat". Pe de altă parte, ce face telefonul dacă dă eroare cererea e discutabil, pentru că oricum, și dacă nu există pagina, tot se va scrie cererea în logurile serverului. Singurul retry ar fi dacă nu răspunde serverul deloc.

3. Ce e dubios e acel times între number of origins și number of destinations. Sunt origins/destinations distincte? Nu e clar din text.

Un loc de trial and error e la partea de timeout-uri. Am avut o aplicație pentru stații OMV, pentru validarea de vouchere, unde ne-am gândit că e ok un timeout de 30 de secunde pentru o cerere simplă (cod voucher + alte câteva chestii trimise la un server central, răspuns de tip ok/nok). De fapt nu a fost deloc suficient, pentru că unele stații au doar conexiuni 3G, se mai deconectează, mai merge și prost (2G), și până la urmă nu doar s-a crescut timeout-ul la peste 1 minut, dar s-a implementat și validare offline, că se făcea coadă la case.