Platforma de Examinare a Cunostiintelor pe Device Urile Mobiledocx

=== Platforma de examinare a cunostiintelor pe device-urile mobile ===

Platformă de examinare a cunoștiințelor pe device-urile mobile

Introducere

Trăim într-o societate în care informația reprezintă putere. Dobândind mai multă cunoaștere despre lume și despre modul în care aceasta funcționează, putem lua decizii mai bune, în cunoștință de cauză, fiind astfel mai valoroși pentru societatea din care facem parte. Accesul la informație și folosirea conformă a acesteia ne poate deschide orice ușă în alte condiții închisă. Dobândirea informațiilor consumă însă o resursă neregenerabilă foarte importantă – timpul. Trăim în secolul vitezei iar societatea pune foarte mare accent pe folosirea rațională a orelor active. Totul se cuantifică în unități de timp: un curs de Tehnologii web – trei săptămâni, să înveți o limbă străină – șase luni, să iți dezvolți propria afacere – un an. Asadar, deși progresul tehnologic a permis accesul nelimitat la o cantitate uriașă de informație, timpul necesar pentru a filtra și asimila aceste cunoștințe este din ce în ce mai redus. Pentru a rezolva nevoia de informare, specialiștii au venit pe piață cu dispozitive mobile ce permit conectarea la aceste resurse de oriunde s-ar afla utilizatorul. În aceasta direcție telefoanele inteligente (smartphone) joacă un rol din ce în ce mai important. Cu ajutorul lor în cinci minute putem vedea starea vremii pentru weekendul următor, putem rezerva locuri la cinema, verifica mailurile importante și putem citi un articol despre cultivarea salciei energetice.

Telefoanele inteligente ne ajută să ne organizăm majoritatea activităților: de la alergat două zeci de minute în fiecare seară, la a ne aminti când e ziua unui coleg, sau a ține pasul cu ce au făcut prietenii noștri. Statisticile arată că stăm mai mult timp pe telefon sau tabletă decât în fața televizorului, unde ne petrecem în medie două ore și jumătate. Iar din acest timp, 58,2% îl petrecem folosind aplicații, spre deosebire de 41,8% pe care îl petrecem accesând Web-ul pe mobil.

Consumul de conținut pe mobil a crescut aproape exponențial din 2009 și până acum și nu pare să se stabilizeze prea curând. Un studiu realizat de cei de la Morgan Stanley în 30 de țări relevă faptul că oamenii petrec zilnic în medie 141 de minute pe telefon și 50 de minute pe tabletă.

În prezent 68% dintre europeni dețin un telefon cu acces la internet, din care 44% folosesc un smartphone. Așadar avem acces la informație rapid, ce mai lipsește? – Un mod prin care să ne putem certifica cunoștiințele dobândite.

Una din cele mai importante etape din procesul de învățare, atât de vital modului în care ne desfășurăm viața, o constituie atestarea sau verificarea cunoștiintelor dobândite. Prin lucrarea de față ne propunem să imbunătățim tocmai această etapă, îmbunătățind experiența atât celor ce urmează să își verifice cunoștiințele, cât și celor implicați în a decide cum trebuie evaluate anumite cunoștiinte. Această aplicație are aplicabilitate în foarte multe domenii, de ex: pentru atestarea cunoștiințelor de legislație rutieră se susține un examen de tip test grilă. Unele companii se promovează prin jocuri de tip întrebări și răspuns adresate clientilor, în care, prin conținutul lor își promovează produsele și își întăresc imaginea brandului față de clienți.

Prin orientarea către platformele mobile, se deschide o foarte mare paletă de posibilități: se pot include cu ușurință poze prin accesul la camera foto, se poate folosi dictarea pentru a evita scrisul la mână, se pot distribui informațiile foarte ușor, aceasta fiind una din cele mai importante funcții ale unui smartphone.

Utilizatorii aplicației vor putea rula aplicația în două moduri:

Evaluator – în calitate de evaluator utilizatorul are access la

Creare / editare de întrebări și răspunsuri

Încărcare de poze, folosind camera foto, sau din galeria locală

Introducere text, folosindu-se de tastatură sau prin dictație, folosind Siri

Configurare funcție de evaluare a întrebărilor

Evaluat

Susține teste publice

Susține teste private, pe baza unui id

Vizualizare rezultatele testelor susținute

Dintre platformele mobile, cea mai stabilă și mai atractivă la momentul de față este iOS, iar ca și limbaj de programare, am hotărât sa fim în pas cu tehnologia, dezvoltând aplicația în Swift (la momentul dezvoltării versiunea activă era Swift 2.2).

Pentru stocarea datelor în cloud s-a folosit o soluție de BaaS (Backend as a Service) oferită de cei de la Parse.

Fundamentarea teoretică și documentarea bibliografică pentru tema propusă

Domeniul și contextul temei abordate

Se observă în ultima vreme o evoluție din ce în ce mai mare a aplicațiilor de tipul quiz. Acestea deseori îmbină caracterul educațional cu cel de distractie, multe jocuri din ziua de azi bazându-se pe antrenarea utilizatorilor prin supunerea lor la tot felul de întrebări, cu diferite grade de dificultate și oferirea de punctaje prin care să își poată verifica nivelul de cunoștințe sau chiar permit concurarea împotriva altor utilizatori reali, din aceeași rețea. De asemenea se constată utilizarea lor cu scop comercial și de marketing – unele companii se folosesc de mini quizz-uri pentru a-i atrage pe clienti oferind mici premii în cazul în care răspund corect.

Fiecare companie, când are nevoie să transpună ceva sub forma unui quiz, începe dezvoltarea unei aplicații noi, de la zero. Astfel apar pe piață zilnic aplicații care fac lucruri similare, diferența fiind doar de conținut, fie că este un joc, o aplicație promoțională sau una în scop educațional.

Tema propusă. Obiective. Justificarea abordării

Tema centrală se bazează pe necesitatea de a crea și susține teste de tip quiz într-o manieră standardizată, care să se poată adapta oricărei nevoi. Necesitatea vine din faptul că soluțiile existente pe piață sunt de cele mai multe ori specifice conținutului, și nu oferă posibilitatea utilizatorului să își creeze propriul conținut.

Fiind implicat în domeniul dezvoltării de aplicații mobile pentru platforma iOS, platformă specifică dispozitivelor precum: iPhone, iPad, iPod Touch, etc, și ținând cont de evoluția pieței mobile din ultimii ani, am hotărât utilizarea acestei platforme pentru a crea un produs simplu de folosit și calitativ.

Deoarece piața mobile este una foarte dinamică, se recomandă ca o aplicație să fie compatibilă înapoi cu o singură versiune de iOS față de cea curenta. Și deoarece în această perioadă va fi lansat iOS 10, am hotărât ca versiunea minimă de iOS suportată să fie iOS 9.0.

Limbajul de programare ales a fost Swift atât pentru a aprofunda cunoștiințele, cât și pentru a fi în pas cu direcția de dezvoltare a aplicațiilor iOS. Fiind un limbaj de numai doi ani, Swift este deja în topul celor mai populare limbaje de programare.

