Elaborarea Unei Aplicatii Pentru Dispozitive Mobile

Universitatea „Petru Maior” din Târgu Mureș

Facultatea de Științe Economice, Juridice și Administrative

Programul de studii de licență: Contabilitate și infomatică de gestiune

Elaborarea unei aplicații pentru dispozitive mobile

2016

Introducere

Motivarea alegerei temei

Tema proiectului meu este “Dezvoltarea aplicațiilor pentru dipozitivele mobile” și reprezintă rezultatul curiozității mele și al unei provocări.Motivul alegerii acestei teme rezultă din dorința de a cerceta acest subiect deoarece în zilele noastre echipamentele mobile tot mai mult fac parte din viața noastră atât la nivelul țării noastre cât și la nivel mondial. În aceste condiții universul dispozitivelor mobile și programele informatice devin din ce în ce mai puternic asigurându-și o nișă importantă în economia mondială. Consider acest segment al economiei unul foarte prosper cu o perspectivă foarte bună în viitor deoarece el stă la baza dezvoltării tuturor mediilor economice.

Remarcăm cum în viața noastră își fac loc noile tehnologii apărute pe piața națională și internațională și dau omenirii o altfel de alternativă la informare, organizare si desfășurare a activităților. Aceste noi echipamente mobile sunt menite să simplifice viața fiecăruia ajutându-l, organizându-l, ele fiind prezente în majoritatea activităților pe care omul le întreprinde. Pare de necrezut pentru cineva care și-a petrecut majoritatea vieții, notându-și în bloc-notes sau agenda următoarei zile diferite mențiuni pentru a nu le uita.

Acum tot acel om cu o aceeași viață și cu aceeași agendă sufocant de încărcată, își poate organiza munca si timpul chiar de pe telefonul mobil sau de pe noile si inovatoarele tablete electronice, de diferite tipuri, mărimi și mărci, putând să citească într-o formidabilă lejeritate aceeași agendă, dar si poate lucra numai cu un mic obiect in mana.

Știm că timpul reprezintă o valoare importantă în viața fiecăruia dintre noi, el fiind poate cel mai deficitar lucru de care suntem mereu dependenți și care ne limitează de la multe activități. Uneori, simțim că pur și simplu nu avem destul timp ca să realizăm sarcinile de la locul de muncă. Ne-am dori să avem mai mult timp ceea ce, în realitate, este aproape imposibil. Fizic nu avem cum sa obținem mai mult timp, așa că soluția este să îl folosim optim pe cel pe care îl avem la dispoziție. Dar nu se întâmplă mereu așa, de ce? Pentru că de multe ori suntem nevoiți să îl folosim pe lucruri neesențiale cum ar să aștepți autobusul în stație fără a ști cu exactitate când va veni. De aceea m-am gândit să creez ceva în folosul comunității și prin asta să reduc din timpul pierdut în zădar în așteptarea transportului public. Ideea mea constă în dezvoltarea unei aplicații pentru dispozitivele mobile care ar permite utilizatorului să dețină la îndemână informația despre orarul transportului în comun. Pentru că cei mai mulți dintre noi dețin gadget-uri care le permite să acceseze o astfel de aplicație astfel încât implementarea acestei idei este pe cât se poate de fezabilă. Fiind student și utilizator al transportului public din orașul Tîrgu Mureș, m-am ciocnit de foarte multe ori cu cu această problemă, fiind pus în situația de a aștepta timp în stațiile de autobus deoarece fiind un oraș mic intensitatea circulației autobuselor este mică din lipsa unei cereri mari de la utilizatori, majoritatea rutelor având un interval de timp de peste treizeci de minute, ceea ce este destul de mult și creează un oarecare disconfort.

Am ales această temă de licență pentru că problema pusă în fața în opinia mea este una foarte actuală și căutarea unei soluții pentru ea reprezintă un studiu de caz marcant pentru comunitate și pentru cunoștințele proprii, abordarea acestui subiect fiind unul interesat și în același timp el reprezintă o provocare pentru mine de a-mi pune la încercare cunoștințele acumulate în timp.

În continuare voi prezenta în primul capitol mai multe aspecte teoretice în linii generale care stau la baza creării unei aplicații mobile și caracteristicile relevante de care se ține cont în acest proces. În partea secundă voi prezenta un concept și modelul de aplicație care reprezintă o bază de date cu orarul transportului public din Tîrgu Mureș. În ultima parte voi veni cu concluzii și cu un plan de dezvoltare a aplicației cu implementarea mai multor comodități pentru utilizator, dar și posibilitatea de ieși cu produsul pe piață.

Capitolul 1 Conceptul de aplicație mobilă

Caracteristicile unei aplicații

În zilele noastre, dispozitivele electronice devin tot mai mici și mai puternice și sunt disponibile pentru om în toate locurile posibile. Datorită acestei evoluții rapide a tehnologiei și a nevoilor oamenilor de a avea cât mai aproape tate aplicațiile necesare, dezvoltarea acestor aplicații a luat o amploare foarte mare. Acestea, prin mărimea lor și necesarul realizării ca aplicație orientată spre cetățean reprezintă o noua categorie de aplicații spre deosebire de cele obișnuite pentru calculatoare sau laptop-uri sau aplcațiile web.

Aplicațiile mobile depind foarte mult de caracteristicile dispozitivului, de platforma dispozitivului și a sistemului de operare implementat pe dispozitivul mobile pe care rulează aceste aplicații. Astfel cum exista o diversitate foarte mare de dispozitive mobile și aplicațiile pentru acestea trebuie să prezinte această diversitate.

În opinia mea o aplicație de succes trebuie să fie utilă, să fie inovatoare și să fie ușor de folosit. Acesta e cel mai important factor, dacă aduce comoditate, economie de timp, acces rapid la informație și divertisment pentru utilizator. A ști ce caracteristici acoperă necesitățile utiizatorilor, ce i-ar putea încânta vă poate ajuta să vă decideți asupra căror lucruri să vă concentrați eforturile. Caracteristicile cele mai importante fiind:

Generalitatea aplicației este o caracteristică prin care se măasoară dimensiunea grupului țintă, persoanele cărora aplicația le va fi utilă. Astfel, pe baza categoriilor din care face parte aplicația se stabilește și dimensiunea grupului țintă. Cu cât aplicația este mai generală, cu atât numărul posibililor utilizatori va crește și astfel dimensiunea grupului țintă va fi mai mare.

Fiabilitatea reprezintă gradul în care aplicația continuă să funcționeze în ciuda erorilor apărute fără a afecta utilizatorul și gradul în care aceasta este operațională în ciuda defectării sistemului hardware sau software

Corectitudinea este o caracterisitică ce presupune lipsa erorilor din cadrul aplicației, capacitatea acesteia de a produce rezultate corecte pentru date de bază introduce correct.

