Institutionen för datavetenskap
Department of Computer and Information Science
Final thesis
Smart TV front-end application for cloud
computing
by
Jaime Miguel Montero
LITH-IDA/ERASMUS-A—12/004—SE
2012-12-14
Final thesis
Smart TV front-end application for
cloud computing
by
Jaime Miguel Montero
LITH-IDA/ERASMUS-A–12/004–SE
2012-12-14
Supervisor at the company: Daniel Arthursson Supervisor: Maria Vasilevskaya
På svenska
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –
under en längre tid från publiceringsdatum under förutsättning att inga
extra-ordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida
http://www.ep.liu.se/
In English
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page:
http://www.ep.liu.se/
Abstract
This master project focuses on the development of a front-end application for cloud computing. Traditionally, televisions have been excluded from the always connected world. With the appearance of the smart televisions it is now possible to connect them to the Internet. However, there still exists a gap between televisions and services in the cloud.
To solve the problem,we have developed a JavaScript application. This ap-plication allows the user to log into their CloudMe account from a Samsung SmartTV with multimedia support. This application is centered on improv-ing the responsiveness performance of a cloud computimprov-ing application. It also enhances the user experience by creating a user-friendly UI for a television. During the course of this thesis, the application and its functionalities have been studied, designed, developed, optimized and finally tested. We have also done a set of measurements to validate the responsiveness of the pro-posed design.
The development of this TV application shows the TV is a potential target device for cloud computing services due to its better resources and capabil-ities in di↵erent areas such as multimedia reproduction.
Acknowledgements
First of all, I would like to thank my examiner Simin Nadjm-Tehrani and my supervisor Maria Vasilevskaya for their patience and support during the realization of this thesis. Your feedback has been really helpful.
I would also like to thank all the people of CloudMe, who helped and guided me when I most needed it. Specially, I would like to thank Daniel Arthurs-son, for believing in me and giving me the opportunity to carry out this thesis in CloudMe.
Finally, I would like to thank my family and friends for their unconditional support.
Contents
1 Introduction 2 1.1 Problem description . . . 2 1.2 Objectives . . . 3 1.3 Approach . . . 3 1.4 Evaluation criteria . . . 4 1.5 Limitations . . . 5 1.6 Thesis outline . . . 6 2 Background 7 2.1 CloudMe system description . . . 72.1.1 Software architecture . . . 7 2.2 Samsung SmartTV . . . 7 2.3 Technologies . . . 9 2.3.1 JavaScript . . . 9 2.3.2 jQuery . . . 9 2.3.3 Ajax . . . 10 2.3.4 HTML . . . 10 2.3.5 CSS . . . 11
2.3.6 Model View Controller . . . 11
2.3.7 Digest access authentication . . . 11
2.3.8 Simple Object Access Protocol . . . 11
3 Design 13 3.1 Functional requirements . . . 13
3.1.1 Navigation . . . 13
3.1.2 Login and Logout . . . 13
3.1.3 Create account . . . 14
3.1.4 Open media file . . . 15
3.2 Design goals . . . 17
3.3 Architecture . . . 18
3.4 User interface . . . 20
3.5 Responsiveness improvement . . . 24
3.5.1 Separate the JavaScript files . . . 24
CONTENTS CONTENTS
3.5.3 Number of files ordered to server . . . 25
3.5.4 Pre-load of images . . . 26
3.5.5 Minify . . . 27
4 Implementation 28 4.1 Controller . . . 28
4.1.1 Estimation of the network throughput . . . 28
4.1.2 Login and Logout . . . 29
4.1.3 Handle files . . . 30 4.1.4 Play music . . . 30 4.2 Model . . . 31 4.3 Scenes . . . 32 4.3.1 Drive scene . . . 32 4.3.2 Folder scene . . . 33 4.3.3 Image scene . . . 34 4.3.4 Login scene . . . 36 4.3.5 Sign up scene . . . 36 4.3.6 Video scene . . . 37 4.4 Problems . . . 38 4.4.1 Authentication . . . 38
4.4.2 Loading images in the 2011 model . . . 39
4.4.3 Fetching data from a XML response . . . 39
4.4.4 Download and upload from an USB disk . . . 40
4.4.5 Open PDF file . . . 40
4.5 Overview . . . 40
5 Testing 42 5.1 Functional tests . . . 42
5.1.1 Login and Logout test . . . 42
5.1.2 Sign up test . . . 42
5.1.3 Open file test . . . 44
5.1.4 Navigation test . . . 45
5.1.5 Language test . . . 46
5.1.6 Print image test . . . 46
5.2 Non-functional tests . . . 46
5.2.1 Usability test . . . 47
5.2.2 Memory usage test . . . 47
5.3 Samsung tests . . . 48
5.4 Test results . . . 48
6 Validation of design decisions 49 6.1 On demand load of JavaScript files . . . 49
6.2 Dynamic HTTP requests . . . 49
6.3 Minify . . . 50
CONTENTS CONTENTS
CONTENTS CONTENTS
List of Acronyms
AJAX Asynchronous JavaScript And XML API Application Programming Interface CSS Cascading Style Sheet
GNU GNU’s Not Unix
HTML HyperText Markup Language HTTP HyperText Transfer Protocol HTTPS HyperText Transfer Protocol Secure JS JavaScript
MD5 Message-Digest Algorithm 5
MIT Massachusetts Institute of Technology MP3 MPEG Audio layer III
MVC Model View Controller PDF Portable Document Format SDK Software Developer Kit SOAP Simple Object Access Protocol TV Television
UI User Interface USB Universal Series Bus
Chapter 1
Introduction
Nowadays, with the increasing number of devices that can run third parties applications available in the market and the improvement of telecommuni-cation networks, users expect to have all their data accessible any time and anywhere. As the users’ demand increases, the companies have to innovate with new devices and new applications. One example of these new devices are the smart televisions: a television which can be connected to the Internet and in which applications can be installed [25, 8]. To that extent, most of the major manufacturers (such as LG, Panasonic, Philips, Samsung) already o↵er the possibility to develop applications for their own platforms [39].
1.1
Problem description
In this thesis, we study a set of technologies and specify requirements in order to design and develop a multimedia application for these new devices. Additionally, the viability and success of the application is checked by run-ning tests during the development process.
This thesis is centered on two main aspects. First, how to develop a good user interface for a television. Secondly how to build a multimedia application for cloud computing efficient in responsiveness terms. It also presents some interesting aspects about how to authenticate to a server us-ing a suitable authentication method and usus-ing standard web protocols to communicate to the server.
1.2
Objectives
The objective is to create an application which will be able to connect a Samsung SmartTV (the smart television of Samsung) with a user’s CloudMe
1.3. APPROACH CHAPTER 1. INTRODUCTION
account which fulfills the following requirements:
• The application must provide a UI that allows the user to browse their CloudMe file system.
• The application must be able to play video, display images and repro-duce audio.
• The application has to be ”fast enough” to be usable. By ”fast enough” we mean that the booting time has to be at least the same time as the web browser application needs (around 8 seconds). It also has to be fluid, or in other words, the waiting time inside the application itself should be minimal. By minimal we mean that the time to open a folder when no network congestion occurs and the network throughput of above 1Mbps is below 0.5 seconds.
• The UI has to be user-friendly for TV, that means, for example, that it has to fit a TV screen and have to be controlled by a remote. It will also follow Samsung user experience guideline [30].
• In order to internationalize the application, multi-language support should be added.
• The application should be able to print directly from the TV. • To deploy the application and upload it on the Samsung market [10]. The starting point of this thesis is the existing HTML 5 and Ajax-based web client from CloudMe, which in certain occasions is going to be used as a model. However, this thesis is the first approach to create a Samsung SmartTV application.
As for the last three points, they will be done if time allows its realiza-tion. On the contrary, all of the other points are considered as minimum requirements for this thesis.
1.3
Approach
Given the preceding problems, the approach adopted is to split the work in di↵erent phases each one with di↵erent tasks:
1. Software requirements 2. Planning
(a) Installing the programs needed, configuring the working environ-ment (TV and laptop) to make it work together.
(b) Getting used to the Samsung Developer Kit (SDK) and the work-ing environment to learn how the applications work in the TV.
1.4. EVALUATION CRITERIA CHAPTER 1. INTRODUCTION
(c) Getting familiar with the CloudMe environment and studying how the communication between the application and the server is possible.
(d) Planning and designing the application, and describing the ratio-nale for the design choices made.
3. Developing
(a) Developing a first prototype of the application: it should be able to login to the CloudMe account and to navigate through the file system as specified in Section 3.1.2.
(b) Improving the user’s interface (see objectives, Section 1.2). (c) Adding the multimedia reproduction feature (see use case 3.1.4). (d) Developing the create account functionality described in use case
3.1.3.
(e) Adding extra requirements, such as multi language support and image printer.
4. Testing
(a) Testing the prototype in the Samsung’s TV emulator.
(b) Testing the visualization in the real Samsung SmartTV that CloudMe has provided. This is possible by connecting the TV to the local network.
(c) Running a battery of tests to check that the application is working in a proper way.
5. Deployment
(a) Packaging the application and upload it to the Samsung market.
1.4
Evaluation criteria
In order to measure the success of the application, the following tests are carried out. These tests are done manually, since the automation of the tests is not an easy task and due to the time limit of this project, is not feasible. However, Samsung will expose the application to the procedure of automatic and manual testing before uploading it to the market. The testing environment is the emulator provided by Samsung for both 2011 and 2012 models and a real 2011 TV (model UE40D8005YUXXE). The application is considered as successful if it passes the following tests.
• Login test: Given a user name and a password, the application has to be able to login to the CloudMe server. It also has to check the credentials introduced.
1.5. LIMITATIONS CHAPTER 1. INTRODUCTION
• Logout test: The application has to be able to log out from the user account.
• Sign up test: The application has to be able to create a user account in CloudMe.
• Remember me test: The application has to be able to remember the user credentials and log in automatically.
• UI test: The application has to fulfill the Samsung guideline to design a good UI.
• Navigation test: The application has to be able to navigate between files.
• Video test: The application has to be able to play a video file in full-screen.
• Image test: The application has to be able to display an image file in full-screen and in slide show mode.
• Responsiveness test: The application has to fulfill the time require-ments described in the problem description in Section 1.2.
• Print test: The application should be able to print an image if a compatible printer exists.
• Language test: The application has to be developed in di↵erent lan-guages (for now, English and Spanish) and it has to check that it can be changed.
1.5
Limitations
There are some limitations in the use of this application:
• The application only works in 2011 and 2012 models of the TV. • A television needs to be connected to the Internet in order to login to
the application.
• If the network throughput is not good enough, video playing will not work.
• The application has to be compatible with CloudMe web interface. • The number of languages is limited, but can be extended easily by
1.6. THESIS OUTLINE CHAPTER 1. INTRODUCTION
1.6
Thesis outline
In this section we explain how this thesis is structured. There are seven chapters: introduction, background, design, implementation, tests valida-tion of design decisions and conclusion. The background gives informavalida-tion about the CloudMe service, the Samsung SmartTV and the technologies used to develop the application. The design chapter describes the key con-cepts used to design the application. The implementation points out some important aspects about how the application is developed. The tests chap-ter presents the tests done and the results to check that the application works as expected. In the validation of design decisions chapter we show measurements to check whether the design decisions made where good or not. Finally, the conclusion section is centered on what has been achieved.
Chapter 2
Background
In this section background information necessary for a better understanding of the thesis is given.
2.1
CloudMe system description
CloudMe is a cloud computing service that focuses on storing, sharing and accessing information. Inside all the cloud computing services, it belongs to the group Data as a Service, (DaaS) [21]. This means that the users can access their (or shared) data over a network. The concept of cloud computing o↵ers some advantages. It is scalable because it can be accessed from anywhere with an internet connection. This is possible because the information is located in a data center. Moreover, it can be accessed with multiple devices, not only web browsers. Cloud computing is flexible because it can be shared between multiple users. It is an autonomous system which is managed transparently to the user. It can also be used as a backup service.
2.1.1
Software architecture
The CloudMe system consists of a back-end, the server where all the infor-mation is stored, and multiple front-end applications, such as a websites, iPhone and android applications, used to access an account, as seen in Fig-ure 2.1. To access an account, the user has to be authenticated by providing a valid user name and a password.
2.2
Samsung SmartTV
The new generation of televisions, called SmartTV [37], o↵er the possibility to connect a television to a network and to install third parties applications
2.2. SAMSUNG SMARTTV CHAPTER 2. BACKGROUND
Figure 2.1: CloudMe client applications
Figure 2.2: Application on a SmartTV [34].
[39].
With the release of the SmartTV, Samsung launched a Software Devel-oper Kit (SDK). By using this SDK, a external develDevel-oper has the possibil-ity to create applications for Samsung’s television. The applications for a Samsung’s SmartTV are web-based and are developed in HTML, CSS and JavaScript or Flash. However, even though they are web based, they present some specific aspects which make them di↵erent to traditional web applica-tions. These aspects are for example, the way the user interacts with the application and the available memory compared to a PC.
As seen in Figure 2.2, the application runs in a browser in the TV screen. Every application developed for the SmartTV consists of: HTML files, CSS files for visualization, JavaScript files to control the behavior and some con-figuration files. Moreover, these files are grouped to form scenes. Each scene can have one or multiple tasks.
All SmartTV users can download applications if they have an internet connection. These applications are stored in the television internal memory.
2.3. TECHNOLOGIES CHAPTER 2. BACKGROUND
The main screen of the Samsung SmartTV is the Smart Hub, where all the installed applications are located.
2.3
Technologies
In this section, some of the technologies used in the application are briefly explained for better understanding of the design and implementation pro-cess. These technologies are: JavaScript, CSS, HTML, jQuery and Ajax. Additionally, we will also explain the model view controller paradigm, the digest authentication method and the simple object access protocol.
2.3.1
JavaScript
JavaScript [9] is an interpreted programming language. This means that it has to be executed using an interpreter, instead of using a compiler as the compiled languages. This kind of language o↵ers some advantages:
• It is platform-independent. • The program’s size is smaller.
• The memory management is done automatically using a garbage col-lector.
However, it also has some drawbacks:
• The execution time using an interpreter is greater. • The necessity of having an interpreter locally.
Additionally, JavaScript o↵ers object-oriented capabilities. The main issue about using JavaScript is that some parts of JavaScript’s core are spe-cific to the browser extension. This makes cross-browser compatibility a problem for developers [9].
JavaScript is the main language used in the development of a Samsung SmartTV application. Additionally, we have used jQuery library (see Sec-tion 2.3.2).
2.3.2
jQuery
jQuery [18] is a JavaScript library created by John Resig. Its purpose is to simplify the way JavaScript is used. It basically o↵ers multiple functions that would need much more coding if JavaScript is used instead. One of its advantages is that it is free and open source licensed with both MIT license and GNU license. It also has cross-browser compatibility [20]. Thus, jQuery deals with the cross-browser compatibility problem of the JavaScript language.
2.3. TECHNOLOGIES CHAPTER 2. BACKGROUND
jQuery can be used in two ways: via the $ or via $. functions. The first one is used to modify the the content of the DOM (Document Object Model). The result of this function is an object that matches HTML elements. These objects can then be modified. The second one alters global properties.
2.3.3
Ajax
Asynchronous JavaScript and XML (Ajax) [2] is a technique used in web applications. It consists of performing requests to the server asynchronously. These requests can modify the displayed content without reloading the entire page. This technique di↵ers from the classical way of programming web applications. In the classical way, the HTTP request is sent to the server which responds with an entire HTML page to the client. Even if only one small part of the whole page has to be changed, it will be reloaded entirely. With this approach, time is gained as the application can perform other tasks while waiting for a response.
2.3.4
HTML
HyperText Markup Language (HTML) [13] is the main language to elabo-rate web pages. The HTML files are text files with a .html extension. Inside this file, there are multiple tags, normally in pairs (one to start and one to end the instruction) and between them the content is written. An example of an HTML document can be seen in Figure 2.3. In this figure, a simple hello world message is displayed. It can be observed that the content is embedded between html tags. Inside this tag, the tags head and body can be seen. These files are opened by web browsers, which read the HTML tags and generate the layout of the web site. Additionally to HTML several other technologies can be used. For example, JavaScript can be used to make the web site dynamic by changing content without reloading the entire page. Also, CSS can be used to separate the content from the view.
2.3. TECHNOLOGIES CHAPTER 2. BACKGROUND
2.3.5
CSS
Cascading style sheets (CSS) [6] is a language used to define the appearance of a document written in a markup language, such as HTML. The CSS file helps to separate the structure from the presentation of a document. The version used in this thesis is CSS3. However, CSS3 is not fully supported in Samsung’s televisions [7]. The elements inside the HTML files are organized in tags (see Figure 2.3). These divisions are positioned in the screen layout using the position CSS tag.
2.3.6
Model View Controller
The Model View Controller (MVC) [11] architecture is a technology used to divide the application into di↵erent components to separate data struc-ture, presentation and logic of an application. This modularity o↵ers two advantages [11] [3]. It is easy to read and easy to modify because the code is not mixed. In the following, we explain the function of the model the view and the controller. The model groups all the classes belonging to the core of the application. The view gathers all the classes that are related to the presentation of the information to the user (or, in other words, the user interface). The controller groups all the classes managing the interaction between the view and the model.
2.3.7
Digest access authentication
The digest access authentication is an agreed-upon method to negotiate cre-dentials used in the HyperText Transfer Protocol (HTTP) [14]. It checks that both parties know a password without the password being sent clear through the network. A sequence diagram of the process of authentication using digest is shown in Figure 2.4 The www-authenticate header contains the nonce value, which is generated in the server, and is needed to au-thenticate. This value is then read by the client, which creates the digest authentication header. The most important part of this header is the re-sponse, which is a string created by hashing the user name, the password, the nonce value, the HTTP method and the Uniform Resource Identifier (URI). Normally the MD5 algorithm is used as the cryptographic hash function.
2.3.8
Simple Object Access Protocol
The Simple Object Access Protocol (SOAP) [33] is a protocol which defines how two nodes in a network can communicate by using extensible markup language (XML) data over HTTP. Every SOAP message is comprised of an envelope, which contains the header and the body. It also needs to specify the encoding rule used in the message [31]. The messages that are sent to and received from the server are SOAP messages.
2.3. TECHNOLOGIES CHAPTER 2. BACKGROUND
Chapter 3
Design
In this chapter the design of the application is explained. It has five sections: functional requirements, design goals, architecture, user interface and design decisions made to improve responsiveness.
3.1
Functional requirements
In this section the requirements of the application are explained.
3.1.1
Navigation
This requirement describes one of the main functionalities of the application: navigation within the CloudMe file system, as specified in the first objective. Therefore, this is a primary use case. This use case has a prerequisite: the user must be logged in to be able to navigate through their files.
Basic flow
The user moves between the di↵erent files and folders using the arrow keys of the remote controller. Also, he/she can open any folder by pressing an-other button.
Alternate flow: Sort folder and files
Additionally, the user can sort the files in each folder, for an easier naviga-tion.
3.1.2
Login and Logout
The purpose of this use case is to describe how the user connects to the application. It is a primary use case since it is needed in order to achieve
3.1. FUNCTIONAL REQUIREMENTS CHAPTER 3. DESIGN
the previous requirements. The actors involved in this use case are the user, who has to enter their credentials, and the server, which performs the au-thentication.
Basic flow
The fist scene shown in the application is the login scene. Once it is dis-played, the user types his user name and password into two input fields for that purpose. There are also two buttons, one to log in and the other one to create a new account. To log in, he/she selects the sign in button and press enter. A request then is sent to the server asking for authentication. If the authentication succeeds, another request is sent to the server asking for the folders and files of the root drive. When the response is received, the drive scene must be shown. Finally, once in the drive scene, the user must be able to log out and then redirected to the login scene.
Alternate flow: Invalid credentials
Additionally to the basic flow, there is a chance of failure in the authentica-tion process. In this case, a pop up window should appear warning about the failure and informing the user why it happened. Some reasons explaining this issue could be, for example, that the introduced credentials are wrong or blank, or that the server could not be reached.
Alternate flow: Keep signed in option
In the login scene, there should be also a check box which will keep the user signed in for the next time, if the validation succeeds. In other words, next time the application starts, the user will be logged in automatically and redirected directly to the drive scene. This should remain this way until the user chooses to log out in the drive scene.
3.1.3
Create account
This is a secondary use case that describes how a user that does not have an account can create one within the application. This is not a necessary requirement, since the objectives can be achieved without it (see Section 1.2), but it will be useful for a client that launches the application for the first time. This use case and the login and logout one can be seen in detail in the flow diagram in Figure 3.1.
3.1. FUNCTIONAL REQUIREMENTS CHAPTER 3. DESIGN
Basic flow
As seen in Section 3.1.2, in the login scene, there is a button to create an account. When pressed, the view should switch to the sign up scene. This scene must show di↵erent fields that the user has to fill in order to get an account and a button to submit the data. When all the necessary fields are filled and the button is pressed, the request to the server is sent. However, before being able to send the request to server, it has to provide validation in order to avoid sending unnecessary HTML requests. The validator needs to check the following points:
• The user-name is not already taken (a request to the server is needed for this).
• The password is long enough (at least five characters). • The format of the email is correct.
• The user has accepted the user agreement.
If the validator fails, then a pop up message will appear, mentioning all the validators that are creating the error. When the account is created, the user is redirected to the drive scene.
Alternate flow: Error creating the account
If any error is produced in the server while creating the account, the user should be noticed by displaying a pop up.
Alternate flow: Open user agreement
To create a new account, the CloudMe’s user agreement must be accepted. Therefore, the user has to be able to read the user agreement within the application. By pressing a button in the remote, the user agreement should appear/disappear on top of the screen.
3.1.4
Open media file
This is a primary use case and is one of the main features of the application, since achieves the second objective. This use case has a prerequisite: the user has to be logged in.
3.1. FUNCTIONAL REQUIREMENTS CHAPTER 3. DESIGN
3.2. DESIGN GOALS CHAPTER 3. DESIGN
Basic flow
When the user selects a media file the application has to run the following type of files according to the specifications of each type:
• Audio File
It must start the reproduction of the file in the same scene. It also needs to display in the scene the volume, which song is playing and the current duration of the reproduction. When the file is playing, it must provide buttons to control the reproduction. The user has to be able to stop the music, control the volume, play next song or pause it. • Video File
It has to be opened in full screen mode and start playing the file. It has to provide buttons to control the reproduction. The controls needed are volume control, play, pause, stop, fast forward and rewind. Additionally, the file name and the current duration must be displayed. • Image File
As the video file, it has to be opened in full screen in a new scene. Alternate flow: Image slide show
It has to provide a slide show functionality, that is, when selected, it has to display all the images in the folder until stopped by the user. It should also be possible to move to the next or previous image by pressing one button in the remote.
Alternate flow: Printing an image
The image scene should provide a button to print the current displayed image. However, the printing functionality is optional as it is not supported by every TV and printer.
3.2
Design goals
In the following paragraphs we will explain the main issues that have been taken into account while designing this application.
The main goal is to develop an application that provides a good user ex-perience. Two important aspects to achieve a good user experience are the responsiveness and the ease of use. If it takes to long to perform a desired task, it is highly probable that the user would get bored and stop using it. A more detailed design of the responsiveness is o↵ered in Section 3.5. To implement an easy to use application, the user interface has to be clear. In other words, the user interface has to be so that a user knows at every moment what he/she has to do to perform a task. The user interface is
3.3. ARCHITECTURE CHAPTER 3. DESIGN
detailed in Section 3.4.
CloudMe is already ready to be used in multiple platforms. In order to give a user a di↵erent experience, we have to focus on the advantages of a TV. The main advantage of a television is the screen size. Therefore, the application will be focused on multimedia. Hence, special attention is going to be given to audio and video reproduction and also to the display of images. Another important aspect is the compatibility. Since Samsung changed the internal rendering engine from Gecko [12] to WebKit [36] in the 2012 ver-sion of the televiver-sion, a special care has to be taken in compatibility between this two models, as probably most of the users will not have a 2012 model. Therefore, it has to be compatible with both 2012 and 2011 TV devices. The modularity and extensibility of the application is also important be-cause this is not the final version of the application. This will make the application easier to maintain and to add new features. Therefore, it is es-sential to structure the application into modules to make it is easier to add new functionalities. Thus, the scene based architecture for the views has been chosen, as each scene performs a limited number of tasks. Adding new scenes with new functionalities to the current application does not interfere with the previous system.
It is absolutely essential to build a secure application. To improve the secu-rity of the application, some design decisions have been made. For example, when it is not possible to use digest authentication due to limitations of the web engine, HTTPS (secure HTTP) [15] is going to be used instead of HTTP, so the communication with the server is encrypted.
3.3
Architecture
The application for the Samsung SmartTV has to follow the Samsung’s AppsFramework [29] to be able to use the scenes. This framework provides a high level API which provides a set of features to the application. The architecture is detailed in Figure 3.2. In this figure we can see that the Apps-Framework (highlighted with the red border) contains a framework API, UI component API and a service API. The framework API is used to control the basic and core functionalities for the applications. UI component API is used to add components such us buttons or scroll bars to the application. It is based on a modified jQuery version. Service API is used for specific TV functionalities. These can be image or video viewing, opening USB disk or using a di↵erent kind of remote controller. In Figure 3.2 we can also see the methods onStart and onDestroy which belong to the application
(high-3.3. ARCHITECTURE CHAPTER 3. DESIGN
lighted with the green border). These methods are the entry and exit point of the application (the first and last methods to execute).
Figure 3.2: Application framework structure [29].
The user interface is based on scenes (see Section 3.2). A scene is a layer, which consists of a JavaScript file, a HTML file and a CSS file, that can be displayed in the TV. The scene manager (inside Framework API in Figure 3.2) is in charge of showing or hiding each of the scenes, so only one of them is focused at a time. Each scene is in charge of a particular task, so there are scenes to login, to sign up, to view the user’s drive, to display images, to play video. The use of scenes also helps to the extensibility of the application, as it is easy to add a scene with a particular task, without modifying the previous system.
Even though the MVC architecture (see Section 2.3.6) is one of the most popular architectures for web applications, and had been considered as a possible technology for design, due to the usage of the AppFramework and its scenes, it has not been completely followed. Nevertheless, since it o↵ers good features to web applications, the application is divided in a similar way. The similarity with the MVC architecture comes as follows. In our archi-tecture, the views are the scenes, as they contain the files related to the user
3.4. USER INTERFACE CHAPTER 3. DESIGN
interface and how the user interacts with the application. The controller is divided in two modules controller.js and storage.js. The controller.js mod-ule is in charge of displaying the corresponding scene and to communicate with di↵erent modules to perform operations. The storage.js module is in charge of storing the application data. Finally, there is one module in charge of performing the queries to the server (similar to the model in a MVC ar-chitecture).
However, there are also some di↵erences between our architecture and the MVC paradigm. For example, in our application, the scenes also manage scene-specific functions. This means that the scenes have two purposes. First, they are in charge of the layout of the application. Secondly, they are in charge of some operations that take place within the scene. Regarding the model, instead of communicating directly with the database, it commu-nicates with another model in the server side.
An image of the architecture of the application can be seen in Figure 3.3. In this figure, the arrows mean that the modules communicate with each other. We can also observe that each scene contains its view (.html file), its view format (.css file) and scene-specific functions (the .js file).These functions include a handler for button pressing, functions to change the view content, and functions called when the scene is shown or hidden. The non-specific functions are in the controller and can be accessed from any scene. Finally the model performs all the queries to the database through HTTP requests when requested by the controller.
One of the reasons to imitate the MVC architecture is that is makes easier to maintain the application by o↵ering a great modularity. For ex-ample, in this kind of application, where the user interface is one of the most important features, it o↵ers the possibility to change it easily without modifying the rest of the code.
3.4
User interface
The design of the user interface for a TV application presents some unique aspects that have to be considered. Some of the most important ones that make the UI of a TV application di↵erent from classical web UI, is the fact that the user has to navigate through the application using a remote con-troller. In a TV application, the navigation with the remote controller is based on four directional arrow buttons. In the following paragraphs we will explain some other aspects to keep in mind while developing the UI. Giving feedback to the user is necessary to make the usage of the appli-cation easier. One way that this feedback is given is by letting the user
3.4. USER INTERFACE CHAPTER 3. DESIGN
Figure 3.3: Application architecture
know in which element the focus is set. This will be done by adding some border to the element, changing the background color or changing the font color. It is also important to give feedback when the application is perform-ing an action and has to wait. This can happen, for example, when waitperform-ing for the data from the server to arrive. In this case an animated image will appear in the middle of the TV and will remain until the action is finished. Finally, in order to help the user not to get lost throughout the application, the folder route is always displayed in the screen. If this feedback is not given, the user would not know in which point of the folder structure is. This may lead to a misuse of the application and in the end not been used at all.
As said before, the application is controlled by a remote. Hence, compared to a web application controlled by a mouse, there are more buttons that can be used. The usage of these buttons has to be consistent with the knowledge
3.4. USER INTERFACE CHAPTER 3. DESIGN
the user may have (for example, the play button should reproduce some kind of media). They also have to be consistent with the Smart Hub environment [28], in the sense that identical buttons should perform the same task in the Smart Hub and in every application. This is essential to improve the appli-cation usage learning curve. If a button is used to perform a task with no possible common prior knowledge, its function has to be clearly defined by stating its functionality on the screen. Normally, in the Samsung SmartTV, these buttons are defined in the helper bar of the application which is lo-cated in the footer. Nevertheless, as more buttons than can be fitted in the bar are planned to be used, a special menu is displayed with extra buttons functions, as it can be seen in Figure 4.4.
As this application is intended to display multimedia content, a HD res-olution will be selected. Since 1080p resres-olution needs more bandwidth and some televisions do not support it, a 720p resolution has been chosen. This resolution may be changed in future versions, when greater bandwidths will be available. It is important to adapt also the size of the elements to make it legible.
The Samsung guide-line defines some mandatory items that the applica-tion must contain. One of these items is, for example, displaying the user name in the left side of the help bar.
As the user will be sitting at around 2-3 meters from the TV, instead of the normal distance to mobile phones or computer screens, the legibility of the application has to be strongly considered. The font size and images used have to be big enough to be seen perfectly by a person with normal sight. To fulfill these requirements match with Samsung requisites, a minimum font of 21 pixels is going to be used.
As the users may be familiar with using the web version of CloudMe [5], it is necessary to maintain certain similarities to make the learning process of the application faster and easier (see appendix A).
The navigation within the scenes is detailed in Figure 3.4. In this flow diagram, we can observe which scene is shown when a particular button is pressed. The button is specified in the arrows. To emphasize the color of the button, some arrows have been drawer in the same color as the button. The most important scene is the drive scene because from this scene the user can move to any of the scenes except the sign up one. We can observe also that the folder navigation is controlled by the buttons Enter and Return.
3.4. USER INTERFACE CHAPTER 3. DESIGN
3.5. RESPONSIVENESS IMPROVEMENT CHAPTER 3. DESIGN
3.5
Approaches to responsiveness improvement
In order to build the application suitable in term of responsiveness, the fol-lowing decisions have been made.
3.5.1
Separate the JavaScript files
With this decision, we try to reduce the booting time of the application. To achieve it, the JavaScript files have been separated into modules. The application only loads dynamically those files that are needed. Therefore, the application booting time is decreased as it does not need to load all the files before the screen is rendered. This is done in two ways:
• Since the first scene to show is the login scene, it is the one that will a↵ect the booting time. Most of the files are needed to perform the login operation, but these files are needed after the user actually press the login button. These files are not needed to display the login scene itself. Given this fact, the following decision has been made to improve the booting time. The application shows the login scene and then it loads the needed JavaScript files to login asynchronously. This can be done because the user needs time to insert their user name and password and this time is greater than the time needed to load these files, specially because it has to be introduced using the remote con-troller. In other words, while the user is typing their credentials, the application is loading the needed files to perform the login operation. However this method can only be done if the user needs to provide their credentials. If the credentials are stored from previous login, the files need to be loaded in advance.
• The part of the code that is needed to create an account is not normally used (the user is not supposed to create an account every day). Thus, it is only loaded if the sign up scene is shown. In the same way as the previous point, it loads the files while the user is typing.
A test is going to be performed in Section 6.1 to calculate the improvement of the booting time by using these techniques.
3.5.2
Reproduction bu↵er size
It is essential to set the reproduction bu↵er to a correct value to avoid the video stop to many times and to avoid to wait too long before the reproduction starts. The bu↵er size is determined by the network jitter, that is, the variation of the network throughput. According to Ozbek and
3.5. RESPONSIVENESS IMPROVEMENT CHAPTER 3. DESIGN
Tunali [24], a bu↵er size to hold data that is transmitted within 5 seconds is suggested when the network jitter can not be known. To calculate the bu↵er size, the duration of the video and its size is needed. However, the application does not know the duration of the video in advance. Therefore there is a initial bu↵er that is estimated by using the throughput. The network throughput is estimated when the application starts. For example, if the video should start within the next 5 seconds, the initial bu↵er size has to be 5 times the network throughput. Additionally a limit is set to avoid very large initial bu↵ers when the throughput is big.
initialbu↵ersize = networkthroughput⇤ 5s
Then, when the information of the video is fetched, the video bit rate is calculated using this formula:
bitrate = videosize videoduration
The total bu↵er size is recalculated to 5 seconds with the formula:
bu↵ersize = bitrate⇤ 5s
3.5.3
Number of files ordered to server
The sequence of actions that occur when a user opens a folder is the follow-ing. First, a request is sent to the server asking for the folders inside the current folder that is being opened. Second, another request is sent asking for the files in that folder. The second request has a parameter that is the number of files requested from the server. If the total number of files in the folder is very large, the time needed to get all that data is quite large. Therefore, the number of requested files is changed according to the user’s network throughput. The objective is to make the loading time of the files less than 0.5 seconds, as stated in the objectives in Section 1.2.
However, following this approach, more requests are sent and it would ac-tually take more time to load the images. Thus, to make the application more fluid, when the first response from the server reaches the television, its content will be displayed. The remaining requests then are sent in the background and are added to the files grid when their response is received. The advantage of using this method is that the user can navigate between files before all of them are loaded. A sequence diagram of this process can be seen in Figure 3.5
3.5. RESPONSIVENESS IMPROVEMENT CHAPTER 3. DESIGN
Figure 3.5: Open folder sequence diagram
3.5.4
Pre-load of images
For a correct and quick visualization of images, specially in the slide show, two approaches have been followed.
• Loading the images before displaying them:
The time needed to download an image from the server varies depend-ing the size of the image and the network throughput. Therefore, if the network throughput is slow, more images will be pre loaded since it needs more time to download. The number of images to pre load is set when the network throughput is estimated. When an image is opened, the application pre loads the number of images previously settled.
• Select a suitable image to download:
CloudMe’s back-end not only stores the original image but also dif-ferent copies of itself in di↵erent sizes. The maximum resolution of the application is 1280x720 pixels (see Section 3.4). This implies that images can not be larger than that. However, if an smaller image is chosen, the quality will be worse. Therefore, an image of 1280x720 pixels is preferred. Since the server does not have a 1280x720 image we are going to use the smallest image stored in the server which is big-ger than the application resolution. In this case, the image resolution is 1600x1200 pixels.
3.5. RESPONSIVENESS IMPROVEMENT CHAPTER 3. DESIGN
Table 3.1: Number of images pre-loaded
Network throughput (Mbps) Download time (s) Images needed
0.5 32 7 1 16 4 2 8 2 5 3,2 1 8 2 1 10 1.6 1
We have assumed that a user spends an average time per image of 5 seconds and an average file size of 2MB for the given resolution (1600x1200 pixels). Considering given the previous approaches, we have calculated the number of files that are pre loaded for di↵erent network throughputs. The results can be observed in Table 3.1.
3.5.5
Minify
Minify is the process of getting rid of all unnecessary characters from the code, such as white spaces or comments. The files are going to be minified for deployment. This reduces considerably the size of the application, and therefore makes it faster to load. The tool chosen to minify the application is JS Minifier [17].
Chapter 4
Implementation
In this chapter aspects from the implementation are explained.
4.1
Controller
The controller performs multiple operations within the application. Some of these operations are the estimation of the network throughput, login and logout operations, handle the files and play music. The handling of files refers to choose what to do when the user press the enter button in a file.
4.1.1
Estimation of the network throughput
As seen before, the network throughput is needed to set some parameters in the application. To get an estimation of it, the following approach has been followed. An image whose file size is known is downloaded from the CloudMe server. The time needed to download it is measured. Algorithm 1 explains how the estimation of the network throughput is calculated. Additionally, the steps to estimate the network throughput are:
1. A random number is added at the end of the image address. The reason to do this is to avoid the browser to use a previously cached image.
2. A new image variable is created.
3. The source of this image is assigned to the address generated in the first step. Once is done, the request to the server is sent. Therefore, the initial downloading time is set.
4. When the image is received, the onload method of the image is called. 5. The end time is set.
4.1. CONTROLLER CHAPTER 4. IMPLEMENTATION
6. The download time is calculated by subtracting the end time and the initial time.
7. Then, the network throughput in bits per second is calculated by using this formula:
networkthroughput = imagesize(bits) downloadtime(s)
Algorithm 1 Estimation of the network throughput url imgUrl + random
img NewImage img.src url
startT ime timeNow while img not received do
wait end while
endT ime timeNow
downloadT ime endT ime startT ime
networkSpeed imageSize(bits)/downloadT ime(s)
This whole process is repeated 20 times and then the average time is calculated. The reason to do this is because there can be network errors, for example, produced by network congestion. Therefore, if it is only calcu-lated once, it can lead to an erroneous estimation of the network throughput. Once the estimation is done, it assigns values to the necessary param-eters. The network throughput has been separated in 5 intervals: below 1Mbps, from 1 to 3 Mbps, from 3 to 6 Mbps, from 6 to 10Mbps and over 10Mbps. The reason to discretize the network throughput is because we have to assign values to the number of files fetched (as specified in Section 3.5.3).
4.1.2
Login and Logout
The user name and the password introduced by the user in the drive scene are received by the controller. The controller then encrypts the password using a hash function. The hashed password and the username are given to the model. The model creates a request with a login SOAP action to the server to check the credentials. If the authentication succeeds, the controller asks the model for the content of the root folder and send that information to the drive scene to display it.
4.1. CONTROLLER CHAPTER 4. IMPLEMENTATION
To logout, the controller erases all the variables that have been used and all the user data for security and memory usage reasons. Then, it sends a message to inform the server that the user is logged out. Finally, it redirects the user to the login scene.
4.1.3
Handle files
The controller decides what to do when a user press the enter button to open a file. Firstly, it reads the mime type of the file and then compares it to check if it can be opened. There are multiple options:
• MP3 audio file
It plays the file as shown in the next subsection. • Video file
Calls the video scene with the file. • Image file
Calls the image scene with the file. • Other file
If the user tries to open an unsupported file type, a message is displayed in a pop-up. This gives feedback to the user.
This process is explained in Figure 4.1.
4.1.4
Play music
If an audio file is selected, the controller creates a play list. This play list is an array which contains the file info (url, song name, artist, album) received from the server of each song in the current folder. Then an instance of the player plug-in (which belongs to SEF Plugin [26]) is created and the repro-duction of the song starts. Additionally, the file name is displayed in the drive scene to know which song is being played. To view the reproduction time, the player has a method (onCurrentPlayTime) that is called every second. This method returns the time in milliseconds the audio has been played. The controller formats this number into hours, minutes and seconds, i.e., HH:MM:SS, to improve the visualization. Additionally, a progress bar of the reproduction time is displayed. To create the progress bar, we proceed as follows.
Firstly, two div elements have been superposed in CSS with the same height, one with white background and the other with blue. The audio controls can be seen in detail in Figure 4.1.4. When the reproduction time is fetched, it is calculated as a percentage of the total. Then the width of the blue bar, initially set to zero, is changed using this percentage adapted to the length
4.2. MODEL CHAPTER 4. IMPLEMENTATION
Figure 4.1: Open file flow diagram
Figure 4.2: Music player UI
of the bar.
The reason that the play list is created is that when the song finishes, the next one is played. In this way, the user can still listen to the songs belonging to one folder even if he/she moved to another folder. This play list is maintained until it is overwritten by playing another audio file in another folder.
4.2
Model
Every time a request is needed to be sent to the server the model is called. These HTTP requests need to contain the authentication header which is constructed among others with the user name and the password. Otherwise,
4.3. SCENES CHAPTER 4. IMPLEMENTATION
an unauthorized message will be received from the server. Therefore, when the user logs in, the model needs to store the user name and password. There are two possible ways of doing this: storing them in a global variable or inside another function. The first approach is not safe, since its value can be overwritten any time. Thus, the second approach has been followed. One function has been created (called outer function) which has the user name and the password as attributes. Then, the functions (inner functions) that make the query to the server are inside the outer function. Therefore, the user name and password are only accessible inside the outer function, which is safer. When the user logs in the outer function is called and when a query is needed, one of the inner functions is called.
Before a request is sent to the server, a SOAP message [31] has to be created. In the same way, when the response is received, the model has to unsoap the message and then send the XML information to the controller.
4.3
Scenes
In this section the di↵erent scenes used are explained.
4.3.1
Drive scene
This scene is divided in three parts: in the left side there is a grid with the folder and files, on the right side there is an options menu and below the menu there are the audio controls. An image of the drive scene can be seen in Figure 4.3.1. Additionally, on the top-left corner the user account info is displayed. In the rest of the section, we will explain the grid and the menu in more detail.
The drive scene shows the folder and files in a grid. When a folder is opened and the response is received from the server, the controller sends two arrays to the drive scene containing the name of the folders and the files in the current folder. Firstly, the scene goes over the folders and then over the files. For each file or folder, the scene selects the icon that corresponds to its file type and draws it in its position in the grid. The position in the grid is the position of the array, drawing first the folders and then the files. Each row contains seven items (folders or files). If the file is an image, the thumbnail is requested from the server. Finally, since the user needs to know which element is the focus set on, a border is going to be drawn around the position of the element in the grid.
The navigation inside the drive scene is done using the arrows buttons from the remote controller. The main drawback of any remote controller is that the user needs to go through all the elements one by one. As the menu is located in the right side, the user may have to go through all the
4.3. SCENES CHAPTER 4. IMPLEMENTATION
Figure 4.3: Drive Scene UI description
files in a row to reach it. Therefore, we have developed a di↵erent approach to facilitate using the menu. In particular, this approach takes advantage of the number of buttons in a remote controller. To use the menu, the user needs to press the numbers from 1 to 6, instead of moving the focus to the menu. Each number corresponds to one task. The menu with the numbers assigned to the task can be seen in detail in Figure 4.4. In the same way, to use the audio controls, the buttons play, pause, fast forward and rewind are used. However, these buttons do not need to be specified because are present on the Samsung remote controller.
4.3.2
Folder scene
This scene lets the user select the folder in which the previously selected items are going to be copied or moved. It provides a folder tree. To display this folder tree a request needs to be sent to the server in order to know which folders belong to the current folder. When the scene is first shown, the folders belonging to the current folder are displayed. The user can navigate in the folder tree by pressing the left button, to open the parent folder and the right button to open the selected folder. This scene is shown
4.3. SCENES CHAPTER 4. IMPLEMENTATION
Figure 4.4: Menu detail
when copy or move functions are selected. Therefore, a variable is needed to know which action it should perform when pressed enter in a folder. This scene can be seen in Figure 4.5.
4.3.3
Image scene
This scene is in charge of image displaying. There are two significant aspects about the image scene: image loading and its displaying. In the following we discuss these aspects in detail.
First, before the image is displayed, it has to be loaded. To get the image, a request to the server is needed. During the time that the image is fetched from the server, the user needs to know that it is actually being downloaded. Thus, a loading image is displayed until the image is loaded. Afterwards, the image is displayed at a full screen size if it is bigger than the screen or at its maximum possible size. Once it is displayed, the process of pre loading the next images starts. This is done to let the user visualize the rest of the images quicker. The requests for these images are sent in parallel to the server and when downloaded, the images are stored in an array. If the user moves to the next or previous image, the application gets the following image. Therefore, when the user reaches its position, it is already loaded. For example, if the user opens the image number 5, when displayed, it will pre load number 6, 7 and 8. If then the user moves to number 6, the server will ask for the ninth.
Secondly, when an image is displayed, both horizontal and vertical align-ment is required to improve the appearance of the application. This is a problem because the size of the image is not known in advance (before the image is completely loaded). In addition, the image has to be displayed in the maximum dimension. This means that if the image is bigger than the screen it will be scaled to fit the screen’s width or height, maintaining the
4.3. SCENES CHAPTER 4. IMPLEMENTATION
Figure 4.5: Folder scene description
image width/height ratio. To do this, the max-width and max-height CSS properties [22] of the image has to be set to 100%. To center the image, jQuery and CSS has been used. To center the image horizontally the CSS property margin is set to auto. This makes that the distance from the image to the border from both sides is the same. A excerpt from the CSS centering code can be seen in Listing 4.1.
Listing 4.1: Excerpt of centering code
#SceneImageScene img{ display:block; margin:auto; max-width:100%; max-height:100%; }
To center the image vertically the height of the image is needed, but this is not known until the image is actually displayed. Therefore, the only possibility if the height is not known, is displaying the image at the top of the screen and then moved to the center. This presents an issue because the user would see the image moving. To avoid it, the image is displayed hidden, that is, the div visibility CSS property is set to hidden. Then, the image’s height and width is read using jQuery. With these values, the aspect ratio (width / height) is calculated and compared to the screen’s one (16:9 for panoramic screens). To know if the image has to be repositioned, the pseudo-code in Algorithm 2 has been used. Finally the image’s top position
4.3. SCENES CHAPTER 4. IMPLEMENTATION
is changed using jQuery and its div is set to visible.
Algorithm 2 Calculate Distance to top
if 16/9 < ratio AND (height > 720 OR width > 1280) then top (720 (height⇤ 1280/width))/2
else if height < 720 then top (720 height)/2 else top 0 end if end if
4.3.4
Login scene
The login scene is in charge of getting the user name and the password from the user to perform the authentication. Before sending any data to the controller, the log in scene performs a validation process. This helps in order to avoid sending already known wrong login requests to the server and congesting the network. The validator checks that the user name or the password are not blank and if there is a valid network connection, that is, if the television’s wireless or Ethernet cable is connected. This is done by using the network plug-in provided by Samsung SDK. If the validator fails, a pop up shows and the request is not sent. On the other hand, if it succeeds the user name and password is sent to the controller which processes the information.
4.3.5
Sign up scene
This scene is in charge of getting the user’s data to create an account. Thus, it shows input fields that the user has to fill. The user can move from one input field to another by pressing up or down buttons on the remote controller. The focus is then moved to the next or previous element. The data from the filled fields is validated each time the user presses a button in an input field. In the case of the email, a validator checks that @ sign and a dot are present and that is something written before the @ and after the dot. This validator can be seen in Algorithm 3.
In the case of the user name, it has to send a request to the server to know if it is already in use. This may seem a waste of network bandwidth, as more HTTP requests are needed and the server already validates the user name. However, this has been done in order to let the user know in real time if the selected user name is available. The sign up scene can be seen in Figure 4.6.
4.3. SCENES CHAPTER 4. IMPLEMENTATION
Figure 4.6: Sign up scene description
4.3.6
Video scene
This scene handles the reproduction of videos.To control the reproduction of videos there are some buttons in the remote controller, such us play and pause that have been used. Additionally, these controls have been displayed in the screen to give feedback to the user with some information about the status of the reproduction. Finally, to avoid disturbing the visualization of the video, the on screen controls are going to be hidden five seconds after the last button is pressed. To be able to achieve this, the method setTimeout [35] from JavaScript has been used. This method executes a certain action after some time has passed. To prevent the controls disappear after five seconds any button is pressed Algorithm 4 has been implemented. There is a variable startTime that records the last time any button was pressed. If the variable startTime minus the current time is greater than 5 seconds, the on screen controls are hidden. The variable startTime is updated every time a button is pressed.
Fast forwarding and rewinding the video are two features that are nec-essary in video reproduction. Since the application only stores five seconds of reproduction in the bu↵er, implement them in video streaming is not an easy task: the video has to be received from the server. Therefore, instead
4.4. PROBLEMS CHAPTER 4. IMPLEMENTATION
Algorithm 3 Email validator lastAtP os lastpositionof@ lastAtDot lastpositionofdot
if lastAtP os < lastDotP os AND lastAtP os > 0 AND lastDotP os > 2 AND (length lastDotP os) > 2 then
return T RU E else
return F ALSE end if
Algorithm 4 Hide video controls if AnyButtonP ressed then
return startT imer end if
while currentT ime startT imer < 5 do W ait
end while
HideOnScreenControl
of implementing real fast forwarding and rewinding, the e↵ects of these op-erations are going to be imitated. To accomplish it, a method from the TV (jumpForward ) that can move the position of the reproduction is used. This method is called every 100ms as long as the user does not press another but-ton in the remote. The reproduction time will move then from the current time some seconds forward or backward. Additionally, the user can control the number of seconds the video is moved by pressing FF or RW buttons multiple times.
4.4
Problems and workarounds
In this section some problems that have been found out during the devel-opment of the application are pointed out. Also, if a workaround has been implemented it will be explained as well.
4.4.1
Authentication
A problem has been found when implementing the authentication in the 2011 television model. In order to authenticate an HTTP message is sent to the server. This message is generated using the jQuery.ajax method [19]. The server then responses with a 401 unauthorized message which contains a www-authentication header. This header has the information necessary to create a digest authentication header.
4.4. PROBLEMS CHAPTER 4. IMPLEMENTATION
In the 2012 television model, when this message is received by the televi-sion, it reads the header and automatically adds the authentication header to another message. As this message contains the authentication, the server responds with a 200 Ok message. However, we have observed that in the 2011 television model this answer is not generated.
Therefore, another approach has been taken in this model: instead of us-ing the jQuery.ajax method, which internally uses XMLHttpRequests, the XMLHTTPRequests are going to be generated manually. When the unau-thorized response is received from the server, the www-authentication header is read and its information parsed to generate a digest authentication header. Once it is created, it is sent back to the server, which now responds with an OK message. This authentication method needs two request-response mes-sages to succeed. However, as we already know the authentication header, every time a request is sent to the server the authentication header is added. This is done pre-emptively to avoid congesting the network. Therefore, the authentication header is stored. It can happen that the authentication cre-dentials from the server have changed. In these cases, another query will be sent with the updated header.
The authentication header has to be sent in every request to the server. This presented some difficulties in the fetching of images, video and audio files from the server, because we needed to send this header somehow. In web browsers, the authentication header is added automatically or the browser prompts the user for the user name and password. The solution found to this problem is to use an url in the form http://username:password@server. This type of URL is interpreted by the browser and the user name and the password are introduced in a digest authentication header after the server responses with the www-authenticate header.
4.4.2
Loading images in the 2011 model
While implementing the image scene, it has been found out that in the 2011 TV models the maximum number of files than can be loaded is 5. This limitation does not allow some images to be displayed as they can not be loaded. We have approached this issue as follows. When an image is going to be displayed, it first checks whether the application has already tried to fetch the image or not. If this is the case, the array containing the images is destroyed and created again. Then, the next 5 images are preloaded. How-ever, this solution is not perfect as the application will not be as fluid as it should, since it has to wait before an image is loaded every five images.
4.4.3
Fetching data from a XML response
There are also some di↵erences in the behavior of the 2011 and 2012 TV models in how they fetch the data from a XML response. In the 2011 TV