Pentru partea de persistență a datelor am început întâi prin a persista datele local, folosind biblioteca oferită de Apple numită CoreData. Acesta este un framework care permite organizarea componentei Model a unei aplicații sub forma unui graf de obiecte. Acest lucru ne-a permis dezvoltarea rapidă și armonioasă a aplicației.

Pentru partea de stocare în Cloud am hotărât inițial să folosim tot soluția oferită de cei de la Apple, prin Cloud Kit. Din cauza unor probleme tehnice, am hotărât orientarea către o soluție gratis numită Parse.

Un alt aspect important în dezvoltarea aplicațiilor mobile o constituie adaptabilitatea la diferitele dimensiuni ale ecranului ale dispozitivelor compatibile. În acest sens elementele vizuale din cadrul aplicației sunt afișate ținând cont de un set de reguli, numite constrângeri. Care este un sistem de ecuații, al cărui soluție reprezintă locația și dimensiunea componentelor afișate pe ecran.

Pentru partea de criptare am folosit o librărie specifica iOS implementată in C, numită CommonCrypto. Aceasta oferă algoritmii de criptare SHA1, SHA256, SHA512, MD5.

Analiza tipurilor de aplicații existente care adresează problema quiz-urilor

TestMoz – Test generator

Aplicația este doar web. Oferă un link de la care poate fi accesată sesiunea de întrebări și parola de acces.

Poate fi folosită doar pentru a crea teste. Se poate seta punctajul unui răspuns corect. Are din oficiu setat 1 punct pe întrebare.

Permite introducerea de răspunsuri cu variante multiple, cu unul sau mai multe răspunsuri corecte, adevarat/fals și completează spațiile libere.

Nu permite inserarea de imagini în intrebări și răspunsuri.

Designul este simplu și intuitiv.

Socrative

Aplicația este disponibilă pe multiple platforme (iOS, Android, Windows, Chrome).

Oferă un link și un cod de la care poate fi accesată sesiunea de întrebări și parola de acces.

Permite introducerea de răspunsuri cu variante multiple, cu unul sau mai multe răspunsuri corecte, adevarat/fals și introducerea de răspunsuri scurte

Nu permite inserarea de imagini în răspunsuri.

Designul este plăcut.

Aplicația este simplă și intuitivă.

Polleverywhere.com

Aplicația este disponibilă atât online (web) cât și offline.

Utilizatorii pot răspunde pe website, prin mesaje text și pe Twitter.

Permite introducerea de răspunsuri cu variante multiple, cu unul sau mai multe răspunsuri corecte, adevărat/fals, selectarea unei imagini, ordonarea unor răspunsuri/imagini și introducerea de răspunsuri scurte

Permite inserarea de imagini în răspunsuri.

Designul este plăcut.

Aplicația este simplă și intuitivă.

Google Forms

Aplicația permite crearea de formulare, teste ce pot fi accesate atât de pe calculator cât și de pe dispozitive mobile cu acces la internet.

Permite expedierea formularului pe e-mail, twitter, facebook și stocarea sa în google drive.

Permite introducerea de răspunsuri scurte, paragraf, cu variante multiple, introducerea de casete de selectare și tip dropdown.

Deși permite inserarea de fotografii și videoclipuri în interiorul formularului, nu permite inserarea de imagini, elemente grafice sau operatori numerici în răspunsuri.

Permite adăugarea de colaboratori care pot să participe la crearea sondajului.

Răspunsurile la sondaje sunt adunate în mod ordonat și automat în formulare, cu informații și grafice despre răspunsuri în timp real. Sau prelucrați și mai mult datele afișându-le pe toate în foi de calcul.

Designul este simplu.

Folosirea aplicației poate crea dificultăți începătorilor.

ClassMarker

Aplicația permite crearea de formulare, teste ce pot fi accesate de pe un link unic pentru testul format.

Permite introducerea de întrebări cu răspunsuri fixe, aceleași pentru test, dar permite suplimentar și adăugarea de întrebări aleatorii, accesate la întâmplare dintr-o bancă de întrebări

Permite configurarea testelor cu variante multiple de răspuns, adevărat – fals, paragrafe, verificare corectitudinii gramaticale și completarea unui câmp pentru esee.

Permite inserarea de fotografii și videoclipuri în interiorul întrebărilor și răspunsurilor.

Rezultatele pot fi adunate, prelucrate cu informații și grafice despre răspunsuri în timp real pe care utilizatorul poate opta să le primească pe e-mail.

Designul simplu și intuitiv.

Elaborarea specificaţiilor privind caracteristicile aşteptate de la aplicaţie

Pe baza aplicațiilor existente pe piață, și a dorinței de a avea o aplicație cât mai flexibilă, adaptabilă diferitelor cerințe am hotărât că aplicația va avea două funcționalități principale:

Prima funcționalitate este aceea de a putea crea teste

A doua, de a putea susține teste create de noi sau de alte persoane.

Și pentru că și experiența joacă un rol important în dezvoltarea unei aplicații am hotărât realizarea unei aplicații mobile, în detrimentul aplicațiilor web. Un alt motiv pentru a susține decizia este acela că dispozitivele mobile sunt mai la îndemână și mai ușor de folosit.

Astfel ne-am propus ca aplicația dezvoltată să îndeplinească următoarele criterii:

Mobilitate – criteriul îndeplinit prin dezvoltarea aplicației pentru dispozitivele mobile de tipul iPhone / iPad

Intuitivitate – aplicația trebuie să aibă o interfață plăcută și ușor de folosit, astfel încât curba de învățare să fie cât mai mică, utilizatorii putând să folosească aplicația fără a avea nevoie de un ghid de folosință

Flexibilitate – scopul aplicației este să fie folosită într-o varietate mare de domenii, adaptându-se diferitelor nevoi specifice. De exemplu pentru testele de inteligență de foarte multe ori variantele de răspuns includ forme geometrice, de aceea aplicația trebuie să ofere o modalitate prin care să poată fi incluse și desene sau simboluri specifice unui anumit domeniu.

Securitate – datele distribuite între utilizatori pot avea caracter sensibil, motiv pentru care trebuie asigurată securitatea datelor.

Să permită configurarea funcției de calcul a rezultatelor – gradul de dificultate al întrebărilor nu este liniar, motiv pentru care este firesc ca și funcția de calcul a rezultatelor să țină cont de acest lucru. Pentru aceasta am hotărât ca întrebările să poată avea o pondere configurabilă din nota finală.

Să permită distribuirea testelor între utilizatori – pentru distribuirea testelor vom folosi un identificator unic pentru test care va fi comunicat utilizatorului sau va fi trimis prin mail

Layoutul să fie adaptat la dimensiunea ecranului – diferitele tipuri de dispozitive (iPhone5, iPhone 6, iPhone 6 Plus) presupun diferite rezoluții pentru ecran. Aplicația trebuie să ruleze corect și să arate bine pe toate tipurile de dimensiuni

Să permită introducerea de text verbal – pentru aceasta se va folosi Siri, disponibilă pentru toate aplicațiile iOS ce permit manipulare de text.

Să fie customizabilă – fiecare utilizator are propriile gusturi în materie de culori, de aceea, pentru a fi cât mai pe placul utilizatorilor, aplicația trebuie să permită utilizatorilor să iși modifice aspectul aplicației, după preferințele proprii