Caracterul prietenos al aplicației este o caracteristică foarte importantă mai ales pentru aplicațiile de pe dispozitivele mobile. Aceasta presupune ca aplicația să fie cât mai aproape de utilizator, să aibă o interfață cât mai ușor de utilizat și cât mai intuitive. Aplicațiile care sunt greu de utilizat vor consuma mai mult timp pentru înțelegere și astfel utilizatorii se vor îndrepta către alte aplicații mai intuitive, considerând-o pe aceasta o aplicație cu calitate scăzută.

Continuitatea este o caracteristică prin care aplicațiile folosesc elemente cunoscute de la alte aplicații software, astfel încât utilizatorul să nu mai depună efort pentru învățarea utilizării noii aplicații. Această caracteristică vine în sprijinul caracteristicii prezentate mai sus deoarece dacă în cadrul aplicației sunt prezentate elemente cunoscute deja de utilizator, caracterul prietenosal acesteia este mai mare și astfel aceastaeste mai ușor de utilizat.

Portabilitatea este o caracteristică de calitate prin care se măsoară posibilitatea de rulare a aplicației pe diferite dispozitive mobile. Dispozitivele mobile prezintă o gamă foarte largă de modele și de aceeea este foarte important ca o aplicație să aibă posibilitatea de a fi rulată pe un număr cât mai mare de dispozitive. Astfel se asigură o omniprezență a aplicației și o continuitate în cazul în care utilizatorul își va schimba modelul de telefon.

Securitatea este capacitatea de a conserva toate resursele la parametrii definiți de dezvoltator și utilizator.

Cu toate că sunt folosite aceleași unelte pentru dezvoltare, programarea aplicațiilor pentru dispozitivele mobile este diferită, puțin mai dificilă, deoarece dezvoltatorul trebuie să raspundă unor provocări precum:

Bateria este cel mai important punct care trebuie în considerare în dezvoltarea unei aplicații mobile. O aplicație cu un timp al procesorului mare va conduce la consumul rapid al bateriei, ceea ce face ca aplicația sa fie inutilă

Procesoul dispozitivelor mobile au frecvențe mult mai mici, afectând timpul efectuării operațiilor sau interogării asupra bazei de date.

Dimensiunea dispozitivului impune foarte multe restricții în ceea ce privește interfața utilizatorului. Se recomandă ca aplicația să ceară utilizatorului să interacționeze cu cât mai puțin text, din cauza tastaturii, considerate incomodă. De asemenea, citirea unui text cu foarte multe informații de pe un dispozitiv mobil nu este foarte agreată.

Memoria în cazul dispozitivelor mobile este calculată în megabytes. Aceasta nu poate fi mărită ca în cazul spațiilor de stocare, prin folosirea cardurilor de memorie. Aplicația nu trebuie sa păstreze foarte multe date în memorie, pentru ca sistemul să ruleze ân condiții normale.

Securitate este cea mai importantă caracterisitcă a unei aplicații mobile. Datorită faptului că un dispozitiv poate conține informații personale, securitatea înseamnă introducerea a cel puțin unei parole pentru deschiderea acestuia, criptarea datelor, permisiuni pentru instalarea/dezinstalarea aplicațiilor, etc.

Accesul la rețea este indispensabil unui dispozitiv mobil. O aplicație trebuie să gestioneze foarte bine cazurile în care dispozitivul trece de la o conexiune cu fir la una fără fir, sau în cazul în care nu există conexiune.

1.2. Criterii de clasificare a aplicațiilor

Aplicațiile mobile au cunoscut o diversitate foarte mare în ultimul timp, datorită faptului că telefoanele mobile sunt cele mai folosite dispozitive electronice. Aceste aplicații se împart în mai multe categorii:

aplicații de informare generală – sunt puse la dispoziția oricărui utilizator ce dorește să se informeze într-un anumit domeniu precum timpul probabil, programul TV, horoscop;

aplicații cu logare folosind datele personale – sunt aplicațiile în care se cer anumite informații personale pentru autentificare, informații ce vor fi verificate cu unele existente pe server;

aplicații de comunicare în rețea – sunt aplicațiile prin intermediul cărora utilizatorii comunică cu alți utilizatori la distanță;

aplicații economice – sunt aplicațiile prin intermediul cărora se fac achiziții de bunuri, se realizează plăți sau alte activități economice;

jocuri – sunt aplicațiile de divertisment cu ajutorul cărora utilizatorii își petrec timpul liber.

1.3. Ce este un dispozitiv mobil

Un dispozitiv mobil este un dispozitiv de calcul, de obicei, suficient de mic pentru a fi portabil, de asemenea, cunoscut ca un computer portabil sau pur și simplu portabil, având un ecran de afișare tactil și/sau o tastatură miniatură și cu o greutate mică .

Un dispozitiv de calcul portabil are un sistem de operare și poate rula diferite tipuri de aplicații software. Cele mai multe dispozitive portabile pot fi, de asemenea, echipate cu Wi-Fi , Bluetooth , NFC și capabilități GPS care pot permite conexiuni la Internet și alte dispozitive, cum ar fi un automobil sau un set cu cască microfon sau pot fi folosite pentru a oferi servicii bazate pe localizare. O caracteristică a dispozitivelor este capaciatea de reda fișiere video sau muzică. Camerele foto de asemenea sunt găsite în mod obișnuit pe aceste dispozitive, împreună cu o sursă de alimentare de la baterie stabilă, cum ar fi o cele cu litiu . Din ce în ce mai mult dispozitivele mobile conțin astfel de senzori cum ar fi accelerometre , compasuri , magnetometre sau giroscoape , care permite detectarea mișcării și asigură orientarea în spațiu.. Dispozitivele mobile pot furniza utilizatorului posibilitatea de a se autentifica biometric cum ar fi folosind camera foto încorporată pentru recunoaștere a feței sau cu ajutorul unui senzor de amprentă digitală de recunoaștere a amprentelor digitale. Exemple sunt Android " Face Deblocare " sau ID-ul Apple Touch .Telefoanele inteligente și tabletele sunt unele din cele mai dinamice dispozitive și unele din cele mai evoluate din punct de vedere al dezvoltării tehnologice și a electronicii moderne. Studiind această dinamică, este greu să propui o definniție certă a termenului de dipozitiv mobil.

Caracteristicile care definesc un echipament mobil sunt:

Încorporează cel puțin un receptor wireless care poate fi conectat la o sursă de Internet WI-FI, rețea celulară de date sau orice altă tehnologie care permite conectarea la Internet

Posedă un mod de depozitare internă a datelor

Aplicațiile pot fi obținute din mai multe surse : La instalarea sistemului de operare, accesibile din browser web, procurate și instalate de la terți.

Dețin elemente de sincronizare cu alte dispozitive: desktop/laptop, servere ale organizației, servere ale providerului de servicii de comunicații, alte servere, etc.

Încorporează una sau mai multe camere foto și video

Posedă un microfon

Unele dețin suport pentru dispozitivele de memorie externă.

1.4. Tehnologii de transmitere a datelor utilizate de echipamentele mobile

