Programació d'aplicacións multidispositiu · Desenvolupament d’entorns interactius...

Programació d'aplicaciónsmultidispositiuJosé Manuel Solís

Desenvolupament d’entorns interactiusmultidispositiu

Desenvolupament d’entorns interactius multidispositiu Programació d'aplicacións multidispositiu

Índex

Introducció 5

Resultats d’aprenentatge 7

1 Programació orientada a objectes (OOP) 91.1 Introducció i conceptes bàsics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.1.1 Blocs de codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1.2 Estructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.1.3 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2 Conceptes avançats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2.1 Exemple pràctic introductori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2.2 Modificadors d’accés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2.3 Herència . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2.4 Relacions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2.5 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2.6 Classes abstractes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2.7 Mètodes virtuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2.8 Mètodes i propietats estàtiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Desenvolupament d’aplicacions multidispositiu 192.1 Dispositius: els components centrals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.1 Memòria principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1.2 Processador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.3 Targeta gràfica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Dispositius: els perifèrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.1 Perifèrics d’entrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.2 Perifèrics de posicionament i orientació . . . . . . . . . . . . . . . . . . . . . . . . . 312.2.3 Perifèrics de sortida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.2.4 Perifèrics d’entrada i de sortida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.3 Famílies de dispositius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.4 Plataformes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.4.1 Classificació de les plataformes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.4.2 Plataformes ’hardware’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.4.3 Plataformes ’software’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.5 ’Kits’ de desenvolupament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.5.1 Compilador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.5.2 Enllaçador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.5.3 Biblioteques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.5.4 Conversors de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.5.5 Sistema de ’build’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.5.6 Entorn de desenvolupament integrat . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

2.6 Desenvolupament multiplataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Desenvolupament d’entorns interactius multidispositiu Programació d'aplicacións multidispositiu

2.6.1 Estratègies de desenvolupament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.6.2 Tècniques i eines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3 Verificació i validació 653.1 Què vol dir validar i verificar? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.2 Desplegament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.2.1 Diferències entre la màquina de desenvolupament i el dispositiu final . . . . . . . . . 663.2.2 Plataforma oberta o tancada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.3 Adquisició de dispositius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.3.1 Emuladors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.4 La validació segons la fase del cicle de vida de l’aplicació . . . . . . . . . . . . . . . . . . . 693.4.1 Fase de desenvolupament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703.4.2 Fase de verificació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723.4.3 Fase de publicació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.5 Cas pràctic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Desenvolupament d’entorns interactius multidispositiu 5 Programació d'aplicacións multidispositiu

Introducció

La tendència dins de la programació d’aplicacions interactives i videojocs és anarunificant el procés de desenvolupament per famílies cada vegada més diversesde dispositius fent servir eines com les llibreries cross-platform i, en els darrerstemps, entorns integrats que permeten produir versions per tots ells des d’unamateixa finestra. Aquestes aplicacions fan servir típicament llenguatges orientatsa objectes.

Aquesta unitat té l’objectiu de presentar aquestes eines i que les entengueu dinsdel seu context, ja que tot i els avenços que s’han fet encara necessiten unacomprensió per part del desenvolupador de com han arribat a aquest punt. Aixímateix, introduirem els fonaments del llenguatge de programació que fareu servirpròximament per desenvolupar els vostres projectes.

En el primer apartat, “Programació orientada a objectes (OOP)“, veureu comla programació orientada a objectes és el paradigma de programació dominantdes de fa algunes dècades i, per tant, tot programador i programadora ha de saber-lo fer servir; parlarem d’aquest paradigma, l’emmarcarem en el seu context i enpresentarem els elements principals.

En el segon apartat, “Desenvolupament per a multidispositiu”, veureu que avuidia també és molt estrany que una aplicació només existeixi a un tipus de dispositiu.Per aquesta raó, cal saber dissenyar i generar versions diferents per cada tipus.Això ens obliga a conèixer les diferents famílies i plataformes, així com les einesque proporciona cadascuna.

Finalment, en el tercer apartat, “Verificació i validació”, veureu com necessi-tarem verificar i validar aquestes aplicacions, i conèixer les particularitats que téaquest procés en el cas de les aplicacions multidispositiu. Ens ajudaran, en aquestaqüestió, eines com els emuladors, la virtualització, la connexió amb els diferentsdispositius mitjançant cable o un enllaç de xarxa.

Esperem que els continguts siguin útils i els podeu assolir correctament. Pertal d’assegurar-vos-en, cal que feu els exercicis d’autoavaluació i les activitatsproposades. En cas de dubte, podeu preguntar al fòrum de l’assignatura, ja queaixí us podran ajudar els vostres companys o el professor.


Resultats d’aprenentatge

En finalitzar aquesta unitat, l’alumne/a:

1. Implementa projectes multimèdia multidispositiu, tenint en compte les especifi-cacions tècniques de cada tipus de dispositiu amb el qual es va a accedir al projectemultimèdia.

• Adequa els dissenys dels elements multimèdia a les especificacions tècni-ques d’emmagatzematge, connectivitat, interactivitat i visualització pròpiesde cada tipus de dispositiu (ordinadors personals, dispositius mòbils isuperfícies tàctils, entre altres) de les aplicacions multimèdia específiquesper a cada tipus de dispositiu.

• Realitza un disseny en capes de les aplicacions interactives per a la sevaadequació als diferents dispositius, buscant l’optimització dels desenvolu-paments i la seva reutilització.

• Desenvolupa les aplicacions interactives per a entorns multidispositiu, uti-litzant llenguatges orientats a objectes i buscant-ne l’optimització.

• Desenvolupa aplicacions interactives que incorporen les funcions i lescaracterístiques de maquinari pròpies dels diferents dispositius.

• Verifica i valida els desenvolupaments en els diferents entorns multidispo-sitiu.

• Implementa solucions per a la difusió d’aplicacions multidispositiu, garan-tint la correcta emissió dels continguts.


1. Programació orientada a objectes (OOP)

La programació orientada a objectes és un paradigma de programació posteriora la programació modular i la programació estructurada, que en certa manera elsengloba, ja que cadascun d’aquests paradigmes parteix de la base dels anteriors.

Un paradigma de programació és una forma de concebre el codi com una represen-tació d’unes certes entitats, juntament amb unes construccions que permeten ferservir aquestes entitats al llenguatge de programació. En el cas de la programacióorientada a objectes, aquestes entitats són els objectes i les classes; en el cas dela programació modular aquestes entitats són els mòduls.

En aquest apartat farem servir un format de classe amb pissarra, en el qualalternarem teoria amb exercicis pràctics. Idealment, hauríeu de prendreapunts sobre els continguts exposats. Podeu seguir els exercicis fent servirpaper i llapis.

1.1 Introducció i conceptes bàsics

En aquesta secció presentem els conceptes principals de la programació orientadaa objectes, partint del concepte d’estructura i les construccions pròpies de laprogramació modular; per tal que pugueu copsar el gir que suposa aquest estilde programació respecte als que el van precedir. Ens referim als blocs de codi, lesestructures i les classes.

1.1.1 Blocs de codi

En aquesta sèrie de vídeos parlem dels blocs de codi, un concepte genèric queengloba tant funcions com procediments i que designa una sèrie d’instruccionsque fan algun tipus de tasca concreta. Els blocs de codi constitueixen la unitatd’organització més bàsica i la programació modular i l’orientada a objectes elstracten de forma molt diferent.

A continuació teniu els vídeos on tractem aquest tema:

Podeu complementar lainformació teòrica delsvídeos amb el “Resum” dela unitat.


https://player.vimeo.com/video/293543875



1.1.2 Estructures

Les estructures són unes construccions dels llenguatges de programació que tenenmoltes característiques en comú amb les classes, unes construccions pròpiesdels llenguatges orientats a objectes. Per aquest motiu, dediquem unes lliçons adescriure-les des d’aquesta perspectiva. A continuació teniu els vídeos on tractemaquest tema:


















1.1.3 Classes

Les classes, juntament amb els objectes, són els components centrals de laprogramació orientada a objectes i dediquem aquest grup de lliçons a descriure’nles característiques, quines construccions del llenguatge hem de fer servir perdeclarar-les, el concepte de tipus referència i la forma en què es reserva l’espainecessari a memòria quan creem objectes a partir d’elles. A continuació teniu elsvídeos on tractem aquests temes:






















1.2 Conceptes avançats

Una vegada tingueu clares les bases de la programació orientada a objectes, ésl’hora de introduir-ne alguns conceptes avançats. El més important i característicde tots ells és el d’herència, que permet ampliar la funcionalitat de les classes fentque incloguin característiques de les altres.














1.2.1 Exemple pràctic introductori

En aquest grup de lliçons us presentem un exemple pràctic que farem servir debase posteriorment, i que constitueix un primer exemple de disseny de la soluciód’un problema fent servir orientació a objectes.





1.2.2 Modificadors d’accés

Un cop ja us heu introduït en la mecànica de l’orientació a objectes, és el momentque conegueu el concepte de modificador d’accés; un afegitó que fem a ladeclaració de les propietats i mètodes de les classes que ens permet seleccionar desde quins punts del codi podrem llegir-les i escriure-les, en el cas de les propietats,i trucar-los, en el cas dels mètodes. A continuació teniu el vídeo on tractem aquesttema:











1.2.3 Herència

Dediquem les lliçons d’aquest punt a presentar el concepte d’herència, que éscentral dins la programació orientada a objectes i que il·lustrem amb un exemplepràctic. A continuació teniu els vídeos on tractem aquest tema:




1.2.4 Relacions

En programació orientada a objectes, els problemes es resolen distribuint lestasques entre diferents objectes que col·laboren entre si. És molt important, doncs,que els objectes puguin localitzar-se els uns als altres per poder-se coordinar, iaixò es fa a través de relacions. Hi ha dos tipus principals de relació: “un a un” i“un a molts”. En aquestes lliçons us les presentem, així com algunes eines auxiliarsque heu de fer servir per crear-les.

A continuació teniu els vídeos on tractem aquests temes:

















1.2.5 UML

Un cop heu entès el funcionament de les relacions, cal fer un incís per presentarels elements del llenguatge UML que necessitareu per poder seguir les lliçonssegüents. A continuació teniu un vídeo on tractem aquest tema:















1.2.6 Classes abstractes

Les classes abstractes són una construcció pròpia de la programació orientadaa objectes que ens permet introduir als programes entitats que no tenen unaexistència completa, sinó que reuneixen les característiques comunes de diferentsclasses d’entitats. És un concepte força teòric, però molt pràctic (s’entén milloramb els exemples), ja que ens permet tractar uniformement grups d’entitats sensepreocupar-nos del tipus de cadascuna. És també un exemple de polimorfisme, unacaracterística pròpia dels llenguatges orientats a objectes.


















1.2.7 Mètodes virtuals

Els mètodes virtuals són una altra eina que podem fer servir per aprofitar elpolimorfisme. A diferència de les classes abstractes, en aquest cas les classes quefem servir com a base corresponen a conceptes que tenen una existència completai, per tant, podem programar tots els seus mètodes. A continuació teniu un vídeoon tractem aquest tema:


1.2.8 Mètodes i propietats estàtiques

Sovint, una propietat o un mètode no poden pertànyer a un objecte concret,sinó que pertanyen a una classe d’objectes; és en aquests casos quan parlem depropietats i mètodes estàtics. D’altra banda, com a modificador de declaració,“static” també designa un tipus de reserva de memòria. Finalment, els mètodesestàtics juguen un paper important a qualsevol programa, ja que usualment ésobligatori que n’hi hagi almenys un, que és on arrenca l’execució. A continuacióteniu uns vídeos on tractem aquest tema:













1.3 Conclusions

Presentem aquí algunes conclusions que podem treure d’aquest primer contacteamb la programació orientada a objectes i plantegem el treball futur que podríeufer a partir d’aquest punt. A continuació teniu el vídeo on tractem aquest tema:







2. Desenvolupament d’aplicacions multidispositiu

El desenvolupament d’aplicacions multidispositiu consisteix en el disseny i pro-gramació d’aplicacions amb l’objectiu que s’executin a una àmplia varietat dedispositius.

Per poder assolir aquest objectiu, cal conèixer les característiques que podentenir els diferents dispositius, les diferents famílies en què els podem agrupar,les plataformes que faciliten a les aplicacions l’accés als seus components i lesestratègies i eines que podem fer servir per desenvolupar les diferents versions del’aplicació.

Un dispositiu és un aparell on podem executar una aplicació. Constarà com amínim dels components centrals d’un ordinador, és a dir, processador i memòriaprincipal, així com alguns perifèrics que permetin a l’usuari interactuar amb ells(vegeu la figura 2.1). Mentre que els components centrals processen les instrucci-ons de l’aplicació, els perifèrics comuniquen les dades que tracta l’aplicació capa l’exterior, en sentit invers o en ambdós. Per tal de poder programar aplicacionsque aprofitin bé i no excedeixin les capacitats d’un dispositiu, hem de conèixercom funcionen i com mesurar les seves capacitats.