În completarea acestor criterii am adăugat o serie de criterii care nu sunt obligatorii dar ar aduce un plus aplicației:

Editarea fotografiilor – pe langă a îi permite utilizatorului să încarce poze folosind camera foto, sau din galeria sa de fotografii, ar fi de preferat să se permită și editarea lor, pentru o mai buna experiență.

Utilizarea deeplink-urilor – în acest fel, utilizatorii care au primit un mail cu un cod pentru un test, vor putea deschide aplicația direct din mail, accesând linkul primit.

Generarea de teste automată – pentru că de cele mai multe ori factorul aleator ajută în procesul de testare, oamenii fiind subiectivi, utilizatorii vor putea genera teste lăsând aplicația să decidă pentru ei ce subset de întrebări va fi inclus în test, având ca input un set de întrebări.

Proiectarea aplicației

Descrierea aplicației țintă

S-a dorit implementarea unei soluții care să permită unor utilizatori să creeze formulare de teste pe baza unor șabloane, și apoi să poată distribui aceste teste pentru a fi susținute de către alți utilizatori.

Un utilizator poate avea două roluri:

Creator

este cel care creeaza întrebările și le pune la dispoziția altor utilizatori spre a le susține în cadrul unui test

are drepturi de scriere asupra întrebărilor.

Consumator

este cel care beneficiază de munca Creatorului. El primește testul și trebuie să îl susțină.

Are drepturi de citire asupra întrebărilor și drept de scriere asupra răspunsurilor proprii la întrebări

De asemenea credențialele utilizatorului vor fi salvate de la o pornire la alta a aplicației, pentru a ușura procesul de autentificare.

Structura aplicației și justificarea alegerilor făcute

Pentru a putea întelege mai bine ce presupune dezvoltarea unei aplicații mobile iOS trebuie întâi să cunoaștem foarte bine platforma, să înțelegem care sunt limitările și care sunt etapele prin care trebuie să trecem pentru a putea dezvolta o astfel de aplicație.

În primul rând, platforma iOS este o platformă cu totul deosebită. Compania Apple este o companie exclusivistă, care dezvoltă produse și servicii specializate pentru a lucra în armonie cu celelalte servicii și produse ale lor.

La fel este și cu limbajul de programare. Atât Swift cât și Objective-C sunt limbaje de programare în care se pot dezvolta doar produse compatibile Apple (aplicații mobile – iOS, sau aplicații desktop – MacOS).

Objective-C, deși pare un limbaj mai exotic, este aparut încă de la începutul anilor 80’ca un superset peste libajul C. În 1988 a fost licențiat de către NextSTEP, ajungând in 1996 să constituie inima sistemelor de operare Apple.

În 2014 Apple a anunțat în cadrul WWDC noul limbaj de programare Swift. Iar începând de la versiunea 2.2 Swift a devenit open source. Din 2014 și până în prezent principala direcție de dezvoltare Apple a fost către Swift, iar partea de dezvoltare din Objective C a fost tot pentru o mai bună interoperabilitate cu Swift. În numai doi ani Swift a intrat deja în top 15 cele mai populare limbaje de programare conform indexului TIOBE, depășind poziția ocupată de Objective-C:

Figura 3.1 Repartiția limbajelor de programare dupăpopularitate conform indexului TIOBE

iOS SDK

Dezvoltarea aplicațiilor iOS presupun un intreg ecosistem. În primul rând aplicațiile iOS pot fi dezvoltate doar pe dispozitive ce suportă sistemul de operare OSX (Începand cu anul curent numele fiind MacOS).

De asemenea este nevoie de un compilator, iar specific aplicațiilor de iOS este compilatorul LLVM, și debuggerul LLDB. Acestea sunt incluse în XCode începând cu versiunea 4 a acestuia.

XCode – este principalul mediu de dezvoltare integrat destinat aplicațiilor Objective-C și / sau Swift. Acesta este dezvoltat de Apple, beneficiind de ultimele actualizări în materie de versiuni noi ale limbajului, sau ale bibliotecilor oferite de Apple.

La momentul de față XCode reprezintă cea mai ușoară și cea mai stabilă variantă de IDE care permite compilarea codului Objective-C / Swift. XCode oferă posibilitatea de a crea aplicații pentru oricare din cele patru tipuri de produse Apple:

tvOS – sistem de operare specific dispozitivelor Apple TV

iOS – sistem de operare specific telefoanelor, tabletelor (iPhone, iPad, iPod)

macOS – sistem de operare specific laptopurilor și desktopurilor (MacBook, iMac)

watchOS – sistem de operare specific ceasurilor inteligente (iWatch)

Pentru fiecare din cele 4 tipuri de proiecte XCode oferă niște șabloane de proiecte, pentru a ușura munca developerilor:

Figura 3.2 Șabloane de proiecte pentru aplicațiile de iOS în XCode

Interface Builder – este una din cele mai importante unelte puse la dispoziție de XCode. Cu ajutorul Interface Builder (IB) se pot crea interfețe, pentru aplicații, cu un minim de cod. Din XCode se poate face drag & drop la elementele vizuale pe care dorim să le adaugăm, iar IB encodeaza layoutul făcut de noi în format xml, iar la runtime layoutul este decodat și se creează elementele așa cum au fost reprezentate în InterfaceBuilder.

Interface builder permite crearea a două tipuri de fișiere:

Xib-uri – un xib definește layoutul unui view. (view-ul fiind componenta ce stă la baza interfețelor vizuale din iOS). Sunt potrivite pentru designul unor componente care se reutilizează în intreaga aplicație. Nu se recomandă în cazul view-urilor foarte mici, care se reutilizează mult, deoarece implică o operație de citire de pe disc. În acest caz se recomandă scrierea layoutului din cod.

Storyboard-uri – acestea au ca și componentă de baza ViewController-ul. Sunt potrivite pentru a defini layouturi. Astfel se poate vizualiza foarte ușor interacțiunea dintre view-uri

Indiferent de modul în care sunt create view-urile, în implementarea clasei se poate adăuga cod care să modifice modul în care vor fi randate.

Simulatorul – testarea codului este una din cele mai importante faze din dezvoltarea unui produs. Pentru a îmbunătăți posibilitățile de testare ale aplicațiilor iOS, Apple a pus la dispoziție Simulatorul iOS. Acesta se comportă ca orice aplicație obișnuită de Mac și simulează un mediu specific iPhone, iPad, Apple Watch, sau Apple TV. Simulatorul poate fi considerat ca un instrument de testare preliminară a aplicației, înainte de a o testa pe un dispozitiv real.

Unul din cele mai importante avantaje ale simulatorului o constituie faptul că poate simula toate tipurle de dispozitive suportate de aplicație, cu fiecare versiune de sistem de operare suportat de aplicație. Astfel suntem scutiți de a cumpăra toate dispozitivele compatibile și de a avea grijă la sistemul de operare instalat pe fiecare.

Sunt și câteva dezavantaje ce privesc utilizarea simulatorului și este bine să ținem seama de ele în timpul dezvoltării aplicațiilor. În primul rând, metricile de performanță ale simulatorului depind de configurația sistemului pe care este instalat, nu de dispozitivul simulat. Pentru metrici și performanță este bine să facem testarea pe un dispozitiv real. Un alt dezavantaj îl constituie faptul că unele funcționalități nu sunt disponibile: de exemplu camera foto nu poate fi accesată din cadrul simulatorului.