Echipamentele mobile sunt foarte populare în rândul utilizatorilor deoarece ele le oferă proprietarilor săi posibilitatea de a gestiona datele prin intermediul mediilor de transmisie fără fir, ele comunicând prin intermediul undelor radio, microundelor, raze infraroșii sau raze laser în cadrul conexiunilor fără fir (wireless). Cele mai populare medii fiind Bluetooth, Wi-fi si NFC.

Bluetooth

Bluetooth este un standard pentru o rețea personală (PAN) fără fir (wireless), bazată pe unde radio. Această tehnologie a fost inveentată în 1994 de către compania Ericsson.„Bluetooth” este o traducere în engleză a cuvântului scandinav Blåtand/Blåtann,, astfel era supranumit regele viking Harald I al Danemarcei în sec. al X-lea. Harald I a reușit sa unească Norvegia și Danemarca de unde și era foarte renumit ca fiind foarte comunicativ și priceput să îi facă pe oameni să comunice între ei. În română bluetooth s-ar traduce „dinte albastru”. Bluetooth este un protocol standard de comunicații destinat în primul rând pentru un consum redus de energie, cu o rază scurtă de acțiune bazat pe microcipuri transceiver low-cost în fiecare dispozitiv .

Astăzi această tehnologie este utilizată pe larg găsindu-se aproape pe toate dispozitivele mobile.

Wi-fi

WiFi este o tehnologie care folosește undele radio pentru a oferi conectivitate la rețea. O conexiune WiFi este stabilită cu ajutorul unui adaptor wireless pentru a crea hotspot-uri – zone în vecinătatea unui router wireless care este conectat la rețea și permite utilizatorilor să acceseze serviciile de internet. Odată configurat, WiFi oferă conectivitate wireless pentru dispozitivele care emit frecvențe între 2,4 GHz – 5 GHz , pe baza cantității de date în rețea. Tehnologia fără fir este răspândită pe scară largă în ultimul timp și puteți obține conexiune la ea aproape oriunde la domiciliu, la locul de muncă, în biblioteci, școli, aeroporturi, hoteluri și chiar în unele restaurante. La fel ca telefoanele mobile, o rețea WiFi utilizează undele radio pentru a transmite informații într-o rețea. Calculatorul trebuie să includă un adaptor wireless care va traduce datele trimise într-un semnal radio. Același semnal va fi transmis, printr- o antenă, un decodor cunoscut ca router. Odată ce e decodat, datele vor fi trimise la Internet printr -o conexiune prin cablu Ethernet.

Pe măsură ce rețeaua fără fir funcționează ca un trafic cu două sensuri , datele primite de pe internet va trece, de asemenea , prin router-ul care urmează să fie codificate într -un semnal radio care va fi primit de către un adaptor wireless al calculatorului .

NFC

Near-field communication (NFC) este un set de protocoale de comunicare care permit două dispozitive electronice , dintre care unul este , de obicei, un dispozitiv portabil , cum ar fi un smartphone , pentru a stabili o comunicare prin aducerea lor în termen de aproximativ 4 cm (2 inch) una față de cealaltă .

Capitolul 2. Modelarea unei aplicații pentru dispozitive mobile

2.1. Fazele dezvoltăarii unei aplicații

Pentru dezvoltarea unei aplicații se urmăresc 4 faze fundamentale:

Analiza

Proiectarea

Implementarea

Testarea

Cu toate că fazele de mai sus se referă în exclusivitate la ciclul de viaţă programului software, ele se aplică și în alte etape de existență prin care trece un produs de la „concepere” până la „moarte”.

1. Faza de analiză

În prima fază se stabilesc cerinţele sistemului, independent de forma în care acestea vor fi executate. Aici se stabilesc obiectivele pe care clientul vrea să le atingă. Finalul acestei faze reprezintă un raport cu toate solicitările clientului care trebuie de efectuat. Raportul caută să înfățișeze toate solicitările din perspectiva clientului, definind obiectivele şi interacţiunile la un grad descriptiv ridicat, neatârnat de detaliile de implementare, ca de ex, de exemplu: exprimarea problemei, previziunile clientului sau normele pe care trebuie să le satisfacă produsul. Faza de analiză poate fi interpretată ca o rafinare a detaliilor. Diferența dintre detaliile de nivel înalt şi cele de nivel scăzut sunt puse mai bine în evidenţă de abordările top-down (unde se merge către detaliile de nivel scăzut) şi bottom-up (care tind către detaliile de nivel înalt). Documentul cerinţelor poate fi realizat într-o manieră formală, bazată pe logică matematică, sau poate fi exprimat în limbaj natural. În mod tradiţional, el descrie obiectele din sistem şi acţiunile care pot fi realizate cu ajutorul obiectelor. Aici noţiunea de „obiect” nu trebuie confundată cu obiectul din programarea orientată obiect. Descrierea obiectelor şi acţiunilor trebuie să fie generală şi să nu depindă de o anumită tehnologie. Desigur, într-o abordare POO, descrierile vor lua forma obiectelor şi metodelor, însă în alte abordări, obiectele pot fi de exemplu servicii care accesează baze de date. În general, documentul cerinţelor descrie ontologia proiectului, adică vocabularul de cuvinte cheie (în special construcţii substantivale şi verbale) care va fi utilizat pentru definirea protocolului specific aplicaţiei. Descrierile acestea nu implică proiectarea arhitecturii aplicaţiei, ci enumerarea părţilor componente şi a modului în care acestea se comportă. Mai târziu, în faza de proiectare, acestea vor fi transformate în primitive informatice, precum liste, stive, arbori, grafuri, algoritmi şi structuri de date.

Mai concret, documentul trebuie să conţină descrieri pentru următoarele categorii:

–  Obiecte: Documentul trebuie să definească mai întâi ontologia sistemului, care este bazată în mare parte pe construcţii substantivale pentru identificarea pieselor, părţilor componente, constantelor, numelor şi a relaţiilor dintre acestea;

–  Acţiuni: Documentul trebuie să definească de asemenea acţiunile pe care trebuie să le îndeplinească sistemul şi care sunt sugerate în general de construcţii verbale. Exemple de acţiuni sunt: metodele, funcţiile sau procedurile;

–  Stări: Sunt definite ca mulţimi de setări şi valori care disting sistemul între două ipostaze spaţio-temporale. Fiecare sistem trece printr-o serie de schimbări de stare. Exemple de stări sunt: starea iniţială, cea finală sau stările de eroare. Cele mai multe stări depind de domeniul problemei. Stările sunt asociate cu obiectele sistemului. Un eveniment declanşează o tranziţie de stare care poate conduce la îndeplinirea unei acţiuni de către sistem;