Figura 2.1. Components d’un dispositiu

2.1 Dispositius: els components centrals

Els components centrals de qualsevol dispositiu són la memòria i el processadorprincipal. Des del punt de vista del programa, són responsables d’executar elcodi i d’emmagatzemar les dades que aquest faci servir (veure la figura 2.2). Unaaltra funció del processador és tractar certs recursos, com gràfics o so, sempreque no hi hagi un processador específic que assumeixi aquesta tasca, per exempleuna targeta de so que pugui afegir per si mateixa un efecte d’eco a un so.


Els recursos solen ocuparmolt més espai que lesvariables de control del

programa.

Figura 2.2. Processador i memòria principal

2.1.1 Memòria principal

La memòria principal emmagatzema les dades que tracta el processador. Enfunció del llenguatge de programació que fem servir, aquestes dades s’organit-zaran de diferents maneres, en variables locals i globals, en el cas d’un llenguatgeestructurat, o en objectes i classes en el cas d’un llenguatge orientat a objectes.

Físicament la memòria està formada per un o més xips que emmagatzemen lesdades en cel·les, cadascuna de les quals emmagatzema un bit. La seva capacitat esmesura, per tant, en múltiples d’aquesta unitat, típicament Megabytes, Gigabyteso Terabytes.

Si el que volem és avaluar el seu rendiment, la mesura més important és la latència,és a dir, el temps que passa entre que el processador demana escriure o llegir unadada i el moment en què aquesta realment s’escriu o es llegeix.

A banda de les variables de control del programa, la memòria principal també esfa servir per emmagatzemar els recursos com sons, imatges i vídeos que faci servirl’aplicació (vegeu la figura 2.3). Cal tenir en compte que aquests recursos podenresidir també en memòries específiques; com per exemple, els gràfics que podenresidir a la memòria de vídeo (targeta gràfica).

Figura 2.3. Memòria principal


Per prevenir l’esgotament de la memòria, les aplicacions divideixen els seuscontinguts en pantalles o escenes, de manera que només es mantenen a memòriales variables i recursos de la pantalla o escena actual.

Memòria virtual

El problema principal que pot provocar la memòria és que aquesta s’esgoti i el programademani espai per a noves variables o recursos. Si això succeeix, poden donar-se duessituacions: que la memòria retorni un error al programa i aquest no pugui continuar amb latasca que estava fent; o bé que el dispositiu comenci a fer servir memòria virtual.

En aquest segon cas, el dispositiu reserva espai a algun perifèric d’emmagatzematgemassiu per fer-lo servir com si fos memòria principal, i l’aplicació pot continuar però ambun rendiment molt més baix; ja que la latència del perifèric és molt més alta i, per tant, lesoperacions de memòria es tornen molt més lentes.

Finalment, no tots els sistemes que formen part d’una aplicació interactiva fan elmateix ús de la memòria; a la taula 2.1 podeu veure una comparativa.

Taula 2.1. Ús de la memòria

Sistema Sí No Només si notenenmemòriaespecífica

Requeriments

Gràfics 2D/3D V Alts

Vídeos V Alts

Sons V Mitjans

Codi V Baixos

2.1.2 Processador

El processador és l’encarregat d’executar el codi de l’aplicació. Aquest consisteixen instruccions que demanen dades a memòria, les processen i les tornen aemmagatzemar, més instruccions de salt que fan que el processador no executiel codi en seqüència(veure la figura 2.4).

Figura 2.4. Processador


A banda d’això, el processador també juga un paper en el procés dels recursos,com imatges i models 3D, sempre que aquesta tasca no pugui derivar-se enprocessadors especialitzats, per exemple un processador de gràfics.

Quant al rendiment d’un processador, aquest és difícil de mesurar, ja que depènde la seva arquitectura i de la tasca concreta que se li assigni, però hi ha algunsparàmetres que ens poden ajudar a avaluar-lo, com la freqüència de rellotge ambla qual funcioni, que es mesura en cicles per segon o Herzs i que té una relaciódirecta amb la quantitat d’instruccions per segon que pot executar o el nombre denuclis de què disposa, que té relació amb quantes tasques simultànies se li podenassignar.

Programació concurrent (els fils d’execució)

L’existència de nuclis implica que el processador en realitat és capaç d’executar mésd’un programa a la vegada, o d’executar un programa repartint les instruccions entre elsdiferents nuclis. Per aprofitar aquesta capacitat, podem definir al programa diferents filsd’execució, de manera que el processador pugui assignar a cadascun un nucli.

Per tal que aquests fils puguin executar-se a la vegada, interessa que les tasques que facinsiguin com més independents millor. Un cas típic a una aplicació interactiva seria dedicarun fil al procés de la lògica de l’aplicació i un altre al dibuix dels gràfics. Aquesta forma deprogramar es diu programació concurrent.

Com que moltes aplicacions que necessiten fer un ús intensiu del processador fanservir operacions amb números reals, per exemple un videojoc, una mesura mésobjectiva del rendiment d’un processador són els FLOPS, acrònim de FLoatingPoint Operations per Second; és a dir, quantes operacions amb números reals potfer per segon.

Finalment, no tots els sistemes que formen una aplicació interactiva fan el mateixús del processador; a la taula 2.2 podeu veure’n una comparativa.

Taula 2.2. Ús del processador

Sistema Sí No Només si notenenprocessadorespecífic

Requeriments

Gràfics 3D V Alts

Gràfics 2D V Mitjans

Vídeos V Mitjans

So V Baixos

Codi V Baixos

2.1.3 Targeta gràfica

Els gràfics tenen molta importància en les aplicacions interactives, ja que suposenuna càrrega de treball considerable, tant en termes de procés com en termes dememòria. Això ha suposat que històricament s’hagi fet un esforç per separar elseu tractament en processadors i memòries especialitzades, tendència que vaculminar amb l’aparició de les targetes gràfiques.


La tasca d’una targeta gràfica consisteix principalment en el processament massiude vèrtexs i píxels per tal de formar una representació tridimensional d’un escenaridiverses vegades per segon. Aquest procés es separa en dues etapes principals(vegeu la figura 2.5):

• Vertex Shading, és a dir, transformar i projectar cada vèrtex dels polígonsa la seva posició final a pantalla.

• Pixel Shading, és a dir, donar a cada píxel el seu color final tenint en comptela il·luminació i les propietats de la superfície representada.

Figura 2.5. ’Vertex’ i ’pixel shading’

Aquest procés té unes característiques especials, i és que es tracta de fer operacionssenzilles però que s’han d’aplicar a un nombre molt gran d’elements. Per exemple,calcular la quantitat de llum que emet en un cert vèrtex d’un objecte pot suposarunes poques multiplicacions, però en una escena típica d’un videojoc pot haver-hi milions de vèrtexs. Això fa que el processador gràfic també s’aprofiti per aaltres tasques amb el mateix perfil; per exemple, el processament de físiques oinclús càlculs d’intel·ligència artificial, alliberant d’aquesta tasca el processadorprincipal.

Les targetes gràfiques també es poden fer servir per processar gràfics 2D, tot i queaquests tenen uns requeriments molt més senzills, i en general només consisteixena emmagatzemar mapes de bits a memòria i copiar blocs d’un mapa a un altre,operació coneguda com a blit (veure la figura 2.6).

Figura 2.6. Operacions de ’blit’

Com en el cas del processador principal, la mesura del rendiment d’una targetagràfica és difícil de fer, ja que depèn de la tasca concreta que se li doni. Així i tot,una mesura comuna són els frames per segon o FPS, és a dir, quantes imatges potfer per segon d’una escena concreta.

Mesurar el rendiment

Per tal de tenir una referènciaobjectiva del rendiment, hi haproves específiques, com elwww.3dmark.com.

https://www.3dmark.com


Per exemple, normalmentels mòbils no tenen una

memòria gràfica separada.

Processador gràfic

El processador gràfic o GPU és l’equivalent al processador principal dins de latargeta gràfica. Com que la seva tasca consisteix a processar grans quantitatsd’elements, està format per molts petits processadors anomenats shader units,cadascun dels quals fa el procés d’un element a la vegada (veure la figura 2.7).

Figura 2.7. Processador gràfic

Els petits programes que executen les shader units s’anomenen shaders i podenprogramar-se en diferents llenguatges com HLSL o GLSL. Com el processadorprincipal, cada processador gràfic admet un joc diferent d’instruccions, de maneraque per traduir el codi del programa a aquest joc d’instruccions cal fer servir uncompilador específic.

Memòria gràfica

La memòria gràfica és l’equivalent de la memòria principal dins la targeta gràfica.Les seves característiques són molt similars a les de la memòria principal, i algunsdispositius poden fer servir memòria gràfica com a memòria principal i a la inversa.Les diferències amb la memòria principal són:

• Típicament, es poden llegir i escriure més dades per segon.

• Té una latència menor.

• Té una capacitat d’emmagatzematge més petita.

En el cas de les aplicacions en 3D, les dades que emmagatzema la memòria gràficasón els vèrtexs i les textures que formen els models, i en el cas de les aplicacionsen 2D, les imatges o mapes de bits (vegeu la figura 2.8).


Figura 2.8. Memòria gràfica

Disposició a la memòria de les textures i mapes de bits

Les textures o mapes de bits poden emmagatzemar-se a la memòria gràfica en uns formatsespecials quan no s’han de modificar durant l’execució d’un programa. Aquests formats fanmés ràpid l’accés a la textura o mapa de bits per part del processador gràfic, però imposenalgunes limitacions com que les textures o mapes de bits siguin quadrades i les sevesdimensions siguin múltiples de dos.

En cas que una aplicació necessiti modificar una textura o un mapa de bits, aquestas’emmagatzemarà en la memòria principal ordenada per files i començant de dalt a baixo de baix a dalt segons el format que s’empri. Però quan el processador gràfic lesnecessiti, caldrà copiar aquestes textures a la memòria gràfica, i això afecta negativamentel rendiment.

2.2 Dispositius: els perifèrics

Els perifèrics són tots aquells components diferents del processador i la memòriaprincipal que serveixen per comunicar-se amb l’usuari, un altre dispositiu o perfer una tasca específica que el processador delega en ells. Com que cada dispositiupot comptar amb un nombre i tipus diferent de perifèrics, és important conèixer-neel funcionament i les capacitats. Podem classificar-los segons la direcció en quèflueixen les dades respecte al processador i la memòria principal en:

• Perifèrics d’entrada, si la transmissió de dades es fa en la direcció delperifèric al processador i memòria principal (el teclat, el ratolí, els joysticksi gamepads, les pantalles tàctils, les càmeres i els micròfons i als perifèricsde posicionament i orientació).

• Perifèrics de sortida, si la transmissió de dades es fa en la direcció delprocessador i la memòria principal al perifèric (les pantalles, les targetesd’àudio i els perifèrics hàptics).

• Perifèrics d’entrada i sortida, si la transmissió de dades es fa en els dossentits (un medi d’emmagatzematge massiu, com un disc dur, o una targetade xarxa).


2.2.1 Perifèrics d’entrada

Els perifèrics d’entrada serveixen per comunicar dades al processador i memòriaprincipal; per exemple, el codi de l’última tecla premuda en el cas d’un teclat(vegeu la figura 2.9). Hi ha dues formes principals en què aquesta comunicaciópot tenir lloc:

Figura 2.9. Flux de dades als perifèrics d’entrada

• Si hi ha una necessitat contínua per part de l’aplicació de conèixer l’estatdel perifèric, l’accés es fa per enquesta (vegeu la figura 2.10), és a dir,l’aplicació consulta cada cert temps el perifèric i li demana les dadesque tingui, per exemple un videojoc pot consultar el teclat cada cinquantamil·lisegons per saber on cal dirigir un personatge.

Figura 2.10. Accés per enquesta

• Si l’aplicació té altres tasques a fer o pot esperar i només necessita saberquan hi ha noves dades disponibles al perifèric, l’accés es fa per interrupció(vegeu la figura 2.11), és a dir, el perifèric avisa el programa principalmitjançant un esdeveniment i l’aplicació deixa el que estigui fent peratendre’l. Aquest tipus d’accés és típic d’aplicacions interactives basadesen finestres, on per exemple un programa no fa res fins que l’usuari fa unclic amb el ratolí sobre algun element.


Figura 2.11. Accés per interrupció

En cas que el perifèric hagi de comunicar una gran quantitat de dades a l’aplicació,o bé si no hi ha una mida preestablerta sinó que la comunicació de dades éscontínua, es fa servir la tècnica del buffering o streaming, que consisteix areservar una àrea de memòria o buffer per tal que el perifèric desi allà les dadesa mesura que les vagi generant (vegeu la figura 2.12).