Framework-uri oferite de Apple

Datorită politicii Apple și a modului sigur în care funcționează sistemul de operare iOS, ca și dezvoltator de aplicații esti constrâns la a folosi anumite frameworkuri pentru a interacționa cu anumite componente alte dispozitivului. De exemplu, pentru a putea folosi camera foto trebuie să folosim unul din frameworkurile:

AVFoundation.framework – oferă access la un nivel de abstractizare mai mic. Fiind potrivit pentru aplicațiile care au nevoie de un grad mai mare de customizare.

UIKit.framework – oferă access prin intermediul unor ViewControllere deja create la cameră sau la galeria foto existentă

Pentru a putea folosi GPS-ul este nevoie de CoreLocation.framework.

Alte framework-uri folosite:

Parse.framework – este un framework oferit de cei de la Parse pentru a putea lucra cu serviciul de BaaS furnizat de ei

Bolts.framework – framework dezvoltat de Facebook ce permite efectuarea diferitelor operații într-o manieră serială. Frameworkul a fost inclus în principal ca o dependință pentru Parse

Arhitectura aplicațiilor iOS

Pentru a putea dezvolta aplicații de iOS trebuie să înțelegem modul în care sistemul de operare interacționează cu aplicațiile:

Aplicațiile trebuie să suporte câteva cerințe de bază – sistemul presupune ca fiecare aplicație are resurse și configurări specifice precum o iconiță și informații despre capabilitățile aplicației

Aplicațiile urmează un fir de execuție foarte bine definit – din momentul în care utilizatorul lansează o aplicație și până în momentul în care o închide, aplicația urmărește un fir de execuție foarte bine definit. De-a lungul vieții unei aplicații ea poate tranztiționa între execuția în background și execuția în foreground. Poate fi terminată, relansată și poate intra temporar într-o stare suspendată. De fiecare dată când tranziționează la o nouă stare se schimbă și așteptările de la aplicație. O aplicație în foreground poate face aproape orice în timp ce o aplicație în background trebuie să facă pe cât de puține lucruri posibil. Pentru a ajusta corespunzător comportamentul aplicației trebuie să ne folosim de tranzițiile de stare ale acesteia.

Aplicațiile trebuie să ruleze eficient într-un mediu paralel – Durata de viață a bateriei este foarte importantă pentru utilizatori, de asemenea și performanța și timpul de răspuns și un bun user experience. Prin minimizarea consumului de baterie utilizatorii pot rula aplicația o durată mai îndelungata fără a fi nevoie să reîncarce dispozitivul, dar lansarea și rularea rapidă sunt de asemenea importante. Implementarea de paralelizare din iOS oferă o bună durată de viață a aplicației fără însă a sacrifica din timpul de răspuns și din experiența dorită, dar implementarea necesită ca aplicația să se adapteze la comportamentele definite de sistem.

Comunicarea dintre aplicații urmărește anumite rutine specifice – Din motive de securitate, aplicațiile iOS rulează în sandbox și au interacțiuni limitate cu alte aplicații. Pentru a comunica cu alte aplicații sunt câteva moduri specifice în care se poate realiza acest lucru.

Abordarea propriu-zisă a temei

La baza oricărei aplicații de iOS se află paradigma de programare MVC ( Model – View – Controller)

Figura 3.3 Diagrama MVC specifică aplicațiilor iOS

Componenta view din arhitectura MVC este reprezentată de elemente numite UIView și subclase ale acesteia. Specific unui UIView este faptul că poate fi reprezentat grafic prin metoda drawInRect:. Fiecare subclasa a unui view suprascrie implementarea acestei metode. Astfel pot fi create diferite tipuri de obiecte ce pot fi reprezentate pe ecran.

Deoarece interfața grafică este prima legătură între utilizator și aplicație, aspectul ei este foarte important, fiind un factor decisiv în rata de retenție a utilizatorilor pentru orice aplicație. De aceea, componentele oferite de sistem de cele mai multe ori nu sunt suficiente pentru a implementa un design plăcut și atractiv. Din acest motiv dezvoltatorii de aplicații mobile investesc o mare parte din timpul dezvoltării pentru a creea variante customizate de view-uri. Acest lucru se poate realiza prin trei moduri:

Din cod. Astfel în clasă este inclus tot codul ce ține de customizarea modului în care va fi randat view-ul și de ierarhia de subcomponente.

Folosind Xib-uri, cu ajutorul Interface builder.

Folosind Storyboards, cu ajutorul Interface Builder.

Pentru partea de adaptare la diferitele dimensiuni ale ecranului, Apple a pus la dispoziție un mecanism de redimensionare și rearanjare a view-urilor printr-un sistem de constrângeri. Fiecare constrângere constituie o ecuație liniară, iar rezultatul este obținut printr-un sistem incremental de rezolvare a constrângerilor numit Cassowary.

Sistemul de constrângeri din figura alaturată va avea ca efect afișarea view-ului în partea de jos a ecranului, și având o înălțime fixă de 40 pixeli.

Componenta model este reprezentată de baza de date și obiectele care corespund înregistrărilor din baza de date. Pentru faza inițială a aplicației s-a folosit CoreData ca și model iar ulterior s-a tranziționat la obiecte Parse.

Core data este o bază de date de tip graf de obiecte, motiv pentru care este foarte ușor de integrat într-un mediu OOP. XCode are implementat un editor de obiecte CoreData. Se poate vedea cu ușurință modul în care obiectele interacționează între ele printr-o diagramă UML generată automat de XCode.

Figura 3.6 Dispunerea obiectelor în graful de obiecte CoreData

În organizarea bazei de date am avut în vedere necesitatea aplicației de a fi flexibilă și a se putea adapta oricărei nevoie. De aceea, în inima modelului se află entitatea de tip Content.

LiteContent se referă la orice tip de obiect ce poate constitui conținutul unei întrebări sau a unui răspuns. Formele de conținut suportate sunt text sau imagine, dar datorită modului în care a fost conceput, ulterior se poate adăuga orice alt format: video, audio, sau o combinație între toate cele menționate.

LiteQuestion definește o întrebare. O întrebare este definită de două entități importante: conținutul întrebării și răspunsul la intrebare.

LiteAnswer răspunsul este definit de asemenea de o proprietate de tip conținut. Pentru testele grilă de exemplu această proprietate definește mai multe variante de răspuns, fiecare variantă de răspuns înglobând un obiect de tip content și flaguri specifice pentru a determina care variantă este corectă și care este ordinea în care trebuie afișate.

Componenta controller este cea care mediază comunicarea dintre view și model. Controllerul este responsabil să preia date din model și să le afișeze corespunzător în view și apoi să preia acțiunile utilizatorului și să facă modificările corespunzătoare asupra modelului. Tratarea evenimentelor în iOS se realizează prin intermediul lanțului de responsabilități.