–  Scenarii tipice: Un scenariu este o secvenţă de paşi urmaţi pentru îndeplinirea unui scop. Când sistemul este terminat şi aplicaţia este disponibilă, clientul trebuie să poată utiliza, într-o manieră cât mai facilă şi clar specificată, toate scenariile tipice ale aplicaţiei. Scenariile tipice trebuie să reprezinte majoritatea scenariilor de utilizare ale aplicaţiei. Ponderea acestora variază de la un sistem la altul, dar 90% se consideră o proporţie acceptabilă. Bineînţeles că un sistem cu un singur scenariu de utilizare este relativ simplu de obţinut, pe când unul cu mii de scenarii posibile va fi mult mai dificil de analizat. Deseori este invocată regula 80/20: 80% din funcţionalitatea sistemului se realizează cu 20% din efortul de muncă. Executarea restului minoritar de funcţionalitate necesită marea majoritate a timpului de lucru;

–  Scenarii atipice: Un scenariu atipic trebuie să fie îndeplinit de sistem numai în cazuri speciale. Clientul poate să spere, de exemplu, că o eroare neprevăzută este un eveniment atipic. Totuşi, sistemul trebuie să gestioneze un număr cât mai mare de categorii de erori, prin tehnici stabilite, precum handler-ele de excepţii, monitorizarea proceselor etc.;

–  Cerinţe incomplete sau nemonotone: O enumerare completă a cerinţelor pentru toate situaţiile care pot apărea în condiţii de lucru reale nu este posibilă. În logica tradiţională, o teorie este definită de o mulţime finită de axiome. Teoremele din teoria respectivă sunt propoziţii adevărate. Dacă se adaugă ulterior noi axiome, teoremele existente rămân valide iar noile teoreme dezvoltate sunt adăugate teoremelor stabilite. În logica nemonotonă, adăugarea de noi axiome poate invalida unele teoreme care au fost demonstrate anterior. O nouă teorie nu mai este o simplă extensie a teoriei vechi, ci o mulţime de teoreme noi, împreună cu o parte din teoremele vechi. Procesul de stabilire a cerinţelor are o natură iterativă şi nemonotonă. Mulţimea iniţială de cerinţe (axiomele) defineşte posibilităţile (teoremele) sistemului. Noile cerinţe pot infirma soluţiile vechi. Pe măsură ce un sistem creşte în dimensiuni şi complexitate, stabilirea cerinţelor devine din ce în ce mai dificilă, mai ales când procesul de colectare a cerinţelor este distribuit, fiind realizat de indivizi cu specializări diferite.

2. Faza de proiectare

Pe baza cerinţelor din faza de analiză, acum se stabileşte arhitectura sistemului: componentele sistemului, interfeţele şi modul lor de comportare:

–  Componentele sunt blocurile de construcţie ale produsului. Acestea pot fi create de la zero sau reutilizate dintr-o bibliotecă de componente. Componentele rafinează şi capturează semnificaţia detaliilor din documentul cerinţelor;

–  Interfeţele ajută la îmbinarea componentelor. O interfaţă reprezintă graniţa dintre două componente, utilizată pentru comunicarea dintre acestea. Prin intermediul interfeţei, componentele pot interacţiona;

–  Comportamentul, determinat de interfaţă, reprezintă răspunsul unei componente la stimulii acţiunilor altor componente.

Documentul de proiectare descrie planul de implementare a cerinţelor. Se identifică detaliile privind limbajele de programare, mediile de dezvoltare, dimensiunea memoriei, platforma, algoritmii, structurile de date, definiţiile de tip globale, interfeţele, etc. În această fază trebuie indicate şi priorităţile critice pentru implementare. Acestea sugerează sarcinile care, dacă nu sunt executate corect, conduc la eşecul sistemului. Totuşi, chiar dacă priorităţile critice sunt îndeplinite, acest fapt nu duce automat la succesul sistemului, însă creşte nivelul de încredere că produsul va fi o reuşită. Folosind scenariile tipice şi atipice, trebuie realizate compromisurile inerente între performanţă şi complexitatea implementării. Analiza performanţelor presupune studierea modului în care diferitele arhitecturi conduc la diferite caracteristici de performanţă pentru fiecare scenariu tipic. În funcţie de frecvenţă de utilizare a scenariilor, fiecare arhitectură va avea avantaje şi dezavantaje. Un răspuns rapid la o acţiunea a utilizatorului se realizează deseori pe baza unor costuri de resurse suplimentare: indecşi, managementul cache-ului, calcule predictive etc. Dacă o acţiune este foarte frecventă, ea trebuie realizată corect şi eficient. O acţiune mai rară trebuie de asemenea implementată corect, dar nu este evident care e nivelul de performanţă necesar în acest caz. O situaţie în care o astfel de acţiune trebuie implementată cu performanţe maxime este închiderea de urgenţă a unui reactor nuclear. Planul de implementare şi planul de test pot fi considerate şi ca aparţinând fazelor de implementare şi respectiv testare. Însă unul din scopurile fazei de proiectare este stabilirea unui plan pentru terminarea sistemului. Planul de implementare stabileşte programul după care se va realiza implementarea şi resursele necesare (mediul de dezvoltare, editoarele, compilatoarele etc.). Planul de test defineşte testele necesare pentru stabilirea calităţii sistemului. Dacă produsul trece toate testele din planul de test, este declarat terminat. Cu cât testele sunt mai amănunţite, cu atât este mai mare încrederea în sistem şi deci creşte calitatea sa. Un anume test va verifica doar o porţiune a sistemului. Acoperirea testului reprezintă procentajul din produs verificat prin testare. În mod ideal, o acoperire de 100% ar fi excelentă, însă este rareori îndeplinită. De obicei, un test cu o acoperire de 90% este simplă, însă ultimele 10% necesită o perioadă de timp semnificativă. În general, este suficient ca testele să cuprindă scenariile tipice şi atipice, fără să verifice întregul sistem, cu absolut toate firele de execuţie. Acesta poate conţine ramificaţii interne, erori sau întreruperi care conduc la fire de execuţie netestate. Majoritatea sistemelor sunt pline de bug-uri nedescoperite. De obicei, clientul participă în mod logic la testarea sistemului şi semnalează erori care vor fi îndepărtate în versiunile ulterioare.

3. Faza de implementare

În această fază, sistemul este construit, ori plecând de la zero, ori prin asamblarea unor componente pre-existente. Pe baza documentelor din fazele anterioare, echipa de dezvoltare ar trebui să ştie exact ce trebuie să construiască, chiar dacă rămâne loc pentru inovaţii şi flexibilitate. De exemplu, o componentă poate fi proiectată mai restrâns, special pentru un anumit sistem, sau mai general, pentru a satisface o direcţie de reutilizare. Echipa trebuie să gestioneze problemele legate de calitate, performanţă, biblioteci şi debug. Scopul este producerea sistemului propriu-zis. O problemă importantă este îndepărtarea erorilor critice. Într-un sistem există trei tipuri de erori:

–  Erori critice: Împiedică sistemul să satisfacă în mod complet scenariile de utilizare. Aceste erori trebuie corectate înainte ca sistemul să fie predat clientului şi chiar înainte ca procesul de dezvoltare ulterioară a produsului să poată continua;