Figura 2.12. Buffering

L’aplicació pot llavors interrogar el perifèric per saber si hi ha noves dadesdisponibles o bé esperar i rebre un esdeveniment quan això succeeixi. Com quela mida del buffer és limitada, pot donar-se la situació que s’ompli, de maneraque és important que l’aplicació llegeixi com més aviat millor les dades per podertreure-les i desar espai per a altres de noves.

El teclat

El teclat és un perifèric d’entrada bàsic present a molts dispositius. Això fa quenormalment tinguem disponibles funcions per accedir-hi en qualsevol llenguatgei entorn de programació. Quan hi accedim per interrupció, l’aplicació rep elsesdeveniments següents:


• Tecla premuda o key press, quan l’usuari prem la tecla.

• Tecla amunt o key up, quan l’usuari la deixa anar.

Juntament amb l’esdeveniment, l’aplicació rep un codi numèric que correspon alcodi de la tecla que s’ha premut o s’ha deixat anar. Hem de tenir en compte, però,que aquest codi pot correspondre a diferents caràcters en funció de les preferènciesd’idioma de l’usuari.

Una altra manera d’accedir a les dades del teclat és per la tècnica de buffering. Enaquest cas, es reserva un espai de memòria on s’emmagatzemen les últimes teclespremudes i l’aplicació les llegeix “consumint” una porció de les dades cada cop,per exemple una línia. Si el buffer s’omple sense que l’aplicació llegeixi les dades,les tecles premudes a partir d’aquell moment no queden registrades i el dispositiupot emetre un avís a l’usuari per indicar-l’hi.

Cada teclat té unes limitacions quant a les combinacions de tecles que es podenprémer a la vegada i quan l’usuari arriba al límit de tecles simultànies que lipermet la combinació que està prement, prémer una tecla addicional no generacap esdeveniment.

El ratolí

El ratolí és un perifèric de posicionament bàsic present als dispositius d’escriptoricom els PCs. Consta de com a mínim un botó i és força habitual que també tinguiuna rodeta o altres botons auxiliars. Com a perifèric de posicionament, el ratolíno té una referència absoluta de la seva posició, sinó que cada cert temps premuna mesura de quant s’ha desplaçat i transmet aquesta informació a l’aplicació.És, per tant, un perifèric de posicionament relatiu.

Un altre element vinculat habitualment al ratolí és el cursor. És una fletxa o iconaque es representa a la pantalla i que l’usuari pot fer servir per interaccionar amb unaaplicació. Cal dir, però, que podem trobar aplicacions, per exemple un simuladorde vol, que facin servir el ratolí sense mostrar un cursor. La comunicació ambel ratolí es pot fer per interrupció, i en aquest cas l’aplicació rep els següentsesdeveniments:

• Mouse Up, quan es prem algun botó.

• Mouse Down, quan es deixa anar un botó.

• Mouse Move, quan es mou el ratolí.

En el cas dels dos primers esdeveniments, porten com a dada el botó que s’hapremut o deixat anar; en el cas de l’últim, el desplaçament mesurat en els eixos xi y.


Els ’joysticks’ i ’gamepads’

Els joysticks i gamepads són dispositius dissenyats específicament per controlaraplicacions interactives, típicament videojocs. Consten d’una certa quantitat debotons i palanques que podem desplaçar en un o més eixos (vegeu la figura2.13) i també altres components complementaris com acceleròmetres o giroscopis.L’accés als botons es fa típicament per interrupció, i de manera similar a un teclat,l’aplicació rebrà els esdeveniments:

• Joystick Button Up.

• Joystick Button Down.

Figura 2.13. Elements d’un ’gamepad’

Cadascun d’aquests esdeveniments vindrà acompanyat de l’identificador del botóque s’ha premut o deixat anar. Pel que fa a les palanques, l’accés se sol fer perenquesta i, en aquest cas, l’aplicació demana cada cert temps l’estat de la palancai rep aquestes dades:

• En el cas de les palanques digitals, la dada que es rep és, per cada eix, uncodi que indica si la palanca està centrada o inclinada en un sentit o l’altre,per exemple 0, -1 i 1.

• En el cas de les palanques analògiques, es rep un nombre real que indicael grau d’inclinació de la palanca en cada eix, per exemple un nombre realentre -1 i 1, per exemple 0,7.

En el cas de les palanques analògiques, hi ha una limitació, i és que encaraque l’usuari la deixi anar completament, l’aplicació usualment no rep el valorzero, sinó un nombre proper, i pot interpretar erròniament que l’usuari vol fer undesplaçament (vegeu la figura 2.14). Per adreçar això les aplicacions han de ferservir el concepte de zona morta, que és un valor mínim d’inclinació per sota delqual consideren que l’usuari no està fent cap desplaçament (vegeu la figura 2.15).


Figura 2.14. Codi que no fa servir zona morta

Figura 2.15. Codi que fa servir zona morta

Pantalles tàctils

La pantalla tàctil és un perifèric de posicionament format per una pel·lícula quedetecta el contacte dels dits mitjançant les variacions que això provoca en certespropietats elèctriques, per exemple la seva capacitància. A diferència d’altresperifèrics de posicionament, la pantalla tàctil pot donar una posició absoluta percada dit amb què es prem, ja que el contacte es fa sobre una superfície amb unesdimensions concretes. La comunicació de l’aplicació amb una pantalla tàctil sesol fer per interrupció, i els esdeveniments que es reben són (vegeu la figura 2.16):

• Touch Down, quan l’usuari toca la pantalla amb un dit.

• Touch Move, quan l’usuari mou el dit sense aixecar-lo.

• Touch Up, quan l’usuari aixeca el dit de la pantalla.

Figura 2.16. Interacció amb una pantalla tàctil

Amb cadascun d’aquests esdeveniments, l’aplicació rep un identificador numèricque indica el dit amb què s’ha fet el touch i la posició a la pantalla d’aquest. Podem


trobar que hi ha una limitació en el nombre màxim de dits que pot detectar unapantalla tàctil simultàniament.

Les càmeres i els micròfons

La càmera és un perifèric que podem trobar en equips com PCs i mòbils i queproporciona imatges de l’entorn del dispositiu. Aquestes imatges poden tenir unamida considerable, en funció de la resolució a què treballi el perifèric, i per aquestmotiu es fan servir buffers per comunicar-la amb els components centrals. Quanl’aplicació vol capturar una imatge, ho comunica a la càmera i aquesta l’avisaper interrupció quan la captura ha tingut lloc, donant-li accés a l’àrea de memòriao buffer on ha emmagatzemat la imatge.

En cas que vulgui capturar vídeo, se sol fer servir la tècnica de buffering, és adir, l’aplicació envia una comanda a la càmera per iniciar la gravació i aquesta vadeixant les dades a un buffer que l’aplicació pot consultar (vegeu la figura 2.12).A partir d’aquell moment, la càmera pot avisar per interrupció quan hi hagi novesdades disponibles o bé l’aplicació pot gestionar el procés per enquesta. En cas queel buffer s’ompli, normalment les dades antigues es descarten, ja que en el cas d’unvídeo l’assumpció comuna és que les imatges més recents són més importants.

Per la seva banda, el micròfon és un perifèric d’entrada que tenim disponible adiferents famílies de dispositius, com els mòbils o les consoles portàtils. L’accésal micròfon és similar a l’accés a una càmera i també es fa servir la tècnica delbuffering, ja que el perifèric produeix dades contínuament. La diferència méssignificativa és que el format de les dades de so és diferent del d’una imatge i laseva mida és molt més petita, de manera que el seu procés no és tan costós.

2.2.2 Perifèrics de posicionament i orientació

Els perifèrics de posicionament i orientació, com el teclat o el ratolí, són perifèricsd’entrada (és a dir, la transmissió de dades es fa en la direcció del perifèric alprocessador i memòria principal). La seva funció és donar una referència de laposició local, l’orientació i la posició global del dispositiu (vegeu la figura 2.17).

Figura 2.17. Dispositius de posicionament i orientació

Observem que tractaraquesta informació pot serdifícil, ja que el nombre detouches simultanis potvariar d’un moment a l’altre.


Aquestes mesures la poden donar en termes relatius, és a dir, com un desplaça-ment respecte a l’última posició i orientació mesurades, o en termes absoluts,respecte a un marc de referència immòbil, com per exemple el pol nord terrestre.Segons la seva qualitat i les condicions de l’entorn, aquesta mesura pot tenir unaprecisió variable, és a dir, pot correspondre’s amb la mesura real en major o menorgrau.

També és força comú la presència d’una gran quantitat d’oscil·lacions d’altafreqüència a la mesura, és a dir que, a un cert instant, el perifèric pot donaruna mesura molt alta, a l’instant següent una de molt baixa i una de molt altaa continuació. Això fa que sigui necessari fer algun tipus de filtratge que doni unvalor més estable, per exemple fent una mitjana de les deu últimes mesures.

La major part de dispositius compta amb almenys un d’aquests perifèrics, i enel cas dels mòbils i altres dispositius de mida similar, amb més d’un. Tambépodem trobar-los integrats com a components a altres perifèrics, per exemple alsgamepads.

Els perifèrics de posicionament i orientació són els acceleròmetres, les brúixoles,els giroscopis i els GPS. Considerats per separat, cap d’ells determina completa-ment la posició i orientació del dispositiu sinó que cadascun aporta informaciód’un aspecte concret. Per tant, és necessari combinar la informació que aportenper tal d’obtenir una imatge de conjunt.

Els acceleròmetres

Els acceleròmetres mesuren l’acceleració que està patint un dispositiu en un mo-ment donat. En el cas dels acceleròmetres integrats als mòbils, aquests fan servirmaterials que canvien les seves propietats de conductivitat quan estan sotmesosa forces. Quan l’aplicació vol consultar aquesta acceleració, l’acceleròmetre liretorna els valors que corresponen a les acceleracions als eixos x, y i z d’un sistemade referència vinculat al dispositiu (vegeu la figura 2.18).

Figura 2.18. Funcionament d’un acceleròmetre

Amb aquesta informació, l’aplicació pot calcular el desplaçament que ha patit eldispositiu en termes relatius, és a dir, respecte a l’última posició mesurada, totmultiplicant el temps transcorregut per l’acceleració aplicada, sempre que tambéconegui la velocitat que tenia el dispositiu anteriorment.


Si l’aplicació vol obtenir la mesura de la posició en valors absoluts, primer detot cal fer que l’usuari prengui una referència, és a dir, parteixi d’una posicióconeguda amb el dispositiu en repòs. Una vegada s’ha pres la referència,l’aplicació pot calcular els desplaçaments en termes relatius i sumar-los a aquestaposició i orientació inicials.

Una limitació que té aquest procés és que la mesura d’un acceleròmetre no éscompletament precisa, de manera que en cada pas s’acumula un error que faque, amb el temps, la posició calculada esdevingui molt diferent de la real (vegeula figura 2.19). Una forma d’evitar aquesta situació és fer que l’usuari prengui unanova referència periòdicament.

Figura 2.19. Error acumulat fent servir un acceleròmetre per mesurar la posició d’un dispositiu

Cal tenir en compte també que l’acceleròmetre també mesura l’acceleració produ-ïda per la força de la gravetat, de manera que, en repòs, sempre donarà un valorde -9,8 m/s2 en la direcció de terra, i amb aquesta dada l’aplicació pot deduirl’orientació del dispositiu respecte al pla de terra. Un altre ús que pot fer l’aplicacióde l’acceleròmetre és detectar quan l’usuari està agitant el dispositiu.

Les brúixoles

La brúixola fa una mesura del camp magnètic i dona a l’aplicació la direcció enquè està el pol Nord. Aquesta mesura es dona com un angle amb relació a unsistema de referència solidari al dispositiu (vegeu la figura 2.20).

Hem de tenir en compte que la mesura que dona la brúixola fa referència al polNord magnètic, que no coincideix amb el pol Nord geogràfic, que és un puntfix a la superfície de la terra. Per obtenir la direcció Nord geogràfica, l’aplicacióha de combinar la lectura que li dona la brúixola amb algun tipus d’informaciócartogràfica addicional.


Figura 2.20. Mesura d’una brúixola

Els giroscopis

El giroscopi es fa servir per mesurar l’orientació del dispositiu. Podem con-cebre’l com un conjunt de petits discs que contenen un element que detecta larotació del dispositiu i la transforma en un senyal elèctric. El giroscopi dona unamesura de l’orientació absoluta (vegeu la figura 2.21) amb relació a una certaorientació inicial, per exemple la que tingués en el moment d’iniciar-se l’aplicaciói, a diferència de l’acceleròmetre, no té un error acumulat, ja que fa servir lagravetat de la Terra com a referència.

Figura 2.21. Giroscopi

Els GPS