După cum se poate vedea în figura alăturată, evenimentele din cadrul unui view sunt trimise către view controllerul responsabil. Dacă view controllerul nu poate trata evenimentul acesta este pasat mai departe către view-ul container, până când se găsește un controller capabil să răspundă la eveniment sau dacă nu până când se ajunge la capătul lanțului, adică la UIApplication.

Pentru o bună delimitare a responsabilităților se recomandă utilizarea view controllerelor imbricate astfel încât un view controller să nu aibă prea multe responsabilități, în cazul în care este responsabil pentru un view cu o ierarhie de subview-uri mai complexă.

Pentru a exemplifica modul în care au fost delimitate responsabilitățile am extras câteva metrici referitoare la numărul de linii de cod pentru fiecare clasă și media lor.

În medie clasele de tip controller au ~71 linii de cod. Acest lucru a fost posibil ținându-se seama de principiul unei singure responsabilități pentru obiecte, dar și datorită modului în care este conceput limbajul de programare Swift.

Cerințe hardware și software

Cerințe hardware

Pentru a putea dezvolta aplicații iOS trebuie îndeplinite câteva cerințe hardware estențiale:

În primul rând dezvoltarea trebuie făcută pe un sistem de tip Mac Machine. Acestea pot fi atât laptop (MacBook Air, MacBook Pro, etc), cât și desktop (iMac, Mac Mini Mac Pro). Se recomandă ca sistemul de calcul să fie echipat cu un SSD și cu cel puțin 4GB memorie RAM, deoarece instrumentele de dezvoltare iOS sunt consumatoare de memorie și chiar și cea mai simplă aplicație poate îngreuna mult procesul de dezvoltare

În al doilea rând trebuie să avem cel puțin un dispozitiv fizic pe care să rulăm aplicația, pentru a ne asigura că funcționează la parametri corespunzători. De asemenea, ținând cont că vom folosi facilități precum Camera foto, testarea acesteia nu poate fi făcută pe simulator. Pentru proiectul de față s-a folosit un dispozitiv de tip iPhone 5C, motiv pentru care aplicația a fost destinată în special smartphone-urilor, în detrimentul tabletelor.

Cerinte software

Pentru dezvoltarea aplicațiilor în Swift 2.2, este necesar ca sistemul de operare să fie cel puțin 10.11 (El Capitan). De asemenea, este nevoie folosirea IDE-ului XCode, cu versiunea minimă de 7.0.

XCode nu vine preinstalat cu sistemul, acesta trebuie descărcat din AppStore – principalul loc de distribuire a aplicațiilor MacOS și iOS. Pentru a putea descărca XCode trebuie să ne autentificăm cu un cont de Apple valid, iar descărcarea este gratis.

Spre deosebire de alte platforme, pe iOS procesul de testare este și el unul puțin mai complicat. Pentru a putea rula aplicații dezvoltate de noi pe iOS este necesar să avem un cont de Apple Developer. Există mai multe tipuri de conturi de developer:

Autentificarea cu contul obisnuit Apple (Gratis)

Cont Individual (99$)

Cont asociat unei Organizații (99$)

Cont premium (299$)

În cazul nostru, am decis cumpărarea unui cont de tip Individual, având în vedere faptul că distribuirea aplicației în AppStore nu este posibilă pe contul gratis. În figura de mai jos se poate vedea o comparație între cele patru tipuri de cont și la ce facilități avem acces pentru fiecare dintre ele.

Figura 3.9 Comparatie intre tipurile de conturi de dezvoltator

Implementarea aplicației

Ecranul de autentificare și ecranul de înregistrare

Condiția de bază pentru a putea folosi aplicația, este aceea de a avea un cont valid, toate datele fiind corelate cu identitatea utilizatorului. Accesul se face pe baza unei adrese email și a unei parole. Pentru a ne asigura de corectitudinea parolei, am impus utilizatorilor să introducă de două ori parola în momentul în care iși crează un cont nou. Și nu li se permite continuarea procesului de înregistrare până când cele două câmpuri nu sunt identice. De asemenea, pentru a spori securitatea am impus ca lungimea parolei să fie de cel pțin șase caractere.

Pentru a verifica validitatea câmpurilor introduse, am folosit paradigma de programare MVVM. Fiecare text field este legat de un ViewModel iar legătura dintre ele este făcută în ViewController.

Interfața unui astfel de view model este următoarea:

ViewModelul își preia informațiile despre text și dacă a început editarea textului din view și în plus știe să valideze conținutul și să returneze rezultatul. Funcție de tipul câmpului de introducere s-a folosit un obiect specific ca și ViewModel. În cazul nostru am avut nevoie de trei tipuri de ViewModel.

Șablon – este o clasă care implementează interfața FieldValidationViewModel și care în metoda de validare verifică textul dacă corespunde unei expresii regulate primită la inițializarea ViewModelului. Acest tip de ViewModel a fost folosit pentru a valida câmpurile de tip email.

Lungime minimă – este o clasă care implementeaza FieldValidationViewModel și care în implemetarea funcției de validare verifică dacă lungimea textului curent este mai mare sau egală decât lungimea minimă primită ca parametru la inițializare.

Callback – este o clasă care implementează FieldValidationViewModel și care în implementarea funcției apelează callback-ul primit ca parametru. Permite utilizarea acestui tip de ViewModel pentru cazurile în care trebuie să luăm în calcul mai multe condiții ce ar duce la o cuplare strânsă între obiecte. Acest tip de view model ne permite să verificăm dacă al doilea câmp de introducere a parolei respectă atât condiția de a avea lungime minimă dată cât și condiția de a fi identic cu primul câmp de introducere a parolei.

ViewModele ne permit reutilizarea codului în cel mai eficient mod posibil, astfel încât acelaș tip de view model poate fi folosit pentru mai multe textfield-uri și validarea lor se poate face în timp real cu un minim de cod scris, iar view controllerul, în loc să preia responsabilitatea de a valida câmpurile, lui ii revine doar responsabilitatea de a instantia ViewModelul corespunzător și de a face legătura între acesta și textfieldul său.

Figura 4.1 Ecranul de logare fără avatar Figura 4.2 Ecranul de logare cu avatar

Pentru a salva credențialele utilizătorului între două rulări ale aplicației, s-au stocat informațiile sensibile precum emailul și parola în Keychain.

Keychain reprezintă un container criptat, care conține parole pentru multiple aplicații și servicii care necesită securitate. Keychain-urile sunt containere de stocare securizată, ceea ce înseamnă că în momentul în care un keychain este blocat, nimeni nu il mai poate accesa.

În iOS aplicațiile au mereu acces la itemele din propriul keychain dar nu au acces la elementele din keychainul altor aplicații. Sistemul își generează propria parolă pentru keychain și stochează cheia pe dispozitiv în așa manieră încât să nu fie accesibilă de nici o altă aplicație. De asemenea când se salvează copii de rezervă ale dispozitivelor, elementele din keychain nu sunt salvate, pentru a împiedica accesul la ele pentru persoanele care ajung în posesia copiilor de rezervă. De aceea este importantă folosirea keychain-ului pentru a stoca parole și alte date (precum cooki-urile) care pot fi folosite pentru autentificarea securizată pe siteuri.