–  Erori necritice: Sunt cunoscute, dar prezenţa lor nu afectează în mod semnificativ calitatea observată a sistemului. De obicei aceste erori sunt listate în notele de lansare şi au modalităţi de ocolire bine cunoscute;

–  Erori necunoscute: Există întotdeauna o probabilitate mare ca sistemul să conţină un număr de erori nedescoperite încă. Efectele acestor erori sunt necunoscute. Unele se pot dovedi critice, altele pot fi rezolvate cu patch-uri sau eliminate în versiuni ulterioare.

4. Faza de testare

Calitatea produsului software este foarte importantă. Multe companii nu au învăţat însă acest lucru şi produc sisteme cu funcţionalitate extinsă, dar cu o calitate scăzută. E mai simplu să-i explici clientului de ce lipseşte o anumită funcţie decât să-i explici de ce produsul nu este performant. Un client satisfăcut de calitatea produsului va rămâne loial firmei şi va aştepta noile funcţii în versiunile următoare. În multe metodologii ale ingineriei programării, faza de testare este o fază separată, realizată de o echipă diferită după ce implementarea s-a terminat. Motivul este faptul că un programator nu-şi poate descoperi foarte uşor propriile greşeli. O persoană nouă care priveşte codul poate descoperi greşeli evidente care scapă celui care citeşte şi reciteşte materialul de multe ori. Din păcate, această practică poate determina o atitudine indiferentă faţă de calitate în echipa de implementare. Tehnicile de testare sunt abordate preponderent din perspectiva producătorului sistemului. În mod ideal, şi clientul trebuie să joace un rol important în această fază. Testele de regresiune (engl. „regression test”) sunt colecţii de programe care testează una sau mai multe trăsături ale sistemului. Rezultatele testelor sunt adunate şi dacă există erori, bug-ul este corectat. Un test de regresiune valid generează rezultate verificate, numite „standardul de aur”. Validitatea rezultatului unui test ar trebui să fie determinată de documentul cerinţelor. În practică, echipa de implementare este responsabilă de interpretarea validităţii. Testele sunt colectate, împreună cu rezultatele standardelor de aur, într-un pachet de test de regresiune. Pe măsură ce dezvoltarea continuă, sunt adăugate mai multe teste noi, iar testele vechi pot rămâne valide sau nu. Dacă un test vechi nu mai este valid, rezultatele sale sunt modificate în standardul de aur, pentru a se potrivi aşteptărilor curente. Pachetul de test este rulat din nou şi generează noi rezultate. Acestea sunt comparate cu rezultatele standardelor de aur. Dacă sunt diferite, în sistem a apărut o greşeală. Greşeala este corectată şi dezvoltarea continuă. Acest mecanism detectează situaţiile când starea curentă de dezvoltare a produsului invalidează o stare existentă. Astfel, se previne regresiunea sistemului într-o stare de eroare. Există patru puncte de interes în testele de regresiune pentru asigurarea calităţii. Testarea internă tratează implementarea de nivel scăzut. Fiecare funcţie sau componentă este testată de către echipa de implementare. Aceste teste se mai numesc teste „clear-box” sau „white-box”, deoarece toate detaliile sunt vizibile pentru test. Testarea unităţilor testează o unitate ca un întreg. Aici se testează interacţiunea mai multor funcţii, dar numai în cadrul unei singure unităţi. Testarea este determinată de arhitectură. De multe ori sunt necesare aşa-numitele „schele”, adică programe special construite pentru stabilirea mediului de test. Numai când mediul este realizat se poate executa o evaluare corectă. Programul schelă stabileşte stări şi valori pentru structurile de date şi asigură funcţii externe fictive. De obicei, programul schelă nu are aceeaşi calitate ca produsul software testat şi adesea este destul de fragil. O schimbare mică în test poate determina schimbări importante în programul schelă. Aceste teste se mai numesc teste „black-box” deoarece numai detaliile interfeţei sunt vizibile pentru test. Testarea internă şi a unităţilor poate fi automatizată cu ajutorul instrumentelor de acoperire (engl. „coverage tools”), care analizează codul sursă şi generează un test pentru fiecare alternativă a firelor execuţie. Depinde de programator combinarea acestor teste în cazuri semnificative care să valideze rezultatelor fiecărui fir de execuţie. De obicei, instrumentul de acoperire este utilizat într-un mod oarecum diferit: el urmăreşte liniile de cod executate într-un test şi apoi raportează procentul din cod executat în cadrul testului. Dacă acoperirea este mare şi liniile sursă netestate nu prezintă mare importanţă pentru calitatea generală a sistemului, atunci nu mai sunt necesare teste suplimentare. Testarea aplicaţiei testează aplicaţia ca întreg şi este determinată de scenariile echipei de analiză. Aplicaţia trebuie să execute cu succes toate scenariile pentru a putea fi pusă la dispoziţia clientului. Spre deosebire de testarea internă şi a unităţilor, care se face prin program, testarea aplicaţiei se face de obicei cu scripturi care rulează sistemul cu o serie de parametri şi colectează rezultatele. În trecut, aceste scripturi erau create manual. În prezent, există instrumente care automatizează şi acest proces. Majoritatea aplicaţiilor din zilele noastre au interfeţe grafice (GUI). Testarea interfeţei grafice pentru asigurarea calităţii poate pune anumite probleme. Cele mai multe interfeţe, dacă nu chiar toate, au bucle de evenimente, care conţin cozi de mesaje de la mouse, tastatură, ferestre etc. Asociate cu fiecare eveniment sunt coordonatele ecran. Testarea interfeţei presupune deci memorarea tuturor acestor informaţii şi elaborarea unei modalităţi prin care mesajele să fie trimise din nou aplicaţiei, la un moment ulterior.

Ce este MVC?

MVC, sau Model-View-Controller este un sablon arhitectural utilizat în industria de software development. Acest mod de funcționare izbutește cu succes izolarea secțiunii logice de interfața proiectului, rezultând în aplicații extrem de simplu de modificat. In strucutura MVC, modelul reprezintă datele de care necesită aplicația, viewerul coincide cu elementele de interfață, iar controller-ul reflectă sistemul comunicativ și decizional ce proceseaza datele informaționale, facând conexiunea între model si view.

Modul de funcționare a arhitecturii MVC

Modelul reflecă secțiunea de hard-programming adică partea logica a programului. El are în sarcine acțiunile și operațiile asupra datelor, autentificarea utilizatorilor, înglobarea diferitor clase ce permit prelucrarea informațiilor din diferite baze de date.

View-ul are funcția de a afișa date, practic aceasta secțiune a programului va fi responsabil de cum va fi afișată utilizatorului informația procesată de controller. Odată ce funcțiile sunt executate de model, viewului îi sunt oferite rezultatele, iar acesta sunt trimise către browser. În general viewul reprezintă o mini-aplicație care ajută la randarea unor informații, având la bază diverse template-uri.