El GPS dona una mesura absoluta de la posició del dispositiu al planeta, en formade latitud i longitud. Aquesta mesura té una precisió variable que en el millor delscasos pot suposar un error de només uns pocs metres. Cal notar que el perifèricés un receptor, és a dir, només capta els senyals que envien els satèl·lits GPS. Perpoder fer la mesura, el GPS necessita que li arribin els senyals d’un mínim desatèl·lits. Una vegada arriba a aquest mínim, tots els satèl·lits addicionals ques’hi rebin incrementen la precisió de la mesura, reduint el marge d’error. Altresfenòmens que afecten el camp electromagnètic de la Terra, com les tempestessolars, també poden interferir en el seu funcionament.


2.2.3 Perifèrics de sortida

Els perifèrics de sortida reben dades des del processador i la memòria principal,i les transmeten a l’usuari o a un altre equip. Aquestes dades poden ser imatges,so i qualsevol altre tipus d’informació que aquest pugui captar. En alguns casos,es pot donar permís al perifèric perquè llegeixi les dades de memòria mentrel’aplicació fa altres tasques. Aquest mecanisme es diu accés directe a memòria,Direct Memory Access o DMA.

En cas que la mida de les dades que s’hagin d’enviar al perifèric sigui petita,l’aplicació les pot enviar com a paràmetres, juntament amb les comandes, demanera similar a com es fa l’accés per enquesta a un dispositiu d’entrada. Encanvi, si la mida de les dades és molt gran, es reservarà una àrea de memòria obuffer on l’aplicació escriurà les dades per tal que el perifèric les llegeixi (vegeula figura 2.22).

Figura 2.22. Accés d’un perifèric d’entrada a memòria

Les pantalles

La pantalla és el dispositiu de sortida més important a una aplicació interactiva.Físicament està composta per una gran quantitat de cel·les distribuïdes en formade matriu que es poden il·luminar individualment amb diferents tècniques per talde formar imatges.

Tecnologia TFT-LCD

En els dispositius més antics, les cel·les que componien la pantalla estaven formadesper un recobriment de fòsfor en el qual impactava un raig electromagnètic, d’intensitatvariable, que els il·luminava amb el color corresponent. Als actuals dispositius TFT-LCD(Thin Film Transistor-Liquid Crystal Display ; és a dir, ‘pantalla de cristall líquid de transistorsde pel·lícula fina), aquesta tècnica està abandonada i cada cel·la conté un petit transistor iun cristall líquid que pot variar la seva opacitat en funció del voltatge aplicat, deixant passarla llum. Combinant tres d’aquestes cel·les acolorides amb els colors vermell, verd i blaupodem obtenir tota la varietat de colors que pot captar l’ull humà.

L’aplicació es comunica amb la pantalla a través d’una àrea de memòria anome-nada framebuffer. Aquesta àrea pot residir a memòria principal o a memòriade vídeo i conté una matriu de píxels ordenada per files que es correspon amb les


cel·les luminescents de la pantalla. Si l’aplicació vol mostrar una imatge a pantalla,només ha d’escriure a les posicions corresponents d’aquesta matriu de memòriaels valors de vermell, verd i blau que vol que mostrin els píxels (vegeu la figura2.23).

Figura 2.23. Funcionament del ’Framebuffer’

Les dimensions del framebuffer determinen la resolució que pot mostrar lapantalla en un moment donat, i la quantitat de bits que es facin servir per codificarels colors determinen el nombre de colors diferents que es poden mostrar. Lacombinació d’unes dimensions concretes amb una quantitat determinada de bitses coneix com un mode de vídeo, i cada pantalla suporta un grup concret d’entretots els possibles.

Moltes aplicacions, especialment les aplicacions en 3D, no accedeixen directa-ment al framebuffer sinó que transmeten les imatges, els models i les textures ala targeta gràfica, i és aquesta qui s’encarrega de produir la imatge corresponent.D’altra banda, en les aplicacions de realitat virtual l’usuari fa servir duespantalles, una per cada ull, i per tant es fan servir dos framebuffers.

Les targetes d’àudio

La targeta d’àudio és el perifèric encarregat d’interpretar una ona sonora pertal que la puguin reproduir els altaveus. Aquesta ona s’emmagatzema a una àreade memòria especial, el buffer de so, i s’interpreta mitjançant un componentanomenat conversor analògic digital o ADC. L’ona sonora es codifica fent servirsamples, que són mesures de la intensitat de l’ona en un punt concret. Com méssamples per segon es facin servir i més bits es dediquin a codificar cada sample,l’ona reconstruïda serà més semblant a l’original i, per tant, el so serà més fidel(vegeu la figura 2.24).


Figura 2.24. Digitalització d’una ona sonora

Les aplicacions usualment no escriuen directament al buffer de so, sinó que creenpetits fragments de so anomenats clips i demanen a la targeta que els reprodueixi.Aquests clips resideixen a la memòria principal, i cada vegada que l’aplicaciódemana que se’n reprodueixi un, la targeta de so ho fa mesclant-lo amb la restade clips que s’estiguin reproduint en aquell moment. Algunes targetes comptentambé amb xips que poden afegir efectes als clips, els Digital Signal Processorso DSP, i alliberen d’aquesta tasca el processador principal.

Quan es demana reproduir un clip, aquest s’assigna a un canal, i en funció de cadatargeta hi ha un límit de canals disponibles que es fan servir per fer la mescla finalque es deixa al buffer de so. Això vol dir que, encara que els canals s’alliberin quanacaba la reproducció del clip, no podem reproduir un nombre il·limitat de clips almateix temps, i una vegada s’arriba al límit els nous clips que li demani l’aplicacióno sonaran.

Els perifèrics hàptics

Els perifèrics hàptics permeten transmetre a l’usuari una sensació física o unaforça de resistència. L’habitual és trobar-los integrats a dispositius com mòbils,gamepads i joysticks. Per activar-los, l’aplicació només ha de donar una comandaal perifèric amb la intensitat amb què vol que es faci l’efecte.

En el cas dels perifèrics de feedback de força, aquests introdueixen una resistènciaal moviment que una aplicació pot fer servir per simular els efectes d’un fenomenfísic, per exemple la duresa del volant de direcció d’un cotxe. En el cas delsperifèrics de vibració o rumble, aquests fan que el perifèric vibri amb una certaintensitat, recurs que pot aprofitar una aplicació per, per exemple, avisar l’usuarid’un perill o transmetre-li la sensació que està travessant un terreny accidentat.

2.2.4 Perifèrics d’entrada i de sortida

Els perifèrics d’entrada sortida es fan servir per transmetre dades tant del proces-sador i la memòria principal cap al perifèric com en sentit invers. Com que potdonar-se el cas que aquestes dades siguin voluminoses, es reserven buffers separatspels dos sentits.


Cal aclarir que sempre hi ha una comunicació de dades en ambdós sentits enqualsevol perifèric, però quan parlem de dispositius d’entrada i sortida la quantitatde dades que circula en un sentit i el contrari estan equilibrades i, en el casd’un dispositiu que només sigui d’entrada o de sortida, les dades que circulenen sentit contrari al flux principal de dades només són senyals de control o avisosque serveixen per coordinar les diferents operacions.

D’emmagatzematge massiu

Els perifèrics d’emmagatzematge massiu són perifèrics que tenen la capacitatd’emmagatzemar una gran quantitat de dades. L’aplicació es comunica amb ellsmitjançant buffers a memòria principal que el perifèric llegeix o escriu en funcióde l’operació que se li demani (vegeu la figura 2.25). Hi ha diferents tipus segonsel medi d’emmagatzemament que es faci servir, cadascun amb una capacitat i untemps d’accés o latència diferents:

• Els discs durs magnètics, que fan servir discos magnètics, tenen unalatència alta i una gran capacitat d’emmagatzematge.

• Els disc durs d’estat sòlid, que fan servir transistors, tenen una latènciapetita i una capacitat d’emmagatzematge moderada.

• Les targetes de memòria, que fan servir transistors, tenen una latènciapetita i una capacitat d’emmagatzematge petita.

• Les unitats òptiques, que fan servir medis com un DVD o un Blu-ray, tenenuna latència alta i una capacitat d’emmagatzematge petita.

• Les unitats magnètiques, que fan servir cintes magnètiques, tenen unalatència alta i una gran capacitat d’emmagatzematge.

Figura 2.25. ’Buffers’ d’entrada i sortida

Targeta de xarxa

La targeta de xarxa és un perifèric que permet enviar i rebre dades a o des d’altresequips. Aquesta comunicació es pot fer de diverses maneres. Cadascuna d’elles


admet una quantitat de dades més gran o més petita, i resulta en una latènciadiferent entre equips.

Si els equips estan connectats a una xarxa d’àrea local, podem fer servir protocolscom l’Ethernet, que permeten enviar i rebre petits paquets de dades amb unalatència molt baixa. En aquest protocol, cada equip s’identifica per la seva adreçaMAC, que és un identificador propi de cada targeta.

Si els equips estan connectats a través d’internet, podem fer servir el protocolUDP. Aquest protocol permet transmetre petits paquets de dades amb una latènciarelativament petita, però més gran que la que tindrien a una xarxa d’àrea local. Elprotocol UDP fa servir internament el protocol IP, de manera que cada equip s’had’identificar en la comunicació per l’adreça IP. Cal tenir en compte també queaquest protocol no assegura que els paquets es rebin.

Si el que es necessita és un flux de dades bidireccional entre dos equips, segur isense limitació en la mida de les dades, es pot fer servir el protocol TCP/IP. Aquestprotocol té una latència més gran, ja que s’ha d’establir primer una connexió entreels dos equips i també fa servir internament el protocol IP. Compta amb un sistemade detecció d’errors que fa que quan un paquet de dades no es rep correctamentes torni a demanar i no té un límit en la mida de les dades que es transmeten. Comque la mida de les dades no està limitada, en aquest cas es reserva un buffer detransmissió i un de recepció.

Protocols de xarxa en aplicacions interactives i videojocs

En el cas d’aplicacions interactives i videojocs, per exemple en un joc en xarxa, els protocolstipus TCP/IP no solen ser recomanables, ja que és molt important que la latència siguimínima i sol ser acceptable que es perdi algun paquet de dades en la comunicació. Perexemple, si en un joc en xarxa un jugador no pot enviar la seva posició al servidor enun moment concret, aquest pot fer la suposició que el jugador continua movent-se en lamateixa direcció, i quan la qualitat de la transmissió millori aquest pot enviar la seva posicióuna altra vegada. En moltes ocasions no es notarà la diferència i es guanya fluïdesa en eljoc.

2.3 Famílies de dispositius

Al mercat hi ha una gran varietat de dispositius de diferents models, cadascundels quals té uns components de diferent tipus i capacitats. Per tal de poderdesenvolupar aplicacions per a ells, el primer pas és agrupar-los en famílies. Elsdispositius de cada família compartiran una sèrie de característiques comunes,com mida, capacitat de procés o presència d’alguns perifèrics, i això ens permetdissenyar aplicacions amb la seguretat que el dispositiu admet aquestes caracte-rístiques. Vegem-los detingudament (vegeu la figura 2.26):


Figura 2.26. Famílies de dispositius

• Ordinadors personals. Els ordinadors personals són equips relativamentvoluminosos que l’usuari fa servir típicament assegut a un escriptori i quecompten amb una pantalla, un teclat i un ratolí. Entre totes les famíliesde dispositius, sempre que comparem dispositius de preus similars, ésla que presenta unes prestacions més altes, tant en l’àmbit de capacitatd’emmagatzematge de dades com de procés i presència de perifèrics, ambl’excepció dels perifèrics de posicionament i orientació que, en ser equipsque no es desplacen durant el seu ús, normalment no són necessaris.

• Consoles. Les consoles són una família de dispositius amb unes prestacionssimilars a un ordinador personal però orientades a videojocs, i comptenamb un conjunt de perifèrics adaptats a aquesta finalitat específica. Enconcret, disposen de joysticks i gamepads i, en comparació a un ordinadorpersonal amb un preu similar, tenen una capacitat de memòria i de procésmés baixa, que compensen amb una targeta gràfica amb una capacitat deprocés i de memòria més alta, almenys en el moment de la seva sortida almercat.

• Mòbils. Els mòbils són una família de dispositius que es caracteritza perquèl’usuari els transporta amb ell i els fa servir principalment per comunicar-se i consultar informació, fent servir com a perifèric d’entrada una pantallatàctil. En ser dispositius que no romanen a un mateix lloc, compten amb totun seguit de dispositius de posicionament i orientació com acceleròmetresi GPS. Com que la seva mida ha de ser reduïda i han de limitar el consumd’energia per tal que la bateria no s’esgoti ràpidament, les prestacions delsseus components són més baixes en comparació amb un ordinador personal.