În iOS toate acțiunile ce implică interfața vizuală se execută pe firul de execuție principal. De aceea este important în momentul în care se dezvoltă o aplicație ca operațiile consumatoare de timp, precum accesul pe disc sau operații de prelucrare de imagini, etc să se execute pe un fir de execuție secundar. În caz contrar utilizatorul va avea impresia că aplicația s-a blocat. Dacă sunt operații consumatoare de timp, fără de care nu se poate trece la pasul următor, se recomandă adăugarea indicatoarelor vizuale care să informeze utilizatorul că se execută o operație și că totul decurge conform așteptărilor, fără elemente neprevăzute.

Din aceste motive în aplicația de față, toate operațiile ce presupun interogarea bazei de date, sau comunicarea în orice fel cu serverul se execută pe un fir de execuție secundar, iar utilizatorul reprimește accesul la aplicație în momentul în care operația s-a finalizat într-un fel sau altul.

După logare, utilizatorul poate alege unul din cele două moduri de funcționare a aplicației:

Poate alege să meargă la modul de creare a întrebărilor și a testelor (Modul Consumator)

Poate alege să susțină un test (Modul Creator)

Modul Creator

Aici utilizatorul are acces la toate întrebările create de el pe parcursul timpului, fiind grupate pe categorii. O categorie are specific un titlu și faptul că testele pot fi create din întrebările conținute într-o singură categorie. De aceea categoriile în interiorul aplicații mai sunt denumite și domenii.

Pentru a putea creea întrebări, trebuie mai întâi să creăm o categorie. Acest lucru se face folosind butonul + din colțul din dreapta sus a ecranului. În urma adăugării unui nou domeniu, vom fi duși pe un nou ecran – ecranul de editare a unui domeniu.

Din acest ecran utilizatorul poate modifica titlul domeniului, poate adăuga noi întrebări, sau poate edita o întrebare existentă. În funcție de tipul conținutului, întrebările vor fi afișate diferit în cadrul acestui ecran.

În figura alăturată se poate observa modul de afișare al întrebărilor dintr-un domeniu.

Întrebările care au conținutul de tip text, afișează direct conținutul, atât cât încap, iar restul este decupat și afișat cu puncte de suspensie.

Întrebările care au conținut de tip imagine, sunt afișate în înălțimea dată. Dacă raportul lungime lățime al imaginii este diferit de cel al celulei în care este afișat, imaginea este mărită păstrându-se raportul, până când poate umple celula. În acel moment ea este centrată în celulă, și ce depășește limitele celulei este decupat.

Afișarea conținutului întreg pe acest ecran nu ar fi adus nici un beneficiu, ba chiar ar fi venit cu foarte multe dezavantaje în ceea ce privește complexitatea implementării. În plus, în felul acesta se pot afișa mai multe întrebări pe ecran, fiind în interesul utilizatorului să aibă o privire de ansamblu asupra întrebărilor.

În cazul în care utiliztorul atinge una din intrebări, sau apasă butonul de adăugare a unei întrebari, acesta este trimis pe ecranul de editare a întrebării.

Editarea întrebărilor

În acest ecran se poate configura o întrebare și conținutul ei.

Conținutul întrebării – în forma curentă a aplicației tipurile de conținut specifice unei întrebări sunt imagine sau text, considerând că prin folosirea unuia din cele două tipuri suportate se poate transpune aproape orice întrebare.

Conținutul răspunsului – Pentru simplitate, pentru răspuns s-a decis implementarea doar a tipului de răspuns grilă (cu una sau mai multe variante de răspuns, dintre care una sau mai multe pot fi corecte). Fiecare din variantele de răspuns conține un obiect de tip Conținut, care, la fel ca și întrebarea poate fi imagine sau text.

Reutilizarea codului este una din caracteristicile importante pentru un cod de calitate. De aceea, am împărțit responsabilitățile în așa manieră încât să ajungem la un nivel de granularitate care să ne permită o reutilizare cât mai mare a codului. Astfel am ajuns la a creea view controllere de tip ContentProvider.

Un obiect care implementează interfața de ContentProvider știe să încarce un anumit tip de conținut și permite modificarea lui. După ce utilizatorul alege să persiste modificările, provider-ul trimite un callback către un delegat prin care informează asupra schimbării de conținut, și pasează noul conținut către acesta.

Au fost implementate două providere, câte unul pentru fiecare din cele două tipuri de conținut menționate. De asemenea, o altă paradigmă de programare care s-a pliat foarte bine pe problema noastră a fost paradigmă de programare creațională numită Fabrica. Prin intermediul acesteia, deciziile asupra modului în care trebuie editat sau încărcat conținutul pentru un anumit obiect sunt luate încă de la prima interacțiune cu ele, instanțiindu-se content providerul corespunzator.

Figura 4.4 Fabrica de obiecte de tip ContentProvider

Un alt exemplu de implementare pentru aceeași paradigmă de programare, dar în care ne-am folosit de avantajele limbajului de programare Swift, o constituie modul în care se creează conținutul, după ce utilizatorul alege tipul de conținut cu care vrea să populeze o întrebare sau una din variantele de răspuns:

În acest caz printr-un simplu enum, putem afișa utilizatorului tipurile de conținut suportate într-un mod prietenos. Și în urma selecției, putem creea direct obiectul pe baza răspunsului oferit de utilizator.

Astfel se poate observa puterea pe care o oferă limbajul Swift, dar și naturalețea cu care poate fi utilizat.

Editarea raspunsului presupune cateva operatii mai complexe fata de continutul intrebarii. Motivul este pentru ca raspunsul este compus la randul lui din alte elemente, numite variante de raspuns. Fiecare varianta de raspuns are 3 proprietati, care sa asigure functionalitatea corecta:

Continutul variantei – similar cu intrebarea, si variantele de raspuns pot lua diferite forme, suportate la momentul de fata fiind doar imaginile si textul

Corect – este o variabila de tip boolean, care marcheaza daca o varianta de raspuns este corecta sau nu. Cu ajutorul ei se pot verifica raspunsurile corecte, si se pot suporta multiple variante corecte de raspuns.

Index – pentru anumite intrebari este important ca ordinea de afisare a raspunsurilor sa fie identică cu cea gandită initial de către creatorul intrebării. Exemplu: Q: Ce capitale sunt străbătute de Dunăre? A: Vienna, Bratislava, Belgrade, Bucuresti; In acest caz primele trei variante sunt corecte, ultima fiind greșită

În figura alăturată se poate vedea ecranul de editare a unei intrebari, in care atat intrebarea cat si variantele de raspuns sunt de tip Text.

De asemenea se poate observa ca raspunsul corect este selectat, si in urma selectiei, varianta de raspuns corecta va fi evidentiata prin schimbarea culorii de fundal in verde.

In cazul in care s-a gresit bifarea raspunsului corect, prin apasarea butonului cu „v” se poate anula selectia. De asemenea o varianta de raspuns poate fi stearsa prin apasarea butonului rosu din dreapta celulei.

De mentionat in cazul operatiei de stergere este faptul ca trebuie sa se asigure si integritatea proprietatii index. O alta intrebuintare a acestui camp este ca, pe viitor sa fie suportata afisarea raspunsurilor in ordine aleatoare, daca utilizatorul va marca raspunsul ca fiind potrivit pentru aceasta. In acest caz, indexul va ajuta foarte mult si la functia de evaluare a raspunsurilor pentru a potrivi corect variantele din raspunsul original oferit de creatorul intrebarii, cu raspunsul oferit de sustinatorul testului.

