1. TAMPERE UNIVERSITY OF TECHNOLOGY
Department of Information Technology
NIKO KUMPU & JEROME RANNIKKO
MOBILE FRIENDLY WEB SERVICES
Master of Science Thesis
Topic accepted in the department council meeting
on 18
¢¡
August 2004.
Examiners: Prof. Ilkka Haikala (TUT)
Lic.Tech. Jari Mononen (Nokia)
2. Acknowledgements
This thesis has been done as part of a research project at Tampere University of Tech-
nology and was funded by Nokia. We would like to thank Professor Ilkka Haikala
for his guidance and support during the writing of this thesis. We would also like to
thank Jari Mononen from Nokia for his feedback and comments regarding our work.
Special thanks go to the third member of our project team, Ilkka Poutanen, for his
significant contribution to the Gallery case study. Our gratitude also goes to Kathryn
Williams for proofreading our thesis. Finally, we would like to thank everybody who
has in some way helped us during the writing of this thesis.
Tampere, 24
£¡
November 2004
Niko Kumpu Jerome Rannikko
mobile: +358 40 7573 205 mobile: +358 41 5020 789
email: niko.kumpu@jyvaskylalainen.com email: jerome.rannikko@iki.fi
3. iii
TAMPERE UNIVERSITY OF TECHNOLOGY
Department of Information Technology
Institute of Software Systems
KUMPU, NIKO and RANNIKKO, JEROME: Mobile Friendly Web Services
Master of Science Thesis, 87 pages
Examiners: Prof. Ilkka Haikala (TUT) and Lic.Tech. Jari Mononen (Nokia)
Funding: Nokia
December 2004
Keywords: Internet, mobile friendliness, open source
Most new mobile phones and PDAs include a possibility to access the Internet with
the device’s own or a third-party XHTML browser. However, small displays and slow
Internet connections are a problem. These complicate browsing and especially pages
containing images download slowly. A mobile friendly web service offers the users
of mobile devices the same service than for the desktop computer users, but in a form
that is suitable for mobile user agents. In practise this means recognizing the mobile
devices, scaling down the images, and altering the page layout, so that they fit on the
narrow screen of a mobile device.
In this thesis the concept of mobile friendliness is defined and modifying existing
software to become mobile friendly is studied in practise. Two programs, Gallery
and LiveJournal, are used as examples. Gallery is a popular web server based photo
gallery software programmed in PHP. LiveJournal is written in Perl and provides over
one million of its users with the possibility to publish an online diary. Both programs
are distributed under the GPL open source license, which means that their source code
is publicly available and can be freely modified.
Modifications necessary for mobile friendliness were made in both Gallery and Live-
Journal. The programs were modified so that they recognize mobile devices and
present the content in a form suitable for them. In addition, support for the Image
Uploader functionality found in some Nokia mobile phone models was implemented
for Gallery. The modified programs were made available on the homepage of this
project and the Image Uploader support was included in the official Gallery release.
4. iv
TAMPEREEN TEKNILLINEN YLIOPISTO
Tietotekniikan osasto
Ohjelmistotekniikka
KUMPU, NIKO ja RANNIKKO, JEROME: Mobiiliystävälliset www-palvelut
Diplomityö, 87 sivua
Tarkastajat: prof. Ilkka Haikala (TTY) ja tekn.lis. Jari Mononen (Nokia)
Rahoittaja: Nokia
Joulukuu 2004
Avainsanat: Internet, mobiiliystävällisyys, avoin lähdekoodi
Useimmat uudet matkapuhelimet ja PDA-laitteet sisältävät mahdollisuuden käyttää
Internetiä joko laitteiden omilla tai kolmannen osapuolen XHTML-selaimilla. Ongel-
mia aiheuttavat kuitenkin laitteiden pienet näytöt ja hitaat Internet-yhteydet. Näistä
johtuen selaaminen on vaivalloista ja varsinkin kuvia sisältävien sivujen lataaminen
hidasta. Mobiiliystävällinen www-palvelu tarjoaa sekä mobiililaitteen että tietoko-
neen käyttäjälle saman palvelun. Mobiileille päätelaitteille palvelun sisältö esitetään
niille sopivassa muodossa. Käytännössä tämä tarkoittaa mobiililaitteiden tunnistamis-
ta sekä kuvien pienentämistä ja sivujen rakenteen muuttamista siten, että ne mahtuvat
mobiililaitteen kapealle näytölle.
Tässä diplomityössä määritellään mobiiliystävällisyyden käsite ja tutkitaan käytän-
nössä valmiiden ohjelmistojen muokkaamista mobiiliystävällisiksi. Esimerkkeinä käy-
tetään Gallery ja LiveJournal -ohjelmistoja. Gallery on suosittu PHP-kielellä ohjel-
moitu www-palvelimella toimiva valokuvagalleria. LiveJournal on Perl-kielellä kir-
joitettu ohjelmisto, joka tarjoaa yli miljoonalle käyttäjälleen mahdollisuuden julkais-
ta päiväkirjaa Internetissä. Molemmat ohjelmistot on julkaistu avoimen lähdekoodin
GPL-lisenssillä, minkä johdosta niiden lähdekoodit ovat julkisesti saatavilla ja va-
paasti muokattavissa.
Esimerkkiohjelmistoihin toteutettiin mobiiliystävällisyyden vaatimat muutokset. Oh-
jelmia muokattiin niin, että ne tunnistavat mobiililaitteet ja muokkaavat sisällön niille
sopivaan muotoon. Lisäksi Galleryyn toteutettiin tuki joissakin Nokian matkapuhelin-
malleissa olevalle Image Uploader -toiminnolle. Muokatut ohjelmistot laitettiin saa-
taville projektin kotisivulle ja Image Uploader -tuki saatiin osaksi Galleryn virallista
jakeluversiota.
7. Chapter 1
Introduction
The Internet today is an essential source of both information and entertainment for
many people. Every day we use it for various purposes such as to check the weather
forecast, to see what is on television in the evening, to book a holiday, or just send an
email to a friend or a colleague. The Internet also has an increasing importance within
our work places, both as an information resource and as a communication channel.
An increasing number of people have a mobile phone or a PDA (Personal Digital
Assistant) with an Internet connection and a browser. The combination of the Internet
and a mobile device has great potential, and immediately suggests several possible use
scenarios: sending email wherever you want to, getting driving instructions to your
mobile device while on the road, reading timetables, or checking the latest additions
to the family’s picture gallery on your way to work. All this and more could be done
with your mobile phone or a PDA away from you desktop computer.
These visions are examples of a mobile friendly Internet as we would like to see it.
By mobile friendly we mean that the users have essentially the same user experience
of a website whether they are using a desktop browser or a mobile browser to access
the resource. From a wider perspective mobile friendliness can also mean having a
totally different way of implementing a web service or part of it. For example, an
image gallery could provide an email address instead of a web form for mobile users
to upload their images.
Unfortunately, there are some major problems between the current situation and the
mobile friendly Internet we envision. These problems range from the websites them-
selves through to the mobile networks and the mobile devices.
8. CHAPTER 1. INTRODUCTION 2
The first major problem is the combination of the small screens on mobile devices
and the layouts of many webpages. Most layouts are designed for the big screens of
desktop computers without considering the restrictions of mobile user agents. When
browsing these sites with a mobile device, the pages usually need to be scrolled both
horizontally and vertically, which makes the use of the site difficult and inconvenient
for the user.
Another issue is the images on webpages. Most of the time images are far too wide
and tall to fit on the small screen of a mobile device. This again forces the user to scroll
the page in both dimensions to view the whole picture. If the visible dimensions of
an image are large, this implies that the file size will also be large. Considering the
limited bandwidth of mobile networks, big image files make page downloads slow.
One option for mobile browsers is not to download images on webpages at all. This
does enable the device to render the page faster but it might also make the page hard
to understand, for example if the images are navigational links. Some browsers auto-
matically scale the images to fit on the screen but this takes even more time and uses
more processing power.
In order to provide mobile friendly web services we first need to be able to recognize
mobile user agents. This can be done based on the user agent string that the browser
sends with the request for a webpage. The user agent string usually consists of at
least the browser’s name and version, operating system, language, and, in the case of
mobile user agents, usually the device model and make. Based on this information
we can usually know or at least make an educated guess as to the screen size of the
device.
The next step is to make the page suitable for the small screens. This involves scaling
the images and altering the layout. When building our site using modern web stand-
ards such as Extensible Hyper Text Markup Language (XHTML) and Cascading Style
Sheets (CSS), achieving mobile friendliness may be easier than we think. XHTML
has a strict syntax which makes it easy for mobile browsers to parse it. With CSS we
can define different layouts and styles for mobile and desktop users. When we add
to this image scaling and avoid using tables where possible, we are making our site
quite accessible for mobile users without compromising our other visitors’ browsing
experience.
Using open source software allows us to experiment with our ideas and put them into
practise in an existing system. Open source software means, essentially, that you have
access to the program’s source code and the program is available for free. You can
9. CHAPTER 1. INTRODUCTION 3
modify the code and redistribute it if you wish. There are different licenses that have
different restrictions on what you can do and how. One of the most popular licenses
is GPL (GNU General Public License) which allows you to modify the code, use it
as part of your own program and even sell it. However, GPL requires that if you sell
your program you must supply the source code with it, and the source code also has
to be available for free for anybody who is interested.
In this thesis we will explain in detail what exactly is mobile friendliness and why the
current Internet, for the most part, is not mobile friendly. Then we will use two open
source projects, Gallery and LiveJournal, to demonstrate how existing software can be
modified to achieve mobile friendliness. Gallery is a very popular web image gallery
software and LiveJournal is a popular weblogging service with millions of users. We
add to these software products functionality to recognize mobile user agents, and
based on that, alter the layout and scale images. For the image gallery we will also
build a support for Nokia’s Image Uploader, which enables phone owners to upload
images directly from their camera phones straight to their Gallery account.
Chapter 2 looks into the current situation regarding the browsing experience when
using the Internet with a mobile device. In Chapter 3 we define mobile friendliness
and some basic principles and view points that need to be considered when designing
a mobile friendly website. This chapter also explains how open source is relevant
to mobile friendliness. Chapter 4 is a short introduction to open source software, its
different licenses and development models.
Chapter 5 is a case study of an open source image gallery software called Gallery.
Gallery was chosen for our case study because of the association between camera
phones and web image gallery. We work with two versions of Gallery, Gallery 1 and
Gallery 2, and in this chapter we describe their architecture, the differences between
these versions, and how they work. An important part of this chapter is to show how
we made Gallery mobile friendly and added the Nokia Image Uploader support to it.
In Chapter 6 we present our other case study: LiveJournal weblogging software.
Today weblogging, or blogging, is a popular way to preserve your memories and
daily events. It is similar to keeping a diary or journal but it is done over the Internet.
Obviously, being able to do this with your mobile phone or PDA would be a benefit.
This chapter explains how we added mobile friendly features to LiveJournal.
Chapter 7 summarizes our work in this thesis. In this chapter we also offer some
conclusions and share the experiences we learned while working on this project.
10. Chapter 2
The Internet and Mobile Devices
The Internet offers us many useful services that make our lives easier and that we use
daily. Many people have mobile phones with an Internet connection, which in theory
enables us to use these services whenever and wherever we like. In practise, it is often
quite different. This chapter takes a closer look at the mobile browsing experience,
the problems we encounter, the reasons behind them, and some of the solutions that
are used to try to make things work better.
2.1 Overview
Some of the most useful websites available to us on the Internet include bus and train
timetables, news headlines, search engines, weather forecasts, and driving instruc-
tions. We can also book tickets, buy books and DVDs, check out the movie showtime
listings or television program, upload a picture to the family photo gallery or update
personal online journals. We use most of these services daily with our computers both
at work and at home. However, many of these services are of such a nature that we
often find ourselves in need of that particular resource, e.g. a timetable, but are not
at our computer. Or we would like to use the time we spend every day in a bus or a
train commuting to work to read the news headlines or to book a theater ticket for the
evening but are not able to so because we do not have our computer and an Internet
connection.
However, almost all of the new mobile phones are equipped with GPRS (General
Packet Radio Service) and a web browser. So why not browse the web and use its
11. CHAPTER 2. THE INTERNET AND MOBILE DEVICES 5
services with your mobile? Unfortunately it is easier said than done. Many websites
we like to use are very difficult to navigate or almost completely inaccessible with our
mobiles and other handheld devices. This problem is caused by a number of reasons
including the mobile browsers, the available bandwidth, and the technology used on
websites.
2.2 Specialized content
When an Internet connection was introduced to mobile phones it was obvious that
normal Hypertext Markup Language (HTML) webpages were not suitable for these
devices. Phones have many constraints compared to desktop computers which makes
processing of the page content quite demanding. Mobile devices have less powerful
CPUs, less memory, smaller displays, very limited input devices and restrictions on
power consumption. Also, the mobile network offers, in most cases, less bandwidth
and more latency than a normal modem or broadband connection on a computer.
To solve the problem Nokia, Ericsson, Phone.com (then Unwired Planet) and Mo-
torola founded the WAP Forum1
. Its goal was to develop a common format for Inter-
net transfers to mobile phones. Since then more companies have joined WAP Forum
so that it now has more than 200 members.
WAP and WML
The major results of the WAP Forum’s work are Wireless Application Protocol (WAP)
and Wireless Markup Language (WML) [40]. WML is an Extended Markup Lan-
guage (XML) application and it is used to create webpages that can be delivered to a
mobile device using WAP. A WAP browser on the phone can then render the WML
document to the small screen of the device. The set of tags that WML offers is very
limited due to the various constraints caused by the mobile environment.
WAP services are usually easy and relatively fast to use with a mobile device but there
is also a downside. WAP content always needs to be specifically designed for mobile
devices, which results in two problems: availability and cost.
1
WAP Forum no longer exists as an independent organization but is now part of the Open Mobile
Alliance http://www.openmobilealliance.org/
12. CHAPTER 2. THE INTERNET AND MOBILE DEVICES 6
Let us first consider the problem of availability. Internet has millions and millions of
homepages and other sites full of more or less useful information. The problem is that
these pages are mostly HTML and therefore not accessible with a WAP browser. In
many cases these sites are created and maintained by individuals who do it in their
spare time. They do not usually have enough time or knowledge to develop a WML
version of their pages as well as HTML, because that would in practise double the time
and effort used to create the page. For this reason the content available for WAP users
is only a marginal portion of the whole Internet. There have been some attempts to
overcome this problem by translating HTML to WML. This is possible to accomplish
on a single site where the page structure is well known but a general solution is a lot
harder to achieve. This can be seen, for example, at Google’s WAP portal2
where they
offer WML translation as part of their service. Certain kinds of page structures, such
as simple news headline pages, seem to be relatively easy to automatically translate
into WML. However, more complicated HTML sites translate into WML pages that
are practically impossible to navigate.
The second problem is cost. It is mostly the big organizations and commercial entities
who have the resources to create a WAP version of their sites alongside the main
HTML version. But using their resources to expand their service also means more
costs for the company. Many times, unfortunately, they want to move that cost to their
customers. One such example is Finland’s biggest news paper, Helsingin Sanomat,
who charge a small fee for their WAP service3
although the same content in HTML
is available for free. Of course not all companies work like this and for example the
BBC offers a free WAP portal4
where mobile phone users can access news and some
other services.
2.3 XHTML
Web browsers are usually quite forgiving when it comes to following the HTML
standards. If a tag is missing it does not cause a problem as long as the browser can
deduce what is missing, or if there are unknown tags in the document (some browser
vendors have their own extensions to HTML) the browser just ignores them. Also,
browsers tolerate improperly nested elements although it is illegal according to the
2
http://wap.google.com/
3
http://wap.hs.fi/
4
http://www.bbc.co.uk/mobile/
13. CHAPTER 2. THE INTERNET AND MOBILE DEVICES 7
HTML standards. All these things have lead to many poorly written HTML pages.
After all, how can web authors know their markup is wrong if the browser shows
the page correctly anyway. This makes writing new browsers and keeping the old
ones up to date increasingly difficult as one needs to be prepared for many different
non-standard HTML markups.
Another reason demanding development in HTML is the emerging of numerous new
devices accessing Internet. These devices include mobile phones, PDAs, televisions,
etc. which do not have the capacity of a desktop browser to parse and render the
incorrect HTML. Their memory and processing capacity are so limited that parsing
malformed HTML can be very resource consuming and even impossible with the
simpler devices.
For these reasons the World Wide Web Consortium5
(W3C) started to work on a new
version of HTML that would be based on XML. The result, XHMTL 1.0 (Extens-
ible HTML), was published in January 2000 [44]. XHTML 1.0 is a reformulation
of HTML 4 in XML 1.0. This means that while syntactically XHTML is an XML
application, its semantics are defined by HTML 4. The W3C recommendation lists
twelve differences between HTML 4 and XHTML, including the following:
¤
XHTML is case sensitive. Element and attribute names must be in lower case.
¤
All elements must be properly nested,
i.e. <p><em>text</em></p> instead of <p><em>text</p></em>.
¤
All elements, including empty elements, must have a closing tag.
¤
Attribute values must always be quoted.
These are just the most important ones. The whole list and more detailed explanations
can be read from the recommendation ([44], section 4).
XHTML Basic
As explained above, parsing HTML on a mobile device is very resource consuming.
XHTML makes it a lot easier by removing many ambiguities and clarifying the syn-
tax. XHTML Basic, published in December 2000, is the second recommendation in
5
http://www.w3c.org/
14. CHAPTER 2. THE INTERNET AND MOBILE DEVICES 8
the W3C’s series of XHTML specifications and it takes XHTML yet one step closer
to the requirements of web clients with limited capabilities.
The specification describes itself with the following: "The XHTML Basic document
type includes the minimal set of modules required to be an XHTML host language
document type and in addition it includes images, forms, basic tables, and object
support. It is designed for Web clients that do not support the full set of XHTML
features; for example Web clients such as mobile phones, PDAs, pagers, and set-top
boxes. The document type is rich enough for content authoring." [43]
XHTML Basic combined with Cascade Style Sheets (CSS) [2] allows the web author
to create versatile pages with the added benefit that they look good not only on a com-
puter screen but also work well when accessed with a mobile device. This becomes
very important if the site is meant for use with both desktop browsers and mobile user
agents, as there is no need to create two different versions of the page.
2.4 Layout
Page layout is one of the major problems with many websites when accessing them
with a mobile user agent that has a small screen. It is very difficult for the users to
read a page when they need to scroll in every direction to see the whole page.
Tables
One big reason behind the problems with layout is the use of tables. Tables are usually
slow to render, especially if they are nested, as the whole table definition must be read
before it can be properly presented. This prevents incremental rendering, which is
inconvenient for the user. This is a major usability concern that should be noted by
everyone making websites for general Internet users. When tables are used for the
purpose they are meant for – to present tabular data – they are not a problem but when
tables are used to do the page layout it means trouble. In addition to usability, one big
concern is the mixing of presentational markup with content.
For the sake of different user agents (e.g. screen readers for the blind, mobile devices)
and maintainability, web designers should use semantic markup. Semantic markup
means making a clear difference between the content and the presentation. The
15. CHAPTER 2. THE INTERNET AND MOBILE DEVICES 9
markup, (X)HTML, describes the content – what it is and what is its role in the doc-
ument. The presentation, how the data should be displayed to the user, is explained
with CSS. Separating presentation from content makes it easier to maintain and up-
date the site as changes in the outlook can be made in one or just a few files instead
of editing tens or hundreds of them individually.
Partial Solutions
Semantic markup with media dependent CSS offers an easy way to alter the layout
based on the user agent. One can define several different style sheets for one document
by using the media attribute of the HTML link element. The media attribute has
many possible values including screen, print, handheld, and all. Unfortunately not all
mobile browsers support the media attribute.
For mobile users there is some help available even when the site’s design does not
acknowledge them in any way. There are several browsers for mobile phones and
PDAs that try to render the page so that it fits on the small screen of the device and is
still readable.
Opera software’s solution is a technology called Small Screen Rendering (SSR) [34].
Its main concern is to avoid horizontal scrolling and this is achieved by using several
different techniques. If the layout uses columns and they are too wide to fit on the
screen side by side, they are merged into one in the document order (the order in
which the elements appear in the page source code). Big images do not work well on
the small screen so they are either scaled down or removed altogether. Background
images are not shown and SSR also adjusts the fonts so that only three different sizes
are used in order to improve readability. Based on our experiences and given the wide
variety of different webpages, SSR works quite well while still not being the ideal
solution to access the Internet with mobile devices.
There are many other similar approaches to solve the problem. For example Access6
has an embedded browser for mobiles called NetFront. It uses its own Smart-Fit
technology to adapt pages on a small screen.
6
http://www.access-us-inc.com/
16. CHAPTER 2. THE INTERNET AND MOBILE DEVICES 10
2.5 Images and Bandwidth
Images on webpages can be a real annoyance for the mobile user. The issue is the
size of the images, in terms of both pixels and bytes. An image that looks good on
the desktop browser does not fit on the small screen of a mobile device and forces the
user to scroll in every direction. Also, as previously mentioned, the mobile bandwidth
is very limited and downloading of a single image, let alone several images, takes a
long time.
What makes the problem worse is the fact that the first solution that comes into mind,
turning off image downloads, is not always feasible. Sometimes images are used for
important functions on webpages such as navigation buttons or menu items. Without
those images the whole page is useless, but with the useful images can come many
unwanted and unnecessary graphics. This slows the download speeds to an unbearable
level or just makes reading the page very hard on a small screen.
Mobile networks currently offer very limited bandwidth compared to that of the broad-
band or even the modem Internet connection of a desktop PC. This causes page
downloads to the mobile browser to be slow, which is quite inconvenient for the user.
Again, webpages designed specifically for mobile users usually download fast, but
these pages represent only a tiny portion of the potentially interesting pages available
on the whole Internet. Many mobile operators and other companies offer services de-
signed to help users to improve their mobile browsing experience by compressing and
caching data. Examples of such services include Sonera’s Nettinopeutin and Mobile
Accelerator from Opera Software.
The Finnish mobile operator Sonera has a service called Nettinopeutin [39] (web
accelerator) that promises three to four times faster downloads on average. Net-
tinopeutin works by reducing the image quality, blocking GIF-animations and com-
pressing all the data. This service does not require any program to be installed on the
device and is free for Sonera GPRS customers.
Opera Software, who are best known for their web browser, have a Mobile Accelerator
service [33]. It reduces the size of webpages by approximately 50-70% by optimizing
code, compressing data, and removing unnecessary content. Mobile Accelerator is a
commercial service, prices start from 6.90 euros for three months.
17. Chapter 3
Mobile Friendly Features
The term mobile friendly will be used in the following chapters. It is derived from
user friendly and it means how easy it is to use a webpage and how nice the browsing
experience is for the user of a mobile browser. A website is mobile friendly when
it provides the mobile users with the same service than the desktop users and offers
an easy user interface. To offer mobile users a mobile friendly experience we need
to take following things into consideration: device recognition, content scaling, and
webpage structure modifications. In addition, to achieve a superb mobile browsing
experience, new styles and layouts for mobile devices need to be implemented.
3.1 Mobile Friendliness Is Needed
Mobile friendly features offer users a much better browsing experience than what it
would be without these features. With mobile friendly features users do not have to
scroll webpages in both horizontal and vertical directions. Scrolling in both directions
would sooner or later become uncomfortable because users would get lost while trying
to view the content from a small “window”. Mobile friendliness provides a way where
only vertical scrolling is needed, which is the case also with regular desktop browsers,
at least when the website is not poorly designed or implemented.
Nowadays an increasing number of the released mobile devices have the capability to
show XHTML content. In other words, mobile devices have a GPRS connection and
either they have an XHTML browser or one can be downloaded and installed. There-
fore, the group of potential people wanting to access web services with their mobile
18. CHAPTER 3. MOBILE FRIENDLY FEATURES 12
devices is becoming too big to be ignored by web service designers. Furthermore, all
the time new people are becoming aware of the possibilities that mobile devices offer,
and therefore the number of potential users is increasing with a rapid rate. Unfortu-
nately, there are not many websites that support mobile devices in a way we would
like them to.
Mobile phones travel with their owners, so wherever they go their phones will follow.
This is one very essential reason why mobile friendliness is needed. With mobile
friendly features it is easier for users to keep track of their daily events, for example by
writing them down to a weblog or uploading images taken with their camera phones to
an online gallery. These and many other similar services already exist in the Internet
but the problem is that only a tiny fraction of them provide a mobile friendly user
interface.
3.2 Recognizing Mobile Devices
In order to enable mobile friendly features we must first be able to determine when a
mobile device is present, i.e. when the device requesting a webpage from our server is
a mobile device. One way to do this is to use device’s user agent string as an identifier.
The user agent string is a string of text containing information about the device, such
as operating system, platform, used browser, and localization. Also, other details
can be inserted into the user agent string. Some mobile devices may even include
their display dimensions in pixels. Table 3.1 lists some user agent strings of different
mobile and desktop browsers. Most user agent strings in the table were acquired from
the Internet [35][45] and others by manually checking them with mobile phones.
Knowing just the user agent string is obviously not enough to activate mobile friendly
features. Display dimensions is another important step on our way towards mobile
friendly web services. We need to know the display dimensions of those mobile
devices that we want to support on our website. There are a few ways to find out
display dimensions of different devices. If dimensions are not included in the user
agent string, which seems to be the case most of the time, they can usually be found
from the device manufacturer’s homepage. When we have both the user agent string
and the display dimensions of a mobile device we will need to map them together.
This can be done best by using a tabular data structure where user agent strings are
keys to the corresponding display dimensions.
19. CHAPTER 3. MOBILE FRIENDLY FEATURES 13
Table 3.1: User agent strings of various devices.
Device Browser User Agent String
Nokia 3650 phone’s Nokia3650/1.0 SymbianOS/6.1 Series60/1.2
browser Profile/MIDP-1.0 Configuration/CLDC-1.0
Nokia 7610 phone’s Nokia7610/2.0 (4.0421.4) SymbianOS/7.0s Series60/2.1
browser Profile/MIDP-2.0 Configuration/CLDC-1.0
Nokia 7700 Opera Mozilla/4.0 (compatible; MSIE 5.0;
Symbian OS; Series 90) Opera 6.0 [en]
Sony Ericsson T610 phone’s SonyEricssonT610/R201 Profile/MIDP-1.0
browser Configuration/CLDC-1.0
Sony Ericsson P900 phone’s SonyEricssonP900/R101 Profile/MIDP-2.0
browser Configuration/CLDC-1.0
Pocket PC PocketIE Mozilla/4.0 (compatible; MSIE 4.01;
Windows CE; PPC; 240x320)
PC w/Linux Opera Mozilla/4.0 (compatible; MSIE 6.0;
X11; Linux i686) Opera 7.23 [en]
PC w/Windows XP Mozilla Mozilla/5.0 (Windows; U; Windows NT 5.1;
Firefox rv:1.7.3) Gecko/20041001 Firefox/0.10.1
The user agent string holds a lot of information and therefore we do not need to
use the whole string as a key. Instead, we could use regular expressions to rep-
resent the user agent strings. Regular expressions are special text strings for de-
scribing search patterns. Plenty of information on regular expressions is available
on the Internet1
. A Regular expression could cover only the part of a user agent
string that is needed to uniquely identify a device. For example, a regular expression
“.*?Nokia3650.*?” matches only with user agent strings containing the string
“Nokia3650”. Furthermore, if we look at user agent strings in Table 3.1, we see a pat-
tern emerging, at least, when Nokia’s Series 60 phones (Nokia 3650 and Nokia 7610)
are considered. For example, the regular expression string “.*?Series ?60.*?”
matches to all Nokia’s Series 60 mobile phones This is a good way to reduce the
number of needed regular expressions. All Nokia’s Series 60 phones can be grouped
together because they all have the same display dimensions (176 pixels wide and 208
pixels tall screen). Instead of using individual identifiers for all Series 60 phones we
are able to use just one identifier for the whole group. It is possible to use even more
general identifiers, such as the operating system and browser. These “default” iden-
tifiers should only be used as a fall-back, i.e. if some device’s identifier is not on the
list, we can take a guess based on its operating system. For example many Series 60
mobile phones use Symbian OS and therefore a suitable fall-back regular expression
string for them would be “.*?Symbian ?OS.*?”.
1
http://www.regular-expressions.info/
20. CHAPTER 3. MOBILE FRIENDLY FEATURES 14
At this point we have individual, group and “global” identifiers for different devices.
These identifiers should be placed in a table structure in an order where first comes
the individual identifiers and then the more general identifiers. This is necessary (if
the table is searched from beginning to end without any wiser algorithms) because
in the case of a “global” identifier coming first, it would likely match with a huge
number of devices. Furthermore, this would result in errors because not all devices,
e.g. devices using Symbian OS, have the same display dimensions. Another reason
for keeping the identifiers in a strict order is that groups may have exceptions, i.e. not
all devices belonging to a certain group necessarily have the same display dimensions,
and therefore the group identifiers must not come before the individual identifiers.
Based on the ideas given above the actual process of identifying a mobile device and
sending suitable content back to it would be something like the following (Figure 3.1
illustrates the process):
Figure 3.1: Adjusting content based on recognized devices.
21. CHAPTER 3. MOBILE FRIENDLY FEATURES 15
1. The device requests a webpage from the server.
2. The server finds out device’s user agent string.
3. The server tries to match the user agent string against known identifiers.
4. The server chooses suitable layout to use based on the results from the user
agent string matching.
5. The server sends the webpage to the device.
3.3 Layout
Usually the basic layout structure of a webpage is a narrow pane on the left edge of
the page for menu items, and the rest of the screen is occupied by the actual con-
tent. Sometimes there may also be another narrow pane on the right edge of the page
containing possibly more menu items, a poll, links, site related news, etc. Figure 3.2
shows a typical layout with three panes. It is a screenshot from an open source CMS
(Content Management System) software called Mambo Open Source. To show this
kind of pages on mobile devices it is necessary to divide the page into two or three
sections. The main content forms one section and the panes on the sides of the page
form the other, one or two, sections depending on the situation. In cases where only
Figure 3.2: Front page of Mambo and its three-column layout.
22. CHAPTER 3. MOBILE FRIENDLY FEATURES 16
one section besides the main content is desired, left and right panes can be tiled one
above another to form that one section.
Mobile devices come with varying sized displays. Table 3.2 lists dimensions of
multiple devices measured in pixels. As can be seen from the table, the smallest
devices have a very small screen compared for example to a regular desktop monitor.
Nokia’s Series 60 mobile phones have only 176 pixels wide display, which is just
about a quarter from the standard VGA resolution (Video Graphic Array resolution
is 640x480 pixels). Due to the variable display sizes, the designed layout must be
flexible in a way that it can smartly fill the available area given to it regardless of the
display width.
Some mobile browsers have built-in functionality (e.g. Opera’s Small Screen Render-
ing) that tries to alter the structure of a webpage so that it would fit to the display and
still be legible. We could say this is “filling the available area somewhat smartly and
automatically”. This might be something that most website designers would want to
avoid, because it can possibly destroy the designed look of their site. Therefore, web-
site designers should take mobile devices into consideration when designing a layout
for a website. One layout should be designed for mobile devices and one for desktop
browsers, or if possible, one very flexible layout to cover them both.
What does the phrase “to smartly fill the available area” really mean and how could it
be done? This is one of the main questions of this project. In short, it means that users
can easily view a good looking webpage in their browsers and only need to scroll the
page in the vertical direction. This is what users are used to do with their desktop
browsers. Rarely do they have to scroll horizontally and even then it is probably
because of the inferior design of a website.
Table 3.2: Display dimensions of multiple devices.
Device Display Dimension (pixels)
Sony Ericsson T610 128x160
Samsung SGH-P510 128x160
Samsung SGH-Z105 176x192
Nokia 3650 176x208
Nokia 7610 176x208
Sony Ericsson P900 208x320
HP iPAQ h2215 Pocket PC 240x320
Toshiba Pocket PC e800 240x320
Nokia 7700 640x320
Desktop Computer e.g. 1600x1200
23. CHAPTER 3. MOBILE FRIENDLY FEATURES 17
The basic idea in optimizing the screen usage is that first everything has to be squeezed
into a small space and when the display size increases, the content and the elements
are adjusted accordingly. Some elements, like headers and text paragraphs, are com-
pressed and expanded automatically by the browser to the extent possible. Some other
components, however, need the programmer’s attention. These include broad text
fields and areas with fixed size, buttons with long texts, tables with multiple columns,
big images, etc. One possibility is to construct these components with the principle
“one size fits for all”. With this approach we should follow the limitations set by the
narrowest display. Another possibility is to make the components dynamic in a way
that their width changes in accordance with the width of the present device’s display.
Tables may cause some trouble that should be resolved by modifying their structure
or by removing them completely and using CSS instead. If the removal and CSS are
not an option, probably the best thing would be to move adjacent table cells to con-
secutive rows. That will cut down enough the space the table is taking, but it also may
reduce the legibility of the table at the same time. To maintain the legibility it would
be beneficial to insert some kind of a separator between groups that consist of cells
belonging logically together.
3.4 Images and Bandwidth
Images are a major usability concern when dealing with mobile devices. Usually
the pictures are far too big to fit on the small screen of a mobile phone or a PDA.
Also, as mobile networks offer very limited bandwidth, a webpage containing images
downloads considerably slower than the same page without the images. There are,
however, some ways to deal with this problem.
The easiest and most obvious solution is not to download any images at all. This cer-
tainly solves the problem with bandwidth but considering the use of the page, espe-
cially if the website uses images as navigational links, it may not be the best solution.
(This is not a very good design practise and you should avoid it if at all possible. Even
more so, if you intend your pages for mobile audiences as well.) Other image hand-
ling option utilized by mobile browsers is to download only selected images. This
option is not very useful though as usually there is no way for the user to know what
size the image is or what is its importance considering the information on the page.
Some browsers, such as Opera, offer a third choice: automatic image scaling to make
the images fit on the screen. If we think the usability of this solution from the layout
24. CHAPTER 3. MOBILE FRIENDLY FEATURES 18
point of view only it seems rather good. However, there is still the issue with band-
width. The full image needs to be downloaded before scaling can be done. And then
there is a new concern: the scaling takes time and reduces the battery life of the mo-
bile device. So, we see that although scaling images on the mobile is a step towards a
better user experience it is still far from truly being called mobile friendly.
For a website to be mobile friendly we require, that considering the restrictions on mo-
bile devices, the mobile user experience is as close as possible to the user experience
offered by a desktop browser.
With current mobile devices and their capacities, mobile friendliness in the case of im-
age and bandwidth issues, can only be achieved through server-side solutions. Some
of the options available to the mobile users were mentioned in section 2.5. The prob-
lem with all those solutions is that they are either mobile network operator specific,
they cost, or they might require extra software to be installed on the mobile device.
True mobile friendliness must be implemented within the website itself. Compared
to a third party “mobile friendlifying” service, the in-house solution has the added
benefit of knowing the structure and semantics of the site so more intelligent choices
can be made in making the page mobile friendly.
When the site detects a mobile user agent, images must be scaled down to a proper
size according to the user’s display size. Images can be scaled on the fly or different
sized versions can be stored on a server. Alternatively, if images are not essential,
they can be left out altogether. In Chapters 5 and 6 we show how this can be added to
existing systems. Implementing a mobile friendly web service is even easier if mobile
users are taken into account right from the start of the design process.
The numbers of Internet enabled mobile device owners are growing rapidly. We be-
lieve that it is in the interest of (commercial) web services to make their sites mobile
friendly. This should be done without any extra charges for the mobile users or re-
quiring them to use some third party “mobile proxy” service.
3.5 Mobile Friendly Web Services
Now that we have defined the solutions for the problems presented in Chapter 2, we
need to test them in practise. We want to know whether it is possible to recognize
mobile devices and based on that scale the web site content automatically and alter
the layout to be suitable for mobile devices. We could start off by writing our own
25. CHAPTER 3. MOBILE FRIENDLY FEATURES 19
software from scratch and design a very sophisticated support for mobile devices into
it. Another way, that we decided was the best approach for us, is to use some popular
open source programs and integrate mobile friendly features into them. This way we
will save the time in actually implementing the whole functionality of the software.
After some research we decided to use Gallery and LiveJournal. When choosing
the web services one important criteria was their popularity. Another criteria was
that once completed, would these software products add value to the use of mobile
phones, i.e. what good would they offer to the mobile users. Gallery (over 100,000
installs) is a photo hosting service and a mobile friendly version would naturally be a
valuable service for camera phone owners because you can upload pictures you have
taken straight from your mobile to the web service. LiveJournal (over million active
users) is a blogging service and the possibility to update one’s journal or diary from
anywhere at any time using a mobile device would be a benefit for the user.
Both of these services would be good examples on how to increase the value of us-
ing mobile devices, if we succeed in modifying them to be mobile friendly. Also,
because open source is considered, we will not be completely satisfied even though
we do get these mobile friendly features implemented, unless we are able to get the
modifications to be part of the official distribution packages of these programs.
Chapters 5 and 6 describe how Gallery and LiveJournal, respectively, were made mo-
bile friendly. Both Gallery and LiveJournal are open source software and therefore
the next chapter gives an introduction to open source. The chapter can be skipped if
the open source concept already is familiar.
26. Chapter 4
Open Source Software
What is open source? Many people seem to think it is just a free access to software
products. While it is true that open source means a free access to software’s source
code, there is also a more complex side to it, i.e. what are the limitations and respons-
ibilities when using and distributing open source software? How open source software
can be distributed, is determined by a license attached to the software by its original
developers. There exist various open source licenses which all have to fill completely
the criteria of the Open Source Definition (OSD) [30]. Besides the matters described
above, this chapter also takes a look at open source software development and some
successful open source projects.
4.1 The Open Source Definition
Working in software development and using source code of a another program written
by someone else is something that brings up legal issues about immaterial rights, such
as who owns the source code and how the code or the modified version of it should be
distributed. It is good to know your rights when it comes to dealing with source code
that is not yours.
Proprietary software, shareware, freeware, free software, public domain, copyleft, and
open source are terms that one eventually runs into in open source software develop-
ment. In order to understand what open source means precisely, it is necessary to
know the meanings of these terms. In the following a short explanation on each of the
terms is given [13].
27. CHAPTER 4. OPEN SOURCE SOFTWARE 21
Proprietary software is copyrighted. No source code is provided with the release nor
by other means leaving the customer with no possibility to modify the software. The
only people with an access to the source code are the ones working with the project in
the corporation who owns the copyright. This is the traditional way for commercial
projects to release their software.
After the release of a shareware software it is available to anyone with no initial cost.
However, if anyone decides to continue to use the software after its free trial period
has expired, a reasonable price for a license has to be paid. Shareware software can
be redistributed to other users while the license is not passed along with it. There
also exists a shareware derivative software type called crippleware. It is released with
some of its functionality pruned. When someone decides to pay the license for it,
he gets access also to the originally deactivated functionality. The source code is not
usually released with this type of software.
Freeware is equal to shareware without the exception that users do not have to pay for
the license at any point. Freeware gets easily mixed with free software even though
they are two different cases.
Free software licensing aims to guarantee access to the source code. Therefore it is not
the same as freeware. It gives the rights for everyone to use, modify and redistribute
the software in any way they choose. However, distributors are also obligated to give
the same access to the modified source code and the license must remain unchanged.
Free software is often confused with public domain.
Software released in the public domain has no restrictions because nobody owns a
copyright to it. To be more specific, there is no copyright. This means that anyone
can use, modify and redistribute the software in anyway one chooses. Furthermore, it
is even possible to charge for the original software without any obligations to give the
source code for free.
Copyleft was originally Richard Stallman’s idea to address the problems releasing a
software in public domain, which makes the software lose its copyright. Copyleft does
not remove software’s copyright but instead it adds specific distribution terms. Alto-
gether it says that copylefted software may be used, modified and redistributed, with
or without changes, as long as the distribution terms follow the software unchanged.
Open source goes alongside with free software. They both want to ensure that the
source code remains free and available to everyone, but open source can be considered
to be more commercial-friendly. For example, an open source license called GNU
28. CHAPTER 4. OPEN SOURCE SOFTWARE 22
Lesser General Public License (LGPL, section 4.2) allows source code licensed under
it to be used in products that are not open source. The open source definition, released
by Open Source Initiative (OSI), is a list of criteria which a license has to fulfill in
order to be an open source license. The ten most important parts of the open source
definition will be explained in the following [30].
Free Redistribution. The first requirement of the definition concerns one of the most
important characteristics of open source. The clause says that open source software
must be redistributed freely, which means the license can not restrict selling or giving
away the modified software nor require any royalties or other fees for it. However,
this does not say that you can not charge for example for your customer support or
printed documentation of the software.
Source Code. The second clause is about the software’s source code. It requires
that the source code must be obtainable for free, e.g. preferably downloadable via the
Internet. Furthermore, the distributed code must not be deliberately obfuscated.
Derived Works. The third clause demands that the license must allow modifications
and derived works, and must allow them to be distributed under the same license that is
used with the original software. This clause, together with the second one, guarantees
access to the software’s source code and allows it to be modified. Therefore it is
possible that open source software can be developed by anyone.
Integrity of The Author’s Source Code. The next part deals with the integrity of the
author’s source code. It says that the license may restrict source code from being
distributed in a modified form. However, it must allow distribution of patch files.
This gives users a possibility to know who is responsible for the software they are
using.
No Discrimination Against Persons, Groups nor Fields of Endeavor. The fifth and
sixth clauses require that the license must not discriminate against any persons or
groups nor the place where it is used. These clauses guarantee that open source soft-
ware can be used by anyone in any group and in any business branch.
License Features. The last four clauses are all concerning features of the license. The
first one is about distributing the license. It says the rights attached to software must
also apply to all whom the software is redistributed to. The next one says the license
must not be specific to a product. By demanding this, the clause closes one class of li-
cense traps which are ways of questionably making open source software proprietary.
The third one requires that the license does not restrict other software. It means that
29. CHAPTER 4. OPEN SOURCE SOFTWARE 23
the license can not place any restrictions on any software that is distributed along with
the licensed software. The last clause says the license must be technology-neutral,
meaning that non of the license’s clauses may be based on individual technology or
style of interface.
As we can see the open source definition is quite complex and demands a lot from a
license. When designing a license that aims to be open source valid, one needs to be
very exact when writing the conditions and it is probably not a bad idea to have some
legal advice on as well. Each piece of software that is open source should have an
individual license attached to it to guarantee that the software remains open source.
Fortunately most open source licenses have been created as templates, where the user
can just fill in the software name and the copyright owner to have a valid open source
license for the software. This way programmers can use ready-made licenses and
do not have to waste time in creating one of their own from scratch. Programmers
can can pick up a license suitable for their software product for example from the
Open Source Initiative’s website1
that lists all the licenses OSI have approved as open
source licenses.
4.2 Popular Open Source Licenses
In this section we will describe the features of some of the most popular open source
licenses. We start with GPL and LGPL and then move on to BSD, MIT, and Artistic
License. All of these licenses protect the software with a copyright. To make a license
to be an open source license, copyright holders add copyleft to it, which means they
grant permission to copy, distribute and modify the software if certain conditions are
met.
GPL – GNU General Public License – was released by Free Software Foundation in
1989, and is today the most popular license used in open source projects. About 69%
of all 33,931 projects at Freshmeat.net and around 70% of all 53,345 Open Source
Initiative (OSI) approved projects at SourceForge.net use GPL [31][32]. The license
says that anyone may copy and distribute verbatim copies of the source code as long
as copyright notices and disclaimers are included unchanged. A fee may be charged
for physical distribution of copies or if one decides to offer warranty. The software
may be modified and then redistributed by anyone if the modified files are marked
1
http://www.opensource.org/licenses/
30. CHAPTER 4. OPEN SOURCE SOFTWARE 24
with the name and date modified. Also, the modified program, or the program the
modification is part of, must be licensed as a whole under GPL. The software, or a
work based on it, may be distributed and copied in object code or executable as long as
the complete corresponding source code is included in the distribution. A reasonable
fee can be charged based on the physical reproduction cost of the code. [29]
LGPL – GNU Lesser General Public License – was also released by Free Software
Foundation in 1991. It is the second most popular open source license at Fresh-
meat.net with 7.5% share, and at SourceForge.net with a share of 11% [31][32]. This
license is mainly intended for libraries. Like GPL it allows anyone to copy and dis-
tribute verbatim copies of the source code under the license. Also, a reasonable fee
may be charged for physically distributing copies or if one decides to offer warranty.
The library or any part of it may be modified. If the result itself is a library and
modified files are marked with the modifier’s name and date, the modification may
be copied and redistributed. It is possible to change the license type of a modified
library from LGPL to the ordinary GPL by simply replacing all notices referring to
LGPL with those of GPL. The library may be copied and distributed in object code or
executable form, provided the complete corresponding source code is also included.
Programs using LGPL libraries do not fall under LGPL as long as the programs are
only compiled or linked with the library, and therefore do not contain any portions of
the library. [29]
BSD License - Berkeley Source Distribution License was released by the University
of California, Berkeley, in 1998. The BSD License is almost as popular as LGPL.
At Freshmeat.net it is used in 5.6% and at SourceForge.net in 7.2% of all projects
[31][32]. This license’s clauses are easy to understand and there are just a few of them.
First it says that anyone can redistribute and use the source or binary forms, with or
without modifications as long as the license’s clauses are not broken. Clauses define
that copyright notice and disclaimer must be included with the redistributed software.
Furthermore, neither the copyright owner’s name nor the names of the software’s
contributors may be used to promote the product without written permissions from
original authors. Features of the MIT License, released by Massachusetts Institute of
Technology, and the BSD License are equal without the final no-promotion clause of
the BSD-license. [29]
Artistic License is the last example. It was released by Perl in 1987 but despite of the
releaser’s name, it is today widely used in various other projects as well. About 1.8%
of projects at Freshmeat.net and around 2.1% of OSI approved projects at Source-
Forge.net use this license to copyright their software [31][32]. The first clause says
31. CHAPTER 4. OPEN SOURCE SOFTWARE 25
that anyone may distribute verbatim copies of the original, unmodified, version as
long as they include copyright notices and disclaimers with the distribution. Anyone
may use patches derived from the copyright owner and the software is still considered
as original and unmodified. Anyone may modify the software provided they make a
notice of the changes they have made at the beginning of each modified file and, of
course, make the modified software freely available. It is also possible to use a modi-
fied version of the software within organizations or rename the whole software so the
names do not conflict with the original. Anyone may distribute binary or source form
as long as they provide the whole package, i.e. the original version must be included
with modified versions. Reasonable fees may be charged by anyone for physically
distributing the package or if they choose to support the package. Fees on the pack-
age itself may not be charged, though. Scripts and libraries supplied as input to or
produced as output from the package do not fall under the copyright of Artistic Li-
cense. C and Perl subroutines linked to this package and supplied by the distributer
of this package are not considered as part of the package. The name of the copyright
owner may not be used to promote products derived from software under this license
without written permission from the original authors. [29]
Choosing the right license for your own open source software may be difficult, but
it is something that has to be done. Also, when you take an open source software
package and modify it to suit your needs, you will need to know what are the rights
and responsibilities defined by the software’s license. Table 4.1 summarizes important
features of licenses that have been discussed in this section including GPL, LGPL,
BSD, MIT, and Artistic License. Some other popular licenses, such as QPL (Qt Public
License), MPL (Mozilla Public License), IBM Public License, and Apache Software
License are presented as well. Though it is easy to see from the table what are each
licenses’ features, one should still always get to know the original license thoroughly.
Working with a license whose conditions are not familiar may lead into trouble. The
following will explain the meaning of each column in the Table 4.1 [5].
Possible to link with proprietary software. For example, according to the terms of
GPL, if you mix code published under GPL to your software, you must distribute
your software under GPL. It does not matter whether your software already is open
source or whether it is proprietary, from there on it is open source under GPL. This
kind of licensing is not beneficial for commercial software and because of it, other
licenses have been created which do not include this requirement.
If software is published, modified source code must be redistributed. A free software
license requires always that if any modifications have been made to the source code,
32. CHAPTER 4. OPEN SOURCE SOFTWARE 26
Table 4.1: Features of popular OS licenses. Slightly modified from [5].
Possible to If software Modifications Can GPL
link with is published, can be prohibit compatible
proprietary modified source forked to commercial
software code must be proprietary sale
redistributed
GPL no yes no yes yes
LGPL yes yes no yes yes
BSD yes no yes no yes
MIT yes no yes no yes
Artistic License yes no yes yes yes
QPL no yes no yes no
MPL yes yes yes no no
IBM Public License yes no yes no no
Apache Software License yes no yes no no
it must be redistributed. Open source licenses have provided some relaxation for this
requirement by not demanding the redistribution of modified source if certain condi-
tions are met. For example, open source software can be modified, but the modified
source does not need to be redistributed if the software is kept private or within an
organization, i.e. the software is not published.
Modifications can be forked to proprietary. This is another major difference between
open source and free software. Most free software products are copylefted and by that
they disallow the possibility to turn them to proprietary. Open source, however, leaves
it for licenses to decide whether to allow forking or not. If it is allowed, the software
can be modified and made proprietary.
Can prohibit commercial sale. This option is important for companies who plan to
release both commercial and non-commercial versions of their software. If the license
does not prevent commercial sale, the copyright owner can release a commercial ver-
sion of the program in addition to the open source version. The license prevents
subsequent developers from commercially distributing the open source version of the
software.
GPL compatible. If any code is mixed with code that is licensed under GPL, the
result will be all GPL as the GPL demands. When a license announces that it is GPL
compatible, it means that the software under the license can be relicensed to GPL. In
other words, source code that is not published under a GPL compatible license can
not be joined with GPL licensed source code.
33. CHAPTER 4. OPEN SOURCE SOFTWARE 27
4.3 OSS Projects
Open source software is free and anyone can obtain their own copy of the source
code with no charge (except the almost non-existent cost of an Internet connection).
Open source projects can be found best by visiting some web services hosting these
projects. Probably the most known ones of these are SourceForge2
and Freshmeat3
,
which were already mentioned in section 4.2. Together they host over 115,000 open
source projects with over 1,100,000 registered users [32][31]. Besides SourceForge
and Freshmeat, there are other similar services including BerliOS Developer4
with
just over 1,500 projects, and Open Source Directory5
with about 700 open source
projects [28][1].
While most open source projects remain unknown to the general public, there are
some that really have made their way through and some of them are even making
money. Some of the well known open source projects include Apache, Linux, and
MySQL. Apache is a web server software that started to gain much reputation during
1995 and by the end of the first quarter of 1996, its market had closed up the gap
with Microsoft’s web server. From there on Apache has been the leading web server
software and it has gained a market share of 67.2% (Figure 4.1) [25].
Linux is probably the best known open source project. It is an operating system
that was released by Linus Torvalds in 1991. Since then many programmers have
made their own contributions for Linux development. Gradually Linux has gained
reputation as a good and stable operating system and has become more and more
used amongst academic society and Internet service providers [13]. The most popular
open source database is MySQL. Its market share is still far from its commercial rivals
Oracle, IBM and Microsoft databases but it is still used by some big companies [7].
Just to mention a few, MySQL is used by Yahoo!, Google, Cisco, Sabre Holdings, HP,
and NASA [24].
2
http://sourceforge.net/
3
http://freshmeat.net/
4
http://developer.berlios.de/
5
http://osdir.com/
34. CHAPTER 4. OPEN SOURCE SOFTWARE 28
Figure 4.1: Market share development of web servers.
4.4 Development of OSS
Open source software can be developed using varying development models but even-
tually they all can be categorized to be either the cathedral model or the bazaar model.
The names cathedral and bazaar come from Eric S. Raymond’s essay on open source
software engineering methods. Raymond talks about his observations on the Linux
kernel development and his experiences on managing an open source project [36].
Before Linux, which uses the bazaar model, the cathedral was the prevailing model.
According to Eric S. Raymond’s essay, he thinks that Linus Torvalds is the inventor
of the bazaar model.
One notable difference between the bazaar and the cathedral model is how often the
software is released. Cathedral projects believe that releasing source code early, be-
fore it is tested properly and seen to be quite stable, is a bad policy because early
versions most likely contain more than just a few bugs and it would wear out the pa-
tience of users. Operating quite opposite to the cathedral model, the bazaar model
endorses releasing early and releasing often. The advantage of this style compared
to the cathedral model is that projects get feedback about bugs also from the users
instead of just getting it from the developer team. In his essay Raymond defines the
“Linus’s law” which says that “Given enough eyeballs, all bugs are shallow”. It means
that when the source code is publicly available, like it is in the bazaar model, there are
35. CHAPTER 4. OPEN SOURCE SOFTWARE 29
more people testing the software and therefore bugs will be discovered and reported
considerably faster than in the cathedral model. [36]
What if there are not enough “eyeballs” available, will the bugs be discovered any-
way? This kind of situation can occur when a community around an open source
project has not grown much. This may reduce the quality of source code because
bugs and errors are detected with a much lower rate than what it would be with larger
communities. Therefore, it can be said that the quality of open source software is
not necessarily any better than it is with proprietary software. Eventually the quality
of source code depends on used person hours which can be much greater with large
communities than with proprietary software or small open source projects. [36][12]
Today, partly because of being inspired by Raymond’s essay and the fact that the
bazaar model actually works, most open source projects that used to use the cathedral
model now use the bazaar model. Also, the majority of newly launched open source
projects have adopted the bazaar model. For a contrast, the typical development model
for proprietary software projects would be, without an exception, the cathedral model.
Naturally, most of the time these projects do not publish the source with the release
of their proprietary software. [36]
Open source is open for all and therefore anyone can pick up a project for example
from SourceForge.net and start working on their own modifications. This naturally
leads to a situation where popular open source projects are being developed all over
the world by different individuals who have never even met each other. As arranging
meetings would be difficult and expensive, most open source projects use the Internet
as a medium to discuss and inform others about the changes concerning the project.
The informing can be done using a simple bulletin board website that is dedicated
for the project. The projects that need more interaction between developers, need a
more sophisticated method of communication. These methods include newsgroups,
mailing lists, communities, and forums. Communities and forums are pretty much
the same and one of them can usually be found from the project’s website. They are
meant to be a place for the project related discussion where people can comment on
entries submitted by others, inform about bugs, ask installing or usage instructions,
etc. Communities and forums seem to be used mainly by larger projects with many
developers and users, while newsgroups and mailing lists seem to be used by smaller
projects.
Open source projects are started mainly by one person or a small group of people.
Mostly their common interest is to create something they would need. Initially this
36. CHAPTER 4. OPEN SOURCE SOFTWARE 30
core group of people, or one person from it, becomes the maintainer of the project.
When a project grows larger it is the maintainer’s job to decide which patches, sent
by other developers, get accepted to the software and which ones do not. When the
project maintainer loses his interest over the project or has a lack of time, his final
duty is to appoint a successor. The successor is usually nominated amongst those who
have made significant contributions for the project and of course is willing to accept
the responsibility.
37. Chapter 5
Case Study: Gallery
We chose Gallery as one of our research subjects because of its popularity and for
its obvious value to the camera enabled mobile phone users. Also, Gallery has active
developer and user communities around it who are continuously making Gallery a
better product. This made Gallery an even more attractive option as one of our aims
was to see how we could make the ideas of mobile friendliness better known and
applied in open source software projects. We started working with Gallery 1 and soon
expanded to Gallery 2 that was still in its beta phase at the time. At the time of writing
this, Gallery 2 Alpha 2 has just been published.
5.1 Overview
Gallery’s homepage1
describes the program as follows: “Gallery is a web based soft-
ware product that lets you manage your photos on your own website. You must have
your own website with PHP support in order to install and use it. With Gallery you
can easily create and maintain albums of photos via an intuitive interface. Photo
management includes automatic thumbnail creation, image resizing, rotation, order-
ing, captioning, searching and more.” The administrator of a Gallery installation can
create multiple user accounts with different permissions on a per album basis.
The Gallery project was started in June 2000 by its main developer Bharat Mediratta.
The current version (as of 2004-08) is 1.4.4 and Gallery has a big user base with over
100 000 installs, according to their own statistics. Gallery 1.x is still under active
1
http://gallery.menalto.com/
38. CHAPTER 5. CASE STUDY: GALLERY 32
development and new features are added all the time but at the same time a new
version, Gallery 2, is being developed. Gallery 2 is a complete rewrite of the program
with a new extensible and modular architecture along with some new features. We
will discuss more about the differences later in this chapter. The development of
Gallery 2 has been going on for about two years now and the first public release, 2.0
Alpha, was made on July 18, 2004.
5.2 Programming Languages
Both Gallery 1 and Gallery 2 are programmed in PHP. Gallery 2 also uses a PHP based
Smarty template system to separate the user interface and the logic of the program.
As all data in Gallery 2 is stored in a database, SQL is needed to query the data.
5.2.1 PHP
PHP2
is a very popular general-purpose scripting language that is especially useful
for web development [15]. The name of the language is a recursive acronym for PHP:
Hypertext Preprocessor. PHP can be used on its own (command line scripting) or it
can be embedded in HTML pages (server-side scripting). Figures 5.1 and 5.2 illustrate
the differences between these two methods of using PHP with a familiar Hello World
program. Both examples are fully functional PHP programs and their outputs are
exactly the same.
While PHP alone is enough for command line scripting, server-side scripting requires
a web server. PHP can work with the web server in two ways: as a server module or
CGI (Common Gateway Interface) processor. PHP has a direct module interface for
many popular web servers such as Apache and Microsoft IIS (Internet Information
Server).
One of the most important features of PHP is that it supports a wide range of data-
bases. This allows easy creation of dynamic webpages. The supported databases
include dBase, IBM DB2, Ingres, mSQL, MySQL, Oracle, PostgreSQL, and many
more. PHP also supports ODBC (Open Database Connectivity), an open standard
database access method to connect to different databases without a database specific
client software.
2
http://www.php.net/
39. CHAPTER 5. CASE STUDY: GALLERY 33
1 textbferer
2 <?php
3 $hello = ’Hello World!’; $
4 echo "<html>n<head><title>Hello</title></head>n";
5 echo "<body>n$hellon</body>n</html>";
6 ?>
Figure 5.1: Hello World example, pure PHP code.
1 <html>
2 <head><title>Hello</title></head>
3 <body>
4 <?php
5 $hello = ’Hello World!’;
6 echo $hello;
7 ?>
8 </body>
9 </html>
Figure 5.2: Hello World example, embedded PHP code.
5.2.2 Smarty
Gallery 2 makes extensive use of a Smarty templating engine. Smarty [27] is a PHP
based templating system that is designed to make it easy for web developers and
website designers to separate the layout and the look of a page from the site’s logic.
Figure 5.3 shows a simple Smarty template and Figure 5.4 illustrates how the template
is used in a program.
Using templates has many benefits over the traditional method of printing the HTML
in the application code. The first advantage is that it makes the programmers’ task
easier as they do not need to worry about the presentation layer and the code is easier
to read as well when all the HTML is somewhere else. Secondly, the designers can
modify the layout and presentation without making any changes to the application
code. Actually, the designers do not even need to know PHP.
The third benefit is the close relationship that templates have with the actual page
output. Compared to mixing the application code with the HTML markup, the page
layout is a lot easier to design with a template as it closely resembles the final out-
put. Other advantages Smarty offers include a built-in debugging console and easy
extensions through plug-ins.
The first time a template is used Smarty compiles it into PHP code thus saving the
time used to parse the template on every consecutive request. The page output can
cached too, saving even more time. Even just parts of single page can be cached.
40. CHAPTER 5. CASE STUDY: GALLERY 34
1 <html>
2 <head><title>Message</title></head>
3 <body> My message today is: {$message} </body>
4 </html>
Figure 5.3: simple.tpl - a simple Smarty template.
1 <?php
2 include ’Smarty.class.php’;
3 $smarty = new Smarty;
4 $smarty->assign(’message’, ’Hello world!’);
5 $smarty->display(’simple.tpl’);
6 ?>
Figure 5.4: A simple program using the Smarty template.
5.2.3 SQL
Structured Query Language (SQL) is a computer language for accessing and manipu-
lating relational databases. It is an ANSI3
/ISO4
standard and is supported by virtually
all major databases. For more information and examples see W3 Schools’ online SQL
manual5
.
Gallery 2 module developers do not need to write any SQL queries themselves as the
Gallery framework does it for them. This will be covered in more detail in section
5.3.2. Gallery 1 does not use a database and therefore SQL is not needed there either.
5.3 Architecture
We wanted to make mobile friendly modifications or modules to both Gallery 1 and
Gallery 2 so it was necessary to get to know the structure of both of the programs.
When we started our project Gallery 2 was still under heavy development and chan-
ging often so we begun our work with Gallery 1.4. Later when Gallery 2 had reached
a more stable condition we started working with that also. In this section we will
outline the structure or architecture of both of the Gallery versions.
3
http://www.ansi.org/
4
http://www.iso.org/
5
http://www.w3schools.com/sql/
41. CHAPTER 5. CASE STUDY: GALLERY 35
5.3.1 Gallery 1.x
Gallery 1 grew out of the need to have an easy way to publish online pictures taken
with a digital camera. In the beginning it was just a small script for sharing photos
with a few people. New features were added one by one as they were needed. As a
direct result of this the program lacks of any real architecture.
Functionality
The functionality of Gallery 1 consists of small scripts such as login.php, search.php,
view_album.php, and add_photos.php. Each of the scripts implements one logical
function in the gallery. For example, login.php implements the process of prompting
the user for the username and password, checking their validity, and logging the user
into Gallery. albums.php is the file that takes care of rendering the HTML for the
Gallery’s main page whenever a user browses there.
The first thing all the scripts do before their own functionality is to initialize the Gal-
lery. All work that is needed to set up the Gallery is done in the init.php file. This
loads the utility functions in util.php, the proper file system functions depending on
the platform (Unix or Windows), and the current installations configuration inform-
ation in config.php. During the initialization the different classes such as Album and
User get loaded as well as the session information and the language settings.
Layout and Themes
One of the main problems with Gallery 1 is that the layout is not clearly separated
from the program logic. All the different functions render most of their HTML code
themselves. The rest of the layout code is in the html, html_wrap, and layout direct-
ories. The navigation images and other symbols are in the images directory and the
default style files are in the css directory.
Users can create their own themes of skins. Skins are CSS files that override the
default values and attached image files. They are all located in subdirectories under
the skins directory. Gallery 1 comes with about twenty different skins of which the
installation’s administrator can choose the one she likes or create a new one herself.
42. CHAPTER 5. CASE STUDY: GALLERY 36
Data Storage
All user data (usernames, passwords, email addresses etc.) and the images are stored
in an installation specific directory. Under that directory, albums have their own sub-
directories where all images and sub-albums belonging to that album are kept.
In the user data directory there is a file called albumdb.dat that contains the name of
each top level album. Under each album directory there are the files album.dat and
photos.dat. These files hold all the album details and photo properties respectively.
Each of these .dat files is a serialized version of a PHP object. In essence a serial-
ized object is a string representation of the object’s value and it can be easily stored
anywhere.
5.3.2 Gallery 2
As new features were added to Gallery 1 it grew bigger and more complex and difficult
to maintain and develop because of the lack of proper architecture. At that point the
developers decided to write everything again from scratch but this time plan it ahead
and create a solid, modular and extensible architecture for Gallery. The result of this
work is Gallery 2.
MVC Pattern
Gallery 2 uses several design patterns and coding methodologies to make the system
easier to implement and understand [23]. The main design pattern is the Model-View-
Controller (MVC) pattern. MVC pattern’s basic principle is to separate data from the
logic and display.
Model or data in Gallery 2 is a relational database where all the information is stored.
Currently Gallery 2 supports MySQL, PostgreSQL, and Oracle databases but sup-
port for different databases can be added relatively easy. Data is then processed by
controllers and finally presented to the user through a view i.e. the user interface.
Figure 5.5 clearly shows how the data is only accessed through the Gallery Core
API (Application Programming Interface), the modules do all the processing, and in
addition to the theme CSS files, all output to the browser goes through the main.php
file.
43. CHAPTER 5. CASE STUDY: GALLERY 37
Figure 5.5: The top level architecture of Gallery 2. The diagram is slightly modified from [22].
Gallery 2 Is Modular
All functionality in Gallery 2 is implemented using modules. The core module provides
the framework and some basic functionality like creating users, creating albums and
viewing images. All other functionality, such as search, commenting, and slide show,
which are not essential, are provided as separate modules. The administrators of the
Gallery installations can install and then activate or deactivate any combination of
modules they wish.
44. CHAPTER 5. CASE STUDY: GALLERY 38
The only mandatory thing for a module to have is a file called module.in that should
define a class extending the GalleryModule class. This class contains all the necessary
functionality to install and initialize the module so that the services provided by the
module can be used.
Gallery framework provides two classes called GalleryView and GalleryController.
The various modules of Gallery 2 must extend (implement) these classes in order to
process user input and render HTML to the browser.
Other Design Principles
Other patterns or methodologies that Gallery 2 uses are templates, redirect-on-post,
locking, and code generation, among others. The reason behind many of these prin-
ciples is to protect the data integrity. Another motivation is the easier maintenance
and updating of the code base.
Templates are used to help separate the logic from the user interface. Specifically
Gallery uses the Smarty template engine that was described in section 5.2.2. It is a
powerful templating system that allows modifications to the existing pages and the
designing of new templates without needing to change the application code. The
template designer does not even need to know any PHP.
Redirect-on-post means that every time an operation is used that changes the data
model (e.g. an album is renamed or a picture is deleted), the user is redirected to a new
page, providing the operation was successful. This ensures that possible reloading of
the page does not have any unwanted effects. In cases like viewing an image where
the the model does not change the redirect is not used. Locking is also used to ensure
that the data does not get corrupted. Before any changes are made to an item, a lock
must be acquired for that particular item and in some cases for its parent items as well.
This guarantees that only one operation at a time can be performed on any object thus
securing the data integrity.
Code Generation
A good example of striving towards easier maintenance and a more robust product is
the code generation. All Gallery entities such as users, albums, and images have XML
code embedded in their class definition comments marked with special tags. Figure
5.6 shows a partial class definition as an example.
45. CHAPTER 5. CASE STUDY: GALLERY 39
1 /* Abstract base class for all objects in the Gallery composite tree.
2 *
3 * @g2 <class-name>GalleryItem</class-name>
4 * @g2 <parent-class-name>GalleryFileSystemEntity</parent-class-name>
5 * @g2 <schema>
6 * @g2 <schema-major>1</schema-major>
7 * @g2 <schema-minor>0</schema-minor>
8 * @g2 </schema>
9 * @g2 <requires-id/>
10 */
11 class GalleryItem_core extends GalleryFileSystemEntity {
12 /* Can this item contain children?
13 * @g2 <member>
14 * @g2 <member-name>canContainChildren</member-name>
15 * @g2 <member-type>BOOLEAN</member-type>
16 * @g2 </member>
17 * @var int $_canContainChildren
18 * @access private
19 */
20 var $_canContainChildren;
Figure 5.6: Class definition with @g2 special comments.
The comment lines with @g2 tags are then stripped from the file and we get the XML
code shown in Figure 5.7. When this XML code is wrapped inside a <class> tag
and a document type declaration (DTD) is added, we have a well-formed XML doc-
ument. Together with the actual class definition the XML code can now be used to
generate an interface class with all the necessary get and set methods. In addition,
Gallery automatically generates the database definitions and access scripts so that the
developers do not need to write a single SQL command themselves. The XML code
can also be used to generate UML diagrams.
1 <class-name>GalleryItem</class-name>
2 <parent-class-name>GalleryFileSystemEntity</parent-class-name>
3 <schema>
4 <schema-major>1</schema-major>
5 <schema-minor>0</schema-minor>
6 </schema>
7 <requires-id/>
8 <member>
9 <member-name>canContainChildren</member-name>
10 <member-type>BOOLEAN</member-type>
11 </member>
Figure 5.7: XML stripped from the class definition code.
46. CHAPTER 5. CASE STUDY: GALLERY 40
A Sample Workflow
We use the following URL to demonstrate how Gallery 2 works.
http://example.com/g2/main.php?g2_view=core:ShowItem&g2_itemId=8
Parameter g2_view tells Gallery that it must show a view specified by the value
of this parameter. The value, core:ShowItem, means that the intended view is
located in the ShowItemView class in core module.
Gallery then loads the view and passes the rest of the parameters to it. g2_itemId
is, clearly enough, the id number of the item the user is requesting to see. In this case
it would be an album. The view loads the album and renders it on the screen based on
the album’s settings.
Another important parameter that could be used is g2_controller. This tells
Gallery which controller to use to process the user input. Controllers are used every
time when the model is updated (data is added, removed, or modified).
5.4 Community
Gallery has a very active community of developers and users around it. The com-
munication takes place in the discussion forums, the developer mailing list (gallery-
devel@lists.sourceforge.net), and the IRC channel (#gallery). The Gallery website6
gathers all these resources, plus some more, together in one place.
Developers
Gallery project’s Source Forge page7
lists 28 developers, some working with Gallery
1 and some with Gallery 2. The development team has many other responsibilities in
addition to writing the code. Some of them manage the project, some do testing, some
user support, while others write documentation and moderate the discussion forums.
Members of the core development team seem to be very committed to the project,
contributing at least 5-10 hours a week each to work with Gallery. This commitment
can be seen by the fast development and quick replies in the discussion forums when
users ask questions or comment the product.
6
http://gallery.menalto.com/
7
http://sourceforge.net/projects/gallery/
47. CHAPTER 5. CASE STUDY: GALLERY 41
Discussion Forums
The discussion forums are an integral part of the Gallery user community. In the
forums users can ask questions, report problems, and give feedback. There are (in
September 2004) over 20 000 registered users who have sent almost 100 000 messages
to the forums.
There are forums for many different subjects. Some are for Gallery 1 and some for
Gallery 2. Within just these groups there is a variety of subjects, such as Installation
and Configuration Help, Customizing Gallery, Suggestions and Feedback, G2 Gen-
eral Development, and G2 User Interface. In addition to these, there are forums for
discussion on embedding Gallery into other applications and translating Gallery to
other languages and much more.
Gallery Website
Gallery’s homepage offers a lot of useful information and resources for Gallery users
and developers as well as for anyone interested to know more about Gallery. From
the homepage you can read the latest news about Gallery, get to know all its features,
and read the installation instructions.
All the documentation for both users and developers is available on the site. There is
also the possibility to submit bug reports and feature requests. One interesting option
is to buy installation service or other support. Money from this goes to the website
hosting costs.
5.5 Mobile Friendly Features
We wanted to modify Gallery so that it would look good on the small screen of a
mobile phone or some other device. This meant changing the layout and scaling
images. In order to be able to achieve these goals we first needed to implement a way
of recognizing mobile user agents. In addition to these features we also added support
for the Image Uploader included in some Nokia mobile phone models (e.g. 3650 and
6600). All modifications were done on Gallery 1.4.3-pl2 and the Image Uploader was
also implemented as a Gallery 2 module.
48. CHAPTER 5. CASE STUDY: GALLERY 42
5.5.1 User Agent Recognition
The first task on making Gallery 1 (or any other system, for that matter) mobile
friendly was to recognize the mobile user agents. This is done based on the user
agent string as reported by the user’s web browser and the list of known mobile phone
user agent strings.
In PHP the user agent string is available in the $_SERVER[’HTTP_USER_AGENT’]
global variable. Our list of known user agent strings is stored in the mobile_term-
inal.php file as shown in Figure 5.8. The keys in the $screenSizes array are
regular expressions that match different user agent strings and the values are screen
dimensions of a respective phone model. The keys are defined in the order where
the most specific ones come first and the most general key comes last. The order of
the keys is meaningful as array items in PHP are internally stored in the order they
are assigned. For example, both Series 60 and Series 90 phones use the Symbian
operating system and this information is in their user agent string. If we had the key
’/.*?Symbian.*?/’ first in the array it would match both models, which is not
what we want since their display sizes are different.
The function screenSize() in Figure 5.9 shows how we use the $screensizes
array. This function is defined in the same mobile_terminal.php file as the array. It
takes the user agent string as an optional parameter with an empty string as the default
value for it. In lines 5–14 we check if we are in the “force mode”. The force mode
means that Gallery does not actually read the user agent string but the decision is made
based on other information. Forcing is meant for testing and demonstration purposes
and it will be better described later in this section.
If the user agent string is not given as a parameter to the screenSize() function,
we get it from a server variable in lines 17–19. When we have the current user agent
1 global $screensizes;
2 // Phones that use the Series 60 platform, e.g. Nokia 3650 and 6600.
3 $screensizes[’/.*?Series ?60.*?/’] = array(’width’ => 176, ’height’ => 208);
4 // Phones that use the Series 90 platform, e.g. Nokia 7700.
5 $screensizes[’/.*?Series ?90.*?/’] = array(’width’ => 640, ’height’ => 320);
6
7 // The generic mobile phone using Symbian OS.
8 $screensizes[’/.*?Symbian.*?/’] = array(’width’ => 176, ’height’ => 208);
9
10 // this is for forcing & test cases
11 $default_screensizes[’series60’] = array("width" => 176,"height" => 208);
Figure 5.8: Mobile user agent strings in mobile_terminal.php file.
49. CHAPTER 5. CASE STUDY: GALLERY 43
1 function screenSize($useragent = ’’) {
2 global $screensizes, $default_screensizes;
3
4 // are we in force mode?
5 if (isset($_SESSION[’force’])) {
6 switch($_SESSION[’force’]) {
7 case ’mobile’:
8 return $default_screensizes[’series60’];
9 case ’desktop’:
10 return null;
11 default:
12 return null;
13 }
14 }
15
16 // if user agent is not specified, use the current from server
17 if ($useragent == ’’) {
18 $useragent = $_SERVER[’HTTP_USER_AGENT’];
19 }
20
21 // check if the user agent string matches any screen size key
22 foreach (array_keys($screensizes) as $key) {
23 if (preg_match($key, $useragent)) {
24 return $screensizes[$key];
25 }
26 }
27 return null;
28 }
Figure 5.9: Function screenSize() returns the user agent’s screen size.
string we can compare it to the known user agent strings. In lines 22–26 we step
through the $screensizes array starting from the beginning and compare each of
the keys with the user agent string. If a match is found we return the respective screen
dimension value.
Finally, in Figure 5.10, we define a function isMobileUser() that returns true
if the user agent is a known mobile device and false otherwise. This function too, is
defined in the mobile_terminal.php file. It takes an optional $useragent parameter
with default value of empty string. To determine the situation isMobileUser()
calls the screenSize() function. If the return value of that function call is not
null then we know that in the list of mobile terminals’ display sizes there is a defin-
ition for our current user agent, and therefore it is a mobile device.
1 function isMobileUser($useragent = ’’) {
2 if (screenSize($useragent) !== null) {
3 return true;
4 }
5 return false;
6 }
Figure 5.10: Function isMobileUser() recognizes mobile user agents.