• Consoles portàtils. Les consoles portàtils són una família de dispositiusamb unes prestacions similars als mòbils, però amb una finalitat específica,que és executar videojocs. Compten, per tant, amb gamepads i joysticksintegrats i sovint també altres perifèrics d’entrada com pantalles tàctils icàmeres. En comparació amb els mòbils, les seves capacitats solen sermés altes, almenys en el moment de la seva sortida al mercat, i destaquenespecialment en l’aspecte gràfic.

• Sistemes de realitat virtual. Tot i que no són pròpiament una família dedispositius, els sistemes de realitat virtual tenen unes característiques prò-pies que els diferencien d’un equip d’escriptori o un mòbil. Compten ambla presència d’un casc, perifèrics d’entrada similars a gamepads, i sistemesde posició i orientació integrats a aquests components que permeten situar-los dins una escena en 3D. Pel que fa als gràfics, els sistemes de realitatvirtual requereixen unes targetes gràfiques amb una gran capacitat, ja que


han de representar dues escenes diferents, amb una taxa de fotogrames persegon molt alta. Si no ho fan així, l’usuari pot patir marejos per la falta decorrespondència entre la seva postura i l’escenari representat.

Figura 2.27. Sistemes de realitat virtual (requereixen un PC)

2.4 Plataformes

Les aplicacions no s’executen directament sobre un dispositiu, sinó sobre unaplataforma. Aquesta està formada pel dispositiu més un sistema operatiu queproveeix de tot el programari necessari perquè l’aplicació pugui interactuar ambell (vegeu la figura 2.28).

La importància de les plataformes està en el fet que permeten desenvolupar unaaplicació per a tota una família de dispositius sense haver de tenir en compteles diferències en la forma de comunicació amb els perifèrics i els componentscentrals de cada model, ja que el sistema operatiu ofereix a l’aplicació unainterfície comuna independent del dispositiu concret en què s’estigui executant.

Figura 2.28. Plataformes

D’altra banda, per desenvolupar una aplicació per a una plataforma concretanecessitarem un conjunt d’eines anomenat kit de desenvolupament (vegeu lafigura 2.29). En el cas que hi hagi una organització responsable de la plataforma,aquesta proveirà els desenvolupadors d’un conjunt d’eines “estàndard” anomenatkit de desenvolupament estàndard o SDK (standard development kit).

Trobareu més informaciósobre el kit dedesenvolupament, enaquest mateix apartat.


Figura 2.29. ’Kit’ de desenvolupament

Si la plataforma és tancada, aquest responsable serà l’empresa propietària i nomésfarà arribar el kit als desenvolupadors que hagi autoritzat; en cas contrari, serà delliure accés.

2.4.1 Classificació de les plataformes

Una plataforma pot fer servir un dispositiu físic, per exemple un mòbil, però tambéuna màquina virtual, és a dir, un dispositiu idealitzat que no té una existència física.En el primer cas parlem de plataformes hardware, i en el segon de plataformessoftware (vegeu la figura 2.30).

Figura 2.30. Plataformes ’software’

Dintre de les plataformes hardware, distingirem dos casos: aquelles en quèla família de dispositius sobre els quals s’executa el sistema operatiu és forçauniforme quant a les capacitats, o homogènies, i aquelles que presenten moltavariabilitat, heterogènies.

Tot i que el sistema operatiu “oculta” les complexitats de tractar amb el dispositiu,l’aplicació pot consultar informació sobre aquest, com la presència de certsperifèrics o la seva capacitat, i adaptar el seu comportament. En conseqüència, eldesenvolupament d’aplicacions per plataformes heterogènies sol ser més complex,ja que cal preveure alternatives en funció de les característiques del dispositiu.

Distingirem també entre plataformes obertes o tancades, en funció de si existeixun propietari que posa restriccions al desenvolupament d’aplicacions per la


plataforma o no. Sovint aquest propietari proporciona també un marketplace, és adir, una botiga virtual on els desenvolupadors poden publicar les seves aplicacions.Si la plataforma és tancada, hi haurà un procés de revisió i aprovació de lesaplicacions que s’hi publiquen.

Diferències entre plataformes Mac i Windows

El sistema operatiu Mac ha d’executar-se obligatòriament sobre un ordinador fabricat perApple. Aquesta empresa només fabrica uns pocs models diferents i, dintre d’un mateixmodel, tots els dispositius tenen el mateix tipus de processador, memòria i perifèrics ambunes característiques fixes o que presenten unes variacions mínimes. Això fa que undesenvolupador d’aplicacions per a Mac pugui comptar amb que el dispositiu tindrà unescertes capacitats, i podrà programar l’aplicació sense preocupar-se’n gaire.

En canvi, el sistema operatiu Windows pot executar-se sobre tot un ventall de modelsd’ordinador de diferents fabricants, cadascun dels quals pot incloure components iperifèrics lliurement, sempre que proveeixi Microsoft del software necessari perquè puguinintegrar-se al sistema operatiu. Això fa que un desenvolupador d’aplicacions per aaquesta plataforma sovint hagi de consultar des del codi la presència i les capacitatsdels components i perifèrics del dispositiu, i preveure com adaptar el comportament del’aplicació en cas que algun d’ells no sigui present o la seva capacitat sigui insuficient.

2.4.2 Plataformes ’hardware’

Les plataformes hardware estan compostes per un sistema operatiu que potexecutar-se sobre una família de dispositius físics o bé sobre un conjunt concretde dispositius dins una mateixa família. Aquestes són les més destacades:

1. PC/Windows. La plataforma PC/Windows és una plataforma propietàriade l’empresa Microsoft que s’executa a la família dels ordinadors personals.És una plataforma heterogènia, és a dir, els dispositius sobre els qualss’executa el sistema operatiu, tot i pertànyer a la mateixa família, podentenir capacitats molt diferents. Des del punt de vista de l’accessibilitat perals desenvolupadors, la plataforma és oberta i el kit de desenvolupamentestàndard és públic i gratuït, tot i que per publicar al marketplace cal pagaruna taxa i passar per un procés de revisió.

2. PC/Linux. La plataforma PC/Linux és una plataforma lliure que s’executaa la família dels ordinadors personals. És extremadament heterogènia, jaque s’executa sobre dispositius amb diferents capacitats sense cap tipus derestricció. Caldrà tenir en compte que:

• No existeix un únic sistema operatiu en aquesta plataforma, sinómolts que comparteixen un nucli comú que proporciona les funcio-nalitats principals.

• Des del punt de vista del desenvolupament d’aplicacions, la platafor-ma és completament oberta, però no existeix un kit de desenvolupa-ment oficial, sinó que cada desenvolupador és lliure de triar les seveseines. Això fa que sigui un entorn ideal per aprendre a desenvoluparaplicacions, tot i que no sigui una plataforma creada amb un objectiucomercial.

Marketplace d’Apple

Aquest seria un exemple de‘marketplace’; el podeu consultara: www.appstore.com.

https://www.appstore.com/


3. PC/Mac. La plataforma PC/Mac és una plataforma propietària de l’em-presa Apple que s’executa a la família dels ordinadors personals. És unaplataforma homogènia, ja que la mateixa companyia selecciona el hardwareque s’integra als dispositius i limita aquests a uns pocs models. Tècnica-ment, es tracta d’una plataforma oberta, ja que qualsevol desenvolupadorpot accedir al kit de desenvolupament estàndard i distribuir aplicacions, peròa la pràctica funciona com una plataforma tancada, ja que la seva based’usuaris està més habituada a fer servir el marketplace, i les aplicacionshan de passar per un procés de revisió i aprovació per accedir-hi.

4. Mòbil/Android. La plataforma Android és una plataforma propietària del’empresa Google que s’executa a la família dels mòbils. És una plataformaheterogènia, ja que els dispositius sobre els quals s’executa el sistemaoperatiu presenten una gran variabilitat quant a capacitats. Caldrà tenir encompte que:

• Es tracta d’una plataforma oberta, ja que l’empresa no limita eldesenvolupament d’aplicacions i el kit de desenvolupament estàndardés públic. Hi ha, però, un marketplace, Google Play, on els desenvo-lupadors han de pagar una petita taxa i passar per un procés de revisió,però no és gaire exigent.

• En sentit estricte, hauríem de dir que es tracta d’una plataforma híbridahardware/software, ja que el sistema operatiu d’Android internamentfa servir una màquina virtual derivada de la Java Virtual Machine.

5. Mòbil/iOS. La plataforma iOS és una plataforma propietària de l’empresaApple que s’executa a la família dels mòbils. És una plataforma homogènia,ja que Apple és responsable també de la fabricació els dispositius, i elslimita a uns pocs models que compten cadascun amb uns perifèrics i unescapacitats concretes. Caldrà tenir en compte que:

• La plataforma és tancada i, tot i que el kit de desenvolupamentestàndard és públic, cal que els desenvolupadors passin per un procésde registre i validació per tal de poder publicar les seves aplicacionsal marketplace, l’App Store, que és a més l’únic lloc on els usuarispoden obtenir les aplicacions. El desenvolupament de les aplicacions,a més, s’ha de fer des d’una plataforma PC/Mac.

• Un altre aspecte diferencial és que el procés de validació de lesaplicacions és relativament exigent, i la mateixa empresa publicaunes guies amb tota una sèrie de requisits que han de complir lesaplicacions per obtenir l’aprovació.

6. Consola/Playstation. La plataforma Playstation és una plataforma propie-tària de l’empresa Sony que s’executa a la família de les consoles. És unaplataforma extremadament homogènia, ja que només existeixen un pocsmodels de dispositiu amb un hardware pràcticament idèntic. Caldrà teniren compte que:

• La plataforma és completament tancada i només els desenvolupadorsautoritzats per Sony poden rebre el kit de desenvolupament estàndard


i publicar aplicacions. Com que els mateixos dispositius no admetenla instal·lació d’aplicacions durant el desenvolupament, cal també queel kit inclogui una versió de desenvolupament de la consola, cosaque encareix el preu que paga el desenvolupador.

• El procés de revisió i aprovació de les aplicacions, en aquest casjocs, és força extens i complex. La mateixa empresa fa arribar alsdesenvolupadors unes guies amb els punts mínims que ha de complirl’aplicació per poder publicar-se.

7. Consola portàtil/Playstation Portable. Les condicions d’aquesta platafor-ma són similars a les de la plataforma Consola/Playstation, tot i que el costper al desenvolupador és menor tant en concepte d’adquirir la llicència dedesenvolupador com en l’adquisició dels dispositius que cal fer servir durantel desenvolupament.

8. Realitat virtual. Els sistemes de realitat virtual són plataformes emer-gents, en el sentit que encara s’estan donant les passes per establir unsestàndards que han de complir tots els dispositius. Així i tot, s’han fetalguns avenços, com les plataformes Windows Mixed Reality, de Microsoft,i Steam VR, de Valve. Aquestes plataformes permeten desenvoluparaplicacions per a diferents conjunts de dispositius de realitat virtual fentservir kits de desenvolupament estàndard.

Publicació d’apps

La publicació d’aplicacions a l’App Store és un procés relativament complex que s’iniciaregistrant-se com a desenvolupador, pagant una quota i creant un perfil per a l’aplicació alportal de desenvolupament i al de publicació.

Tot seguit cal descarregar l’SDK, programar l’aplicació i enviar-la a través d’una einaespecífica i, passats uns dies o setmanes, es rep una notificació de si l’aplicació s’haaprovat o rebutjat.

En el segon cas l’equip de revisió fa saber quines normes incompleix l’aplicació i/o quinesaccions hem de fer, i una vegada fetes les correccions s’envia una nova versió de l’aplicaciói el cicle es repeteix fins que es rep l’aprovat.

2.4.3 Plataformes ’software’

Les plataformes software són aquelles que ofereixen a l’aplicació accés no a undispositiu físic, sinó a una màquina virtual, és a dir, un dispositiu que no existeixal món real però que es pot simular fent servir un programa.

En molts aspectes, el desenvolupament d’una aplicació per una plataforma softwa-re és similar al d’una aplicació per una plataforma hardware, ja que la plataformaofereix uns serveis comuns a l’aplicació i també és necessari obtenir un kit dedesenvolupament del fabricant (vegeu la figura 2.31). La diferència es troba en elfet que com que el dispositiu no existeix realment, quan executem una aplicacióa una plataforma software és necessària la presència d’un programari que simulila màquina virtual.


Figura 2.31. Desenvolupament per plataformes ’software’

Aquest programari, que s’anomena l’entorn d’execució o Runtime Environment,al seu torn és també una aplicació i, per tant, necessita una plataforma hardwareper executar-se (vegeu la figura 2.32).

Figura 2.32. Condicions d’execució reals d’una plataforma ’software’

El benefici de les plataformes software és que si el propietari proveeix d’entornsd’execució per diverses plataformes hardware, qualsevol aplicació desenvolupadaper la plataforma software podrà executar-se a aquestes plataformes (veure lafigura 2.33).


Figura 2.33. Plataforma ’software’ executant-se a diferents plataformes ’hardware’

