Introducció al desenvolupament d'aplicacions per a Palm OS (3a part).
Amb la col·laboració de http://www.dactil.info/cosespalm/
Requisits a l'hora de crear aplicacions per a dispositius Palm OS.
Les característiques pròpies dels ordinadors de butxaca, les seves virtuts i avantatges fan que els requisits a l'hora de desenvolupar aplicacions siguin lleugerament diferents dels d'aplicacions per a ordinadors de sobretaula.
A l'hora de crear una aplicació PalmOS haurem de tenir en compte que:
La interfície d'usuari és molt important, cal un correcte és dels elements que ens facilita PalmOS.
En un ordinador de sobretaula, l'usuari pot utilitzar el ratolí i el teclat indiferentment. En un ordinador de butxaca, el principal instrument és l'stylus (llapis o punter), i de manera secundària, el teclat virtual que s'activa a pantalla o l'escriptura Graffiti. Per tant, l'aplicació ha de facilitar al màxim que l'usuari la pugui utilitzar amb el mínim de complicació.
El tamany final de l'aplicació
Per memòria que puguin tenir actualment els ordinadors de butxaca (a partir de 2 Mb en amunt i amb la possibilitat d'afegir targetes de memòria), cal que la nostra aplicació n'ocupi el mínim possible, ja que sempre podrem carregar el Palm amb més aplicacions i dades. En una aplicació per a un ordinador de sobretaula, la limitació de memòria fins a cert punt no és important, ja sigui la RAM o l'espai en disc, les aplicacions arriben a ocupar molt.
L'espai de pantalla és reduït
En un Palm, segons el model, treballem amb pantalles de 160x160, 320x320 o 320x480. En un ordinador de sobretaula, actualment, la majoria de monitors ja treballen per defecte a 800x600. és evident que una aplicació en un ordinador de sobretaula no pateix problemes de manca d'espai de pantalla.
En un ordinador de butxaca hem de ser capaços d'aprofitar al màxim l'espai de pantalla, simplificant la quantitat d'elements d'interfície utilitzats i mostrar només la informació necessària a cada moment.
Els menús estan amagats
Per aprofitar el màxim d'espai, els menús de qualsevol aplicació PalmOS estan amagats i només es mostren quan l'usuari toca (amb l'stylus) la pestanya de nom de l'aplicació o la icona de menús que hi ha a la zona d'escriptura. No ens hem de refiar que qualsevol usuari coneixerà/recordarà aquesta funció. I, en tot cas, hem d'evitar a l'usuari l'obligació d'activar sovint el menús per qualsevol funció. En un ordinador de sobretaula l'ús del ratolí o de les combinacions de teclat fan més viable l'ús intensiu de menús, però, en un ordinador de butxaca, això es converteix en un entrebanc per a l'usuari
Reduir al mínim possible
En la documentació de desenvolupament de PalmOS es comenta que en general en els ordinadors de sobretaula els usuaris utilitzen només el 20% de les prestacions d'un programa durant el 80% de temps del seu ís. Cal dissenyar eficientment les nostres aplicacions perquè s'ajustin a una tasca molt específica. Un ordinador de butxaca s'utilitza sovint en situacions que requereixen agilitat d'ús i immediatesa, no calen súper aplicacions amb moltíssimes prestacions, només aplicacions que fan tasques molt concretes.
Aquests conceptes afecten tant a les aplicacions compilades com a les aplicacions script. La diferència fonamental és que les aplicacions script s'executen dins d'una altra aplicació, que és la que encapsula l'ús de la interfície d'usuari de PalmOS. Això significa, per exemple, que l'aplicació script en si ocuparà molt poc, però el que ocuparà molta més memòria serà el programa que el permet executar.
Per exemple, l'SmallBasic ocupa 325k. Si l'utilitzem per crear un programa que reculli que ens permeti convertir d'euros a pessetes i viceversa, ens trobarem que:
Per utilitzar el programa cal utilitzar l'SmallBasic, per tant, el programa en si ocuparà molt poc (en aquest cas) uns 2k, però tot l'SmallBasic ocupa 325K.
Si el mateix programa de conversió d'euros a pessetes el desenvolupem amb C i la API de PalmOS i el compilem, tindrem una aplicació de només 3k.
La diferència és significativa: amb 3k fem el mateix que amb el que hem necessitat 327 k (32d k+ 2k) amb SmallBasic.
El programa compilat és molt senzill d'utilitzar, l'engeguem, escrivim l'import i obtenim la conversió En canvi per utilitzar el que està fet en l'SmallBasic, primer hem d'engegar l'SmallBasic, carregar el programa i executar-lo. Amb l'afegit que no podrem utilitzar elements propis de la interfície d'usuari de PalmOS ja que, en el cas de l'SmallBasic, la interacció amb els programes té l'aspecte de la tradicional consola de DOS.
Si un altre usuari ha d'utilitzar aquest programa i nosaltres l'hem creat amb SmallBasic, obliguem l'usuari a disposar de l'intèrpret (Smallbasic.prc), tenir espai suficient en el seu Palm, disposar del script (un fitxer *.pdb amb el programa) i saber carregar-lo i engegar-lo.
Si a l'usuari li facilitem només un fitxer PRC (el que hem creat a C i compilat) només ha d'instal·lar i executar per tenir el programa funcionant i utilitzant elements de la interfície d'usuari de PalmOS (per exemple, botons o menús).
Amb això no vull dir que SmallBasic no sigui pràctic ni viable, simplement vull mostrar que hi ha uns requisits que cal tenir en compte a l'hora de desenvolupar aplicacions per PalmOS, requisits que són diferents de crear una aplicació per ordinadors de sobretaula i que sovint ens ajuden a determinar quin ha de ser el concepte de desenvolupament.
En el cas concret de SmallBAsic, és un bona eina per crear les nostres pròpies aplicacions d'ús personal en el Palm, per interactuar amb dades (agenda, notes, ...) i per automatitzar/programar tasques i càlculs de manera més ràpida i flexible que en un cicle de desenvolupament basat en compilació.
El proper dimarts parlarem del model de programació basat en la interfície d'usuari i els events, amb que ja tindrem uns coneixements mínims per posar-nos a programar quelcom concret amb el cicle habitual de desenvolupament: codi font+recursos+compilació=fitxer PRC.
També us avanço que en els propers articles començarà a mostrar de manera complementària, exemples de programes fets en llenguatges script com SmallBasic i Rexx per tal de començar a adquirir paral·lelament experiència en els camps d'aplicació de la programació script.
Següent: Introducció al desenvolupament d'aplicacions per a Palm OS (4a part).
Anterior: Introducció al desenvolupament d'aplicacions per a Palm OS (2a part)
Requisits a l'hora de crear aplicacions per a dispositius Palm OS.
Les característiques pròpies dels ordinadors de butxaca, les seves virtuts i avantatges fan que els requisits a l'hora de desenvolupar aplicacions siguin lleugerament diferents dels d'aplicacions per a ordinadors de sobretaula.
A l'hora de crear una aplicació PalmOS haurem de tenir en compte que:
La interfície d'usuari és molt important, cal un correcte és dels elements que ens facilita PalmOS.
En un ordinador de sobretaula, l'usuari pot utilitzar el ratolí i el teclat indiferentment. En un ordinador de butxaca, el principal instrument és l'stylus (llapis o punter), i de manera secundària, el teclat virtual que s'activa a pantalla o l'escriptura Graffiti. Per tant, l'aplicació ha de facilitar al màxim que l'usuari la pugui utilitzar amb el mínim de complicació.
El tamany final de l'aplicació
Per memòria que puguin tenir actualment els ordinadors de butxaca (a partir de 2 Mb en amunt i amb la possibilitat d'afegir targetes de memòria), cal que la nostra aplicació n'ocupi el mínim possible, ja que sempre podrem carregar el Palm amb més aplicacions i dades. En una aplicació per a un ordinador de sobretaula, la limitació de memòria fins a cert punt no és important, ja sigui la RAM o l'espai en disc, les aplicacions arriben a ocupar molt.
L'espai de pantalla és reduït
En un Palm, segons el model, treballem amb pantalles de 160x160, 320x320 o 320x480. En un ordinador de sobretaula, actualment, la majoria de monitors ja treballen per defecte a 800x600. és evident que una aplicació en un ordinador de sobretaula no pateix problemes de manca d'espai de pantalla.
En un ordinador de butxaca hem de ser capaços d'aprofitar al màxim l'espai de pantalla, simplificant la quantitat d'elements d'interfície utilitzats i mostrar només la informació necessària a cada moment.
Els menús estan amagats
Per aprofitar el màxim d'espai, els menús de qualsevol aplicació PalmOS estan amagats i només es mostren quan l'usuari toca (amb l'stylus) la pestanya de nom de l'aplicació o la icona de menús que hi ha a la zona d'escriptura. No ens hem de refiar que qualsevol usuari coneixerà/recordarà aquesta funció. I, en tot cas, hem d'evitar a l'usuari l'obligació d'activar sovint el menús per qualsevol funció. En un ordinador de sobretaula l'ús del ratolí o de les combinacions de teclat fan més viable l'ús intensiu de menús, però, en un ordinador de butxaca, això es converteix en un entrebanc per a l'usuari
Reduir al mínim possible
En la documentació de desenvolupament de PalmOS es comenta que en general en els ordinadors de sobretaula els usuaris utilitzen només el 20% de les prestacions d'un programa durant el 80% de temps del seu ís. Cal dissenyar eficientment les nostres aplicacions perquè s'ajustin a una tasca molt específica. Un ordinador de butxaca s'utilitza sovint en situacions que requereixen agilitat d'ús i immediatesa, no calen súper aplicacions amb moltíssimes prestacions, només aplicacions que fan tasques molt concretes.
Aquests conceptes afecten tant a les aplicacions compilades com a les aplicacions script. La diferència fonamental és que les aplicacions script s'executen dins d'una altra aplicació, que és la que encapsula l'ús de la interfície d'usuari de PalmOS. Això significa, per exemple, que l'aplicació script en si ocuparà molt poc, però el que ocuparà molta més memòria serà el programa que el permet executar.
Per exemple, l'SmallBasic ocupa 325k. Si l'utilitzem per crear un programa que reculli que ens permeti convertir d'euros a pessetes i viceversa, ens trobarem que:
Per utilitzar el programa cal utilitzar l'SmallBasic, per tant, el programa en si ocuparà molt poc (en aquest cas) uns 2k, però tot l'SmallBasic ocupa 325K.
Si el mateix programa de conversió d'euros a pessetes el desenvolupem amb C i la API de PalmOS i el compilem, tindrem una aplicació de només 3k.
La diferència és significativa: amb 3k fem el mateix que amb el que hem necessitat 327 k (32d k+ 2k) amb SmallBasic.
El programa compilat és molt senzill d'utilitzar, l'engeguem, escrivim l'import i obtenim la conversió En canvi per utilitzar el que està fet en l'SmallBasic, primer hem d'engegar l'SmallBasic, carregar el programa i executar-lo. Amb l'afegit que no podrem utilitzar elements propis de la interfície d'usuari de PalmOS ja que, en el cas de l'SmallBasic, la interacció amb els programes té l'aspecte de la tradicional consola de DOS.
Si un altre usuari ha d'utilitzar aquest programa i nosaltres l'hem creat amb SmallBasic, obliguem l'usuari a disposar de l'intèrpret (Smallbasic.prc), tenir espai suficient en el seu Palm, disposar del script (un fitxer *.pdb amb el programa) i saber carregar-lo i engegar-lo.
Si a l'usuari li facilitem només un fitxer PRC (el que hem creat a C i compilat) només ha d'instal·lar i executar per tenir el programa funcionant i utilitzant elements de la interfície d'usuari de PalmOS (per exemple, botons o menús).
Amb això no vull dir que SmallBasic no sigui pràctic ni viable, simplement vull mostrar que hi ha uns requisits que cal tenir en compte a l'hora de desenvolupar aplicacions per PalmOS, requisits que són diferents de crear una aplicació per ordinadors de sobretaula i que sovint ens ajuden a determinar quin ha de ser el concepte de desenvolupament.
En el cas concret de SmallBAsic, és un bona eina per crear les nostres pròpies aplicacions d'ús personal en el Palm, per interactuar amb dades (agenda, notes, ...) i per automatitzar/programar tasques i càlculs de manera més ràpida i flexible que en un cicle de desenvolupament basat en compilació.
El proper dimarts parlarem del model de programació basat en la interfície d'usuari i els events, amb que ja tindrem uns coneixements mínims per posar-nos a programar quelcom concret amb el cicle habitual de desenvolupament: codi font+recursos+compilació=fitxer PRC.
També us avanço que en els propers articles començarà a mostrar de manera complementària, exemples de programes fets en llenguatges script com SmallBasic i Rexx per tal de començar a adquirir paral·lelament experiència en els camps d'aplicació de la programació script.
Següent: Introducció al desenvolupament d'aplicacions per a Palm OS (4a part).
Anterior: Introducció al desenvolupament d'aplicacions per a Palm OS (2a part)
I que en dieu del superwaba(.org) ?? permet la possibilitat de compilar-lo sense necessitat de l'int�rpret i sobretot, �s programaci� en java (quasi), el que fa que la rapidesa en la creaci� d'aplicacions sigui rapid�ssima (a difer�ncia del C).
ResponEliminaJa sabem que el C �s m�s eficient, per aix� no farem jocs amb java, per� per aplicacions a "devices" port�tils (o no tant port�tils) certament pesa m�s el poder fer 3 aplicacions enlloc de 1.
Jo m'he fet un editor per la meva clie tj-25 (109?+iva a pricoinsa.es) i la velocitat �s equiparable a qualsevol programa.
Podries compartir aquest editor a PalmCAT? Probablement interessar� a altres usuaris.
ResponEliminaL'editor quan estigui llest el posar� GPL, per� vaig molt lent per problemes de treball (jo l'utilitzo per� no est� presentable).
ResponElimina