Controller-ul este creierul aplicației. El făcând legătura dintre model și view, între acțiunile userului si partea decizională a aplicației. În dependență de necesitățile utilizatoruilui, controllerul interoghează diverse funcții concepute special pentru partea de site în care se află userul. Funcția se va folosi de model pentru a procesa datele, după care informațiile noi vor fi trimise către view, care la rândul lui va afișa mai apoi prin template-uri.

2.2.Alegerea mediului de dezvoltare (software development environment)

Un mediu de dezvoltare este un set de programe care ajută programatorul în scrierea programelor. Un mediu de dezvoltare combina toți pașii necesari creării unui program cum ar fi editarea codului sursă, compilarea, depanarea, testarea, generarea de documentație într-un singur soft, care, de regulă, oferă o interfață cu utilizatorul grafică prietenoasă. Principalele componente ale unui mediu de dezvoltaresunt editorul de cod sursă și depanatorul. Mediile de dezvoltare apelează compilatoare sau interpretoare, care pot veni în același pachet cu mediu însuși sau pot fi instalate separat de către programator. Printre facilitățile prezente în mediile de dezvoltare mai sofisticate se numără: exploatarea de cod sursă, sisteme de control al versiunilor, designere de interfață grafice sau unelte de ingineria programării. De obicei un mediu de dezvoltare este specific unui anumit limbaj de programare, însă există si medii de dezvoltare care pot lucra cu mai multe limbaje.

Pentru aplicația mea am ales ca mediu de dezvoltare Xcode deoarece aplicația va rula pe sistemul de operare iOS, sistem care este folosit de către Apple pentru dispozitivele sale: iPhone, iPad și iPod Touch. Pentru a putea programa pentru iOS ai nevoie de anumite cerințe hardware. Minimul necesar este să deții un Macintosh și dacă ai și dispozitive mobile cum ar fi iPhone sau un iPad pentru a testa aplicația este și mai bine însă nu este obligatoriu pentru că kitul de dezvoltare software vine cu simulatoare.

Sunt utilizator al sistemului de operare iOS și asta a fost cel mai important factor care m-a facut să aleg acest mediu de dezvoltare, dar și faptul că iOS este una dintre cele mai mari piețe din lume de unde poți achiziționa gratuit sau contracost.

Ce este Xcode ?

Xcode este un mediu de dezvoltare integrat (IDE) care conține o suită de instrumente de dezvoltare software dezvoltate de Apple pentru crearea de software pentru OS X, iOS, WatchOS și tvOS fiind lansat în 2003, cea mai recentă versiune stabilă fiind 7.3.1 și este disponibilă gratuit prin intermediul utilizatorii OS X El Capitan Mac App Store. Dezvoltatorii înregistrați pot descărca comunicate de previzualizari și versiunile anterioare ale suitei prin intermediul site-ului web al dezvoltatorului.

2.3. Prezentarea generală a aplicației

Obiectivul propus în crearea aplicației a fost de a oferi utilizatorilor de gadget-uri iOS posibilitatea de a nu pierde timpul în așteptarea autobusului prin crearea unei baze date care ar conține orarul de circulație al autobuselor. Pe lângă aceasta am decis ca ar fi binevenit și plasarea traseelor autobuselor sub formă de hartă pentru o orientare mai ușoară a celor care nu sunt familiarizați cu intinerariile lor.

2.4. Conectarea unei aplicații iphone la o bază de date MySQL

Pentru a conecta dispozitivul mobil la o bază de date MySQL trebuie creată o bază de date de tip tabel și de introdus niște date. O aplicație iPhone nu se poate conecta direct la o bază de date MySQL de aceea e nevoie de creat un intermediar care va facilita operațiunile cu baza de date. Acest lucru este posibil cu ajutorul PHP web service . Serviciul web va fi serverul nostru de web și atunci când aplicația iPhone trimite o cerere, ea va interoga baza de date pentru datele solicitate și apoi se va returna la aplicație într-un format pe care îl poate înțelege. Mai jos am reprezentat o diagramă cum funcționează sistemul.

Ce este un API ?

API – este o interfață de programare a aplicațiilor care constă dintr-un set de definiții de rutină, protocoale și instrumente pentru construirea de software și aplicații.

Un API exprimă o componentă software în ceea ce privește operațiunile, intrările, ieșirile, și tipurile sale subiacente, definind functionalități care sunt independente de implementările lor, ceea ce permite definițiile și implementările să varieze, fără a compromite interfața . Un API bun facilitează dezvoltarea unui program prin furnizarea tuturor blocurilor de construcție, care sunt apoi puse împreună de către programator .

Pentru a putea crea un server trebuie să Instalăm pe calculaotorul nostru XAMPP. Acest program funcționează ca un web server capabil de a servi pagini dinamice. XAMPP este disponibil aproape pentru toate sistemele de operare, și este util în principal pentru dezvoltarea proiectelor web. Acest program este utilizat pentru crearea paginilor dinamice, folosind limbaje de programare ca PHP, JSP, Servlets.

PHP – este un limbaj de scripting server-side proiectat pentru dezvoltare web, dar și utilizat ca un limbaj de programare de uz general . Inițial creat de Rasmus Lerdorf în 1994, PHP este produs al Grupului PHP (Personal Home Page). Codul PHP poate fi încorporat în codul HTML, sau poate fi utilizat în combinație cu diverse sisteme șablon web, sisteme de management de conținut web și cadre web. Codul PHP este de obicei procesat de un interpretator PHP implementat ca un modul în serverul web sau ca Common Gateway Interface ( CGI ) executabil. Server-ul web combină rezultatele codului PHP interpretat și executat, care poate fi de orice tip de date, inclusiv imagini, cu pagina web generată. Codul PHP poate fi, de asemenea, executat cu o interfață de linie de comandă ( CLI ) și poate fi utilizat pentru a pune în aplicare aplicații grafice de sine stătătoare.

Înainte de a dezvolta aplicația trebuie creată o bază de date și introduse careva date.

Acum trebuie să creăm un PHP service care să interogheze baza noastră de date care mai apoi îl incarcăm pe server.

Ce este MySQL

Multe programe de calculator, inclusiv programe bazate pe web, cum ar fi bloguri, galerii foto și sisteme de management de conținut au nevoie de a stoca și de a prelua date. De exemplu, software-ul unui blog are nevoie pentru a stoca posturi (de exemplu articole ) pe care le scrie, și să le preia atunci când un vizitator accesează pe site-ul său . În mod similar, galeriile foto pentru stoca informații despre imaginile lor (de exemplu, pentru site-urile care permit utilizatorilor să evalueze fotografii, rating-ul numeric pentru fiecare imagine este stocată într -o bază de date). În loc să reinventeze roata și să pună în aplicare a propriului lor sistem de stocare și extragere a datelor , acest aplicații pur și simplu utilizează programe de baze de date de specialitate .