Actualment, les plataformes software principals són Java i .Net:

• Java és una plataforma software que defineix una màquina virtual anomena-da Java Virtual Machine. Es tracta d’una plataforma oberta i el seu SDKés públic i gratuït. Com que és una màquina virtual, pot executar-se sobremolts dispositius físics diferents.

• .Net és una plataforma software propietat de Microsoft. Defineix unamàquina virtual anomenada Common Language Runtime. Podem trobar-la tant a ordinadors personals com a mòbils i compta amb una versió de codiobert anomenada Mono.

Limitacions de les plataformes ’software’

El rendiment de les aplicacions que s’executen a una màquina virtual es veuafectat pel fet que les instruccions de l’aplicació s’han de traduir del jocd’instruccions de la màquina virtual al del dispositiu físic. Així, podem trobardues situacions:

Si aquesta traducció es fa progressivament durant l’execució de l’aplicació(vegeu la figura 2.34), l’execució de l’aplicació a la màquina virtual serà forçamés lenta que si la mateixa aplicació s’executés directament al dispositiu físic.

Figura 2.34. Traducció progressiva de les instruccions de l’aplicació


Si es tradueixen totes les instruccions abans de començar l’execució (vegeu lafigura 2.35), l’aplicació trigarà més a iniciar-se però una vegada ho faci el seurendiment serà pràcticament igual al que tindria si s’executés directament aldispositiu físic.

Figura 2.35. Traducció en bloc de les instruccions de l’aplicació

2.5 ’Kits’ de desenvolupament

Per desenvolupar una aplicació per una plataforma es necessiten una sèrie d’einesanomenades genèricament kit de desenvolupament. Si la plataforma és propietària,el propietari posarà a disposició dels desenvolupadors un conjunt d’eines “oficials”que s’anomena el kit de desenvolupament estàndard o SDK. En altres casos,els desenvolupadors poden compondre el seu propi kit fent servir altres eines dedesenvolupament disponibles al mercat.

Els components més importants del kit són: el compilador, l’enllaçador, lesbiblioteques, els conversors de recursos, el sistema de build i, encara que no entots els kits el tenen, l’entorn de desenvolupament integrat.

2.5.1 Compilador

El compilador (figura 2.36) és l’eina més important d’un kit de desenvolupament.La seva tasca és convertir el codi font de l’aplicació, escrit en un cert llenguatgede programació, en codi màquina executable a un tipus de processador concret,o en el cas d’una plataforma software, a la màquina virtual.


Figura 2.36. Compilador

És important fer notar que dins una mateixa plataforma poden diferenciar-sediferents tipus de processador entre els dispositius i, per tant, pot ser necessaricompilar versions separades del codi de l’aplicació per cadascun (vegeu la figura2.37).

Figura 2.37. Compilació d’una aplicació per diversos tipus deprocessador

Alguns exemples de compiladors disponibles als diferents SDK de les plataformesmés conegudes, serien:

• LLVM/Clang, compilador de llenguatge C per a consola/Playstation.

• Cl, compilador de llenguatge C++ per a plataformes PC/Windows.

• Clang, compilador de llenguatge C++ per a plataformes mòbils/iOS.


2.5.2 Enllaçador

L’enllaçador o linker, té la funció d’enllaçar diferents arxius amb codi màquinaen un únic arxiu executable. Això té dues utilitats: d’una banda, permet dividirel codi font de l’aplicació en diferents arxius que es poden compilar per separat,facilitant la detecció d’errors, anomenats arxius objecte i, una vegada compilats,podem enllaçar-los per produir l’arxiu executable de l’aplicació (vegeu la figura2.38).

La segona utilitat és poder fer servir biblioteques, que són arxius amb codi jacompilat, que poden provenir d’altres desenvolupadors. Si enllacem el nostreprograma amb aquestes biblioteques, podem aprofitar les funcions, procedimentsi classes que defineixen (vegeu la figura 2.38).

Figura 2.38. Fitxers objecte i biblioteques

2.5.3 Biblioteques

Figura 2.39. Biblioteques incloses a un SDK

Cada kit de desenvolupament inclou una o més biblioteques que ofereixenfuncions, procediments i classes per facilitar l’accés de l’aplicació als diferentsdispositius.

Com a mínim, tota aplicació pot comptar amb la biblioteca de temps d’execució oRuntime Library, que li permet l’accés a les funcions bàsiques d’entrada i sortida,


és a dir, escriure a la pantalla, llegir text introduït pel teclat i fer servir el sistemade fitxers.

Per interaccionar amb altres perifèrics com la targeta gràfica, solen ser necessàriesbiblioteques especialitzades que l’aplicació hi ha d’enllaçar explícitament (vegeula figura 2.39).

Un exemple seria el DirectX, a l’SDK de PC/Windows; un conjunt de bibliotequesorientat a videojocs que inclou:

• Direct3D, per interaccionar amb la targeta gràfica i produir gràfics 3D.

• XInput2, per tractar amb perifèrics d’entrada com gamepads i joysticks.

• XAudio2, per tractar amb perifèrics de so.

2.5.4 Conversors de recursos

Els conversors de recursos són eines que permeten generar recursos compatiblesamb una plataforma concreta a partir de recursos amb formats estàndard. Podenser, per exemple, imatges o sons que pot ser necessari convertir a un format concretperquè els pugui fer servir la biblioteca gràfica o de so que ofereix la plataforma(vegeu la figura 2.40).

Figura 2.40. Conversors de recursos

Aquestes eines usualment les podrem trobar com a aplicacions que es fan servirdes de la línia d’ordres o bé com a connectors que s’integren als editors ambinterfície gràfica. Alguns exemples podrien ser:

• PVRTexTool, conversor d’imatges al format pvr, present a l’SDK d’iOS.

• DDS plugin, connector per a Photoshop que permet guardar imatges en elformat DDS, propi de l’SDK de Windows.


2.5.5 Sistema de ’build’

El sistema de build és una eina que s’encarrega de produir l’aplicació, incloent-hi la compilació del codi, l’enllaçament de les biblioteques, la conversió delsrecursos i l’empaquetatge a un arxiu que puguem instal·lar al dispositiu. El seufuncionament es basa en definir una sèrie de regles per obtenir uns fitxers objectiua partir d’uns fitxers d’origen fent servir una certa eina (vegeu la figura 2.41).

Figura 2.41. Regles de ’build’

Les regles es recullen a un arxiu anomenat makefile i, quan es processa aquestarxiu, el sistema de build executa totes les eines necessàries per obtenir l’objectiuque se li demana, usualment produir l’aplicació (vegeu la figura 2.42).


Figura 2.42. ’Makefile’

Una característica desitjable d’un sistema de build és que una vegada generat unarxiu objectiu, si els arxius d’origen no es modifiquen, el sistema no invoqui altrecop l’eina, és a dir, que sempre faci les mínimes operacions necessàries per obtenirl’objectiu. Per tal de complir amb aquesta característica, els sistemes de buildcomparen les dates de modificació dels fitxers d’origen i els fitxers objectiu i si elfitxer objectiu existeix ja i la data de modificació és posterior a la del fitxer d’origenno es repeteix l’operació.

Alguns exemples de sistemes de ‘build’ són:

• NMake, propi de l’SDK de les plataformes PC/Windows.

• Gradle, propi de l’SDK de les plataformes Java.

2.5.6 Entorn de desenvolupament integrat

Els entorns de desenvolupament integrat, Integrated Development Environmentso IDEs, són aplicacions amb interfície gràfica que podem fer servir per dur aterme tot el procés de desenvolupament d’una aplicació. No són presents a totsels SDK, atès que a les empreses propietàries de les plataformes els suposa un costdesenvolupar-les, però faciliten molt el desenvolupament quan l’empresa els posaa disposició dels desenvolupadors.

Aquests entorns permeten agrupar tots els fitxers que formen part de l’aplicació,com fitxers de codi font i recursos, vinculant-los a un arxiu de projecte (vegeu la


figura 2.43). A més de les referències a aquests fitxers, l’arxiu de projecte inclou laconfiguració per als diferents targets, és a dir, els objectius del sistema de ‘build’.

Figura 2.43. Entorn integrat de desenvolupament

Aquesta configuració pot incloure aspectes com les opcions que cal passar alcompilador, la localització de les biblioteques que faci servir l’aplicació i tambéaspectes relacionats amb la publicació, com la icona o les capacitats que ha detenir el dispositiu per poder executar l’aplicació, recollides a l’arxiu de manifest.

Quan des d’un entorn de desenvolupament integrat s’inicia l’operació de build,aquest genera l’arxiu amb les regles necessàries i invoca el sistema de build perproduir l’aplicació (vegeu la figura 2.44).

Figura 2.44. Operació de ’build’


L’alternativa a un sistema de desenvolupament integrat és crear l’arxiu de reglesmanualment i invocar el sistema de build des de la línia de comandes.

Alguns exemples d’entorns de desenvolupament integrat inclosos als SDK són:

• Android Studio, propi de l’SDK d’Android.

• Microsoft Visual Studio, propi de l’SDK de PC/Windows.

• XCode, propi de l’SDK de PC/Mac i mòbils/iOS.

2.6 Desenvolupament multiplataforma

Una vegada coneixem les eines i els processos necessaris per desenvoluparaplicacions per a una plataforma concreta, podem plantejar diferents opcions perfer un desenvolupament multiplataforma, caracteritzat per una sèrie d’estratègiesi tècniques.

Independentment de l’opció que fem servir, si la plataforma és heterogènia,haurem de fer que l’aplicació s’adapti correctament a la variabilitat que presentinels dispositius; per exemple, diferents mides de pantalla o la presència o nod’alguns perifèrics.

2.6.1 Estratègies de desenvolupament

Una vegada feta la selecció de les plataformes en què volem que s’executi la nostraaplicació, haurem d’elaborar una estratègia de desenvolupament que ens permetielaborar totes les versions amb un mínim d’esforç, és a dir, compartint el màximde codi i recursos i, si és possible, fent servir un procés de desenvolupamentcomú.

Tot i que no hi ha un procediment únic per fer això, sí que podem distingir algunesestratègies generals, com ara: la plataforma software, el repositori comú i diferentsSDK i l’entorn de desenvolupament integrat multiplataforma.

Fent servir una plataforma ’software’

Si fem el desenvolupament d’una aplicació fent servir una plataforma software,una vegada programem l’aplicació, aquesta podrà executar-se a qualsevol platafor-ma per a la qual hi hagi un entorn d’execució, és a dir, una versió de la màquinavirtual.

Per exemple, si desenvolupem una aplicació amb la plataforma .Net, inclosa al’SDK de Windows, aquesta podrà funcionar correctament a plataformes com


mòbils/Android, mòbils/iOS, PC/Windows i PC/Mac, ja que totes elles comptenamb una versió de la màquina virtual de .Net, la Common Language Runtime(vegeu la figura 2.45).

Figura 2.45. Desenvolupament multiplataforma amb una plataforma ’software’

Amb un repositori comú i diferents SDK

Una altra manera d’aconseguir generar versions d’una aplicació per a diferentsplataformes és crear un repositori amb els fitxers de codi font i recursos i instal·lara la màquina on desenvolupem l’aplicació els SDK de les plataformes que volemadmetre.

Per tal de poder fer servir el mateix codi font a totes les versions, caldrà triar unllenguatge de programació comú i assegurar-nos que tots els SDK incloguin uncompilador per a ell. Quant als recursos, haurem de generar-los en un format peral qual tots els SDK incloguin conversors.

Una vegada preparat aquest repositori comú, crearem fitxers makefile separatsper cada SDK, o bé, si els SDK inclouen un IDE, crearem arxius de projectediferents per cada plataforma que vulguem admetre. I, una vegada programadal’aplicació, podem crear les diferents versions de l’aplicació executant directamentels sistemes de ‘build’ de cada SDK o bé obrint els projectes en els diferents IDEi iniciant l’operació de build des d’aquests (vegeu la figura 2.46).


Figura 2.46. Repositori comú i diferents SDK

Quant al codi font, aquest tindrà una part comuna per a totes les plataformes,però possiblement hagi de tenir en compte també alguna diferència entre elles. Enaquest cas haurem de fer servir eines com la compilació condicional.

D’altra banda, cada SDK pot incloure biblioteques diferents per fer una mateixatasca, per exemple obrir un fitxer. En aquest cas haurem o bé de fer servir tambécompilació condicional per distingir entre les dues versions del codi o bé fer serviruna biblioteca cross-platform.

Amb un entorn de desenvolupament integrat multiplataforma

Aquesta opció és la més sofisticada de totes i és fer servir un entorn de desen-volupament integrat que permeti generar versions d’una mateixa aplicació per amoltes plataformes diferents.

De forma similar a com un IDE invoca les diferents eines de l’SDK per produiruna versió de l’aplicació per a una plataforma concreta, un IDE multiplataformaes comunica amb diferents SDK per produir les versions de l’aplicació per amoltes plataformes a partir d’un únic arxiu de projecte (vegeu la figura 2.47).

