Introducing Piclair.com to the iPhone platform
Rikard Engstr¨ om
May 2, 2010
Bachelor’s Thesis in Computing Science, 15 credits Supervisor at CS-UmU: Thomas Johansson
Examiner: Jonny Pettersson
Ume˚ a University
Department of Computing Science SE-901 87 UME˚ A
SWEDEN
Abstract
iPhone is one of the latest smartphones and it has grown in popularity ever since it was
first released in 2007. The iPhone has more advanced features than a regular cell phone
and is more suitable for internet related tasks because of its WiFi and 3G support. This
report describes the development of a server API and a photo sharing application aimed to
run on the iPhone platform. The project was issued by Piclair, the image uploading service
located at http://piclair.com. Piclair already possesses efficient image uploading software
for Windows and Mac OS X. The idea was to broaden the user base by entering one of
the fastest growing smartphone platforms. The objective of the project was to develop a
powerful but simple photo uploader dedicated to Piclair.com running on the iPhone and to
create a lightweight API to handle the uploads server side. This report spans from the idea
stage to a finished product. The result was a fully functional API and a non cumbersome
Piclair characteristic photo uploader, suitable not only for WiFi connected devices but also
3G and EDGE.
Contents
1 Introduction 1
1.1 Background . . . . 1
1.2 Server API . . . . 1
1.3 Smartphone platforms . . . . 2
1.4 iPhone technicalities . . . . 4
1.4.1 Specifications . . . . 4
1.5 Chapter overview . . . . 5
2 Problem Description 7 2.1 Requirements . . . . 7
2.1.1 Functional requirements . . . . 7
2.1.2 Non functional requirements . . . . 9
2.1.3 Managing system resources . . . . 9
2.2 Goals and purposes . . . 10
2.3 Related Work . . . 10
3 Methods 11 3.1 Memory management . . . 12
3.2 Preparations . . . 13
3.2.1 Theoretical . . . 13
3.2.2 Practical . . . 13
3.3 Tools . . . 13
3.4 Documentation . . . 14
4 Implementation 15 4.1 How the work was done . . . 15
4.2 The system in its environment . . . 16
4.2.1 Upload . . . 16
4.2.2 My photos . . . 17
4.2.3 Gallery . . . 18
4.2.4 Image caching . . . 20
iii
4.2.5 Image compression . . . 20
4.2.6 Sharing abilities . . . 21
5 Results 23 5.1 Server API . . . 23
5.2 Client . . . 26
5.2.1 Main view . . . 27
5.2.2 Uploaded photos . . . 30
5.2.3 Gallery . . . 31
5.2.4 Fullscreen view . . . 31
5.2.5 Settings . . . 34
6 Conclusions 35 6.1 Limitations . . . 35
6.2 Future work . . . 35
7 Acknowledgements 37
References 39
List of Figures
1.1 Data presenting requests from different smartphone operating systems . . . . 3
1.2 iPhone and iPod touch side by side . . . . 4
3.1 Memory management example . . . 12
4.1 The system in its environment with an upload scenario depicted. . . 16
4.2 API module used when requesting photos . . . 18
4.3 API module used when requesting public gallery images . . . 19
5.1 Piclair application icon in the iPhone OS SpringBoard . . . 26
5.2 The main view . . . 27
5.3 Upload to server . . . 28
5.4 Camera upload to the left and library upload to the right . . . 29
5.5 View showing the camera and library uploaded photos . . . 30
5.6 View showing the public gallery . . . 31
5.7 Fullscreen view and Facebook feed publishing . . . 32
5.8 Email photos from within application . . . 33
5.9 View showing the settings menu . . . 34
v
List of Tables
1.1 Worldwide smartphone sales to end users in third quarter of 2009 . . . . 2
vii
Chapter 1
Introduction
This report is written as a description of the development of an iPhone photo upload ap- plication and a server API, which was done on behalf of Piclair.com. The report is the theoretical part of a thesis at the Department of Computer Science at Ume˚ a University.
Internet has become a big part of everyday life and people have embraced using their mo- bile phones to access the net. That is a great reason to start adapting your services such as applications and websites for the mobile platform. In this case Piclair.com wanted to adapt to this evolution and enter this relatively new field. The objective in this project was to develop an easy to use photo sharing application for the iPhone platform and an API to handle the uploads server side. Communication will occur between the client (i.e.
the iPhone) and the already existing Apache web server. There are no explicitly stated requirements initially regarding the client or the server, all requirements are elaborated in chapter two.
1.1 Background
In the beginning of 2009 I was involved in the foundation of a company, the main area of this company intended to be website development, not only accomplishing internal web projects but also external jobs. In the fall of 2009 Piclair.com was born, as the result of one of the ongoing internal website projects. Piclair is an image uploading service, what distinguishes Piclair from the traditional image and photo websites is mainly the uploading mechanism.
1.2 Server API
An API
1is an interface implemented by a software program to enable interaction with other software, much in the same way that a user interface facilitates interaction between humans and computers. The underlying functionality that the API exposes is implemented server-side and used by the client (the iPhone). It determines the vocabulary and calling conventions the client should employ to use the services. It may include specifications for routines, data structures, object classes and protocols used to communicate between the consumer(client, i.e. iPhone) and implementer(server) of the API.
1
http://en.wikipedia.org/wiki/Application programming interface
1
1.3 Smartphone platforms
A smartphone could be defined by its high-level operating system, richer user interface and the more advanced hardware. There are several smartphones on the market today and the common smartphone operating systems are: Apple’s iPhone OS, Microsoft’s Windows Mo- bile, Nokia’s Symbian, RIM’s BlackBerry OS, Google’s Android and Palm OS.
iPhone is one of the latest smartphones, released by Apple. In March 6, 2008 they an- nounced that the iPhone SDK was available for third-party developers[1].
As can be seen in table 1.1, Nokia is in the lead of most sold units as of quarter 3 2009[2]
with a share of 39.3%, they decreased their sales from the same quarter 2008 from 42.3%
of the sales. Apple is in third place of most sold smartphones and had a share of 17.1%
quarter 3 of 2009 but instead increased from 12.9% the same quarter the year before.
Company Sales 3Q 09 Share(%) 3Q 09 Sales 3Q 08 Share(%) 3Q 08
Nokia 16156.4 39.3 15472.3 42.3
RIM 8522.7 20.8 5800.4 15.9
Apple 7040.4 17.1 4720.3 12.9
HTC 2659.5 6.5 1656.3 4.5
Samsung 1320.6 3.2 1114.8 3.0
Others 5368.0 13.1 7793.3 21.3
Total: 41067.6 100.0 36557.4 99.9
Table 1.1: Worldwide smartphone sales to end users in third quarter of 2009 (in thousands
of units)
1.3. Smartphone platforms 3
The smartphone usage in terms of data traffic is presented in the chart in figure 1.1.
It is worth noting that this data is gathered from usage of mobile sites and applications.
At least the number of applications for each platform will differ and that might have an impact on the statistics. Despite that, these numbers reveal alot about the internet-related smartphone usage today.
Figure 1.1: Data gathered by AdMob[3] presenting requests from different smartphone
operating systems
1.4 iPhone technicalities
Figure 1.2: iPhone and iPod touch side by side. iPhone to the left and iPod to the right.
1.4.1 Specifications
In this project the 3G model has been used. The device is packed with hardware components[4]
and some of them are listed below.
– 128 MB eDRAM
– Samsung 32-bit RISC ARM 412 MHZ (underclocked from 620 MHz)[5]
– Accelerometer
– GPS - Global Positioning System
– Ambient light sensor and proximity sensor
– 3.5-inch widescreen multitouch display with 480-by-320-pixel resolution – Flashdrive
– EDGE, 3G and Wi-Fi (802.11 b/g) connection possibilites
The most interesting ones indirectly related to this project are CPU, primary memory,
EDGE, 3G and Wi-Fi. The list above can be compared with the later released 3GS which
instead has 256 MB eDRAM and a Samsung S5PC100 ARM Cortex-A8[5] 600 MHz (un-
derclocked from 833 MHz).
1.5. Chapter overview 5
1.5 Chapter overview
This thesis is divided into six chapters and the content of these are briefly summarized now Chapter 1 - Introduction An introduction to the thesis and some background to it. An introduction to the iPhone and an overview of the smartphone market today is given.
Chapter 2 - Problem Description A description of the project that has been realized, elaboration of a specification with functional and non functional requirements. Also goals and purposes are reviewed.
Chapter 3 - Methods All the theoretical and practical preparations are reviewed and the tools that have been used.
Chapter 4 - Implementation The system is illustrated in its environment and some of the most interesting technical solutions are presented.
Chapter 5 - Results The results of the project are presented.
Chapter 6 - Conclusions Discussions about the result, what limitations exists in the
current system and what to expect in the future.
Chapter 2
Problem Description
Data communication will occur between the client and the already existing Apache web server
1. There are no explicitly stated requirements initially regarding the client or the API, these requirements will be elaborated in this chapter.
2.1 Requirements
2.1.1 Functional requirements
When application is launched the user should be directed to the main view. From the main view the user should be able to reach a view for photo upload from either camera or local library, reach a list of all own uploaded photos and reach the public gallery. The public gallery should reflect the gallery on the Piclair website.
Elaborated functional requirements regarding the client are listed below Main view
1.) Ability to upload photos directly from camera mode.
2.) Ability to upload existing photos from the phone’s local albums.
3.) Ability to reach the public gallery.
4.) Ability to view the photos that were uploaded from camera or local photo album.
5.) Ability to reach a view with settings.
Camera mode
1.) Activates the camera and should present a button that takes a picture and another button to cancel the camera mode and returns the user to the main view.
2.) When a photo is taken, the user should be given three options:
– Upload the captured photo and save to the phone’s local camera album.
– Only store the photo in the phone’s local camera album.
– Cancel, throw photo away and return user to camera mode.
1
http://httpd.apache.org/
7
Upload photo from local photo album
1.) List all existing local photo albums and directly upload the photo that the user selects.
List photos uploaded from the application
1.) The images that were uploaded by either camera or existing local albums will be listed. In the listing the following information should be included:
– URL to the photo on Piclair.com.
– Date of upload.
– Photo privacy, i.e. public or private.
2.) The photos should be displayed in a scaled-down thumbnail version. Thumbnails are generated on the web server and has a fixed quadratic size.
Settings
1.) Ability to choose for how long the nextcoming photo uploads should remain on server.
2.) Ability to choose privacy of the nextcoming photo uploads, i.e. if the photos are displayed in the public gallery or not.
3.) Settings will apply to all nextcoming photo uploads.
4.) Settings should be saved to disk.
5.) Read saved settings at application startup, if any settings are stored.
Gallery
1.) The public gallery displays all the uploaded pictures on Piclair.com, that is all pictures that have a privacy set as public.
2.) The latest uploaded pictures should be displayed in a scaled-down thumbnail version. Thumbnails are generated on the web server and has a fixed quadratic size.
3.) In fullscreen mode the user should be able to navigate ”sideways” through the gallery.
Elaborated functional requirements regarding the web server are listed below API
1.) The API should offer at least the following functionality:
– Photo upload. During photo upload a quadratic thumbnail should be created server-side. These thumbnails will be used when listing either the self uploaded photos or the public gallery photos.
– Photo request. Client sends a list of photo hashes to server. Server responds with a list of all the hashes that are still present on server, i.e. all of these hashes that have not been deleted yet because of passed deletion date.
– Gallery request. Client asks server for current photo hashes in the public
gallery. Server responds with a list containing the latest gallery hashes. For
each hash the server checks if an iPhone-customized quadratic thumbnail exists,
if not, one is generated. The reason for this check is that pictures uploaded
from the Windows or Mac OS X clients might not have iPhone-customized
thumbnails.
2.1. Requirements 9
2.1.2 Non functional requirements
The non functional requirements are now listed
1.) The underlying communication between the client and the Apache web server should be HTTP.
2.) The image data should be passed to server via a POST request
3.) Photos should be compressed client-side to minimize data in transfer from client to server
4.) Variables sent to server should be passed via GET
5.) Since Piclair strives for simplicity, the user interaction should be kept to a minimum, i.e. no unnecessary pop-up alerts and minimize the number of steps that has to be taken to accomplish a photo upload.
2.1.3 Managing system resources
The resources should be handled modestly on a mobile platform with limited resources.
Several precautions have been carried out. In this subsection the most important ones are revised.
Careful memory usage is necessary since there is no swapping available. It is not speci- fied how much memory the OS might use, but one should presume that the OS uses at least half of the RAM in the iPhone 3G[6].
Furthermore the application is supposed to work even though the user is on EDGE con- nection
2. Unofficially EDGE has been called 2.75G, just to get a simplified sense of how it relates and measures against 3G. In this kind of application the image upload plays a central role and therefore the upload data rate is seen as very important. During the development it was assumed that the user is on EDGE connection. The iPhone 3G handles up to 3.6 Mbps (3GS at 7.2 Mbps) downstream, but remains limited to 384 Kbps[7] upstream. Regarding EDGE connection it can carry a bandwidth up to 236.8 kbps (or 473.6 kbps in some cases).
Finally these downstream and upstream speeds might be limited by the network and/or the provider. For instance AT&T in the United States currently has a maximum download rate of 1.4 Mbps[8]
The following points were kept in mind during the development:
– No unnecessary communication between server and client – Minimize the image data uploaded to server
– Free objects from memory when not used – No excess code
2
http://en.wikipedia.org/wiki/EDGE
2.2 Goals and purposes
The purpose from Piclair’s point of view was to broaden the user base and reach out to a new kind of users. One of the goals for me as a developer was to gain knowledge in smartphone and mobile development. Another general goal was to acquire knowledge in software project development. The overall goal was to form an upload API and an easy to use photo sharing iPhone application dedicated to Piclair.com.
2.3 Related Work
There are certain big image and photo websites out there like Photobucket
3and Flickr
4. Both of these two have released iPhone applications for uploading images and photos to their websites. Not that Piclair has any real similarities to these sites or for that sake wants to compete against them. Piclair targets completely different and more specific groups of users. Some details that distinguishes Piclair from these actors are for instance the uploading mechanism, the fact that there is no traditional uploading from within the browser and the lack of required user registration.
3
http://www.photobucket.com
4
http://www.flickr.com
Chapter 3
Methods
The project has been carried out using an iterative development process, with the oppor- tunity to go back through each step of the process and make changes. However, there are a number of distinct steps that have been performed. During certain periods, the work has been done with one step at a time, while in some periods the work has been done in several steps in parallel. Much time has been devoted to acquiring new knowledge, both theoretical and practical. Theoretical information gathering through relevant literature and internet sources has been a consistent theme throughout the whole project. Also the practical details had to be taken care of. The steps that the work has passed through are:
Project plan - Including requirements specification, time plan and milestones System planning - System design and determining the program layout
Implementation - Based on system design, program layout and requirements specification Test phase - The final test phase including debugging and sealing of memory leaks Documentation - This report describing the project and code commenting
The initial project planning was devoted 40 hours and included requirement specifications, finding relevant literature and time planning. The next phase included the practical prepa- rations including the system design and program layout, these parts were devoted 60 hours.
This phase was very much interleaved with the implementation phase which separately was devoted 110 hours. The testing phase was partly carried out in parallel with the imple- mentation to minimize errors leading to other errors. A final debugging phase followed to remove undetected errors. Totally 170 hours devoted for design, implementation and testing.
In parallel with the system planning, implementation and testing phases literature has been studied. The literature were exclusively iPhone related, the server API was written in PHP which I considered myself master sufficiently for the project. 120 hours were devoted for information retrieval and acquiring knowledge. The final documentation phase was devoted 70 hours.
In summary, a total of 400 hours were devoted for the project. An additional 40-80 hours spread over the system planning, implementation and testing phases would have been more appropriate.
11
3.1 Memory management
Apple has not specified a limit for how much memory an application is allowed to use.
What they say though is that a memory warning will be sent to the application whenever the memory runs low. If a memory warning is issued it is up to the application to free up cached resources that is not in use. When the memory warning is issued is not defined, it depends on factors such as if the music player(iPod) is running in background and how much primary RAM the device has. To be on the safe side one should presume that the operating system at least uses half of the RAM in the iPhone 3G[6]. Swapping is not available, the only memory that is at disposal is the primary memory[9].
The Objective-C language uses a reference-counting[10] scheme for determining when to release objects from memory[9]. When an object is initialized the reference count is 1.
Other objects can then use the retain, release, or autorelease methods of the object to increase and decrease that reference count appropriately. When an object’s reference count reaches 0, the Objective-C runtime calls the object’s cleanup routines and then deallocates it. To keep memory consumption as low as possible in an application, objects that are not in use should be deallocated, but the programmer need to make sure that not any objects are being used.
Figure 3.1: Memory management example
There is no support for garbage collection or any form of automatic memory manage-
ment. It is important to realize that the autorelease feature is not equivalent to garbage
collection. Autoreleased objects are released in the autoreleasepool every time through the
main event loop, that is the event loop in the main thread. Or if own threads are created
a new autorelease pool must be created manually. Autorelease pools are more demanding
from a performance point of view compared to manual allocation and deallocation.
3.2. Preparations 13
3.2 Preparations
The project began with a lot of preparations, both theoretical and practical. It was stated already in the beginning that the client application should be developed for the iPhone platform, hence some of the practical preparations could be carried out in the end of the project planning.
3.2.1 Theoretical
The theoretical preparations for the project consisted of obtaining detailed knowledge re- garding iPhone development, it included research regarding constraints and possibilities of the development platform. The preparations included reading iPhone SDK Application Development[11], The iPhone Developer’s Cookbook[12] and the Apple developer forums[13].
During the whole development process the literature Beginning iPhone 3 Development[14]
has been used. No explicit preparations were carried out for the API, since the server was already configured and the previous PHP experience was considered sufficient for the project.
3.2.2 Practical
The practical preparations included to obtain an Intel-based Apple computer, obtain an iPhone 3G, learn how to use Mac OS X and study how to use the development environment Xcode. The project was developed in the programming language Objective-C which is the primary language for iPhone development.
3.3 Tools
The developer suite comes with several instruments for maintaining and tuning the appli- cation performance[15]. These tools can be run on Mac OS X and are suitable for tuning some aspects of the code during run in the simulator. Specially designed instruments for memory leak elimination can be run together with the simulator, on a mobile device it is necessary to ensure the overall memory usage is as low as possible.
Once the tuning is done in the simulator the step before release is to tune again during run on the device. Running the code on the actual device is the only way to optimize the code fully. When the code is run in the simulator in Mac OS X, it has the advantage of a faster CPU and more usable memory, which means the performance is generally much better than the performance on the actual device[15].
Tools used during the project are listed below
– Xcode - the IDE
1used for the iPhone development.
– Interface Builder - used for deployment of graphical components. Interface Builder has been sparsely used.
– iPhone simulator - A part of Xcode, used for simulating runs on the iPhone.
– GDB
2- Debugger included in Xcode.
1
http://en.wikipedia.org/wiki/Integrated development environment
2
http://en.wikipedia.org/wiki/GDB
– Instruments - Contains several analysis tools. Comes with functionality for code optimization and memory leak sealing. The Leaks instrument has been heavily used for sealing memory leaks.
– GIMP
3- Imaging software. Has been exclusively used for creation of icons and other graphics.
– VIM
4- Text editor. Used when writing the API in PHP.
3.4 Documentation
The only official documentation is this report. A project plan was elaborated before the project was put into production, but this report covers everything of interest. The source code is not open as of today.
3
http://en.wikipedia.org/wiki/GIMP
4
http://en.wikipedia.org/wiki/Vim (text editor)
Chapter 4
Implementation
4.1 How the work was done
The server-side API is written in PHP and the database management system used is MySQL.
The client application was written in Objective-C. The communication between server and client is accomplished via HTTP as can be seen in figure 4.1.
A protocol has been set up so that the server and client can communicate. A REST-style architecture has been used
1. A REST-style architecture consist of clients and servers where clients initiate requests to servers, in turn servers processes requests and returns appropriate responses. Three main modules were created in the server API:
1.) Photo upload 2.) Photos request 3.) Gallery request
These modules will be dealt with in the nextcoming subsections, the practical usage of them will be shown in the Results chapter.
1
http://en.wikipedia.org/wiki/REST
15
4.2 The system in its environment
Figure 4.1: The system in its environment with an upload scenario depicted.
4.2.1 Upload
A typical upload scenario is depicted in figure 4.1. A photo is either taken with the camera or picked from one of the local libraries, as seen in figure 5.3. The photo is then compressed and resized according to the algorithm described in the compression subsection. Then a connection is established with the server and if it succeeds the image data is transferred via a POST-request
2. Parameters describing how long the image should be saved on server and the image privacy is sent along in the URL. The client then awaits a response from server.
The response in that case will be one of the following:
– The unique server generated image hash – Indicate that the user is currently banned
– Indicate that the user’s daily upload quota has been reached – Indicate that a file system or database error occurred server-side.
The server first checks if the user is banned or has reached the maximum upload quota. If one of these conditions evaluates to true server returns response and cancels the execution, otherwise the information parameters are fetched and dealt with appropriately. Thereafter the image data is handled and an unique hash identifying the image is generated, also a
2
http://en.wikipedia.org/wiki/POST (HTTP)
4.2. The system in its environment 17
quadratic thumbnail is generated intended for the iPhone. Finally the upload successful response is sent back to client, this response contains information about the upload which will be used by the client.
XML was excluded in the server to client response. It was not enough time to study XML parsing in the iPhone API. Instead the response data is separated with "!" (a non reserved URL char). A typical successful upload response would look like:
b2i9i!2010-02-08!2010-02-09!No
The first item b2i9i is the image hash, the next two items are date of creation and re- moval date and the last item No reveals if the image can be viewed in the gallery. The last item is not necessary since the image privacy information is already held by the client. It was decided to keep it this way so that the final decision is held by the server, this gives the server an opportunity to deny the user from posting to the public gallery. All the critical tasks should be held server-side, otherwise if more responsibility were handed to the client, modified clients could take advantage. Instinctively one might get tempted to hand over as much job as possible to the client, like the hash generation for instance.
When the hash is received client-side the information is saved into an array. When the application terminates this information is saved to the file system, more specifically into a property list. A typical property list where there is one image hash and related information saved is shown below:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
<string>b2i9i!2010-02-08!2010-02-09!No</string>
</array>
</plist>
4.2.2 My photos
All the user uploaded photos, either from camera or library, are saved as described in the previous subsection. On a successful upload the hash representation of the image is saved in a property list client-side. These hashes corresponds to the images on the server. All image uploads are available for viewing in the application in the ”My photos” section as seen in figure 5.5.
When the list of photos is loaded for the first time, a connection is established with the server, if it succeeds and if there are any image hashes saved they will be transferred to the server via a GET-request
3, it is worth noting that there is no maximum URL length specified
4. In this phase the image hash is all that is necessary to be transferred, to let the server examine them and determine which of these that are still present on the server.
3
http://en.wikipedia.org/wiki/GET (HTTP)
4
http://www.w3.org/Protocols/rfc2616/rfc2616.html
The client then awaits a response from server. The response in that case will be one of the following:
– All active image hashes together with related information.
– Indicate that none of the sent hashes are present server-side.
– Indicate that a file system or database error occurred server-side.
Client handles the response appropriately and if any image hashes and information were returned, the data is parsed and a list displaying all user photos is filled with the data. For instance a user with two photos uploaded could receive this response:
b2i9i!2010-02-08!2010-02-15!No g323i!2010-02-08!2010-02-15!No
In that case the user uploaded two photos 2010-02-08 and set the removal date to one week later and selected the privacy to non public. If there were any changes server-side, such as image removal or a change in image privacy, client fully overwrites its current prop- erty list with saved hashes. To minimize the communication between client and server, the initial communication described is only performed first time when user selects the ”My photos” as a way to initially synchronize with server, thereafter the list is totally controlled client-side. The communication is asynchronous to avoid locking the GUI.
An illustration of how the ”My photos” module is used is shown in figure 4.2. The client sends the GET-request, the request turns out successful and all the client hashes are syn- chronized with server. Finally all active hashes are transferred back to client:
Figure 4.2: API module used when requesting photos
4.2.3 Gallery
Images available in the gallery on Piclair.com can be shown in this menu, as depicted in
figure 5.6. This particular client requests the 100 latest public images via the gallery module.
4.2. The system in its environment 19
When the gallery list is opened a connection is established with the server, a GET-request is sent with one parameter indicating that the latest gallery image hashes are requested.
The client then awaits a response from server. The response in that case will be one of the following alternatives
– Hash representations and related information for the latest public images – Indicate that there are no images in the public gallery
– Indicate that a file system or database error occurred server-side.
If there are public images available server builds a response string and checks for each image if there is a 85x85 pixels thumbnail available and creates one if it is missing. Images uploaded from other platforms than iPhone will not have these thumbnails prepared. The same procedure follows here as in the ”My photos” case. Client awaits and handles the re- sponse appropriately, if any image hashes and information were returned the data is parsed and a list displaying all user photos is filled with the data. One difference though is that the number of views is available instead of image privacy in this data response:
b2i9i!2010-02-08!2010-02-15!90
In this example one image was returned and that image had been viewed 90 times. The gallery list always synchronizes with the server when the list is opened. The reason for that is to keep track of new images popping up in the gallery and to keep track of the number of views of all the public images. The gallery reflects the original gallery on Piclair.com. Also in this case the communication is asynchronous to avoid locking the GUI.
In figure 4.3 the gallery module request is depicted.
Figure 4.3: API module used when requesting public gallery images
4.2.4 Image caching
Since the internet connection can be somewhat limited, photos are cached in the application.
User uploaded photos and gallery photos will be available for viewing in lists. These lists displays roughly four to five rows at a time, where each row contains a thumbnail of an image together with information about how many times the image has been viewed on the website, when it was uploaded and when it will be removed from the server. Once an image has been loaded in the photo list or gallery list, it will not be loaded from server anymore during the application run. The full size version of the images will only be loaded from server when user chooses to view the image in full view, the full view can be seen to the left in figure 5.7. The same caching applies in the full view case, the full size version will only be loaded from server one time and henceforth the cache is used.
4.2.5 Image compression
Images are both resized and compressed client-side before uploaded to server. Since an original camera photo in the iPhone 3G has the dimensions 1200x1600 (or 1600x1200 in landscape/horizontal mode) pixels and have an average file size around 600 kb, they had to be resized and compressed before sent to server. Images are compressed with 40% JPEG- compression and resized so that the file size rather lands around 50 kb. The compression is always applied and then the image goes through the following resizing algorithm described in pseudo code:
IF original_image.height > original_image.width IF original_image.width > MAX_WIDTH_W
new_height = original_image.height * MAX_WIDTH_W / original_image.width new_width = MAX_WIDTH_W
new_image = resizeImage(original_image, new_height, new_width) RETURN new_image
ELSE
IF original_image.width > MAX_WIDTH_H
new_height = original_image.height * MAX_WIDTH_H / original_image.width new_width = MAX_WIDTH_H
new_image = resizeImage(original_image, new_height, new_width) RETURN new_image
RETURN original_image
The algorithm preserves the aspect ratio when scaling. The new image width is constrained by the MAX WIDTH constants. The very first if-statement checks if the image height is greater than the width, if the height is greater this image has been taken with the camera in an upright vertical position. The image then is resized with respect to the MAX WIDTH W constant. The height of the new scaled image is the current height multiplied with the factor (MAX WIDTH W / original image.width). The factor is necessary to preserve the aspect ratio when the width is resized. If the ELSE-case instead is entered the width was greater than the height. In that case MAX WIDTH H constant is instead used in the resizing
In summary, two different MAX WIDTH constants are used to maintain a new image with
reasonable dimensions independently on the original dimensions. With two constants, both
of the two different original image dimensions can be adjusted to contain the same total
amount of pixels.
4.2. The system in its environment 21
4.2.6 Sharing abilities
Some unanticipated desired functionality were missed during the project planning. Three main features allowing the user to share photos either from the private photos list or the public gallery via Facebook, Twitter or email were implemented alongside with the original requirements specification.
Both the Facebook connect API[16] and the Twitter API[17] has been incorporated into the client application. As can be seen in figure 5.7, both a facebook and Twitter-button is available at the bottom. When the facebook-button is pressed for the first time a face- book login screen is presented, if the user successfully logs in the currently viewed photo is uploaded to the user’s Facebook Photo-section. Immediately after upload follows a screen which allows the user to publish a feed with the uploaded photo and write some feed text, as in figure 5.7. A successful login session is saved, i.e. the next time the user uploads to Facebook a new login action is not necessary. When the Twitter-button is pressed a login screen to Twitter is presented. On successful login to Twitter the user is able to share some text and a direct link to the image on Piclair.com.
In the upper right corner in both of the figures 5.5 and 5.7 an email-button can be seen.
When the email-button in figure 5.7 is pressed the email view is shown, as in figure 5.8. The
current image in the fullscreen view has been inserted into an email and allows the user to
send this email to someone and write text in the email body.
Chapter 5
Results
In this chapter the results of the project will be described. The goal was to create an easy to use photo upload application and a server API for the client to use. The different parts of the application will be shown and their respectively functionality described. Also the requirements from chapter 2 will be revisited.
5.1 Server API
The practical use of the three modules Photo upload, My photos request and Gallery request will now be described.
When user uploads a photo either from camera or library, the photo first goes through the resizing and compression routines, then the image data is sent in the POST-request and the other information parameters are sent along in the URL. In practice the client requests the Photo upload module like this:
http://piclair.com/api/photoupload/4/No/
The image data is also sent along even though it is not visible in the URL. The photoupload is the module name and after that comes the parameters sent to the module. In this case the first parameter holds the value 4 and describes for how many weeks the user wants the image to remain on server. The last parameter holds the value No and tells that the image is not to be found in the public gallery. Ultimately the server checks the parameter values if they are valid. Valid parameter values are predetermined server-side to prevent maliciously modified clients to abuse the system. A response is finally sent back to client as described in the Implementation chapter.
The My photos request module is requested when user enters the ”My Photos” menu the first time. In practice the client requests the module in this way
http://piclair.com/api/myphotos/req/b2i9i_g323i/
myphotos is the module name and req tells that the client wants to synchronize its hash list with server. There is additional functionality available in this module which is not handled in this project and hence will not be described in the report, however this parameter can
23
be switched to access other features in this module. Last but not least the final parameter b2i9i g323i contains all the hashes that client want to synchronize with server, in this case two hashes separated with ” ” are received at the server. A response is sent to client with all actual hashes.
The Gallery request module is used when user enters the ”Public gallery” menu. In practice the client requests the module in this way
http://piclair.com/api/gallery/100/
gallery is the module name and 100 tells that the client requests the 100 latest images in the public gallery. A response is sent to client with the 100 latest gallery hashes.
To keep the interaction with the API clean the notation /api/photoupload/3/No/ is used. This notation is converted server-side to /api/photoupload.php?alive=3&gallery=
No with regular expressions.
Now follows a quick walkthrough and followup of the requirements that were fulfilled re- garding the API:
1.) The API should offer at least the following functionality:
– Photo upload. During photo upload a quadratic thumbnail should be created server- side. These thumbnails will be used when listing either the own uploaded photos or the public gallery photos.
– Photo request. Client sends a list of photo hashes to server. Server responds with a list of all the hashes that are still present on server, i.e. all of these hashes that have not been deleted yet because of passed deletion date.
– Gallery request. Client asks server for current photo hashes in the public gallery.
Server responds with a list containing the latest gallery hashes. During this request for each hash the server checks if an iPhone-customized quadratic thumbnail exists, if not, one is generated. The reason for this check is that pictures uploaded from the Windows or Mac OS X clients might not have iPhone-customized thumbnails.
Fulfilled? - Yes, all three requirements are fulfilled. Thumbnails are created server- side, the client sends a list with its hashes and receives a new list with the hashes still alive on the server. Also the gallery request works exactly as the requirement was stated.
All the non-functional requirements can be considered fulfilled. The non functional require- ments are now listed
1.)The underlying communication between the client and the Apache web server should be HTTP.
2.) The image data should be passed to server via a POST request.
3.) Photos should be compressed client-side to minimize data in transfer from client to server.
4.) Variables sent to server should be passed via GET.
5.1. Server API 25
5.) Since Piclair strives for simplicity, the user interaction should be kept to a minimum,
i.e. no unnecessary pop-up alerts and minimize the number of steps that has to be
taken to accomplish a photo upload.
5.2 Client
The user launches the application from the iPhone OS SpringBoard
1. The SpringBoard is the standard application that manages the iPhone OS home screen. As of iPhone OS 3.0, SpringBoard looks for applications in the /Applications and /var/mobile/Applications directories of the iPhone’s filesystem. In figure 5.1 the application icon can be seen laying in the SpringBoard.
Figure 5.1: Piclair application icon in the iPhone OS SpringBoard
1