Un alt lucru care trebuie luat in calcul aici este faptul ca variantele de raspuns nu contin nici un fel de validare impotriva duplicatelor. Este responsabilitatea celui care creeaza intrebarile si raspunsurile sa se asigure ca raspunsurile nu se repeta.

Desi initial acest lucru pare greu de inteles, rationamentul pentru care s-a decis aceasta este tocmai flexibilitatea despre care vorbeam a aplicatiei.

In primul rand, nu exista nici o restrictie pentru ca toate variantele de raspuns sa fie de acelas tip. O varianta de raspuns poate fi text, una imagine, etc. Daca am fi facut o functie care sa verifice duplicate, aceasta fie ar fi fost extrem de complexa, fie incompleta. Pentru ca o imagine poate reprezenta ce este scris in alta varianta. Si comparatia dintre doua tipuri diferite de continut este aproape imposibila.

Un alt lucru ce merita mentionat, este faptul ca, odata ales tipul de continut pentru intrebare sau pentru o varianta, acesta nu poate fi transformat in alt tip de continut. Pentru aceasta se poate foloseste o noua intrebare sau o noua varianta de raspuns. Decizia aceasta nu a fost impusa de o limitare de sistem, ci pur si simplu pentru o mai buna experienta pentru utilizator, incercand sa ii oferim mereu optiunile strict necesare pentru a merge mai departe, si lasand aplicatia sa ia deciziile care nu sunt blocante.

Crearea testelor

Pana acum am vazut cum se pot creea intrebari, cum sunt acestea grupate in domenii, dar cum ajungem sa creem un test propriu zis?

Domeniile actioneaza ca o plaja de intrebari, din care putem alege o anumita configuratie de intrebari si sa le grupam intr-un test. Aceasta abordare ne ofera luxul de a creea mai multe intrebari, fara a ne preocupa daca am acoperit tot ce era de acoperit sau daca am insistat prea mult pe un subiect si prea putin pe altul etc. La final, in momentul in care am terminat cu creearea de intrebari, putem sa le alegem doar pe cele care ni se par mai potrivite si sa le includem intr-un viitor test.

De asemenea, specific unui test, in majoritatea cazurilor sunt urmatoarele aspecte:

Timpul maxim de desfasurare a testului.

Punctul sau punctele din oficiu

Functia de evaluare a rezultatelor

Pentru ca si testele noastre sa fie cat mai complete am inclus fiecare dintr cele trei aspecte, cu cateva limitari:

Timpul maxim de desfasurare a testului – poate varia intre 0 si 12 ore. 0 reprezentand pentru un timp nelimitat.

Punctele din oficiu – pentru punctele din oficiu, am considerat ca o marja intre 0 si 99 puncte din oficiu poate acoperi orice scala de evaluare

Functia de evaluare a rezultatelor – pentru a creea o functie de evaluare a rezultatelor cat mai capabila, am decis ca fiecarei intrebari sa ii acordam o pondere (reprezentata in numar de puncte) din nota finala. Astfel formula de calcul pentru nota finala va fi de forma: N = O (punctele din oficiu) + P1 + .. + Pn, unde P1 … Pn sunt intrebari la care s-a raspuns corect

Dupa cum se poate vedea in figura de mai sus, utilizatorul are acces rapid, si intuitiv la toate configurarile necesare pentru a da startul unui test. El poate include intrebari, pentru fiecare intrebare inclusa poate specifica ponderea, etc.

Un alt exemplu de paradigma de programare creationala, care s-a potrivit manusa pentru nevoile noastre in acest caz este Builder. Pentru a intarzia creearea de noi intrebari pana in momentul in care este necesar, pentru fiecare intrebare din domeniu s-a instatiat un Builder. Acesta tine informatii precum intrebarea originala, ponderea selectata si daca intrebarea ar trebui sa fie inclusa sau nu in testul final.

In momentul in care utilizatorul apasa butonul Next, pentru fiecare builder se va apela metoda de build. Daca in urma apelului, metoda returneaza un obiect, acesta va fi inclus in lista de intrebari din testul creat.

Datorita faptului ca Swift este un limbaj de programare functional, atat creearea builderelor, cat si creearea de intrebari folosind builderele se traduc in cea mai simpla forma posibila.

Figura 4.9 Clasa Builder pentru obiecte de tip ParseExamQuestion

Figura 4.10 Exemplificare a modului in care sunt create Builderele folosind programare functionala

Figura 4.11 Exemplificare a modului in care sunt utilizate Builerele

Dupa ce s-a ales configuratia dorita pentru test, se poate merge la pasul urmator, prin apasarea butonului next. Acesta va avea ca efect crearea unui obiect de tip ParseExam, si a intrebarilor aferente. Fiecare intrebare dintr-un test va fi un obiect de tip ParseExamQuestion care va clona continutul intrebarii originale. Aceasta abordare a fost preferata pentru a asigura un istoric corect al intrebarilor ce au fost incluse intr-un test. Altfel, din cauza ca intrebarile din domenii pot fi editate, s-ar fi putut ajunge la inconsistente.

Dupa crearea testului, utilizatorul este dus pe un nou ecran, in care ii este afisat un cod unic asociat testului. Cod prin care alti utilizatori se pot conecta si pot sustine testul nou creat. Pentru a veni in ajutorul utilizatorilor, s-a decis adaugarea functionalitatilor de a distribui testul prin mail, sau prin SMS.

In plus, utilizatorii care primesc mail sau SMS pot deschide testul prin simpla accesare a linkului primit. Acest lucru este posibil datorita schemelor URL.

O schema URL permite unei aplicatii sa comunice cu alte aplicatii printr-un protocol definit de noi. Pentru a comunica cu o aplicatie care implementeaza o astfel de schema este necesara construirea unui URL formatat corespunzator, si a ii cere sistemului sa deschida acel URL.

Pentru a suporta o schema personalizata, trebuie declarat suportul pentru acea schema, si trebuie tratate URL-urile care folosesc schema definita.

Tratarea requesturilor URL

Orice aplicatie care are propria schema URL trebuie sa fie capabila sa trateze URL-urile care ii sunt pasate. Acestea toate sunt asate prin delegatul aplicatiei, fie la lansare fi in timpul rularii aplicatiei sau cand aceasta este in background. Functie de starea aplicatiei in momentul in care a fost accesat un URL, tratarea acestuia trebuie facuta diferit

Figura 4.12 Diagrama de evenimente la lansarea unei aplicatii printr-un URL

Figura 4.13 Diagrama de evenimente la accesarea unui URL cand aplicatia este in background

Fie ca au deschis un URL primit prin mail sau SMS, fie ca au mers din meniu catre ecranul de sustinere a unui test si au introdus un cod valid utilizatorii sunt trimisi catre ecranul de Sustinere a unui test. Aici le sunt afisate intrebarile, cate una pe ecran, ei avand posibilitatea navigarii inainte inapoi printre intrebari.

Alegerile facute sunt salvate la fiecare navigare intre intrebari, daca este cazul, dar utilizatorii pot reveni asupra raspunsurilor atata vreme cat nu au depasit timpul maxim.