Vegeu el punt “Sistema debuild”, d’aquest mateixapartat.

Trobareu informacióampliada sobre lacompilació condicional iles bibliotequescross-platform al punt“Eines i tècniques”,d’aquest mateix apartat.


Figura 2.47. Entorn de desenvolupament integrat multiplataforma

Tot i que un IDE multiplataforma és la forma més còmoda de crear les diferentsversions d’una aplicació, cal tenir també un cert coneixement dels SDK en quèes recolzen i haver desenvolupat almenys alguna aplicació per cadascun d’ells,ja que el procés sovint no és completament automàtic i pot caldre interactuardirectament amb ells.

Alguns exemples d’entorns de desenvolupament integrats multiplataforma serien:

• Microsoft Visual Studio que, juntament amb el complement Xamarin,permet produir aplicacions per Mobils/iOS i Mòbils/Android.

• Unity3D, que permet produir jocs per a diferents plataformes, inclosesmòbils/iOS, mòbils/Android i PC/Windows, PC/Mac.

2.6.2 Tècniques i eines

Per desenvolupar aplicacions multiplataforma, haurem de fer servir algunes tèc-niques i eines, com ara: la compilació condicional, la comprovació de capacitats,les biblioteques cross-platform, les eines genèriques de conversió de recursos, elsfitxers de procés per lots i l’adaptació de la interfície.


Compilació condicional

Figura 2.48. Compilació condicional

La compilació condicional consisteix en la presència al codi d’una sèrie dedirectives que indiquen al compilador que un fragment de codi només s’hade compilar per a unes plataformes concretes. D’aquesta podem fer servir elmateix fitxer de codi per a totes les plataformes i, en cas que trobem algunaincompatibilitat, resoldre-ho creant un fragment de codi diferent per cadascuna(vegeu la figura 2.48).

Preprocés del codi

La compilació condicional és possible perquè la compilació d’un programa té una fase depreprocés, on el programa original es reescriu fent servir una sèrie de directives, similars alcodi, però que no es tenen en compte més enllà d’aquesta fase.

Dins les directives, podem trobar variables. Aquestes variables s’anomenen variables depreprocessador i serveixen per controlar la reescriptura del programa.

Les variables de preprocessador pot definir-les el desenvolupador, però normalment hi haun conjunt d’elles definides per defecte, incloses algunes que només estan presents acertes plataformes, cosa que ens permet distingir-les.

Comprovació de capacitats

La comprovació de capacitats consisteix a detectar, generalment a la fase iniciald’un programa, totes les característiques del dispositiu que siguin rellevants decara al funcionament de l’aplicació. Per poder fer aquesta detecció, les plataformesofereixen tota una sèrie de funcions amb informació sobre les característiques deldispositiu, per exemple quantitat de memòria disponible, nombre de nuclis que téel processador o la presència o no de perifèrics com un gamepad (vegeu la figura2.49).


Figura 2.49. Comprovació de capacitats

Una vegada determinades aquestes característiques, l’aplicació pot prendre deci-sions per adaptar-se al dispositiu, per exemple adaptar la interfície a la mida depantalla o fer servir unes textures de menor resolució.

Cal distingir aquest cas de la compilació condicional, perquè aquí l’aplicació téel codi per fer front a totes les circumstàncies que es pot trobar, a diferència de lacompilació condicional, on el codi de les situacions no admeses no està presenta l’arxiu de l’aplicació.

Biblioteques ’cross-platform’

Sovint ens trobarem que per fer una mateixa tasca, les biblioteques de cadaplataforma ofereixen una funció, procediment o classe diferent, de manera quehem de produir versions diferents del codi fent servir compilació condicional(vegeu la figura 2.50).


Figura 2.50. Incompatibilitat de biblioteques

Per simplificar el desenvolupament en aquest cas, una opció que tenim és fer servirbiblioteques cross-platform. Són biblioteques que estan disponibles a diferentsplataformes i ofereixen les mateixes funcions a totes, de manera que no cal distingircasos al codi (vegeu la figura 2.51).

Figura 2.51. Biblioteques ’cross-platform’


Com que una biblioteca no deixa de ser codi màquina compilat, hem de teniren compte que, dins d’una mateixa plataforma, podem necessitar una versiódiferent de la biblioteca per cada tipus de processador que admeti, i assegurar-nos que quan compilem el nostre codi per a un processador concret, enllacem unabiblioteca compilada pel mateix processador.

Algunes biblioteques cross-platform estan especialitzades en una funció concreta,per exemple so, mentre que altres ofereixen tot un ventall de funcions queintenten cobrir totes les necessitats d’un tipus concret d’aplicació.

Alguns exemples d’aquestes biblioteques són:

• SFML, que inclou funcions per a gràfics en 2D, àudio, gestió de perifèricsd’entrada i xarxa. Disponible a plataformes PC/Windows i PC/Mac, entrealtres.

• Cocos2D, que inclou funcions per animació, gràfics en 2D, físiques, àudioi gestió d’escena.

• FMod, especialitzada en àudio i present a una àmplia varietat de platafor-mes, com PC /Windows, Consola/Playstation i Mòbils/iOS.

• OpenGL, especialitzada en gràfics en 3D i present a pràcticament qualsevolplataforma que tingui processador de gràfics.

Eines genèriques de conversió de recursos

En alguns casos les conversions de recursos que haurem de fer per a les diferentsplataformes les podrem fer amb eines genèriques, en cas que aquestes acceptinformats comuns com JPG o PNG en el cas de les imatges o MP3 i OGG en el casdel so.

Alguns exemples d’eines de línia d’ordres que podem fer servir per fer aquestesconversions són:

• ImageMagick, per imatges.

• FFMpeg, per vídeo.

Una altra opció es fer servir editors per fer les conversions com Photoshop,Audacity o Gimp. Per exemple, en cas que la quantitat de fitxers a convertir siguimolt alta, podem fer servir els editors en batch mode, això vol dir executar-los desde la línia d’ordres i que facin les conversions sense mostrar la interfície.

Fitxers de procés per lots

En alguns casos senzills, en lloc de fer servir un sistema de build complex, podemfer servir arxius de procés per lots. Són fitxers on podem deixar comandes perquès’executin en seqüència, invocant per exemple el compilador, l’enllaçador, fent les


conversions necessàries de recursos i copiant els fitxers resultants a una carpetaconcreta.

Alguns exemples de fitxers de procés per lots serien:

• Bash, a plataformes PC/Mac.

• Bat, a plataformes PC/Windows.

Adaptació de la interfície

Una de les diferències més comunes entre dispositius és la mida de la pantalla.Això obliga a preveure que els elements de la interfície gràfica, com botons oindicadors, s’adaptin de forma consistent a aquesta varietat de mides. Aquestsserien alguns dels aspectes més importants:

• Sistema de referència. El sistema de referència de la pantalla sol estarsituat al centre, cantonada superior esquerra o cantonada inferior esquerra,en funció de la plataforma que estem fent servir (vegeu la figura 2.52). Enels dispositius que admetin canvi d’orientació, el sistema de referència potcanviar durant l’execució de l’aplicació.

Figura 2.52. Possibles sistemes de referència de la pantalla

• Unitats lògiques. Des del codi podem consultar l’amplada i l’alçada enpíxels de la pantalla i això ens permet fer el posicionament dels diferentselements de la interfície amb aquestes unitats. Així i tot, aquestes unitatsno sempre són adequades, ja que la resolució dels dispositius pot ser diferent,i per tant els elements de la interfície es veuran amb diferents mides iposicions a diferents dispositius (vegeu la figura 2.53). Una forma d’adreçaraixò és fer servir algun tipus d’unitat lògica, és a dir, que no depengui dela resolució. Aquestes unitats les podem obtenir dividint la posició x i y enpíxels d’un element per l’alçada i l’amplada de la pantalla respectivament,de manera que totes les coordenades dels elements estaran sempre entre 0 i1. Fent servir unitats lògiques, ens assegurem que tots els elements tindranla mateixa mida i posició relativa als diferents dispositius (vegeu la figura2.54).


Figura 2.53. Posicionar elements de la interfície amb píxels

Figura 2.54. Posicionar elements de la interfície amb unitats lògiques

• Punts d’àncora. Una opció que ofereixen moltes aplicacions de dissenyd’interfícies és la tècnica dels punts d’àncora. Ens permet vincular certspunts dels elements de la pantalla als marges d’aquesta per tal que mantin-guin una distància fixa, de manera que els elements puguin adaptar-se adiferents mides de pantalla (vegeu la figura 2.55).

Figura 2.55. Punts d’àncora


3. Verificació i validació

Podem situar la verificació i validació de les aplicacions multidispositiu com uncas particular de la verificació i validació d’una aplicació qualsevol. Així i tot,aquesta presenta una sèrie de dificultats específiques com a conseqüència d’haverde tractar amb diversos tipus de dispositius.

Per entendre aquestes dificultats, primer de tot caldrà que definim què vol dirverificar i validar, entendre el procés de desplegament de l’aplicació a undispositiu i tenir un criteri per adquirir els dispositius que necessitarem durantel desenvolupament. Després, les descriurem situant-les a les diferents etapes delcicle de vida d’una aplicació i proposarem algunes possibles solucions.

3.1 Què vol dir validar i verificar?

Validar i verificar vol dir comprovar que una característica, com un menú nou oun gràfic que hem incorporat a l’aplicació, es comporta tal com estava previst isense errors a les mateixes circumstàncies en què la trobarà l’usuari final. Aixòimplica que:

Si l’aplicació s’ha d’executar a un dispositiu concret, l’única validaciócompletament representativa de l’experiència de l’usuari és la que femamb l’aplicació instal·lada a aquest mateix dispositiu.

La dificultat de la programació d’aplicacions multidispositiu és, doncs, quehaurem de tenir accés als dispositius que faran servir els usuaris, ja que qualsevolvalidació que fem per qualsevol altre mitjà sempre serà parcial. Addicionalment,haurem de fer la validació de cada característica no a un sol tipus de dispositiu,sinó a molts.

3.2 Desplegament

El desplegament o deployment d’una aplicació és el nom tècnic que té la sevainstal·lació i posada en marxa a un dispositiu concret, o dispositiu objectiu. Lasituació serà la següent: usualment, farem el desenvolupament de l’aplicació a unamàquina diferent del dispositiu objectiu, i a aquesta màquina, tindrem instal·latl’SDK corresponent; aquest haurà d’incloure una eina que ens permeti connectar-nos amb el dispositiu i transferir els fitxers necessaris, possiblement des d’un

Al mòdul Projectes de jocsi entorns interactiusaprendreu molts mésdetalls sobre la verificaciói validació d’aplicacions engeneral.


Assumirem que tenimdisponible un IDE de cara a

aquesta explicació.

IDE. Aquest procés pot ser més o menys directe, segons les diferències entre lamàquina de desenvolupament i el dispositiu final, o si la plataforma és oberta otancada.

3.2.1 Diferències entre la màquina de desenvolupament i eldispositiu final

Per una banda, ens podem trobar amb un cas, més fàcil, on l’aplicació s’hagid’executar a un dispositiu del mateix tipus que la màquina de desenvolupament.En aquest cas el desplegament és molt senzill, ja que només cal generar l’arxiuexecutable i l’aplicació començarà a funcionar sobre el mateix equip. A aquestentorn no tindrem dificultats en fer servir totes les eines de depuració que ensofereixi l’IDE com l’execució d’instruccions pas a pas, i ens serà molt fàcilverificar el funcionament de l’aplicació.

Per altra banda, hi ha un cas més complex i més propi de la programaciómultidispositiu: que l’aplicació s’hagi d’executar a un dispositiu diferent de lamàquina de desenvolupament. En aquest cas caldrà disposar físicament d’undispositiu i crear algun tipus de connexió entre la màquina de desenvolupament iell. Per exemple, podem haver de fer servir un cable o bé fer que es connectin através d’una xarxa sense fils (vegeu figura figura 3.1).

Figura 3.1. Màquina de desenvolupament i dispositiu objectiu

Aquest procés sovint és més propens a errors i podem tenir dificultats fins aaconseguir que els dispositius se sincronitzin adequadament. Addicionalment,potser no disposarem d’eines de depuració o aquestes poden funcionar de formamés irregular. Tot això és degut al major nombre de components implicatsen la comunicació i a les diferències entre el programari de la màquina dedesenvolupament i el del dispositiu.


3.2.2 Plataforma oberta o tancada

Un altre factor que pot fer el desplegament més o menys directe és si la plataformadel dispositiu objectiu és oberta o tancada (és a dir, si existeix un propietari queposa restriccions al desenvolupament d’aplicacions per la plataforma o no):

• Si la plataforma és oberta, el desplegament serà més directe, ja que el dis-positiu objectiu no presentarà cap classe de protecció i podrem transferiri executar l’aplicació sense dificultats.

