CMS-driven development of adaptive mobile web applications

CMS-driven development of adaptive mobile web applications using progressive enhancement techniquesCMS-driven development of
progressive enhancement techniques
Begeleider: Ir. D. Blomme
Masterproef ingediend tot het behalen van de academische graad van
Master in de ingenieurswetenschappen: computerwetenschappen
Academiejaar 2009–2010
CMS-driven development of
progressive enhancement techniques
Begeleider: Ir. D. Blomme
Masterproef ingediend tot het behalen van de academische graad van
Master in de ingenieurswetenschappen: computerwetenschappen
Academiejaar 2009–2010
“The author gives permission to make this master dissertation available for consultation and to
copy parts of this master dissertation for personal use.
In the case of any other use, the limitations of the copyright have to be respected, in particular
with regard to the obligation to state expressly the source when quoting results from this master
dissertation.”
Acknowledgements
First and foremost, I would like to thank my promotor Prof. dr. ir. Frank Gielen for the
challenging opportunities I have been given over the past year. His expertise has been of great
value to the direction of this thesis.
I also want to express my gratitude to my advisor ir. Dieter Blomme for the helpful input and
some excellent tips to improve this document.
Heko Desruelle, May 2010
CMS-driven development of adaptive
enhancement techniques
Master’s thesis submitted to obtain the academic degree of
master of computer science engineering
Academic year 2009–2010
Advisor: Ir. D. Blomme
Overview
The growing diversity of devices connected to the web has increased the need for mobile applications being accessible at any time and on any device. This article proposes an architecture and the required algorithms to support the development of adaptive web-based applications. The suggested system addresses this challenge by extending CMS-driven web application frameworks with component-based development capabilities. The necessary degree of adaptivity is provided by an algorithm derived from the Logic Scoring of Preference (LSP) method. Specific mobile modifications are proposed to optimize LSP for mobile usage.
Keywords:
CMS-driven development of adaptive mobile web applications using progressive enhancement
techniques Heko Desruelle
Supervisor(s): Frank Gielen, Dieter Blomme
Abstract— The growing diversity of devices connected to the web has increased the need for mobile applications being accessible at any time and on any device. This article proposes an architecture and the required algorithms to support the development of adaptive web-based applications. The suggested system addresses this challenge by extending CMS-driven web application frameworks with component-based development capabilities. The necessary degree of adaptivity is provided by an algorithm derived from the Logic Scoring of Preference (LSP) method. Specific mobile modifications are proposed to optimize LSP for mobile usage.
Keywords—mobile web applications, adaptivity, component-based development, LSP
I. INTRODUCTION
Mobile has become a powerful mass medium, with a greater reach and faster growth than any other known media type [1]. However, not only penetration rates are starting to outnumber PCs, mobile technology itself is also catching up fast. Today, even devices from the low-end segment start to have internet access capabilities and support for browsing, e-mails, etc. The growing diversity of devices with internet connectivity has resulted in a boosted need for applications being available at any time, anywhere and on any device.
Current technologies for the creation and delivery of mobile applications are however insufficiently prepared for this level of change. Without the appropriate platform or tool support, the adaptivity requirements remains the developer’s responsibility to handle, which inevitably drives up costs and narrows the target market. This unbalance situation has led to the general believe that the development of platform-dependent mobile applications does not represent the future for the mobile industry.
The evolution towards the web as an application platform is gaining momentum. Standardized Web technologies try to overcome most of the restrictions plaguing native applications development and introduces browser technology as a universal client through which all interaction with the device is handled.
This article will demonstrate the feasibility of the web as an application platform. An architecture and the necessary algorithms will be proposed in support of adaptive Web-based application development.
II. ARCHITECTURE
The architecture aims at extending web application frameworks with a portable library for component-based development. Com- ponents can be requested, whilst it is the library’s responsibility to provide the necessary degree of adaptivity and autonomously
select the optimal rendering. The decomposition shown in Fig- ure 1 is at the heart of the proposed system. Given the client- device’s capabilities, an optimal candidate is selected by pushing all available components through a filtering pipeline. This process is elaborated in section III.
Fig. 1. Component Locator
III. ALGORITHM
The suggested component selection algorithm will evaluate the suitability of the available components and autonomously select the most appropriate candidate. It encompasses the following four consecutive steps.
A. Resource fetching
A preliminary step collects all available components and their metadata. The metadata specifies the component type, priority settings and the device capabilities it requires for an optimal rendering. This will be the selection process’s initial set of candidates.
B. Type filtering
A coarse filtering is performed on the fetched candidates. Their defined types are matched to the requested component type. Only the matching candidates are passed to the following filter. This action aims at minimizing the next filter’s execution time, as it is computationally the most complex part of the algorithm.
C. Suitability filtering
The remaining candidates are evaluated and scored by matching their capability requirements to the requesting device. A naive tactic would be to apply simple Boolean logic, in which a component can only be accepted or rejected. This is an almost infeasible approach, as it would require the availability of perfectly matching components for each possible device configuration. Instead, the use of fuzzy logic is proposed to express a degree of similarity in terms of “maybe- ness”. This enables the system to ob- jectively evaluate all candidates and even take less-than-perfect matches into account if no better solution is available.
The suitability filtering relies on the Logic Scoring of Prefer- ence (LSP) method [2] with specific adaptations to fit the mobile context. LSP is a general quantitative decision method, initially designed for the evaluation, comparison and selection of complex hardware and software systems. Using predefined fuzzy distance functions, each of the candidate’s required device capabilities are matched to the actual device characteristics. These functions express a percentage degree of similarity in which the device’s capabilities match that certain requirement.
For each candidate, the individual degrees of similarity for the required device capabilities are combined into one objective overall score. This aggregated score is used to determine the best-matching candidate. The basic aggregator mechanisms in LSP are based on the superposition of fundamental Gener- alized Conjunction/Disjunctions (GCD) [3], enabling the specification of aggregations in terms of 17 graded combinations of conjunction and disjunction. The equation below shows the GCD’s Weighted Power Mean (WPM) implementation [4], with variables Wi representing the relative weight for each individual score xi. The exponent r expresses the degrees of conjunction and disjunction.
Mr W (x1, · · · , xn) = (W1x
r 1 +W2x
r 2 + · · ·+Wnx
D. Conflict resolution
Conflict resolution is the algorithm’s final step. The possibility exists that multiple candidates are evaluated with the same degree of overall similarity regarding the devices characteristics. These conflicts are handled by upholding a priority-based selection policy. The component’s priorities are predefined in their metadata and ensure that the final candidate selection will only contain one component.
IV. DATA STRUCTURE
Each component consists of a metadata descriptor and a container for its markup, styling and scripting resources. For portability considerations, XML is used to specify the component’s
descriptor. The metadata contains an overview of the name, type and device capability requirements. No specific naming conven- tions are imposed for the resources in the container, as the required associations are specified in the metadata descriptor.
V. PROOF OF CONCEPT
To demonstrate the feasibility of this system, a proof of concept implementation was made for Joomla! [5]. This version mainly focusses on the previously identified technical and algorithmic challenges. In a second implementation phase, portability was explicitly verified by porting the system to Drupal [6] , a technologically similar framework.
VI. RESULTS
A proof of concept for the Joomla! 1.5 framework was success- fully implemented, providing the required means to cope with mobile platform fragmentation. It supports the creation of adaptive Web-based applications and offers developers the necessary flexibility to create and instantly deploy new components.
Various types of components were implemented, targeting a wide range of devices. Support was confirmed for low-end devices, feature-phones and smartphones such as Android and iPhone devices.
In terms of portability, the use of encapsulation and restricted communication paths in the architectural design have clearly sep- arated the framework-dependent parts from the rest of the system. Providing a port to Drupal 6 only required the adaptation of the resource storage, caching service and device capability detection. The process of transferring actual components does not require any modifications, as they are completely independent from the underlying framework.
VII. CONCLUSION
The proposed architecture provides a means for developers to cope with mobile platform fragmentation. We have developed an approach for the creation and delivery of adaptive mobile web-based applications. This system extends web application frameworks with component-based development capabilities and applies a mobile adaptation of the LSP method for performing multi-valued candidate evaluations.
REFERENCES
[1] T. Ahonen: Mobile As 7th of the Mass Media: Cellphone, Cameraphone, Iphone, Smartphone. Futuretext, 2008.
[2] J.J. Dujmovic, A method for evaluation and selection of complex hardware and software systems, In: Proceedings of the International Conference for the Resource Management and Performance Evaluation of Enterprise Com- puting Systems (CMG96), San Diego, CA, USA, Vol. 1, pages 368-378, Dec 1996.
[3] J.J. Dujmovic, Preferential Neural Networks. Chapter 7 in “Neural Net- works - Concepts, Applications and Implementations.” Vol. II. Prentice - Hall Advanced Reference Series, Prentice Hall, pages 155-206, 1991.
[4] I. Batyrshin, O. Kaynak, I. Rudas, Generalized conjunction and disjunction operations for fuzzy control. In: Proceedings of EUFIT98, Vol. 1, pages 7-10, Sep 1998.
[5] Anonymous, Joomla!. http://www.joomla.org [Online]. [6] Anonymous, Drupal. http://www.drupal.org [Online].
ACKNOWLEDGEMENTS vi
Nederlandse samenvatting
Inleiding
Context
Mobiele diensten zijn het massamedium van de toekomst. Hun groei is sterker en verstrekkender
dan enig eerder gekende type. Volgens recente bepalingen van de Verenigde Naties bezit meer
dan de helft van de wereldbevolking over een mobiel toestel. Dit is meer dan het dubbele van
het huidig gebruik van computers en televisies.
De huidige mobiele technologie heeft een hele evolutie achter de rug. De eerste mobiele toestellen
ondersteunden slechts de mogelijkheid om gesprekken te voeren en berichten te verzenden via
SMS diensten. Vandaag beschikken zelfs de toestellen uit de goedkoopste segmenten over de
functionaliteit om op het web te surfen, e-mails te verzenden, sociale netwerken te raadplegen,
enz. Het is eveneens mogelijk geworden om de functionaliteit van een toestel uit te breiden door
applicaties afkomstig van derden te installeren.
Mobiele gebruikers dragen hun toestel meestal continu bij zich. Dit maakt het een nuttig in-
strument in vaak uiteenlopende situaties, maar de divergente gebruikscontexten creeeren echter
de nood aan specifieke toepassingen. De mogelijkheid om extra applicaties te installeren is een
belangrijke stap geweest in de vervulling hiervan, omdat het gebruikers de mogelijkheid geeft
om hun toestel naar wens aan te passen.
Toch blijkt het ontwikkelen en distribueren van applicaties niet zo vanzelfsprekend. De frag-
mentatie van mobiele platformen en restricties vanuit de mobiele industrie hebben ertoe geleid
dat de kosten voor het ontwikkelen van mobiele software onhoudbaar zijn geworden. De vereiste
inspanning nemen toe in bijna elk aspect van de software levenscyclus, terwijl de doelmarken
alsmaar kleiner worden. Het is deze evolutie die aan de basis ligt van de groeiende ontevreden-
heid bij ontwikkelaars, die ervan overtuigd raken dat de toekomst van de mobiele industrie niet
bij native oplossingen ligt.
Als we mogelijke alternatieven aanschouwen, groeit de aanhang voor een web-gebaseerde oplossin-
gen. Het is de bedoeling om met deze aanpak de meeste restricties waarmee ontwikkelaars
geplaagd worden bij het maken van native applicaties te omzeilen. Dit door de browser als
universele client te aanzien waarlangs alle interactie met het toestel afgehandeld wordt. De-
salniettemin de maturiteit van het web, bestaan er nog een aantal technische beperkingen ten
opzichten van het ontwikkelen van krachtige web-gebaseerde applicaties. Toch zijn specificaties
voor nieuwe standaarden in aantocht en kan men in afwachting van deze nieuwe mogelijkheden
gebruik maken van krachtige hybride oplossingen.
Browsers worden alsmaar krachtiger en krijgen vaker toegang specifieke toestel interfaces zoals
geolocatie en informatie over de orientatie van het scherm. Toch is dit slechts een schimp van
de mogelijkheden die ons de komende jaren te wachten staan. Standaardisatie inspanningen
van het W3C en BONDI initiative hebben geleid tot specificaties met tientallen verschillende
interfaces naar functies op het toestel. Zo wordt er zelfs verwacht dat web applicaties tegen 2013
via de browser een groot deel van de native applicatie functionaliteit zal kunnen evenaren.
Doelstelling
In deze thesis zullen de vraag, alsook de voordelen en uitdagingen, in beschouwing worden
genomen om een evolutie naar web applicaties mogelijk te maken. In een tweede fase zal de
haalbaarheid van een web-gebaseerd platform voor zowel eindgebruikers als ontwikkelaars aange-
toond worden. Er zal tenslotte een systeem gespecificeerd worden dat in staat is om optimaal om
te gaan met mobiele platform fragmentatie door de ontwikkeling van adaptieve web applicaties
mogelijk te maken.
De Nederlandse samenvatting van deze thesis omvat de volgende onderdelen:
• Specificatie
In dit hoofdstuk zal het systeem dat we willen bouwen gespecificeerd worden. Hierbij zal
een vision document gedefinieerd worden en overlopen we de functionele- en kwaliteitsvereis-
ten waaraan het systeem zal moeten voldoen.
• Architectuur
Een volgende stap is het voorstellen van een architectuur die in overeenstemming is met
de gestelde vereisten uit de specificatiefase. Het ontwerp van de architectuur zal gebeuren
aan de hand van de Attribute-Driven Design (ADD) methode.
• Algoritmen en datastructuren
datastructuren in het voorgestelde systeem.
• Proof of concept
Om de haalbaarheid van het systeem aan te tonen zal in dit hoofdstuk de generieke archi-
tectuur en algoritmen toegepast worden op een bestaand CMS omgeving.
• Besluit
Deze thesis wordt afgesloten met een besluit. We zullen samenvatten wat we bereikt
hebben, wat de mogelijkheden tot verbetering zijn en op welke onderwerpen verder onder-
zoek gevoerd kan worden.
Specificatie
Een eerste belangrijke stap in de specificatie van het systeem dat gebouwd dient te worden is
het vastleggen van het vision document. Deze beschrijft duidelijk wat er gedaan zal worden, wat
de belangrijkste eigenschappen zijn en aan welke kwaliteitsvereisten er dient te worden voldaan.
Na deze definities zal de specificatie-fase besloten worden met de toelichting van de use cases.
Vision Document
Missie
Het is het doel van deze thesis om een CMS-gebaseerd web applicatie framework dat het MVC
principe toepast uit te breiden. Deze extensie zal het mogelijk maken om component-gebaseerde
ontwikkeling te ondersteunen dat optimalisaties bevat voor gebruik in een mobiele context.
Het voorgestelde systeem zal de verantwoordelijkheid hebben om componenten te beheren en
autonoom selecties te kunnen uitvoeren van optimale versies op basis van de capaciteiten van een
gegeven toestel. Met deze aanpak willen we de vereiste inspanningen op het vlak van applicatie
ontwikkeling minimaliseren, zonder het afleveren van toestel-geoptimaliseerde web applicaties te
verhinderen.
Belangrijkste eigenschappen
• Slechts een versie van een web applicatie dient aangemaakt te worden, aanpassingen naar
de eigenschappen van de verschillende toestellen gebeurt automatisch.
• Eenvoudige ontwikkeling en distributie van nieuwe applicatie componenten.
• De evaluatie worden automatisch geevalueerd op hun toepasbaarheid.
• Het gebruik van progressive enhancement technieken wordt ondersteund en zelfs aange-
moedigd in de componenten
• Geen aanpassingen aan de eigenlijke framework code nodig. Het systeem is volledig
gemplementeerd als een CMS extensie.
• Er is geen vereiste om op het mobiele toestel enige software te installeren.
Kwaliteitseigenschappen
• Aanpasbaarheid
Op basis van de problemen die gepaard gaan met mobiele platform fragmentatie, is aan-
pasbaarheid een belangrijke vereiste voor ons systeem. Het systeem dient voldoende flex-
ibiliteit te hebben om het aanmaken van nieuwe componenten door externe ontwikkelaars
te ondersteunen. CMS beheerders dienen eveneens deze extra componenten te kunnen in-
stalleren zonder geconfronteerd te worden met onnodige complexiteit of het onbereikbaar
zijn van hun CMS instantie.
• Gebruiksvriendelijkheid
Het systeem dient om te kunnen gaan met een diversiteit aan toestellen. Het is belangrijk
de optimale ervaring van de eindgebruiker te kunnen garanderen door deze te voorzien van
een web applicatie die schijnbaar geoptimaliseerd is voor zijn specifiek toestel.
• Overdraagbaarheid
Het systeem dient overdraagbaar te zijn naar andere CMSen met een gelijkaardige technol-
ogische basis. Het overzetten van het systeem mag slechts een minimum aan inspanning
vereisen. De eigenlijke componenten dienen volledig CMS onafhankelijk te zijn en dus
onmiddellijk over te zetten naar de nieuwe basis.
• Performantie
Performantie is sowieso een algemeen probleem in CMS-gebaseerde omgevingen. De ex-
tra verwerkingstijd die ons systeem vereist moet tot een minimum beperkt blijven en de
standaard CMS performantie maatregelen niet tegenwerken of onbruikbaar maken.
Use cases
Figure 5.1 geeft een overzicht van het use case diagram. Voor een volledige uitwerking van de
belangrijkste use cases verwijzen we naar Appendix A.
Architectuur
De architectuur van dit systeem zal bepaald worden aan de hand van de Attribute-Driven Design
(ADD) methode. Deze aanpak maakt gebruik van de kwaliteitsvereisten van het systeem om
een software architectuur vast te leggen. In overeenstemming met de methodologie van deze
methode begint het proces met het gehele systeem als een entiteit en wordt het vervolgens
recursief opgedeeld in kleinere componenten.
Eerste iteratie
De eerste iteratie gebeurt op basis van de portabiliteitsvereiste (Eenvoudige portabiliteit naar
andere CMSen met een gelijkaardige technologische basis). Om een flexibel systeem te bouwen
dat relatief eenvoudig over te zetten is naar andere CMSen is het belangrijk de daadwerkelijke
CMS afhankelijkheden van het systeem af te schermen van de rest van het systeem. Dit leidt
tot de decompositie zoals weergegeven in Figuur 6.3, met de volgende componenten:
• Dispatcher
De dispatcher behandelt inkomende aanvragen voor het aanmaken van componenten.
In eerste instantie zal de Locator aangewend worden voor het zoeken van de optimale
beschikbare component op basis van de capaciteiten van het mobiele toestel. Nadat een
geschikte component gevonden is, zal de Dispatcher deze aanmaken en de resulterende
output teruggeven.
• Locator
De Locator heeft als verantwoordelijkheid te zoeken naar de best geschikte implementatie
van een bepaald component-type. Als geen perfecte component gevonden wordt, zal de
Locator de best overeenstemmende kandidaat in beschouwing nemen en deze selecteren.
De Locator handelt eveneens conflicten af in geval van meerdere evenwaardig geevalueerde
kandidaten door regels op basis van prioriteiten toe te passen.
• Application Component
Dit onderdeel is de eigenlijke representatie van een applicatie component. Na geselecteerd
te zijn, zal zijn basis layer en de progressive enhancement layers die van toepassing zijn
gegenereerd en teruggegeven worden aan de web applicatie.
• Resource Manager
De Resource Manager handelt aanvragen af om nieuwe resources toe te voegen aan het
systeem. Deze resources kunnen nieuwe implementaties zijn van bepaalde componen-
ten, of aangepaste similariteitsmaten die gebruikt kunnen worden bij het zoeken naar een
geschikte component gegeven de eigenschappen van een mobiel toestel.
• Service Aggregator
De Service Aggregator is de hoofdcomponent in deze decompositie. Het biedt toegang tot
de verschillende services van het systeem, die vaak een aggregatie zijn van een aantal basis
services zoals device detectie, het opslaan van resources, etc. De Aggregator wordt zo klein
mogelijk gehouden en implementeert enkel atomaire services zoals het delegeren van com-
municatie. De andere basis services, die vaak CMS afhankelijk zijn, worden geabstraheerd
in de volgende vier “service” componenten.
• Device Detection Service
De Device Detection Service biedt het systeem de mogelijkheid om gedetailleerde gegevens
te achterhalen over de capaciteiten van het toestel waarmee de web applicatie geraadpleegd
wordt. Dit is een belangrijke service, omdat een groot deel van de functionaliteit van het
systeem gebaseerd is op deze informatie.
• Scoring Service
Deze service biedt de basis voor het bepalen van similariteitsmaten tussen kandidaat com-
ponenten en de eigenschappen van specifieke toestellen. We verwijzen naar Hoofdstuk 7
voor een uitgebreide bespreking van het achterliggende algoritme.
• Component Resource Service
Deze service behandelt aanvragen voor de opslag en het oplijsten van de beschikbare
componenten in het systeem.
• Caching Service
Door de complexe berekeningen voor het bepalen van de optimale componenten, kan het
systeem de performantie van het CMS in gedrang brengen. Daarom zorgt deze service
ervoor dat resultaten voor populaire toestellen in een cache opgeslaan worden, zodat het
volledige selectie proces niet uitgevoerd hoeft te worden.
Tweede iteratie
De tweede ADD iteratie gebeurt op basis van aanpasbaarheid (Het flexibel toevoegen van nieuwe
systeem resources). Deze iteratie zal zich toeleggen op de Locator, omdat het een belangrijk
onderdeel is van ons systeem. De Locator is opgedeeld in een aantal sequentiele stappen, waarvan
de exacte decompositie weergegeven is in Figuur ??. De samenwerking tussen deze onderdelen
wordt besproken in het hoofdstuk rond Algoritmen en datastructuren.
Algoritmen en datastructuren
De belangrijkste algoritmen en datastructuren in ons systeem zullen hier besproken worden.
Component selectie algoritme
Het eerste algoritme beschrijft de automatische selectie van de meest geschikte component,
gegeven het gewenste component-type en de eigenschappen van het mobiele toestel. Het algo-
ritme bestaat uit vier opeenvolgende stappen:
• Resource fetching
De eerste stap zal alle beschikbare componenten in het systeem verzamelen in combinatie
met hun meta-data. Deze data beschrijft het component-type, zijn prioriteitsinstellingen
en verzameling van optionele en vereiste toestel karakteristieken waarvoor de component
ontworpen was.
• Type filtering
In de volgende stap wordt een eerst grove filtering toegepast op deze set van kandidaten.
Het gevraagde component-type wordt vergeleken met het daadwerkelijke type van elk van
de kandidaten. Enkel de overeenstemmende componenten worden behouden.
• Suitability filtering
De overblijvende kandidaten gaan vervolgens doorheen het selectieproces, waarbij elk een
score toegekend krijgt die de mate van overeenstemming uitdrukt met de capaciteiten
van het mobiele toestel. In plaats van eenvoudige Booleaanse logic die enkel toelaat om
componenten volledig te aanvaarden of af te wijzen, wordt er gebruik gemaakt van vage
logic die toelaat om niet perfecte kandidaten toch nog in beschouwing te houden tot een
betere kandidaat gevonden is. Deze stap wordt verder toegelicht in de sectie over Logic
Scoring of Preferences (LSP).
• Conflict resolution
Conflict resolutie is de laatste stap in het algoritme. Deze is nodig door de flexibiliteit die
het systeem aanbiedt om nieuwe extern ontwikkelde componenten te installeren. Hierdoor
kan het voorkomen dat kandidaat componenten een gelijke similariteitsmaat toegewezen
krijgen. Door het toepassen van prioriteitsregels zal het systeem deze conflicten oplossen.
Het is vanzelfsprekend dat de CMS administrator in zijn backend de instellingen voor
prioriteiten eveneens manueel naar wens kan aanpassen.
Logic Scoring of Preferences
De LSP methode is een algemene kwantitatieve beslissingsmethode voor het evalueren, vergeli-
jken en selecteren van complexe hardware en software systemen. LSP heeft als doel complexe
constructies te vergelijken en mogelijke configuraties objectief een score toe te kennen. Deze
methode vereist de volgende vier stappen . Het is belangrijk op te merken dat enkel stap 2 door
de kandidaat component dient gemplementeerd te worden. Stap 1, 3 en 4 maken onderdeel uit
van het systeem zelf.
1. Het bepalen van alle systeem attributen die gebruikt kunnen worden voor het bepalen van
similariteitsmaten tussen de kandidaten.
2. Elke kandidaat dient voor de attributen die in zijn geval van toepassing zijn te bepalen
wat de gewenste waarde hiervan is. Deze waarden worden aangeduid als de elementaire
criteria.
3. Het bepalen van vage logic functies voor elk van de gedentificeerde attributen. Dit heeft
als doel elementaire similariteitsmaten te bepalen voor het vergelijken van elementaire
criteria met de toestel-specifieke waarde voor dat attribuut.
4. Het ontwikkelen van logische aggregators die elementaire similariteitsmaten combineren
tot een objectieve algemene score voor elke kandidaat.
De logische aggregatie van scores is gebaseerd op de superpositie van fundamentele General-
ized Conjunction/Disjunction (GCD). Deze functies laten toe aggregaties uit te drukken met
een enkele operator in termen van partiele conjunctie, volledige conjunctie, partiele disjunctie,
volledige disjunctie en neutraliteit.
Een vaak gebruikte implementatie voor GCD zijn Weighted Power Means (WPM), omdat het
alle 17 vooropgestelde aggregaties van GCD ondersteunt. De WPM om n individuele simi-
lariteitsmaten te aggregeren is berekend volgens de vergelijking hieronder. De variabelen Wi
vertegenwoordigen de onderlinge gewichten voor elke individuele score xi.
WPM(x1, x2, . . . , xn; W1,W2, . . . ,Wn; r) = (W1x r 1 + W2x
r 2 + · · ·+ Wnx
r n)1/r (1)
De exponent r wordt berekend volgens de gewenste maat van conjunctie en disjunctie in de
aggregatie. Tabellen 7.3 en 7.4 geven de meest gebruikte maten hiervoor terug.
Component datastructuur
Om de portabiliteitsvereiste van het systeem te ondersteunen, is er gekozen voor om de descriptor
van een component in XML op te stellen. We verwijzen naar Appendix B voor een volledig
overzicht van het voorgestelde XML Schema Definition (XSD).
Proof of Concept
Om de haalbaarheid van de voorgestelde architectuur en algoritmen aan te tonen is een proof
of concept gemplementeerd. Omdat niet alle features even belangrijk zijn hiervoor zal eerst
een beperkte scope opgesteld worden, waarin er voornamelijk op de essentie toegespitst zal
worden. Op basis van deze implementatie zullen de bekomen resultaten vergeleken worden met
de vooropgestelde architecturale drivers uit de specificatie fase.
Scope
De proof of concept zal zich richten op de technische- en algoritmische uitdagingen die in de
vorige hoofdstukken gedentificeerd werden. Een eerste implementatie zal voorzien worden als
een extensie voor het Joomla! 1.5 CMS. Vervolgens, zal de portabiliteitsvereiste van het systeem
aangetoond worden door het systeem over te zetten naar het Drupal 6 CMS. In de laatste fase,
zal het systeem gebruikt worden als een platform voor het aanbieden van hybride web applicaties.
Dit zal bekomen worden door bijkomende componenten te implementeren met de mogelijkheid
om een hybride client JavaScript API aan te spreken.
Resultaten
De resultaten van de proof of concept implementatie worden onder meer gedemonstreerd met
behulp van een aantal screenshots in Appendix C. In deze sectie worden de resultaten uit de
verschillende fase van onze scope vergeleken met de belangrijkste architecturale drivers.
Volledig web-gebaseerde applicaties
De eerste fase van de proof of concept is het implementeren van een Joomla! 1.5 extensie die
voldoet aan de specificatie van het voorgestelde systeem. Het systeem werd succesvol gemple-
menteerd en gebruikt als basis voor het aanmaken van adaptieve web applicaties. De proof of
concept werd getoetst aan de verschillende kwaliteitseigenschappen, vooropgesteld in de speci-
ficatiefase van het systeem.
Aanpasbaarheid werd aangetoond door componenten te implementeren voor een verscheidenheid
aan toestellen. Er werden versies gemplementeerd voor lowest common denominator feature
phones, high-end feature phones met basis CSS en JavaScript ondersteuning en versies voor
smartphones met uitstekende CSS en JavaScript ondersteuning en zelfs basis AJAX onderste-
uning.
Bruikbaarheid was een andere belangrijke vereiste voor dit systeem. De focus ligt hiervoor bij
de gebruikservaring van de mobiele eindgebruikers. Deze is voornamelijk afhankelijk van de
prestatie van het component selectie algoritme van ons systeem. Voor een grafische evaluatie
van deze kwaliteitseigenschap verwijzen we naar Appendix C.
Tenslotte werd de performantie van het systeem nagegaan. Dit is een belangrijk aspect omdat
het gebruik van caching mechanismen binnen een CMS omgeving doorgaans van doorslaggevend
belang zijn bij de acceptatie van een voorgesteld systeem. Caching is expliciet ondersteund in de
architectuur van het voorgestelde systeem en kan gebruikt worden om optimale resultaten voor
populaire toestellen efficient op te slaan. Zoals aangetoond in Tabel 8.1, wordt bij het activeren
van caching de performantie van ons systeem amper te onderscheiden van de performantie van
een traditioneel CMS-gebaseerd systeem.
Overdraagbaarheid naar een technologisch gelijkaardig CMS
De tweede fase is het overzetten van het systeem naar een extensie voor het Drupal 6 CMS. Door
de technologische gelijkaardigheid tussen beide CMSen, vereist dit proces enkel het aanpassen
van de CMS-specifieke onderdelen. Portabiliteit van het systeem werd in rekening gebracht vanaf
het eerste stadium van de ontwikkeling van een architectuur. Het gebruik van inkapseling en
beperkte onderlinge communicatie in de Service Aggregator heeft voor een duidelijke scheiding
gezorgd tussen CMS-afhankelijke onderdelen en de rest van de architectuur. Het overdragen van
de Joomla! implementatie naar Drupal vereiste enkel het vervangen van de vier basis systeem
services, zoals weergegeven in Figuur 6.3.
Om ten slotte de CMS onafhankelijkheid van de eigenlijke componenten na te gaan, is ervoor
gekozen geen specifieke componenten te ontwikkelen voor de Drupal implementatie. Alle beschik-
bare componenten, die reeds aangemaakt waren voor Joomla!, werden gekopieerd zonder enige
aanpassing.
Hybride web-gebaseerde applicaties
In een laatste fase is gepoogd het systeem aan te bieden als een platform voor hybride web
applicaties. Zoals besproken in sectie 4.4.2, worden deze applicaties ontwikkeld door gebruik te
maken van web technologie zoals HTML, CSS en JavaScript. Toch wordt de standaard browser
van het toestel niet gebruikt om dergelijke applicaties te benaderen. Er wordt hiervoor gesteund
op specifiek ontwikkelde native applicaties, of webgebaseerde widget engines. Deze voorzien een
rijke JavaScript API, die toegang bieden tot toestel-specifieke functies.
Deze fase van de proof of concept dient voornamelijk als een demonstratie van de kracht van
opkomende standaarden van het W3C en OMTP BONDI om dergelijke API’s aan te bieden
in standaard browsers. In eerste instantie werd een hybride client applicatie gebouwd voor
het Android platform, gebaseerd op de API’s van het PhoneGap project. Aan de kant van de
server waren geen aanpassingen vereist, enkel het implementeren van bijkomstige componenten
met specifieke scripting mogelijkheden om de hybride JavaScript API’s aan te spreken. We
verwijzen nogmaals naar naar Appendix C voor een overzicht van de resultaten.
Besluit
Deze thesis heeft een systeem voorgesteld voor de creatie en aflevering van adaptieve mobiele
web applicaties op een verscheidenheid aan mobiele toestellen. Ontwikkelaars krijgen hiermee
een efficient hulpmiddel bij het omgaan met mobiele platform fragmentatie. Het voorgestelde
systeem pakt deze uitdaging aan door CMS web applicatie frameworks uit te breiden met com-
ponent gebaseerde ontwikkelingsmogelijkheden. De gevolgde aanpak biedt een oplossing voor
de strikte tradeoff in multi-platform ontwikkeling tussen de vereiste ontwikkelingskosten en de
capaciteiten van de resulterende applicaties.
Er werd een architectuur voorgesteld, samen met de nodige algoritmes voor de toestel specifieke
selectie van componenten. De vereiste graad aan adaptiviteit wordt voorzien door een methode
afgeleid van de Logic Scoring of Preference (LSP) techniek. Specifieke aanpassingen werden
doorgevoerd om LSP te optimaliseren voor mobiel gebruik. Dit laat toe het systeem objectief
componenten te laten evalueren op basis van hun toepasbaarheid, gegeven de context van het
mobiele toestel. Voor het uitvoeren van de evaluaties wordt er gebruik gemaakt van vage logica,
die toelaat om toch niet perfecte kandidaten in beschouwing te nemen indien er geen betere
componenten voor handen zijn.
Om de haalbaarheid van het systeem aan te tonen werd een proof of concept implementatie ge-
realiseerd voor het Joomla! 1.5 CMS. Hierbij werden de vooropgestelde kwaliteitseigenschappen
voor en aanpasbaarheid, bruikbaarheid en performantie gevalideerd. De portabiliteitsvereiste
werd expliciet nagegaan door het systeem over te zetten naar een technologisch gelijkaardig
CMS, namelijk Drupal 6. In een laatste fase werd de toepasbaarheid van het systeem als een
hybride web applicatie platform eveneens bevestigd.
CONTENTS xix
1.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Application portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1 Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1 Mobile-specific web standards . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Emerging web standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.3 Standardized best practices . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Web-based mobile applications 24
4.1 The web as a mobile platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Introducing adaptivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1 Modeling aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.3 Towards adaptive web applications . . . . . . . . . . . . . . . . . . . . . . 29
CONTENTS xx
4.4.1 User interface frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.2 Hybrid development solutions . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4.3 Enterprise development solutions . . . . . . . . . . . . . . . . . . . . . . . 43
5 Specification 45
5.2 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3.1 Modifiability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3.2 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3.3 Portability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6 Architecture 53
6.3.1 Locator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7 Algorithms and data structures 65
7.1 Component selection algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.1.1 Resource fetching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.1.2 Type filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.1.3 Suitability filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.1.4 Conflict resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2.1 Component descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.2.2 Resource container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
8.3.2 Porting the system to a technologically similar CMS . . . . . . . . . . . . 77
CONTENTS xxi
9 Conclusion 79
9.1 Accomplishments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
C Screenshots 92
MVC Model View Controller
URI Uniform Resource Identifier
URL Uniform Resource Locator
WAP Wireless Application Protocol
WPM Weighted Power Mean
XML Extensible Markup Language
XSD XML Schema Definition
vending machine.
1.1 Context
Mobile has become a powerful mass medium, with a greater reach and faster growth than any
other known media type [19]. According to the United Nations’ latest figures, more than half
of the world’s population owns a mobile phone [26]. This almost doubles the usage of personal
computers and TV sets. However, not only penetration rates are starting to outnumber PCs,
mobile technology itself is also catching up fast.
Today, even devices from the low-end segment start to have internet access capabilities and
support for browsing the web, sending e-mails, social networking, etc. The growing diversity of
mobile devices with internet connectivity has resulted in a boosted need for applications being
available at any time, anywhere and on any device.
Current technologies for the creation and delivery of mobile applications are insufficiently pre-
pared for this level of change. Without the appropriate platform or tool support, the adaptivity
requirement remains the developer’s responsibility to handle, which inevitably drives up costs
and narrows the target market. This unbalance situation has led to the general believe that the
development of platform-dependent mobile applications does not represent the future for the
mobile industry.
On the other hand, the evolution towards the mobile web as an application platform is gaining
momentum. This approach addresses the mature nature of the web in an attempt to overcome
1
most of the restrictions plaguing native application development. Browser technology is intro-
duced as a universal application client through which all interaction with the device is handled.
With the industry’s current efforts in the development of new web standards, the viability of a
web-based application platform increases by the day.
1.2 Goal of research
This thesis will investigate the needs, benefits and remaining challenges in the evolution towards
a state of market readiness for mobile web applications. The feasibility of the web as an applica-
tion platform will be demonstrated by proposing an architecture and the necessary algorithms
in support of adaptive web-based development.
1.3 Outline
Chapter 2-4: State of the art analysis
As part of the state of the art analysis, these chapters cover the research on market readiness for
web-based mobile applications. The evolution of the mobile internet and the mobile application
market is evaluated. Existing and emerging standards on these subjects are examined. We
conclude with an overview of today’s web mobilization techniques and their applicability to web
applications.
Chapter 5: Specification
The specification chapter defines the system we want to build. The Vision Document is its
starting ground. This document describes the overall plan and the stakeholders’ view of the key
needs and features. Next, the system’s behavioral and quality requirements are captured using
use cases and quality attribute scenarios.
Chapter 6: Architecture
This chapter proposes an architecture that complies with the requirements from the specification
phase. Therefor, he Attribute-Driven Design (ADD) method is applied. This recursive process
decomposes a system by applying a number of architectural patterns and tactics that satisfy its
1.3 Outline 3
Chapter 7: Algorithms and data structures
This chapter elaborates on the main algorithms and data structures that are used in our system.
Chapter 8: Proof of concept
In order to demonstrate the feasibility of our proposed work, this chapter maps the generic
architecture and algorithms to an existing CMS framework. The obtained results are then be
compared with the architectural drivers we have set up in the specification part of this thesis.
Chapter 9: Conclusions
We conclude this thesis with a review of what has been accomplished, what the possible im-
provements are and elucidate the further work to be done.
NATIVE MOBILE APPLICATIONS 4
Native mobile applications
Mobile applications are a rapidly growing segment of the global mobile industry [55]. By in-
stalling additional applications, the functionality of mobile devices can be extended. Users are
given the freedom to adapt a device an make it fit their their specific needs. We will start our
state-of-the-art research by gathering the strengths, weaknesses and emerging trends related to
native mobile application development.
2.1 Trends
Market insight is an important aspect for software developers and their investors. It involves
the evaluation of market readiness regarding the targeted application domain and technologies.
This section aims at supporting stakeholders to optimally assess their options and take resolute
actions. Ongoing and emerging trend for the mobile application industry will be examined.
Dataquest Insight: The Top 10 Consumer Mobile Applications in 2012
Advisory firm Gartner has published a list of the top ten mobile applications by 2012 [22].
This near-future prediction includes mobile technologies that are currently entering a phase
of mainstream adoption, but haven’t reached the state of widespread deployment yet. Some
of the best known examples in this category are definitely location-based services (LBS) and
mobile payments. With this list, Gartner aims at predicting the omnipresent adoption of mobile
application technologies.
2.1 Trends 5
Money transfer This category refers to sending money via SMS messages. This kind of
service has currently an exponential growth in the developing world, where accessing banks is
more difficult. However, Gartner expects this to also become a trend in the Western world.
Location-based services LBSs extend to more than only social networks and include almost
any imaginable application on a mobile device with GPS capabilities. It is even expected to be
one of the most disruptive technologies in the future, with a growing user base from 96 million
in 2009 to 526 million in 2012.
Mobile search Mobile search is not a new category, but the way it is perceived by users might
go through some serious changes on mobile platforms. The recently released Google Goggles
application [44] demonstrates that mobile search is not necessary bound to text-based querying.
Mobile browsing Mobile browsing capabilities currently exist on roughly 60 % of the handsets
today. By 2013, this number is expected to climb up to 80 %, indication a mass growth of web-
enabled devices over the next few years. In this category, Gartner points out the increasing
market share of mobile web applications, placing a hold on the required effort to build separate
applications for all mobile platforms.
Mobile health monitoring This category is still at an early stage of maturity, as well as
implementation. It is expected to have a great impact in developing markets. The coming
years, the healthcare industry is expected to begin the commercial offering of mobile monitoring
products, services and solutions.
Mobile payments As with the mobile transfers, mobile payments are more common in the
developing world. This is however quickly changing with the emerging use of mobile commerce
(m-commerce). A number of challenges are still to be expected due to the highly fragmented
market and the lack of standard practices.
Near Field Communications (NFC) NFC has yet to become a standard feature on mobile
device. Gartner expects this to happen by the end of 2010.
Mobile advertising Mobile advertising is growing fast and will be one of the most important
ways to monetize mobile content. The total spending on mobile advertising in 2008 was $530
million and will grow to $7.5 billion in 2012. Also a better integration of mobile advertisements
2.1 Trends 6
with campaigns on TV, radio, print and outdoors is expected.
Mobile instant messaging While SMS still seems the invincible mobile service, Gartner
expects user to adopt mobile instant messaging within the next few years. Especially in the
developing world, where mobile devices are often the only internet connected device owned.
Mobile music Mobile music for a broad spectrum of devices is expected to become a com-
petitive market, with new innovative models that combine both device- and service bundles.
Hype Cycle for consumer mobile applications
The Gartner Hype Cycle [20] is a graphical tool that communicates the different stages of
technological commercialization and provides time estimates for the different product areas to
reach its stages of maturity, productivity and mainstream adoption. For mobile application
technology in particular, the Hype Cycle reflects the importance of new consumer services and
assesses the maturity of mobile applications and their value. This report aims at preventing
financial burdens by warning companies for immature or hyped applications. Gartner assessed
the maturity of 25 applications. Figure 2.1 shows their progress in relation to each other.
The report considers applications in terms of market penetration, the time it will take them to
enter mainstream adoption and the obstacles to widespread use. It focuses on services, rather
than the underlying technology, though technology is considered because of effect on the speed
of adoption.
According to Gartner, mobile messaging applications such as instant messaging and e-mail
will gain momentum and have a good revenue potential. These services build on the success
of desktop applications and can be integrated with other mobile offerings. Nevertheless, the
traditional SMS and ring tones services will continue to generate the majority of data service
revenues for mobile carriers.
On the other hand, full-track music downloads, mobile television and gaming remain niche offer-
ings in the short term. This will remain until the associated technologies, content and business
models become more mature. The same goes for mobile banking and payment applications,
which need to overcome usability problems and the inhibition of users.
2.2 Platforms 7
As shown in Figure 2.1, it is important to notice that more than half of the evaluated services
have only just passed their peak of inflated expectations. All these services and their supporting
technologies are estimated to need another five years before reaching main productivity.
Figure 2.1: Hype cycle for consumer mobile applications in 2008 [20]
2.2 Platforms
Developers can target numerous platforms when creating applications for mobile usage. How-
ever, as Table 2.2.1 shows, the often incompatible nature of these platforms has to be kept in
mind. Platform selection has to be a carefully considered decision in order to maximize the
application’s reach and revenue.
2.2 Platforms 8
2.2.1 Platform fragmentation
The fragmentation of platforms is an increasing issue for mobile application developers. Plat-
form fragmentation expresses the inability to develop a single application for multiple platforms
and achieve the intended behavior on all devices at once. Table 2.2.1 and Figure 2.2 depict
the market share of mobile platforms over the past three years [50]. For developers to reach a
sufficiently large user base, fragmentation will soon require applications to provide support for
multiple platforms.
2.2 Platforms 9
Blackberry Java (with RIM API) 19.9%
iPhone OS Objective-C 14.5%
PalmOS C, C++ <1%
Symbian C++ 47.0%
Table 2.1: Native mobile development
2.2.2 Fragmentation reduction tactics
Some techniques and development tactics have been stipulated for managing the proportions
of device fragmentation [41]. As we will elaborate in the following paragraphs, none of them
offer a silver-bullet solution. The tradeoff between the required development effort and the
application’s power still remains. In general, the requirement of sophisticated design techniques
for each of the discussed methods will add up to the application’s complexity. Separate testing
of all application-versions will still be needed.
Developers must first identify the set of platform- and context variability points that are rel-
evant to the application. For each of these variability points one of the following methods of
fragmentation reduction can be selected.
Manual development and organization
The most primitive way of managing fragmentation is by manually developing distinct versions
for each platform. These separate versions will be largely similar and result in duplication of
work. Thereby the required effort of software development will increase almost exponentially
with the number of supported platforms. The remaining two alternatives will focus on minimiz-
ing this extra effort.
Derivation from a single base of code
In this approach, platform-specific versions are derived from a single code base. This derivation
can be done in three ways. By selective packaging, using meta-programming, or including
domain-specific generators. While these three approaches still result in multiple versions of the
application, there is only one code base and therefore the effort required may decrease compared
to the manual organization method.
In case of selective packaging, platform variations are localized into interchangeable compo-
nents1. Build scripts are used to create one version for each platform, by picking out only the
components required for that particular platform. An issue associated with this method is the
localization of all variations in components. This will often result in the use of techniques that
heavily impact the run-time performance2.
When using meta-programming, techniques for code manipulation are addressed to specify
the derivation process of platform-specific versions. This can be accomplished by embedding
platform-specific variations in the source code using directives or tagging. In turn, a preproces-
sor will derive the different versions by processing these directives. Alternatively, the platform-
specific variations can also be injected. This requires the developer to write the specific instruc-
tions separately from the application code.
A last method in this category is the automatic generation. Multiple versions are automatically
created by a generator. This generator possesses the necessary intelligence to adapt code and
make it suitable for a specific platform. Instead of only following directives that are manually
embedded by the programmer, generators use their built-in knowledge, requiring less manual
coding. The main issue with this approach is that the generator might not be able to auto-
matically deduced all variations. In addition, the different versions may need to be maintained
separately once they are generated.
Single application development
Single application development will try to build a single application that works on multiple
platforms. This approach is only possible when platforms support a common programming
1by using classes, files, ... 2with dynamic binding as one of the best known example.
2.2 Platforms 11
language or runtime. The developer will attempt o sidestep all variations between platforms
and include only the features supported by all platforms. This approach is commonly referred
to as the Lowest Common Denominator (LCD) approach.
In some cases it is also feasible to build a single application version with the ability to adapt to
a given platform at run-time. The software will in this case discover platform-information and
adapt itself to it at run-time.
2.2.3 Java Micro Edition
Java Micro Edition (Java ME) is a family of specifications, defining several downsized versions
of the standard Java platform [25]. Java ME is optimized for resource-constrained consumer
electronic devices such as smart phones, PDAs, set-top boxes, etc. To cope with this wide range
of devices, Java ME has been given an extensible architecture. Extensions are based on the con-
cept of configurations and profiles. The configurations contain the virtual machine definitions
and specifies the basic run-time environment as a set of core classes. Profiles, on the other hand,
focus on adding new domain-specific APIs.
Figure 2.3: Java ME architecture
In the desktop world, the introduction of Java in 1995 led to a general misconception that it
would offer a solution to all cross-platform development issues. This illusion is often shared when
it comes to solving mobile platform fragmentation problems. However, Java ME fell short in
solving the fragmentation problem due to its extensible architecture and the diversity of virtual
machine implementations. The optional profile APIs are not guaranteed to be supported on all
platforms. Relying on such APIs will still require the management of platform variation points
2.3 Application portals 12
2.3 Application portals
Mobile application portals were introduced to pass native applications from developers to end-
users [1]. The availability of such stores has rapidly grown and its market has become a multi-
billion dollar business. To date, Apple has the most popular application store with nearly
150,000 applications and over 3 billion downloads. Its success came as a shock to the industry
and every major mobile company has since then tried to replicate it. This evolution is clearly
shown in Distimo’s research document on store characteristics [38]. Its overview is depicted in
Figures 2.4 and 2.5.
From a developer’s perspective, application stores are not an ideal means to reach a sustainable
business. The chances for an application to be successful are very lucrative and depend on a
number of factors that are hard to predict. Applications are first of all competing for the top slot
in the store’s catalogue. This ranking-based system mainly focus on newly added applications.
Later on, only the applications that are promoted using aggressive marketing strategies will
be able keep their top rankings. The less fortunate will move to pages, nearly unaccessed by
potential end-users.
Moreover, developers are required to adhere to the portal’s submission policies. These define
restrictive rules of conduct regarding the application’s content, interface and used development
techniques. Submission fees are commonly required which can be up to $200. For the publication
of paid applications, developers will have to cede a revenue share between 20 and 30 %.
THE MOBILE INTERNET 15
The mobile Internet
The mobile Internet is on the rise. This is an important evolution, because it is the key enabler
for the mainstream acceptance of web application development. In this chapter, we will con-
tinue our state-of-the-art research with a brief historical overview of the mobile web, in terms
of standardization efforts. Furthermore, we will elaborate on predictions for mobile internet
penetration and usage rates.
The Mobile Internet Report
Morgen Stanley’s prediction on the mobile internet consists of two parts. The main report [23]
explores a number of themes related to the mobile web, whilst the key themes report [24] drills
down on its covered thoughts. According to the report, two overwhelming trends will affect
commercial potential of the web, namely mobile and social networking.
The mobile internet is currently the center of a new major technological cycle that continues the
evolution of the mainframe era of the 1950s and 60s, the mini-computer era of the 1970s and
the desktop internet era of the 80s. In this context, Morgan Stanley predicts that within the
next five years more users will connect to the internet using mobile devices than desktop PCs,
as depicted in Figure 3.1.
The mobile Internet market will be at least two times the size of desktop Internet. This growth
3.1 Trends 16
is mainly being driven by 3G adoption and the increasing popularity of smartphones [56]. The
3G penetration ratio is expected to reach a sweet-point for mobile service providers in 2010, as
shown in Figure 3.2. In addition, the report predicts that smartphones will out-ship the global
notebook and netbook market in 2010E and out-ship the combined global notebook, netbook,
as well as desktop market by 2012E.
The growth of e-commerce is predicted to be one of the largest implications of mobile internet
usage. Mobile commerce will feature location-based services, time-based offers, push notifica-
tions, etc. Online commerce and paid services in Japan made up 14 % of mobile revenue in 2000
and increased to 32 % in 2008. The rest of the world is still hovering at 14 %, but the report
suggests that much of the same trajectory could be seen over the next 10 years.
Figure 3.1: Global mobile vs. desktop Internet user projection [23]
3.1 Trends 17
Figure 3.2: Global 3G penetration and usage [23]
Key Predictions for IT Organizations and Users in 2010 and Beyond
With this document [21], Gartner highlights a number of trends and events that will change the
nature of business in 2010 and beyond. By 2013E, Gartner predicts mobile phones to overtake
PCs as the worldwide most commonly used means to access the web. This confirms Morgan
Stanley’s prediction. The PC installed base is forecasted to reach 1.78 billion units in 2013E.
That same year, the installed base of web-enabled mobile devices is expected to exceed 1.82
billion units.
Although the number of websites and web applications with support for small form factor mobile
devices is steadily growing, the majority still does not. Websites without optimizations for
smaller screen-formats will become a market barrier for mobile owners. This makes is important
for content providers to prepare the necessary actions and start offering content in a mobile
context. As mobile web users are typically prepared to make fewer clicks on a website, much
content and many sites will need to be reformatted or rebuilt.
3.2 Evolution of the mobile web 18
3.2 Evolution of the mobile web
When internet connections were first introduced to mobile devices in 19961, it was clear that
regular desktop HTML webpages were not suitable for such devices. The stringent device con-
straints and variety of proprietary web technologies created the need for a series of new standards.
In this section we will discuss the evolution of mobile web standards, from the mobile-specific
WML to the latest XHTML-based markup languages.
3.2.1 Mobile-specific web standards
WAP and WML
As an initial effort to address the specific needs for mobile web access, Nokia, Ericsson, Unwired
Planet and Motorola founded the WAP Forum in 19972, a standards organization aiming at the
development of open standards for the mobile industry [27]. At that time, each manufacturer
developed its own specialized web technology. The WAP Forum’s standardization intent was a
first step towards the prevention of further fragmentation[3].
The Wireless Application Protocol (WAP) and Wireless Markup Language (WML) were pub-
lished in 1998. The first set of widely deployed standards for the mobile web [66]. WAP is an
open standard for network communication at the application layer. It is mainly used to enable
mobile access to the Internet. However, WAP requires pages to be authored with a specific
WML markup. This initially cut off users from the conventional HTML web. The set of WML
markup tags was kept to a very minimum, as it had to be rendered on devices with very limited
resources.
i-Mode, cHTML and WAP 2.0
i-Mode is a suite of wireless internet service developed by NTT DoCoMo in 1999. Compared to
WAP, i-Mode encompasses a wider variety of internet standards. It includes web access, e-mail
and a packet-switched network for data delivery. i-Mode also employs an HTML-based markup
language named cHTML. cHTML is a subset of HTML 2.0, HTML 3.2 and HTML 4.0 with
several mobile additions [47].
1The first device was a Nokia 9000 Communicator. 2The WAP Forum was later endorsed by the Open Mobile Alliance (OMA).
F ig
u re
3 .3
The mobile-specific changes relate to support for access-keys, phone number shortcuts in links,
etc. Still, this approach’s main advantage is cHTML’s compatibility with HTML. The evolution
towards HTML-based content made it easier to develop mobile websites and allowed mobile
pages to be accessed using a standard desktop browser.
Due to the superiority of i-Mode over WAP 1.0, an joint integration effort has led to the devel-
opment of WAP’s successor. The final WAP 2.0 specification included the support for TCP/IP-
based communication protocols and implemented XHTML-MP as the primary markup language
[67].
XHTML Basic and MP
XHTML Basic is a structured XML-based markup language published as a W3C recommen-
dation in 2000. It is the most restricted XHTML derivative. Only a minimized set of features
is supported, as its primary use focusses on the most limited mobile devices. XHTML Ba-
sic is suited for mobile phones, PDAs, pagers, and settop boxes. A important advantage of
XHTML Basic over WML and cHTML is the possibility to render page differently in desktop-
and handheld web browsers, without the need for two different versions of the same content [28].
XHTML Mobile Profile is another XHTML derived markup language, specified by the OMA
between 2001 and 2006. It is essentially an extension to the XHTML Basic standard and adds
the concept of XHTML Modules [70]. Successive versions of this standard have added new
modules, providing richer form controls and varying levels of scripting support.
In 2008, the XTHML Basic 1.0 specification was revised to version 1.1 and presented as a W3C
recommendation [28]. As a result of defragmentation efforts from both W3C and OMA, XHTML
Basic and XHTML-MP became almost indistinguishable standards.
Wireless CSS and CSS-MP
The Wireless Cascading Style Sheet (WCSS) standard is a subset of CSS, published by OMA
in 2006. WCSS can be combined with any XML-based document and has been included in
the WAP 2.0 specification3 [69]. It is a specified subset of CSS2 with a set of mobile-specific
extensions.
Wireless CSS contains core CSS functionality. This includes inheritance, cascading and selectors.
Property definitions are supported for the box layout model, text, fonts, visual effects, color and
lists. WCSS can be added to a document through external resource links, or via the insertion
of a style tag in the document’s header. Moreover, W3C and OMA have joint their efforts for
the defragmentation of mobile styling in a standard called CSS-MP [29].
3.2.2 Emerging web standards
HyperText Markup Language 5
The web Hypertext Application Technology Working Group (WHATWG) and W3C HTML
Working Group are developing the intended successor for both HTML 4.01 and XHTML 1.0.
HTML5 tries to address many issues associated with prior versions of (X)HTML. New elements
have led to the explicit support for web-based applications [46]:
• Focus on semantic elements4. Web page fragments are automatically provided with a
richer description. Mobile browsers can use this additional information to optimize the
page’s rendering based on their characteristics.
• The menu-elements define a better structuring description for menus and can be integrated
in the device’s native menu system.
• Form input-elements are given additional type specifications5. The more detailed identifi-
cation allows the device’s browser to render a native platform-specific UI element.
Moreover, HTML5 defines a set of rich JavaScript APIs to bridge the functionality gap between
native and web-based applications [45]:
• Audio- and video-playback APIs.
• 2D drawing API
• Client-side persistent storage. This API provides local storage and advanced SQL querying
interfaces.
4e.g. tags for: section, article, header, footer, etc. 5e.g. calendar, email, url, etc.
• Drag and drop handling API
• Network API, enabling web applications to initiate network communication.
• Browser history API, as a solution to resolve conflicts between JavaScript and the browser’s
history.
• Support for server-side initiated events. Push-based actions allowing the server to dispatch
DOM events into documents.
The latest CSS specification is still under development. Nevertheless, most desktop browsers
have already implemented parts of its definition. CSS3 has moved towards a modular struc-
ture, providing better separation of concepts. Modules are specified for the definition of media
features, providing pattern matching tools, etc. [30].
The concept of the web as an application platform has also had its influence on the CSS specifi-
cation. CSS3 tries to add styling mechanisms for a number of operations that are currently only
supported through client-side scripting. Compared to CSS-supported implementations, script-
ing approaches are tend to be inefficient and error prone. The new features are added with a
set of proposed CSS extensions, ensuring backward compatibility:
• Animation: introduces animations and defines the adaptation of a property’s value over
a given period of time.
• Transforms: allows elements to be scaled, rotated and skewed.
• Transitions: enables implicit transitions by describing how CSS properties can be changed
smoothly from one value to another over a given period of time.
3.2.3 Standardized best practices
W3C Mobile web Best Practices
The W3C Mobile web Best Practices (MWBP) [31] are an effort from the Mobile Web Best
Practces Working Group towards the standardization of best practices for web development.
This document is in part derived from the Web Content Accessibility Guidelines [32]. Although,
its scope has been limited to subjects related to mobile.
The MWBP recommendations’ main objective is to provide end-users with optimal experience
when accessing the web from a mobile device. The document refers to delivered content, not the
processes by which it is created. It is primarily directed at creators, maintainers and operators
of websites, with basic knowledge of creating websites and the general technologies it involves.
However, no background in mobile-specific technologies is required.
The best practices are divided in five groups of guidelines, overall behavior, navigation and links,
page layout and content, page definition and user input. Due to the size of this document, we
refer developers to the actual recommendation [31].
WEB-BASED MOBILE APPLICATIONS 24
Web-based mobile applications
In the last part of our state-of-the-art research, we will focus on the development of mobile web-
based applications. Market readiness will be evaluated and combined with our findings from
the previous chapters. Furthermore, standardization activities will be examined, as well as the
existing development tools and solutions.
4.1 The web as a mobile platform
The mobile market is facing an increasing fragmentation of platforms. The situation is not only
untenable for small and medium-sized software development companies. Even multinational
corporations such as Google openly doubt the feasibility of supporting native application for a
variety of mobile platforms. This unbalance situation has led to the general believe that the
development of platform-dependent mobile applications does not represent the future for the
mobile industry [2].
The internet is evolving towards a ubiquitous concept, connecting numerous types of devices.
With its current standardization efforts, the web is likely to become the ideal common platform
for the future creation and delivery of rich applications using browser technology as a universal
client. Nevertheless, the development of web applications in their purest form will not be possible
for most application-types. This is caused by the sandboxed nature of browsers, which drastically
limits the available interfaces to underlying device. Various standards are being developed to
address this issue. Web applications require the browser to support rich and secure interaction
4.1 The web as a mobile platform 25
with the device’s native functions. Efforts from the W3C [40] and BONDI initiative [39] have led
to an expectation that by 2013 browsers will by default have access to much of the functionality
of native applications today.
Hybrid web applications has been introduced to provide developers with a short-term solution.
Hybrid applications are a combination of native applications and pure web-based applications.
This type of applications is still built with web technology, but no longer uses the browser as the
client-side runtime environment. As shown in Figure 4.1, a client-side web runtime framework
is used to bridge the gap between native- and web applications by granting the application
scripting access to most of the device resources1.
The concept of hybrid applications has been explored from various perspectives. Developers can
opt for web widget engines such as Nokia WRT [63], device-independent frameworks such as the
PhoneGap application wrapper [58] and even web-based operating systems such as ChromeOS
[48] and Palm webOS [62]. We will discuss some existing hybrid solutions in section 4.4.2.
Figure 4.1: Application development platforms
1In most cases through additional JavaScript interfaces.
4.2 Introducing adaptivity 26
4.2 Introducing adaptivity
The growing diversity of mobile devices with internet connectivity has boosted the need for
applications being available at any time, anywhere and on any device. This emerging requirement
for adaptivity has drastically increased the complexity of mobile applications. The concept of
customization needs to be introduced in many aspects of the application development process.
Without the appropriate platform and tool support this becomes the developer’s responsibility
to handle, driving up costs and eventually narrowing the target market.
4.2.1 Modeling aspects
The modeling of traditional web systems is often scoped using three orthogonal dimensions,
namely the development phases, the system’s views and its aspects. In addition, the increasing
range of devices and usage contexts2 when accessing these systems have emphasized the impor-
tance of a fourth dimension: adaptivity. As shown in Figure 4.2, adaptivity can be considered
as a crosscutting aspect [4], influencing all other web modeling dimensions with a much greater
impact than we would normally expect in an environment focussed on desktop usage.
Figure 4.2: Web modeling aspects [4]
A number of web engineering methods have been developed, aiming at early separation of
concerns when modeling mobile web-based systems. Their base approaches vary from basic
rule-based systems [5], to aspect-orientation [6] and reflection-driven mechanisms [7].
2e.g. the growing importance of location-awareness in mobile applications
4.2.2 Basic mobilization approaches
Plain websites are, due their mainly content-driven structure, much easier to mobilize than web
applications. Today, three commonly used approaches can be identified. These approaches will
in general not be sufficient to optimize web applications for mobile usage. However, they should
rather be considered as a starting point for the more advanced methods.
Mobile redirection
The most basic approach is to extend the website’s server side with simple device detection. For
each incoming request, device capabilities are detected. When a mobile device is recognized,
its request is automatically redirected to the website’s mobile-friendly URL. This approach can
even be extended to use multiple alternative URLs, based on a more advanced combination of
device capabilities.
Mobile redirection is easy to set up and can be configured through various mechanisms. Nev-
ertheless, the complexity of maintaining all website’s instances should not be underestimated.
All modifications will need to be performed manually. This decentralization of website-versions
should be avoided by all means. Hence, the following approaches will focus on managing this
issue.
Template switching
Template switching tries to keep the website’s content centralized and thus minimizes the re-
quired effort to add or modify content. This approach is often used in CMS-driven environments,
as templating is a standard provided mechanism for the separation of content and presentation.
Templates are used to enable organizations to brand the look-and-feel of their website, without
having to make core modifications to the underlying framework.
Most templates are designed to provide a rich and multi-column presentation of the content. In
a mobile context, a completely different type of templates will be desirable. For small-screened
devices, a single column design is often found to be the best readable solution. Designers must
also take into account that advanced technologies, such as Flash or AJAX are not supported by
most mobile browsers.
Building a single template that meets both desktop and mobile requirements will lead to com-
promises for both parties. Dynamic template switching has been introduced to cope with this
issue. It allows web administrators to define templates for different types of devices and clients.
Instead of redirecting mobile users to an alternative website, the CMS’s template is dynamically
switched to the mobile-friendly version.
Simple websites can certainly benefit from this approach. Provided that the number of required
content modifications are minimal. For example, blog websites have relatively simple content
that can be reused for desktop and mobile presentation. Nevertheless, as we will discuss in
section 4.2.3, this approach does not suffice when mobilizing more complex websites and web
applications.
Transcoding services
A third common approach are the transcoding services. In this case, only the desktop ver-
sion of the website is maintained. Page requests are first sent to an intermediate proxy server.
This transcoder will in turn request the corresponding desktop page from the website’s original
server. Before returning the page to the end-user, the transcoding server performs a sequence
of adaptations to optimize the output based on the requesting device’s characteristics.
Figure 4.3: Transcoding services
There are two approaches for the composition of adaptation sequences. The transformations
can be composed automatically by the transcoder. Without any intervention from the website’s
administrator, the transcoding server determines a sequence of page-transformation. The Opera
mini browser offers such automatic adaptation. Nevertheless, due to the lacking semantical
information, the transcoder is only able to make a series of “educated guesses”. This often leads
to results below expectations.
A more vigorous approach is to perform semi-automatic adaptations. Administrators are given
the chance to express their wishes in terms of manually specified transformations. These se-
quences are incorporate in the transcoding server’s mobilization process. The use of semi-
automatic transformations results in powerful website mobilizations. Although, most of the
projects are required to be executed ad-hoc because of the need to specify the project-specific
transformations manually. This issue will be addressed in the next section.
4.2.3 Towards adaptive web applications
The basic mobilization strategies render acceptable results for basic websites3. Nevertheless,
when development relies on the desktop website as a starting ground, a compromise between
the necessary development effort and the delivered quality will be required.
This inherent shortcoming emerges when developing more advanced mobile websites and web
applications for a wide range of mobile devices. Further on, we focus on this issue, as general
concepts and techniques for the development of adaptive mobile web applications are examined.
Progressive Enhancement
In desktop web development, coping with different browser capabilities when creating websites
and web applications has always been a substantial part of the development process. The
traditional design strategy4 for the desktop web has been to focus on the most advanced browsers.
The less capable browsers are only provided of a stripped version during the last phase of
development. This approach assumes end-users to just upgrade their browser when the degraded
version doesn’t fit their needs. However, on most mobile devices the option to upgrade the
browser is not supported.
Progressive enhancement (PE) has reversed this strategy and its goal is to maximize accessibility
over browsers with different capabilities [9]. A basic markup document is created, aiming at
an optimal experience for the lowest common denominator (LCD) of browsers. Next, layers of
presentational- and behavioral enhancements are gradually added in function of the browser’s
3e.g. blogs, news sites, etc. 4also known as the graceful degradation approach
capabilities. Enhancements such as CSS, JavaScript and other advanced technologies are always
externally linked. This prevents unusable data to be downloaded by limited browsers.
Figure 4.4: Layers of progressive enhancement
The progressive enhancement can also be used in a mobile context. The possible combinations of
mobile browsers with graded CSS and JavaScript support is even more diverse than for desktops.
PE forces developers to thinks in terms of the least capable devices from the very start of the
development process. The enhancements for devices with more advanced capabilities are only
added afterwards. Enhancements layers are built unobtrusively on top of that basic LCD version
or other enhancement layers.
The basic progressive enhancement philosophy is however limited to distinguish browsers based
on their capability to support stylesheets and JavaScript5. For mobile usage, it can be an
interesting approach to drive the layer selection and inclusion by a server-side process that has
detailed awareness of the client-device’s capabilities. This allows web applications to have e.g.
multiple presentation layers with platform-specific look-and-feels and let have selection process
determine the best selection.
5and a very limited set of device properties when using CSS3 enhancement layers
Figure 4.5: Mobile PE (LCD) Figure 4.6: Mobile PE (basic CSS, JS)
Figure 4.7: Mobile PE (CSS3, AJAX calls)
Figures 4.5, 4.6 and 4.7 depict a single m-commerce web application accessed by three dif-
ferent types of devices. The application’s basic version is identical for each device. It is the
device-driven selection of progressive enhancement layers that supports the optimization of the
application based on the client-device’s characteristics.
New complexity arrises with this approach, as the server-side selection of layers is not actually
handled by the progressive enhancement mechanism. This requires the specific development
of device-aware selection algorithms. Such algorithms can be included ad hoc for each web
application separately. As we mentioned before this quickly leads to unmanageable situations
due to excessive development costs. Using PE as a standalone mobilization approach will thus
result in an insufficiently powerful solution. Nevertheless, it can certainly be used as a part of
more general approaches which we will discuss further on.
CMSs as mobile web application frameworks
A web Content Management System (CMS) is a web-based application, traditionally used for
managing the content of websites. CMSs aim at assisting non-technical content-authors and
simplify the process of creating, editing and publishing content on the web. By using a CMS,
authors are no longer required to master any programming- or web markup skills. Most of the
complexity is abstracted and managed by the system.
Moreover, the scope of most CMSs isn’t limited to creating websites. In the recent years, CMSs
have evolved and are built on top of powerful web application frameworks [10]. Such frameworks
have the goal to support the complex processes of the CMS itself, but also to allow third-party
web developers to use the CMS as a platform for their web applications.
Using a CMS as web application platform has multiple benefits. Developers are given the
means to create web-based applications with a minimum of required effort, whilst the CMSs’
administrators still have the power to manage the application’s content- and publication settings
without having to change any internal code or parameters. This approach has shown to be very
effective for the creation of web applications aiming at desktop users. Numerous CMSs nowadays
offer extensions to support applications such as e-commerce, personal information management
(PIM), social networking, etc.
However, mapping CMS-driven web applications to a mobile context holds some challenges.
Most CMSs handle all clients the same way. Unregarded whether a request originates from a
desktop computer or a mobile device. By default, the CMS frameworks offer web developers
no option to retrieve any device characteristics, nor to manipulate content in order to overcome
device limitations.
Semantically assisted transcoding services are much alike the traditional website transcoding
services from section 4.2.2 and very popular for enterprise mobile solutions. Instead of

Documents

CMS-driven development of adaptive mobile web applications