Finalizarea unui test se face atunci cand utilizatorul apasa butonul Done, sau in momentul in care timpul expira. Atunci ei sunt trimisi pe un nou ecran, unde pot vedea nota finala, si raspunsurile corecte la intrebari.

Probleme speciale / dificultati intampinate si modalitati de rezolvare

Serviciul de backend

Una din problemele intampinate a fost gasirea unui serviciu de backend care sa ne poata satisface nevoile dar care sa fie usor de configurat si folosit, tema proiectului fiind in principal adresata aplicatiilor mobile ci nu celor de pe partea de server.

Dupa restrangerea listei de posibile servicii am ramas cu doua optiuni:

CloudKit – acesta este la ora actuala serviciul cel mai promitator, fiind in primul rand dezvoltat de Apple. Problema a aparut cu faptul ca CloudKit nu poate fi folosit decat in cazul unui cont de developer Individual, si am intampinat probleme la activarea acestui tip de cont. Din aceasta cauza, a trebuit sa ne orientam catre altceva, pentru a ne ramane suficient timp pentru dezvoltare.

Parse – pana la aparitia CloudKit, Parse era cel mai cunoscut si cel mai raspandit serviciu de tip BaaS. Odata cu anuntul incetarii lui incepand cu 2017, developerii au inceput sa se orienteze catre alte solutii. Motivul pentru care am ales totusi sa il folosim este, pe langa arhitectura placuta si usor de folosit, faptul ca acesta este disponibil si pentru a fi instalat pe masinile proprii. Ba mai mult, dezvoltatorii Parse au pus la dispozitie si un instrument pentru a face migrarea catre serverle proprii.

Adaptabilitatea interfetei grafice

Pentru a fi o aplicatie de succes, interfata trebuie sa arate bine pe orice tip de dispozitiv. Acest lucru se face folosind Autolayout. Problema este ca, autolayout necesita o curba de invatare destul de mare, el fiind in sine un sistem de ecuatii. De aceea putina neatentie poate duce la o aranjare a elementelor diferita decat cea dorita. Cu exercitiu si cu multa rabdare am reusit sa rezolvam majoritatea problemelor.

De asemenea, ecranul telefonului fiind relativ mic, a trebuit o atentie deoseibita la evenimente precum afisarea tastaturii (deoarece aceasta se poate suprapune peste alte elemente) sau a altor elemente similare.

Performanta

Nu se poate vorbi de o aplicatie de iOS fara a vorbi de performanta. Aplicatiile iOS sunt renumite pentru faptul ca ruleaza cursiv. Acelas lucru trebuia sa il asiguram si noi, si cu fiecare element afisat pe ecran apar alte probleme. De aceea, am folosit in mod eficient paralelizarea, mutand pe fire de executie secundare toate operatiile care puteau duce la impact al performantei, am afisat indicatoare vizuale pentru toate elementele care inca nu erau incarcate, in loc sa blocam interfata pana cand sosesc acestea, si nu in ultimul rand, a trebuit sa folosim o solutie minimala de caching, pentru a imbunatati performanta la scroll.

Testarea aplicatiei si rezultatele exerimentale

Lansarea aplicației, elemente de configurare sau instalare

Pana in momentul lansarii in AppStore aplicatia va putea fi instalata numai in modul AdHoc numai pe dispozitivele care fac parte din certificatul asociat contului de developer Individual achizitionat.

De asemenea aplicatia va putea fi instalata in modul de dezvoltare pe orice smartphone Apple, daca indeplineste conditia de a fi legat la o masina Mac pe care este codul sursa, si de a da permisiuni din setarile telefonului in momentul in care se incearca instalarea.

Aspecte legate de încărcarea procesorului, memoriei

S-au efectuat metrici pentru a observa incarcarea procesorului, si a memoriei, si s-a constatat ca aplicatia functioneaza la parametri normali, solicitand mai mult procesorul in momentul in care trebuie descarcate mai multe resurse pe o singura pagina:

Figura 5.1 Utilizarea memorie

Figura 5.2 Consumul de energie

Figura 5.3 Utilizarea procesorului in timp, reprezentat pe fiecare fir de executie

Aspecte legate de fiabilitate

In ceea ce priveste fiabilitatea s-a constatat ca in anumite conditii serviciile oferite de Parse nu sunt intotdeauna cele mai calitative, de aceea se recomanda pe viitor a se efectua teste mutand serverul pe o masina proprie, si a se vedea daca sa obtin imbunatatiri ale performantei. De asemenea o functionalitate care pare sa lipseasca frameworkului de Parse in ciuda abstractizarii tabelelor sub forma de obiecte, si a versatilitatii tipurilor de obiecte ce pot fi adaugate, este aceea de faulting. Parse permite creearea pointerilor catre anumite inregistrari, fara a incarca intreg obiectul, insa ce ii lipseste este incarcarea automata a acestuia la prima accesare. Acest lucru impune foarte mare atentie la modul in care sunt manipulate obiectele si daca sunt incarcate la momentul folosirii lor.

Un plus totusi in aceasta privinta este faptul ca implementarea a fost facuta in asa fel incat sa nu se puna accent pe frameworkul responsabil pentru partea de model. Modelele au fost facute ca si interfete, astfel incat tranzitia de la CoreData, la Parse, si poate intr-un viitor mai mult sau mai putin indepartat, la Cloud Kit sa fie factuta cu cea mai mare usurinta.

Concluzii

Dezvoltarea de aplicatii mobile reprezinta o provocare pentru oricine are ocazia sa faca acest lucru. Desi in aparenta aplicatiile mobile sunt simple si placute, ascund in spate nevoia de a livra cele mai bune solutii in cel mai scurt timp, intr-un mediu in care te confrunti in primul rand cu resurse limitate, apoi cu tot soiul de restrictii sau de rutine ce trebuie respectate pentru a putea obtine rezultatul dorit.

La fel a fost si in cazul acestei teme. A trebuit sa gasim solutii optime pentru a modela obiectele, pentru a evita blocarea firului principal de executie si pentru a obtine o experienta placuta. De asemenea o provocare in plus a constituit-o faptul ca a fost prima aplicatie dezvoltata integral in Swift, confruntandu-ne astfel cu tot felul de de limitari de limbaj sau cu nevoia de a schimba modul de gandire astfel incat sa se plieze pe standardele Swift.

De asemenea, proiectul a fost implementat astfel incat sa constituie o fundatie pe care sa se poata extinde foarte mult, de la adaugarea diferitelor tipuri media, pana la a adauga posibilitatea de a introduce diferite tipuri de raspuns, a desena, sau chiar la a se adauga pachete de simboluri, care sa permita extinderea aplicabilitatii si in arii foarte tehnice percum electronica.

Bibliografie

https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.htm

https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.htm

https://developer.apple.com/library/ios/documentation/EventHandling/Conceptual/EventHandlingiPhoneOS/event_delivery_responder_chain/event_delivery_responder_chain.html

https://developer.apple.com/library/ios/referencelibrary/GettingStarted/DevelopiOSAppsSwift/

https://developer.apple.com/library/ios//documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Introduction/Introduction.html