• En canvi, si la plataforma és tancada, trobarem que el dispositiu tindràalgun tipus de protecció contra instal·lacions no autoritzades i caldrà que elfabricant ens autoritzi a superar-les. Això pot comportar adquirir algun tipusde clau o certificat digital que autentifiqui l’aplicació davant el sistemaoperatiu i ens permeti instal·lar-la o haver de fer servir un dispositiu especialsense aquestes proteccions proveït pel fabricant. Tots aquests mecanismesaddicionals de protecció introdueixen passes al procés de desplegament i,per tant, poden ser una font d’errors.

3.3 Adquisició de dispositius

Com que la validació completa del comportament d’una aplicació només latindrem executant-la als dispositius que faran servir els usuaris, en algun puntde qualsevol desenvolupament multidispositiu cal plantejar la qüestió de quinsd’aquests dispositius adquirir. Com que els recursos que tindrem sempre seranlimitats, possiblement ens serà impossible disposar de tots els models i famíliesde dispositius necessàries per cobrir tots els casos, de manera que haurem de triar.

Una excepció a aquesta situació la tindrem si les plataformes objectiu són homogè-nies, ja que en aquest cas potser podrem adquirir una mostra significativa de totsel tipus de dispositiu; però si les plataformes són heterogènies, aconseguir això noserà possible.

Si ens trobem en aquesta situació, haurem de fer una tria que cobreixi com méscasos millor, i podem fer-la per tipus de components i també per capacitats:

• Fer la tria per components vol dir adquirir un dispositiu per cada compo-nent diferent que volem que l’aplicació admeti. Per exemple, podem triarun dispositiu amb un processador de 64 bits i un altre amb un processadorde 32 bits.

• Fer la tria per capacitats vol dir adquirir els dispositius segons la capacitatdels seus components, establint un mínim i un màxim, per exemple podemtriar un dispositiu amb 1GB de memòria principal i un altre amb 8GB.

Vegeu el punt“Plataformes”, a l’apartat“Desenvolupamentd’aplicacionsmultidispositiu”, d’aquestamateixa unitat.


Per descomptat, també haurem d’adquirir un dispositiu per cada plataforma dife-rent que volem admetre; per exemple, un PC/Windows o un PC/Mac. Com podemsuposar, l’adquisició dels dispositius finals pot suposar una inversió quantiosa, demanera que és important conèixer també alternatives més econòmiques; com elsemuladors o la virtualització.

3.3.1 Emuladors

Una alternativa a l’adquisició d’un dispositiu és fer servir un emulador. Unemulador és un programari que reprodueix el comportament d’un dispositiufísic i s’executa a l’equip de desenvolupament. Com que no deixa de ser un cas demàquina virtual, els emuladors també introdueixen un alentiment a l’execució del’aplicació i poden requerir una màquina de desenvolupament d’altes prestacionsperquè la velocitat d’execució sigui acceptable. Solen venir inclosos als SDK deles diferents plataformes (vegeu la figura 3.2).

Figura 3.2. Emulador

Els resultats de l’emulació no són mai completament representatius del com-portament de l’aplicació al dispositiu físic, de manera que els hem de prendresempre com una aproximació. Una raó d’això és que a l’emulador li pot faltaralgun component o servei, per exemple li pot mancar l’acceleròmetre o pot notenir accés a internet. Un altre factor a tenir en compte és que l’emulació sempresuposa una simplificació del funcionament del dispositiu real.

Emulació vs. simulació

És important distingir entre emulació i simulació. L’objectiu de l’emulació consisteix areproduir el comportament extern d’un dispositiu, és a dir, aconseguir que el dispositiuemulat produeixi la mateixa resposta que el dispositiu físic donada una acció per partde l’aplicació o l’usuari, amb llibertat de triar el procés a través del qual elabora aquestaresposta. L’objectiu de la simulació, en canvi, és reproduir fidelment el funcionament internde tots els components del dispositiu, de manera que els simuladors produeixen la mateixaresposta que el dispositiu real perquè internament fan els mateixos processos que aquest.


Així doncs, una simulació sí que pot arribar a ser completament representativa delfuncionament d’un dispositiu físic, i per tant es podria fer servir per validar una aplicaciósense la presència d’aquest. De fet, per aquest motiu és l’eina que es fa servir perdissenyar-los.

Desgraciadament, la fidelitat amb què es reprodueix el funcionament intern deldispositiu comporta una quantitat de càlculs tan gran que normalment la màquina dedesenvolupament no podria executar-la suficientment ràpid, de manera que a la pràcticaes fan servir quasi sempre emuladors.

Virtualització

Una altra tècnica semblant a l’emulació és la virtualització. En aquest cas, lamàquina de desenvolupament executa el sistema operatiu del dispositiu objectiu ili dona accés directe al processador i altres recursos (vegeu la figura figura 3.3), demanera que aquest pot executar l’aplicació amb una penalització en el rendimentmínima. Perquè aquesta tècnica funcioni correctament cal que la màquina dedesenvolupament i el dispositiu virtualitzat comparteixin força característiques,de manera que usualment només funciona si tots dos són de la mateixa família.

Figura 3.3. Virtualització

3.4 La validació segons la fase del cicle de vida de l’aplicació

Hi ha diferents fases del cicle de vida d’una aplicació on caldrà validar el seufuncionament. Ens referim a la fase de desenvolupament, la fase de verificació ila fase de publicació.


Programari especial

Per veure els missatges que lesaplicacions escriuen per lasortida estàndard a algunesfamílies de dispositius, pot

caldre un programari especialque els mostri, per exemple

l’eina LogCat d’Android.

3.4.1 Fase de desenvolupament

Durant la fase de desenvolupament, voldrem desplegar l’aplicació per validar elfuncionament de les característiques que li anirem afegint.

Sovint, en aquesta fase podrem preparar l’equip de desenvolupament perquèexecuti l’aplicació a un entorn molt controlat, per exemple, a un emulador o a undispositiu físic amb una connexió permanent. En aquestes circumstàncies, moltpossiblement podrem fer servir totes les eines de l’entorn de desenvolupament perdepurar l’aplicació; per exemple, executar el codi pas a pas, establir breakpointsi vigilar l’estat de les variables, tot i que podem tenir també alguna dificultat enfer-les servir si es presenta algun tipus d’incompatibilitat.

Així doncs, també hem d’estar preparats per si no disposem d’aquestes funcionsde depuració. En aquestes circumstàncies, haurem de fer servir qualsevol altremitjà per tal que l’aplicació pugui informar-nos de la seva activitat.

Una possibilitat que tenim és fer que l’aplicació imprimeixi missatges per laseva sortida estàndard. Aquesta és una operació que ofereixen pràcticamenttotes les llibreries de temps d’execució dels diferents llenguatges de programacióen forma d’una funció anomenada Print o Write que, en el cas d’un ordinadorpersonal, mostra el missatge per la consola (vegeu la figura figura 3.4). Distribuintestratègicament pel codi trucades a aquesta funció, podem comprovar el valor deles variables a cada moment o comprovar si una certa part del codi s’ha executat.

Figura 3.4. Depuració amb missatges per sortida estàndard

Una altra possibilitat és escriure aquests missatges a un fitxer de log. Aquest fitxerl’obrirem al principi del programa i hi escriurem amb funcions semblants a Printo Write (vegeu la figura figura 3.5).


Figura 3.5. Depuració amb fitxer de ’log’

En aquest cas, però, hem de tenir en compte un possible problema que té a veureamb els buffers d’entrada i sortida. Quan una aplicació es tanca inesperadamentper un error, pot passar que alguns missatges pendents d’escriure quedin al bufferde memòria associat amb el fitxer i perdem l’ocasió d’examinar-los (vegeu lafigura figura 3.6). Per evitar això, hem de forçar que les dades contingudes albuffer s’escriguin al fitxer després d’escriure cada missatge fent servir una funcióespecífica, que sovint s’anomena Flush (vegeu la figura figura 3.7).

Figura 3.6. Missatge de depuració perdut

Vegeu la secció “Perifèricsd’entrada” a l’apartat“Desenvolupamentd’aplicacionsmultidispositiu”.


Aquest procés estàrelacionat amb la tria dedispositius de prova quehaurem fet al principi delprojecte; vegeu la secció

“Adquisició de dispositius”.

Figura 3.7. Missatge de depuració registrat

3.4.2 Fase de verificació

La feina de verificació consisteix a provar el funcionament de l’aplicació totforçant els seus límits per trobar com més errors millor. Amb cada error, el tester(verificador) emplenarà un informe que hauran d’interpretar els programadors oaltres membres de l’equip de desenvolupament per tal d’arreglar-lo a la següentversió.

Quan estem en aquesta fase, la idea és desplegar l’aplicació als dispositius delsverificadors. En aquest cas, caldrà crear versions de prova que puguin instal·lar,i preparar-les perquè puguin informar amb la major precisió possible dels errorsque trobin.

Tot i que els informes dels verificadors sovint inclouen vídeos i captures de pan-talla, no sempre podrem distingir bé en quin model de dispositiu s’està executant,de manera que en el cas d’una verificació a un desenvolupament multidispositiu,és molt important que els informes incloguin el model de dispositiu que s’estavafent servir quan es va trobar l’error.

D’altra banda, l’organització de les sessions de verificació haurà de tenir en comptela varietat de dispositius que s’han de verificar, i triar una estratègia que permeticomprovar com més casos millor dins les possibilitats humanes i materials del’equip.

En general podem dir que les diferències més grans entre dispositius les trobaremals apartats de gràfics i so; mentre que pel que fa a l’execució del codi delprograma, en general podem assumir que serà la mateixa a tots els dispositius,ja que els llenguatges de programació en general estan molt estandarditzats. Aixòvol dir que el flux de l’aplicació generalment només l’haurem de validar a undispositiu i podrem estendre les conclusions a la resta; mentre que els gràfics iel so els haurem de validar per separat segons els diferents models de targetagràfica o de so que presentin els dispositius.


D’altra banda, quant a la capacitat, sovint només serà necessari provar amb eldispositiu de major capacitat i el de menor capacitat. Observem, però, que a undispositiu tenim diferents tipus de capacitats, com la capacitat de memòria i lacapacitat de procés, de manera que, idealment, caldria triar totes les combinacionsde capacitats possibles. Com que això esdevé impracticable ràpidament, sesol triar un dispositiu o un grup de dispositius d’altes prestacions i un altredispositiu o grup de dispositius de baixes prestacions que es verifiquen per separati s’assumeix que els dispositius amb capacitats intermèdies funcionaran de lamateixa manera.

Fins aquest punt estaríem parlant de la verificació interna o fase alfa. Una vegadasuperada, podem iniciar la verificació externa o fase beta.

Fase beta

Una vegada superada la fase alfa, podem lliurar versions de prova de l’aplicació aun grup d’usuaris, i així iniciar la verificació externa o fase beta.

En el cas de la programació multidispositiu, incloure una fase beta té l’avantatgeque els usuaris aporten els seus propis dispositius, fet que presentarà una certavarietat de models i prestacions. Si triem bé els participants, els seus dispositiuspoden constituir un grup representatiu del conjunt de dispositius finals on s’had’executar l’aplicació.

Com que els usuaris no són verificadors professionals, en aquest cas les versionsde prova de l’aplicació han d’estar preparades per generar informes automàtics;per exemple, escrivint l’estat de les variables de l’aplicació a un fitxer cada vegadaque es produeix un error. Aquest mecanisme també es pot fer servir durant la fasealfa.

3.4.3 Fase de publicació

Una vegada arribats a la fase de publicació, poden donar-se alguns problemes,donada la gran quantitat d’usuaris que passen a fer servir l’aplicació en molt poctemps, fet que constitueix un risc per a l’èxit de l’aplicació.

Per minimitzar aquest risc, una estratègia que podem fer servir és fer unapublicació progressiva, per exemple limitant el nombre de descàrregues per diao el tant per cent d’usuaris que poden tenir accés sobre la quantitat total.

Una mesura recomanable en aquest punt és incloure a les aplicacions algun tipusd’informe d’errors automàtic, que s’enviïn automàticament i inclogui el tipusde dispositiu on s’ha produït el problema. Si una vegada iniciada la publicacióprogressiva trobem que no ens arriben aquests informes o que els errors queinclouen són acceptables, incrementarem la proporció d’usuaris amb accés al’aplicació i tornarem a esperar; i així anirem repetint el procés, fins a arribar atots.


3.5 Cas pràctic

A continuació presentem un cas pràctic on desenvoluparem una aplicació multi-dispositiu, inclòs el seu desplegament i la verificació.



















Programació d'aplicacións multidispositiu · Desenvolupament d’entorns interactius...

Documents

Transcript of Programació d'aplicacións multidispositiu · Desenvolupament d’entorns interactius...