SQLite este un motor de baze de date SQL încorporat. Spre deosebire de cele mai multe baze de date SQL, SQLite nu are un server separat. SQLite citește și scrie în mod direct fișierele obișnuite de pe disc. O bază de date completă SQL cu mai multe tabele, indici și declanșatoare este conținută într-un singur fișier de pe disc. Formatul de fișier de bază de date este cross – platform în care aveți posibilitatea să copiați în mod liber o bază de date între sistemele pe 32 de biți și pe 64 de biți sau între arhitecturi mari-endian si little-endian . Aceste caracteristici fac SQLite o alegere populară ca un format de fișier Application.

1. Crearea proiectului în XCode

2. Importarea în bibliotecă a fișierelor fmdb, (source files) pentru lucru сu sqlite 3.Importarea în bibliotecă lsqlite3 în proiect + MapKit framework

4. Crearea clasei Databasemanager pentru lucru cu baza de date

5. Importare MainViewController, RoutesViewController

6. Scrierea funcției pentru lucru cu tabele database, -getroutes() ,- addroute(), getRouteById ..

7.MainViewController, MainViewController, OrarViewController folosesc UITableView

8. MapViewController conține MKMapView pentru reflectarea traseului pe hartă

9.MKMapView – clasă pentru reflectarea în MapKit framework

Map Kit framework reprezintă o interfață care încorporează hărțile în propriile ferestre și vizualizări. Acest cadru oferă de asemenea suport pentru adnotarea hărții, adăugând suprapuneri și efectuarea de căutări inverse – geocoding pentru a determina informațiile marcatorului pentru o anumite coordonate geografice

Acum avem o clasă liberă și trebuie scris codul în ea.

Importăm Mapkit Framework

Map Kit framework reprezintă o interfață care încorporează hărțile în propriile ferestre și vizualizări. Acest cadru oferă de asemenea suport pentru adnotarea hărții, adăugând suprapuneri și efectuarea de căutări inverse – geocoding pentru a determina informațiile marcatorului pentru o anumite coordonate geografice.

Capitolul 3. Evoluția aplicației

3.1. Dezvoltarea aplicației pentru alte platforme

Dezvoltarea aplicației pentru alte platforme reprezintă unul dintre cele mai importante obiective propuse pentru viitor. Pentru că astăzi avem o diversitate de gadget-uri și la fel de multe păreri împărțite asupra alegerii unui dispozitiv mobil, oamenii apelează la diferite companii care la rândul lor folosesc diferite sisteme de operare pentru produsele lor. De aceea scopul nostru este de a oferi tuturor posibilitatea accesării aplicației indiferent de echipamentele mobile pe care îl deține.

O mare parte a pieții este dominată de produse cu sisteme de operare Android de unde vine și o cerere mare pentru aplicațiile care rulează pe acest sistem de operare. Elaborarea unei aplicației care ar rula pe mai multe sisteme de operare ar aduce cu siguranță un beneficiu mult mai mare.

Dezvoltatorii de aplicații sunt mereu în căutarea unei nișe proprii pe piețele de aplicații mobile care să le ofere la rândul lor o stabilitate pe o perioadă lungă de timp. Pentru a face față acestei cerințe, dezvoltatorii sunt puși în situația de a decide în favoarea cărei opțiuni să-și facă alegerea pentru a dezvolta o aplicație, utilizând un cod nativ sau să creeze o aplicație hibridă.

3.2.Aplicații native

Aplicațiile native sunt aplicații dezvoltate prin intermediul unui limbaj de programare caracteristic platformei pentru care aplicația este concepută. În tabelul de mai jos sunt prezentate trei cele mai utilizate sisteme de operare la moment, limbajul de programare pe care îl folosesc, platformele folosite pentru dezvoltarea lor și mediile de dezvoltare utilizate de către creatorii de aplicații mobile.

Caracteristici

Utilizatorii de echipamente mobile pot observa diferența dintre aplicațiile mobile native și cele hibride grație unui timp superior de răspuns și pentru că aplicațiile native au acces la mai multe componente hardware cu ar fi bluetooth, camera foto, wireless și altele, astfel aplicațiile native sunt mai prietenoase pentru oricine.

Giganții piețelor de aplicații mobile sunt mereu în căutarea de noi soluții pentru perfecționarea și simplificarea mediilor de dezvoltare pentru a tenta cât mai mulți programatori să dezvolte aplicații pe platformele lor. Aceste îmbunătățiri sunt binevenite pentru programatori care pot avea accesul la unelte gratuite pentru a-l ajuta la dezvoltarea unei aplicații într-o manieră rapidă, utilizând timpul economisit pentru valorificarea altor idei noi.

Aplicațiile native care sunt dezvoltate pentru o platformă specifică va avea întotdeauna resurse grafice cum ar fi butoane, fundaluri, iconițe distincte de celelalte platforme. Acesta rezultă din faptul că aplicațiile native trebuie să conserve din design și din comportamentul sistemului de operare pentru care se proiectează. Acesta ar trebui să corespundă în totalitate platformei pentru care a optat utilizatorul final.

Aplicațiile native devin foarte dificile atunci când sunt evaluate cunoștințele programatorului, pentru că fiecare platformă folosește un limbaj individual comparativ cu alte platforme, iar studierea unui limbaj de programare reprezintă o provocare destul de grea pentru dezvoltator. Deobicei pentru ca aplicația nativă să ruleze mai multe platforme este nevoie ca la ea să lucreze câte un dezvoltator pentru fiecare platformă în parte în dependență de complexitate și de timpul pe care îl au la dispoziție. În ceea ce privește creativitatea, dezvoltatorul nu are nici o restricție, limitându-l doar resursele dispozitivului pe care va rula aplicația.

Părțile pozitive

Proiectarea aplicațiilor native pot cauza următoarele avantaje dezvoltatorului:

Capacitatea de a utiliza diferite elemente hardware bluetooth, senzori de mișcare, leduri de notificare, camera și altele;

Timpul de răspuns mai scurt la acțiuni;

Dezvoltatorul poate accesa ultimele API-uri lansate pe platformă de la primele versiunile lansate beta;

Aplicația este promovată mai bine pe platforma pe care este lansată deoarece este ditribuită prin intermediul piețelor de aplicații utilizate de majoritatea utilizatorilor de echipamente mobile;

Asigură utilizatorului o experiență superioară în urma folosirii aplicației ceea ce contribuie la cresterea cererii pentru ea;

Oferă unelte de dezvoltare gratis;

Mediile de dezvoltare au instrumente bune de verificare a codului dar si instrumente de analiză a aplicației în ceea ce privește consumul de memorie și a timpului de răspuns.

Aplicațiile native aduc utilizatori noi, dar în același timp în păstrează pe cei vechi. Majoritatea companiilor mari din categoria aplicațiilor sociale cum e facebook, twitter, sau linkedin au înțeles ca aplicațiile native au capacitatea de a atrage utilizatori și au ales a se îndrepta pe acest segment.

Părțile negative

Aplicațiile native nu constituie doar din părți pozitive, ele având și părți negative care pot îl poate pune în dificultate pe un dezvoltator . Părțile negative fiind:

În comparație cu aplicațiile web, promovarea aplicațiilor native de multe ori este limitată de restricțiile acestora de a nu putea fi repartizate pe toate piețele lumii. Pentru unele piețe de aplicații vânzarea lor nu este permisă sau nu pot fi accesate.

Pentru dezvoltarea produsului pentru mai multe platforme, costurile sunt semnificativ mai mari decât în cazul aplicațiilor hibride pentru că este necesar ca codul să fie rescris pentru alte platforme;

Pentru însușirea unei platforme, dezvoltatorul are nevoie de o pregătire care de regulă durează câțiva ani ceea ce reduce semnificativ resursele umane specializate în domeniu.

3.3.Aplicații hibride

Aplicațiile mobile hibride sunt programe care de obicei sunt create folosindu-se tehnologiile WEB cum ar fi JavaScript, HTML, CSS. În prezent aplicațiile hibride încep să devină tot mai populare deoarece multe medii de dezvoltare au devenit mai stabile și asigură acces la tot mai multe componente hardware ale echipamentelor mobile. În Tabelul 2 am reprezentat câteva dintre cele mai utilizate medii de dezvoltare pentru aplicațiile hibride.

Caracteristici

Aplicațiile hibrid de obicei sunt create dintr-un element nativ de tip webbrowser care poate accesa mai multe opțiuni ale platformei pe care rulează cum ar fi camera, lista de contacte, etc. De obicei aplicațiile hibrid au același aspect grafic pentru toate platformele de dezvoltare au fost editate fără a se baza pe ghidul de implementare a interfeței cu utilizatorul a fiecărei dintre platforme pentru care este creată aplicația.

Ar fi suficient să scrii codul de bază pentru o aplicație, pentru ca ulterior, foarte ușor aplicația să funcționeze pe mai multe platforme. Din aceast motiv dezvoltatorii de aplicații hibrid sunt axați mai mult pentru idei noi sau elaborarea unei noi aplicații.

Datorită faptului că majoritatea instrumentelor de dezvoltare utilizează tehnologiile WEB pentru crearea aplicației, căutarea unui programator pentru a dezvolta o aplicație hibridă pentru echipamentele mobile mobile, este o alegere mai puțin costisitoare . Datorită volumului mare de lucru pe WEB a dus la faptul ca tot mai mulți dezvoltatori să însușească limbaje de programare precum JavaScript, HTML și CSS. Astfel a fost posibil ca universul programării să ia o direcție către programarea aplicațiilor hibride.

Părțile pozitive

Timp scurt de dezvoltare compatibile cu mai multe sisteme de operare;

Însușirea mai accelerata a modului de dezvoltare, fiind utilizate în mare parte tehnologi WEB;

Aplicația are un areal mai larg pe platforma unde este lansatăpentru că este repartizată prin piețele de aplicații utilizată în mare parte de către utilizaotrii de echipamente mobile;

Instrumente de dezvoltare gratuite.

Părțile negative

Subordonare față de dezvoltatorii uneltelor de lucru, lcuru ce poate duce la reținerea lansării aplicației care ar rula pe o versiune mai nouă a unui sistem de operare;

Eficiență mai mică în unele zone

Popularitate redusă în rândurile utilizatorilor loiali a unei platforme aparte;

Pierderea timpului pentru soluționarea problemelor depistate din motivul că nu pe toate platformele aplicația o să aibă aceeași performanță.

Pentru început aș dori să menționez faptul că amândouă modalități de dezvoltare a aplicațiilor mobile se repartizează prin intermediul piețelor de aplicații existente pe platformele mobile (AppStore, GooglePlay, Windows Phone Store.). Datorită acestei cauze, amândouă vor participa și la cercetarea de dinaintea lansării oficiale din magazinul virtual.

Prin dezvoltarea nativă pot scoate tot ce se poate din platforma pe care rulează aplicația și totul la performanțe ridicate. Pe de altă parte nu trebuie trecută cu vederea faptul că tot aceste mari companii de echipamente mobile au început activitatea lor în lumea mobilă cu aplicații web, apoi ele au dezvoltat aplicații hibride și în ultima fază au trecut la metoda nativă.

Concluzie

Telefoanele mobile și tabletele sunt unele din cele mai dinamice dispozitive în jurul cărora se concentrează cea mai mare parte a dezvoltării tehnologice a electronicii moderne. În ultimii ani se observă o creștere constantă a cererii pentru echipamentele mobile și în același timp crește și cererea pentru aplicațiile mobile care au ajuns la o diversitate foarte mare. Pentru a satisface fiecare utilizator dezvoltatorii de aplicații software au căutat soluții pentru ca produsele lor să fie universale și să poată rula pe toate sistemele de operare. La rândul lor producătorii de echipamente mobile au încercat să atragă de partea lor dezvoltatorii de programe software oferindu-le medii de dezvoltare și unelte de lucru gratuite.

În încercarea de a dezvolta o aplicație pentru un dispozitiv mobil m-am confruntat cu mai multe dificultăți cum ar fi cunoștințe limitate în domeniu, unelte de dezvoltare contracost, sau incompatibilitatea echipamentului mobil cu aplicația din cauza actualizării sistemului de operare. Dezvoltarea unei aplicații mobile necesită o cunoaștere amplă a mediului în care se crează aplicația și a limbajului de programare specific care reprezintă una din cauzele care m-au limitat în atingerea obiectivelor propuse. Totuși am reușit să creez un concept care cred că va simplifica considerabil organizarea mea în ceea ce privește timpul pierdut în așteptarea transportului public. Am ca obiectiv în viitorul apropiat să aduc la desăvârșire aplicația, lansân-o pe o piață online de aplicații, iar mai târziu și dezvoltarea unei versiuni pe sistemul de operare Android.

Revenind la viitorul acestor tehnologii, sunt profund convins că perspectiva acestora va fi una marcantă și că în timpul apropiat vom avea o varietate vastă de programe software care vin în ajutorul nostru pentru a ne simplifica și mai mult traiul. Ele au devenit atât de familiare și au pătruns atât de adânc în viața noastră încât este greu să ne imaginăm existența în lipsa lor.

În încheiere pot să menționez faptul că dezvoltarea unei aplicații mobile a fost o provocare interesantă ce m-a făcut să mă documentez și să mă implic în totalitate în căutarea unei nișe în care aș putea dezvolta o idee, dar în același timp să obțin o experiență bună în acest mediu a dezvoltatorilor.

Anexe

Anexa 1

Crearea proiectului în Xcode iOS app

Anexa 2

Importare biblioteca (library) SQLite 3 .

Anexa 3

Crearea și inițierea DataBase Class

Anexa 4

Importare Mapkit Framework

Anexa 5

Importarea MainViewController, RoutesViewController, MapViewController, OrarViewController, DataViewController

Anexa 6

Anexa 7

Anexa 8

Funcția pentru OrarViewController

Anexa 9

Scriem funcția pentru Databasemanager

Crearea proiectului în Xcode iOS app