Second Life on a Mobile Phone
Nii Annan
September 2011
Dissertation submitted in partial fulfilment for the degree of
Master of Science in Information Technology
Department of Computing Science and Mathematics
University of Stirling
Abstract
Second Life™ is a multi-user virtual world which provides a three dimensional space shared by a
number of avatars. They interact with their environment and one another through instant messaging
as well as voice communications. The Inter-life project is developing a private island on Second
Life to provide an educational research space aimed at finding ways to aid young people in developing social skills and navigating difficult transitions in their lives [1]. On this private island, the
number of avatars in world at any given time may be small. This could make going in-world uninviting and thus overall interest reduces.
The objective of this project was to change this by allowing a user to see who was in-world using a
mobile phone application. This project aimed at developing a mobile phone application which
would display a map of the Inter-life Island and indicate the current location of users online. The
mobile platform of choice was an HTC 7 Trophy Windows Phone device running a Release Candidate version of Microsoft’s Windows Phone 7.5 operating system code named “Mango”.
Methodology involved determining the requirements of the application, analysing the components
needed, designing the system, implementation of software code and testing the application to eliminate errors.
The most significant achievements in this project included, creating a log-in user interface, the map
interface and features for showing the information of avatars online as well as plotting their location on the Inter-life Island map. A basic version of Twitter was also developed (Twittledoo) and
incorporated within the main Inter-life application for sending messages.
i
Attestation
I understand the nature of plagiarism, and I am aware of the University’s policy on this
I certify that this dissertation reports original work by me during my University project except for
the following:

The Code for the Twitter Client was helped developed by Dennis Delimarsky
Signature
(you must sign and date this page)
ii
Date
Acknowledgements
This project would not have materialized without the help and guidance of a few people.
Sincere gratitude goes to Cliff Simpkins (Senior Product Manager; Windows Phone Developer Experience) who gave me the green light to use the freshly released Windows Phone Mango Beta for
this work. In his words and I quote “You're good to use this to develop apps for a school project,
and present about it and whatever”
I would like to thank Dr Mario Kolberg for being of tremendous help during this period for giving
me various insights as to how the Inter-life server works. Much appreciation also goes to Professor
Magill and Dr Karla Parussel who gave me a detailed description of the Inter-life server architecture. Many thanks go to Dennis Delimarsky for helping out with the twitter code used within the
Inter-life Windows Phone application. Much appreciation goes to Marco Giuliani for helping out
with sections of the code in my work. Thanks to Pablo Almunia for supplying me with C# books
and reference materials.
Finally, loads of appreciation goes to all the staff at the Institute of Computing Science and Mathematics as well as course mates who made this entire academic year at the University of Stirling a
part of my life I will always cherish.
iii
Table of Contents
Abstract .................................................................................................................................. i
Acknowledgements ..............................................................................................................iii
Table of Contents ................................................................................................................. iv
List of Figures ..................................................................................................................... vii
1 Introduction...................................................................................................................... 1
1.1 Background and Context .......................................................................................... 1
1.2 Scope and Objectives ............................................................................................... 2
1.3 Achievements ........................................................................................................... 2
1.4 Overview of Dissertation ......................................................................................... 3
2 State-of-The-Art............................................................................................................... 4
2.1 Second Life™ .......................................................................................................... 4
2.2 The Inter-Life Project............................................................................................... 4
2.3 Second Life Apps ..................................................................................................... 4
2.4 Developing Applications for Windows .................................................................... 6
2.4.1 The .NET Framework ......................................................................................... 6
2.4.2 Programming in C-Sharp (C#) ............................................................................ 7
2.4.3 Relationship between C-Sharp and the .Net Framework .................................... 7
2.4.4 Versions of Windows Phone – Brief Overview................................................... 8
2.4.5 Microsoft’s answer to Windows Mobile OS – Windows Phone ......................... 8
2.4.6 Market Share Projections .................................................................................... 8
2.4.7 Networking and Web Services for Windows Phone ........................................... 9
2.4.7.1 Using Sockets on Windows Phone .............................................................. 9
2.4.8 Character Encoding for Windows Phone .......................................................... 10
3 Early Stages of Development ........................................................................................ 11
3.1 Requirement Phase ................................................................................................. 11
3.1.1 Use Case Diagrams for the System ................................................................... 11
3.1.1.1 Use Case for Component 1: Login and Avatar Details.............................. 11
3.1.1.2 Use Case for Component 2: Communication Support .............................. 12
3.1.2 Class Diagrams for the System ......................................................................... 13
3.1.2.1 Class Diagram for Component 1 ............................................................... 13
3.1.2.2 Class Diagram for Component 2: Communication Support...................... 14
3.2 Designing the User Interfaces of the System ......................................................... 17
4 Implementation Phase .................................................................................................... 19
4.1 Visual Studio Express for Windows Phone IDE .................................................... 19
iv
4.1.1 Writing XAML ................................................................................................. 20
4.1.2 Code Behind...................................................................................................... 20
4.2 Walkthrough of Apps Key Functionalities ............................................................. 21
4.2.1 SocketClient Class ............................................................................................ 21
4.2.2 SignInPage Class .............................................................................................. 21
4.2.3 MapPage Class .................................................................................................. 22
4.2.4 String Manipulation: Highly Essential .............................................................. 23
4.2.5 AvatarStuff Class .............................................................................................. 25
4.2.6 Plotting Avatar Location ................................................................................... 26
4.2.7 Twittledoo – in-built Twitter Client for Inter-Life App Messaging .................. 28
4.2.7.1 Registering an application name with Twitter - Twittledoo ...................... 28
4.2.7.2 AuthConstants Class ................................................................................. 29
4.2.7.3 UserTwitterStuff Class .............................................................................. 29
4.2.7.4 UrlConstants Class .................................................................................... 30
4.2.7.5 OAuthClient Class..................................................................................... 30
4.2.7.6 Twittledoo and Authentication Process ..................................................... 30
4.3 Testing .................................................................................................................... 34
4.3.1 Testing for Suitable Encoding ........................................................................... 34
4.3.1.1 Sending data using Unicode (little-endian) ............................................... 34
4.3.1.2 Receiving data using Unicode (little-endian) ............................................ 34
4.3.1.3 Receiving data using Unicode (big-endian) .............................................. 34
4.3.2 Testing Range of Values for Plotting Avatar Locations .................................... 35
4.3.3 Multi-user Testing ............................................................................................. 35
4.4 Software Maintenance............................................................................................ 36
4.5 User Feedback ........................................................................................................ 36
5 Conclusion ..................................................................................................................... 37
5.1 Summary ................................................................................................................ 37
5.2 Evaluation .............................................................................................................. 37
5.2.1 What worked ..................................................................................................... 37
5.2.2 What did not work so well ................................................................................ 38
5.3 Future Work ........................................................................................................... 38
5.3.1 Region Expansion ............................................................................................. 38
5.3.2 Traveling Across Regions ................................................................................. 38
5.3.3 Real Time Chatting Experience ........................................................................ 38
5.3.4 Empty Strings from Inter-life server ................................................................. 38
5.3.5 Automatic Updates............................................................................................ 39
5.3.6 Log out Button .................................................................................................. 39
v
5.4 Miscellaneous Bits ................................................................................................. 39
5.4.1 Pushing mobile hardware to its limits ............................................................... 39
5.4.2 Limited Knowledge of Programming in C# ..................................................... 39
References ........................................................................................................................... 40
Appendix 1 .......................................................................................................................... 41
vi
List of Figures
Figure 1.
Avatars interacting with each other in Second Life........................................................ 1
Figure 2.
Screenshot of PocketMetaverse for iOS......................................................................... 5
Figure 3.
Market Shares of Mobile Operating Systems [15] ......................................................... 9
Figure 4.
Client-Server Communication using Sockets on Windows Phone [16] ....................... 10
Figure 5.
High-Level Use Case Diagram for Component 1 ........................................................ 12
Figure 6.
High-Level Use Case Diagram for Component 2 ........................................................ 12
Figure 7.
Class Diagram for Component 1 .................................................................................. 14
Figure 8.
High-level Class diagram for Communication Support System of the app ................. 15
Figure 9.
General Assembly of Classes ....................................................................................... 16
Figure 10. Screenshots of Splash Screen and Login user interface ............................................... 17
Figure 11. Screenshots of Inter-life Island Map and Messaging user interfaces ........................... 18
Figure 12. Visual Studio Express for Windows Phone .................................................................. 19
Figure 13.
Screenshot of the Windows Phone Emulator ............................................................... 20
Figure 14.
Shows a typical .cs code behind for the sign in page .................................................. 21
Figure 15.
Screenshot of avatar at location (33,33) on the InterLife app ..................................... 27
Figure 16.
Screenshot of avatar at location (33,33) in-world........................................................ 27
Figure 17.
Screenshot showing Twittledoo as a registered Twitter application ............................ 28
Figure 18.
Twitter page showing OAuth settings for Twittledoo ................................................. 29
Figure 19.
Shows the Authentication process and messaging for the InterLife app ..................... 30
Figure 20.
Acquire PIN page of the phone and the Twitter Authorization homepage .................. 31
Figure 21.
Generated PIN after authorization process is completed and confirming PIN in the
Acquire PIN page ..................................................................................................................... 32
Figure 22.
Twitter message sent from the InterLife app’s twitter messaging client .................... 33
Figure 23.
Twitter Message from the InterLife app on twitter.com .............................................. 33
Figure 24.
Map Showing multi-users online ................................................................................ 35
vii
1 Introduction
More and more sophisticated hand held devices are released nearly every quarter of the year. Most
manufactures, programmers and developers have therefore harnessed the idea of developing powerful applications for these devices.
These days, one does not have to power up their computer in order to log into just one desktop application, for example Windows Live Messenger. Small devices such as mobile phones have made
it possible to gain access to programs which otherwise would have been exclusive to desktops.
Mobile phone applications have become popular in recent times. These applications serve as a miniaturized version of a ‘real’ desktop application. Though their functionality is limited to the mobile
device they are built for, they nonetheless hold the key or core functionality of the main product.
In the next sections and chapters, an in depth discussion will be made on how the idea of mobile
phone applications was used to develop an Inter-life application for accessing the Inter-life Island
on Second Life.
1.1
Background and Context
Second Life is a multi-user 3D virtual world, shared by a number of avatars as shown in figure 1.
These avatars interact with each other and their environment through instant messaging and voice
communications. Second Life is in a lot of ways similar to the popular online game called The
SIMS.
Figure 1. Avatars interacting with each other in Second Life
1
The Inter-life Island is a private Island on Second Life. For this reason, the number of avatars in
world at any given time may be small. Going in-world becomes uninviting and thus overall interest
wanes. Section 1.2 briefly outlines the approaches taken in order to alleviate this issue.
1.2
Scope and Objectives
This project involved building a mobile phone application that would enable users of the Inter-life
Island view other avatars in-world.
The objectives:

To develop the application on a mobile phone platform running Microsoft’s Windows Phone 7.5 OS.

To establish a socket connection between the Inter-life application and Inter-life
server in order to retrieve the details of avatars online.

To extract the relevant data sent from the server which include the number of avatars
online, their names and location coordinates in-world.

To plot their exact location on a 2D Inter-life Island map in the application

To device a suitable means of communication between users of the application and
avatars in-world.
1.3
Achievements
This section sheds light on the important achievements made in the project. The next few paragraphs give a brief overview of what was accomplished.
A login user interface was designed which collects a user’s name and password. These are sent over
a secure TCP connection between the Inter-life application and the Inter-life server for authentication. After authentication, the user is granted access to a page which displays the Inter-life Island
map.
A refresh button on the map interface when clicked sends a query to the Inter-life server requesting
the information of avatars in-world. The information returned includes the number of avatars
online, their names and location coordinates. This data was then manipulated in order to plot their
exact location on the map.
Each avatar’s position on the map is represented by an instance of an interactive miniature button.
The properties of an avatar – name and coordinates are “wrapped” around these buttons. Clicking
any “avatar button” on the map therefore displays, the avatar name and coordinates in a text block
below the map as will be demonstrated in later chapters.
2
In addition to all this, a twitter messaging client was also developed as part of the project. Twitter
messages are sent from the application to twitter.com and finally delivered in-world. Messages
from in-world are delivered to the users main twitter account.
All the designing and coding was made possible using Microsoft's Visual Studio Express for Windows Phone (the main Interactive Development Environment). Microsoft Visual Studio 2010
Ultimate was also used for generating Use Case diagrams and Class diagrams.
1.4
Overview of Dissertation
Chapter 2 covers work already done relating to this MSc project in question. It also looks at a few
technological advancements developers need to familiarize themselves with before attempting to
delve into programming applications for any Microsoft Windows platform. These include understanding what the .Net Framework is. A brief overview of the present Windows Phone 7.5 OS will
also be looked at as well past versions and why in the next few years Windows Phone devices will
become popular amongst the masses.
Chapter 3 takes a deeper look into the software development cycle of the project, covering the requirements for the project, critical analysis of the problem at hand and the design phase.
Chapter 4 focuses on the implementation phase of the software development life cycle, testing and
maintenance.
Chapter 5 mainly covers the conclusion of the project, as well as limitations of the software, recommendations and future work.
3
2 State-of-The-Art
2.1
Second Life™
Second Life is a virtual three dimensional world developed by Linden Lab. Free client programs
enable Second Life users, to interact with each other through avatars. Users can explore this virtual
world, meet other residents, socialize, take part in individual and group events. The age restriction
for users of Second Life varies and there are various clauses for people aged, 13-15, 16 and 17 as
well as 18 years and over [2]. Second Life was launched on June 23, 2003 and has about a million
active users as of 2011 [3].
These client programs have a built-in 3D modeling tool based around simple geometric shapes allowing residents to create virtual objects. A scripting language, known as Linden Scripting
Language, can be used to add interactivity to objects [4]. An in depth look at Second Life is beyond
the scope of this project. Further information about Second Life can be obtained here [5].
2.2
The Inter-Life Project
The Inter-life project aims at harnessing the power of 3D virtual worlds such as Second Life to help
young people develop social skills and navigate difficult transitions in their lives. The team working on the Inter-life project have developed a private 3D island –the Inter-life Island to help with
this research. They are looking at 2 groups, the first are gifted and talented children and the second
are first year university students.
Visitors to the island can engage in creative and confidence building activities in a safe and supportive online environment.
There is an in-world monitoring system which logs back-end activity and positional data at the dedicated server at the University of Stirling [6]. It is this positional data that aids in plotting avatar
locations on the mobile device.
2.3
Second Life Apps
There are quite a number of Second Life mobile applications. A fully functional Second Life application which supported the Second Life 3D world was released on Samsung mobile devices back in
2008. The Second Life client for Samsung cellular devices had some notable features. They included a mixed blogging platform that allowed users to post their blog synchronously in the real world
and Second Life’s virtual world. The Samsung Mixed Contact feature also allowed users to have
mixed world interactions by communicating with avatar friends through voice or short text messag4
ing. The Second Life client was compatible with Samsung mobile devices running Windows Mobile OS [7].
While this seemed like a good idea mobiles devices, usually do not have state-of-the-art hardware
to handle the intensity of such applications. They normally eat away phone resources such as
memory and battery life.
There is also a version of Second Life on the iPhone called PocketMetaverse. Users can have a real-time chat experience with members in-world, as well as from app to app. PocketMetaverse
enables users to teleport from one region to another and it also covers a wide region of the Second
Life grid. All the maps on PocketMetaverse are in 2D. Figure 2 shows as screenshot of PocketMetaverse for the iPhone.
Figure 2. Screenshot of PocketMetaverse for iOS
In addition to the apps already discussed above, Xin Li of the University of Stirling also worked on
an app for the InterLife Island. However, the development platform was the Android operating system. Its main features included plotting avatar locations on the InterLife map as well as a chat
function for communicating with avatars.
The features of the app being built for this current project include the ability for users to see their
contacts online on a 2D InterLife map. Another important attribute is the ability to see their exact
location and coordinates on the map. It also incorporates a communication platform using a Twitter
5
API for interacting with avatars in-world. Most importantly this is one the first apps for the InterLife Island specifically programmed for devices running Windows Phone 7.5.
Developing Applications for Windows
2.4
Before developing any application for Windows devices, be it desktop computers, laptops, notebooks, tablets or even mobile devices; one needs to acquaint themselves with some state-of-the-art
Microsoft Technologies. Obviously these came up during the research stages for this project and as
such deemed it necessary to include their discussion in this report.
2.4.1
The .NET Framework
The .NET Framework is a programming infrastructure created by Microsoft. It is an integral Windows component which supports the development and running the next generation of applications
and XML Web services [8]. The .NET aspect in the Framework’s name should not be misconstrued
as being a purely Internet-focused framework. The .NET tag in the name is there to reiterate Microsoft’s belief that distributed applications, in which the processing is distributed between client
and server, are the way forward [9].
The .NET Framework is designed to bring to realization these objectives:

To make available a coherent object-oriented programming environment whether object
code is stored and executed locally, executed locally but Internet-distributed, or executed
remotely.

To yield a code-execution environment that brings to a minimum software deployment and
versioning incompatibilities.

To provide a code-execution environment that promotes safe execution of code, including
code created by an unknown or semi-trusted third party.

To provide a code-execution environment that discards the performance problems of
scripted or interpreted environments.

To make the developer experience consistent across widely varying types of applications,
such as Windows-based applications and Web-based applications.
To build all communication on industry standards to ensure that code based on the .NET Framework can integrate with any other code [10].
6
The .NET Framework contains 2 major parts:

The Common Language Runtime
Short for Common Language Runtime, a runtime environment that manages the execution
of .NET program code and provides services such as memory and exception management,
debugging and profiling, as well as security. The CLR is a major component of the .NET
framework. The CLR also is known as the Virtual Execution System [11].

The Framework Class Library
This is the collective name for the thousands of classes that compose the .NET Framework.
The services provided by the FCL include runtime core functionality (basic types and collections, file and network I/O, accessing system services, etc.), interaction with databases,
consuming and producing XML, and support for building Web-based and desktop-based
client applications, and SOAP-based XML Web services [12].
There is a downgraded .NET Framework version on handheld devices running Windows operating
systems like the Windows Phone. This version of the framework has limited functionality which
obviously matches the hardware capabilities of the devices they run on.
2.4.2
Programming in C-Sharp (C#)
Main programming for most Windows devices is C#, C++, Visual Basic (VB) or F++. With the
help of the .NET Framework all these programming languages are interoperable. C# was developed
by Microsoft and just like any other programming language is objected oriented. It provides a
means for coding almost any type of software or component that is needed to be written for the
Windows platform. Between them, C# and .NET have revolutionized the way developers write
their programs and have made programming on Windows much easier than it has ever been before
[13].
2.4.3
Relationship between C-Sharp and the .Net Framework
The .NET Framework is the most significant technology for developers at present, .NET is designed to provide an environment within which you can develop almost any application to run on
Windows, while C# is a programming language that has been designed specifically to work with
the .NET Framework. By using C#, you can, for example, write a dynamic web page, a Windows
Presentation Foundation application, an XML Web service, a component of a distributed application, a database access component, a classic Windows desktop application, or even a new smart
client application that allows for online/offline capabilities [14].
7
2.4.4
Versions of Windows Phone – Brief Overview
What is now known as Windows Phone was actually the successor of the Windows Mobile operating system. Over the last decade or so, there were numerous versions of Windows Mobile operating
systems. The very first version debuted as the Pocket PC 2000 operating system in April 2000 running on PDA devices. The operating system metamorphosed into several other different versions
until Windows Mobile 6.5- released to manufactures in May 2009.
The earlier versions of the operating system enjoyed a great deal of success with the consumer
market, especially business organisations. The inception of the iPhone running iOS, by technology
giants Apple in 2007 revolutionised the whole mobile phone industry. The sleek features and design
of the iPhone caught on very fast with consumers. This dealt a heavy blow to Windows Mobile’s
market share.
Not long after Apple introduced the iPhone, Google also shipped out their Google Android mobile
operating system. This went on further to cripple the Windows Mobile operating system which at
that time was struggling to recapture its original consumer market from Apple, amongst others.
2.4.5
Microsoft’s answer to Windows Mobile OS – Windows Phone
As a result of the difficulty Microsoft faced with its waning sales in the mobile technology industry,
there came a need for a total reboot of Windows Mobile, basically starting from scratch. In February 2010, Microsoft unveiled the Windows Phone 7 operating system. This was a totally revamped
mobile operating system which bore no resemblance whatsoever to its predecessor Windows Mobile. The operating system is simply referred to as Windows Phone. On October 21 2010, Windows
Phone was launched in Europe, Singapore and Australia. It was launched on November 8 2010 in
the United States and Canada.
2.4.6
Market Share Projections
The International Data Corporation (IDC) predicts that by 2015 Windows Phone worldwide sales
will beat devices running Apple’s iOS, and will be second to the Android operating system. The
table on page 9 shows the projected market shares of all the mobile platforms by the year 2015.
8
Figure 3. Market Shares of Mobile Operating Systems [15]
2.4.7
Networking and Web Services for Windows Phone
2.4.7.1
Using Sockets on Windows Phone
Windows Phone 7.5 supports the use of socket connections, TCP and UDP. This feature is not supported in version 7.0. The use of sockets played a very important role in this project. TCP was used
in communicating with the InterLife server. Figure 4 shows a typical TCP socket connection using
Windows Phone.
To communicate over TCP, a connection must be established between the client and the server. The
endpoint to which the client wants to communicate must be defined as part of the connection request. This is an asynchronous operation in Windows Phone.
Data can be sent from client to server once connection is established. It does so by setting up a
buffer of data and passing it to the server. TCP is stream-based and the order in which the data is
received is guaranteed to be in the order in which it was sent. The TCP protocol takes care of this
ordering and reliability for the transmission.
The client can request to receive data from the server. This is an asynchronous call and, if successful, the resulting callback will contain the buffer of data that was sent.
Once the client has finished communicating, it calls shutdown to inform the server that the socket
is terminating. This call is used to make sure the remaining data from the server is received before
the socket disconnects. Finally, the client disconnects the socket and closes the communication
channel.
9
Figure 4. Client-Server Communication using Sockets on Windows Phone [16]
2.4.8
Character Encoding for Windows Phone
At present Windows Phone supports 3 types of character encoding, they include UTF8, and
Unicode which uses an encoding of the UTF-16 format that uses little-endian byte order and the
BigEndianUnicode which uses an encoding of the UTF-16 format that uses big-endian byte order.
All information sent from the Inter-life app for Windows Phone to the Inter-life server relied on the
BigEndianUnicode character encoding compatible with that of the Inter-life server whose encoding
is also UTF-16 based.
10
3
Early Stages of Development
Requirement Phase
3.1
The project required devising a means to enable users view avatars in-world on the InterLife Island
by using a mobile device. This was to be done by developing an application on a mobile device
running Windows Phone. The application would have a sign in page for authenticating the user before any other functionality could be accessed. A map page was needed within the app for
displaying the Inter-life map. On this map, the exact location of the avatars in-world would be plotted. To top that all up, a twitter client would be needed for sending messages to avatars in-world.
An important part of the requirement phase was the ability to have a strong command over programming in C#.
With the general concept in mind further analysis could be made. These analyses included, developing use case and class diagrams. These diagrams made it possible in identifying the necessary
components needed to be assembled to make the application fully functional. Use case and class
diagrams offer a high-level understanding of the various functions of the application.
The components for the system were split into 2 major parts:

Component 1 – this covered parts for login and avatar information retrieval

Component 2 – this covered parts for the application’s communication support
3.1.1
Use Case Diagrams for the System
Use case diagrams describe the functionality of a system and users of the system. The diagrams
contain the following elements:
3.1.1.1

Actors - represent users of the system, including human users and other systems.

Use cases - represent functionality or services provided by a system to users.
Use Case for Component 1: Login and Avatar Details
Illustrated in figure 5 is a high-level use case diagram for the project. It involves interactions between the user, the app, InterLife and Second Life servers. The user interacts with the InterLife app
to login. The InterLife app communicates with the InterLife server by sending logged in details to
verify the user’s credentials. After successful verification, the map page is accessible to the user
who then proceeds to interact with the map page to view avatars in-world. Before avatars on the
map are revealed, the InterLife app contacts the InterLife server again, this time requesting the details of avatars in-world. The InterLife server in-turn puts in a request to the Second Life server to
11
retrieve the number of avatars in-world, their names and location coordinates. This information is
sent back and finally reaches the application.
Figure 5. High-Level Use Case Diagram for Component 1
3.1.1.2
Use Case for Component 2: Communication Support
The user might also want to send an avatar a message. The InterLife server uses a fixed Twitter account (@interlife.user2) which is used to receive Twitter messages from the built-in Twitter client
for the InterLife app. The server checks for Twitter messages from this account and relays any messages to the Second Life server which will then convert these messages to in-world messages. The
use case diagram in figure 6 breaks down the possible scenario for sending messages. Before any
messages can be sent from the in-built twitter client, the user needs to authorize the app to use their
twitter credentials. After the authorization process is completed, secure messages can be sent from
the application. There is an in-depth coverage of this process in section 4.2.7.6.
Figure 6. High-Level Use Case Diagram for Component 2
12
3.1.2
Class Diagrams for the System
Class diagrams describe the static structure of a system, or how it is structured rather than how it
behaves. These diagrams contain the following elements:

Classes, which represent the entities with common features. These features include attributes, methods and associations.

Associations, which represent relationships that relate 2 or more other classes where the relationships have common characteristics or features. These features include attributes and
methods.
Having generated the use cases for the project, further drilling could be done in determining the
key classes needed. The next sub-sections cover the classes developed for components 1 and 2.
3.1.2.1
Class Diagram for Component 1
The classes for component 1 of the Inter-life app included the following:

StartupControl

SingInPage

SocketClient

LoadingControl

MapPage

AvatarStuff
Figure 7 illustrates a high- level class diagram showing the associations between these main classes.
The StartupControl is associated with the SignInPage class on a 1 to 1 basis. The SignInPage contains only 1 instance of the StartupControl class at runtime. The StartupControl class is needed for
controlling the behaviour of the application when it is first activated which involves the popping up
of a splash screen. The SignInPage class handles the details logged in by the user. It has a 1 to 0...1
association with the SocketClient class. Meaning, it either has no instance or 1 instance of the socket client when the user attempts the log in procedure. The SocketClient class handles the TCP
socket connection established between the InterLife app and InterLife server for data transfer.
The LoadingControl class is responsible for the behaviour of the application after the login procedure is complete. It handles a similar popup to that of the StartupControl class. It has a 1 to 1
relationship with the MapPage class which contains an instance of the LoadingControl class.
13
Similar to the SignInPage class, the MapPage class either has no instance of the SocketClient or 1
instance of it when the command is given to retrieve avatar details. Therefore their association is a
1 to 0…1 relationship in this case. AvatarStuff class handles the storage of avatar information. The
MapPage class has a 1 to 0…* relationship with it because it either has no instance of AvatarStuff
or multiple instances.
Evaluating the nature of this architecture, clearly the StartupControl and LoadingControl classes do
not play any major role in the core functionality of the app. The splash screens they generate were
only introduced to enhance the ‘beauty’ of the app. Nonetheless they still contribute in making the
app look more realistic. A more serious look at the SignInPage, SocketClient, MapPage and AvatarStuff classes is covered in section 4.2.
Figure 7. Class Diagram for Component 1
3.1.2.2
Class Diagram for Component 2: Communication Support
The structure of the communication support system rather looks complex. This is shown in figure
8. This component has a total of 9 classes but only 7 are shown here, the other 2, the AuthConstants
and UrlConstants classes hold static constant variables and these values do not change. The
OAuthClient class serves as the main gateway for external connectivity with the Twitter API. It
contains methods for sending and receiving http web requests and responses. It has a 1 to 1 relationship with the IsoStoreHelper, UserTwitterStuff, TweetPage and BannedParams classes. The
AuthPage class has a 1 to 1 relationship with the OAuthClient, StringHelper and UserTwitterStuff
classes. A look at the most important classes within this component is covered in section 4.2.7
14
Figure 8. High-level Class diagram for Communication Support System of the app
The IsoStoreHelper class stores the users twitter credential into memory and it is the most important link between Component 1 and Component 2. This is shown in the final assembly of the
classes as seen in figure 9 on the next page. It is linked to the MapPage class.
The important point to note about the class design of the system is that, even though the general
layout of the class seems frightening, majority of the classes generated from the project could have
been embedded in other classes. Some of these classes held only variables. The reason for separating them out was to avoid code clutter, as well as making them publicly available to other classes.
15
Figure 9. General Assembly of Classes
16
3.2
Designing the User Interfaces of the System
The mind set behind the design of the application, was to create an application that would give its
user a true sense of realism when they powered it up. Questions such as, what would the user want
to see when the application was launched and the general appearance of the software were asked.
This led to designing a splash screen which would introduce the user to the application (Illustrated
in figure 10).
Figure 10. Screenshots of Splash Screen and Login user interface
The user needs to be authenticated before accessing the full functions of the application. The login
user interface (shown in figure 10) was also added to the design of the system to take care of this
situation. The login user interface pops up after the introductory splash screen. It has the name of
the application displayed at the very top of the page which also adds that feel of a realism. In order
to give a Second Life user interface perception, font color was kept in mind too.
The login interface has fields for keying in the users name and password as well as a sign in button.
The user also has an option of signing up for Second Life if not already registered. This link takes
the user to the Second Life webpage. Once authentication is complete, another splash screen pops
up and this gives the user an impression the next page (map page) is loading. Note that the
authentication procedure is fully discussed in section 4.2.2.
17
The map page shows a static Inter-life Island map, which displays avatar locations obtained from
the Inter-life server. An appbar feature is also implemented as shown in figure 11. The refresh
button triggers the whole server connection method for retrieving avatar details. The mechanism
behind is discussed later in section 4.2.3.
Figure 11. Screenshots of Inter-life Island and Messaging user interfaces
The ‘write’ button when clicked navigates to the messaging infrastructure of the app and from here
messages are sent out (figure 11). This is discussed into greater detail in section 4.2.7.
18
4 Implementation Phase
4.1
Visual Studio Express for Windows Phone IDE
Figure 12. Visual Studio Express for Windows Phone
The implementation phase heavily relied on Microsoft’s Visual Studio Express for Windows Phone
(figure 12). This is a complete development environment for creating Windows Phone applications.
Visual Studio 2010 Express for Windows Phone includes features such as a Windows Phone-based
design surface, a code editor, Windows Phone project templates, and a Toolbox that contains Windows Phone controls. In addition, Visual Studio 2010 Express for Windows Phone enables
debugging and deployment of applications on a Windows Phone Emulator or a Windows Phone
device. Figure 13 shows a screenshot of the emulator.
The leftmost part of the figure shows the toolbox; elements could be dragged and dropped on to the
design viewer or for better precision, XAML code could be written (code on far right). This
depends entirely on the developer and what they find easier to work with. In this project, a
combination of both was used.
19
Figure 13. Screenshot of the Windows Phone Emulator
4.1.1
Writing XAML
Short for extensible application mark up language, this is a very powerful tool when it comes to the
actual design of the user interface. Visual Studio allows developers the opportunity to either drag
and drop child elements from the toolbox onto the design viewer or write actual XAML code for
these child elements. Each XAML page has a ‘code behind’ .cs file. The .cs extension simply
stands for C-sharp. A XAML page is as good as dead with no functionality whatsoever without its
code behind.
4.1.2
Code Behind
As, the name implies, is the code that adds functionality to the xaml page. These normally
represent a class. So for example the SignInPage class refers to the class that adds functionality to
actual SignInPage.xaml file. Figure 14 shows a section of the code behind for the sign in page. All
coding was done is in C#. The next section covers the walkthrough of the key functionalities of the
application, including the discussion of the important classes that add these functionalities where
necessary.
20
Figure 14. Shows a typical .cs code behind for the sign in page
4.2
Walkthrough of Apps Key Functionalities
The whole Inter-life system has 15 classes in total. However only, the most relevant ones
concerning the core functionality of the application will be discussed. For example, classes such as
the StartupControl class and the LoadingControl class barely have an impact on the applications
core functionality; these are User Control classes. The StartupControl is responsible for generating
a pop at the launch of the application. This splash screen introduces the name of the application to
the user and stays active for only a minimum number of seconds. The LoadingControl class, also
serves the same purpose. It pops up after the logging in process, giving an indication the next page
is loading in the background. The important twitter client classes will be discussed in section 4.2.7
4.2.1
SocketClient Class
The socket client class, has methods for establishing a connection with the interlife server, a
method that handles sending of queries to the server as well as one for receiving server responses.
It also has a close method, for shutting down the socket connection when all data transfer is
completed.
4.2.2
SignInPage Class
On clicking the sign in button, that is after user enters the correct username and password, an
instance of the socket client class is created. The details are sent in a particular format. Most
21
importantly is the encryption of the password. The password encryption algorithm uses SHA1
cryptography. The code snippet below shows a typical example of the encryption process
SHA1 mySHA1 = new SHA1Managed();
byte[] SomePasswordBytesStoredHere = Encoding.UTF8.GetBytes(password);
byte[] myHash = mySHA1.ComputeHash(SomePasswordBytesStoredHere);
string hexPassword = BitConverter.ToString(myHash);
hexPassword = hexPassword.Replace("-", "");
The resulting byte array is converted to a hexadecimal string before being sent to the server for verification. The server returns a response of either a 1 or 0 values. Based these values, the user is
either granted access or denied access to use the application.
4.2.3
MapPage Class
This class contains methods for querrying the InterLife server for details of avatars in-world. The
refresh button on the map page triggers these events. The details returned to the application, are
stored in a string variable. These include, a concactenation of the number of avatars online,
followed by the actual length of the avatar name, the avatar name, the x,y and z coordiantes of the
avatar. A typical example of a returned string looks like this:
string avatarDetailsFromServer = “ 16 Emperar Resident\0!\0!\0!”;
This was a typical example of the string output interpreted by Windows Phone. The special characters (exclamations) within this string are meant to be integers representing the x, y and z
coordinates. Windows Phone however interprets these as ASCII decimal character symbols. There
is a space in front of 16; usually ASCII decimal character symbols less than 33 are not printed.
Nonetheless there exists a character in that position whose decimal equivalent is 1. The value 1 represents the number of avatars. The conversion from a decimal ASCII symbol to its equivalent
decimal digit was calculated using the code shown below:
int decimal = Convert.ToInt32 (someASCIICharacter);
This converts an ASCII character to its equivalent decimal format. The decimal value representing
the number of avatars can easily be picked out by using this code:
int avatarNumber = Convert.ToInt32 (avatarDetailsFromServer[0]);
The daunting task now was to find a way of pulling apart the string and extracting the relevant avatar details for plotting its location on the map. This is discussed in the next section.
22
4.2.4
String Manipulation: Highly Essential
Analysing the string returned from the server, it was observed that, the first thing to consider was
splitting the string along the delimiter ‘\0’. The result was then stored in a string array. The line of
code below demonstrates this process:
string [] split = avatarDetailsFromServer.Split (delimiterChars);
The z value is irrelevant for the purposes of plotting points on a 2D map, so it was necessary to
ignore the last index of the split array. Note that for 2 or more avatars online, this algorithm devised
will cut off the z value of the last avatar in the string.
The new string array resulting from the split had a size of the length of the split array minus 1. Split
string array was looped through with the index stopping short at the length of the array minus 1.
The code below handles this operation:
string[] newStringArray = new string[split.Length - 1];
for (int i = 0; i < split.Length - 1; i++)
{
newStringArray[i] += split[i];
}
The newStringArray looks like this:
string[] newStringArray = {“ 16 Emperar Resident”,”!”,”!”};
The next step was to extract the first index, which is the string at index 0 within this array. The
code below shows the exact working. A loop is run through and only the string whose index modulo 3 equals 0 is considered.
int p = 0;
for (int names = 0; names < newStringArray.Length; names++)
{
if (names % 3 == 0)
{
Names[p] = newStringArray[names];
p++;
}
}
The Names array now contains the number of avatars, the length of the name string and the avatar
name. Taking a closer look at newStringArray what needs to be done now, is extract the x and y
coordinates. This was achieved by using this loop:
int m = 0;
for (int k = 0; k < newStringArray.Length; k++)
{
if (k % 3 != 0)
{
xyNewStrings[m] = newStringArray[k];
m++;
23
}
}
As can be seen from the above code, only the strings at indices 1 and 2 are taken out and stored in
the new xyNewStrings array. Having, x and y in one string array further drilling had to be done to
split these up into x only and y only values stored in different arrays. These values were stored in
separate arrays, as shown below. To pick up x only values, it was necessary to observe indices of x
values, and upon carefully analysis it was discovered that all x values occurred at an index modulo
2 equals 0. The resulting array of x only values were then stored in xNewStrings array.
int n = 0;
for (int j = 0; j < xyNewStrings.Length; j++)
{
if (j % 2 == 0)
{
xNewStrings[n] = xyNewStrings[j];
n++;
}
}
For y only values the same approach was used, except that, y only occur at index modulo 2 not
equal 0. Thus the code below
int b = 0;
for (int j = 0; j < xyNewStrings.Length; j++)
{
if (j % 2 != 0)
{
yNewStrings[b] = xyNewStrings[j];
b++;
}
}
Thus, yNewStrings holds the new y values.
The whole idea of manipulating the string returned for the server this way enables the final combination of values at the same indices across the 3 major string arrays – Name, xNewStrings and
yNewStrings. This is demonstrated in the following code below by using a for loop. It is observed
here that the size of the final array is always the same as int avatarNumber, thus the code below:
for (int fc = 0; fc < avatarNumber; fc++)
{
finalCombo[fc] = newName[fc] + xNewerStrings[fc] + yNewerStrings[fc];
}
The final result, from the server is now stored in string array in this form:
finalCombo[] string = new string {“ 16 Emperar Resident!!”};
It must be noted that, that above manipulation works for multiple avatars as has been tested – refer
to section 4.3. It might seem like a crude way of working with the server string but at the time of
24
development all other alternatives did not produce good results. For singles avatars online a for or
while loop can be used to extract the relevant details, but this falls short with multiple users online.
The next section throws some light on handling finalCombo and plotting avatar location on the
map.
4.2.5
AvatarStuff Class
The processing of finalCombo happens here. The finalCombo array has exactly the format being
sought after. An instance of AvatarStuff called Av is created in MapPage, together with an AvatarStuff array called AvatarItems which stores the avatar details. The code snippet below handles
this situation
AvatarStuff Av = new AvatarStuff();
AvatarStuff[] AvatarItems = new AvatarStuff[avatarNumber];
for (int ava = 0; ava < finalCombo.Length; ava++)
{
AvatarItems[ava] = Av.returnAvatar(finalCombo[ava]);
}
In the code above for every string in finalCombo, method returnAvatar from AvatarStuff is called.
The ‘processed’ avatar information is finally stored in AvatarItems. The returnAvatar method is
seen below.
string someCharDigits = "";
int m = 2;
for (int i = 1; i < g.Length; i++)
{
if (Char.IsNumber(g, i) && !Char.IsWhiteSpace(g, i))
{
someChars += g[i];
m++;
}
else
break;
}
The first index of the original string is ignored. This is because it only represents the number of
avatars and is not relevant at this stage of processing. Thus the index always starts at int i = 1.
Note that g is finalCombo string passed into the constructor.
The loop first checks for any digits which in this case is 16 representing the length of the avatar
name. It breaks off at the next white space. The digits are stored in the variable someCharDigits
and converted to an integer (see code below) used to extract the avatar name.
int value = int.Parse(someCharDigits);
for (int a = m; a < value + m; a++)
{
AvatarN += g[a];
}
25
Avatar.AvatarName = AvatarN;
Avatar.x = Convert.ToInt32(g[value + m]);
Avatar.y = Convert.ToInt32(g[value + m + 1]);
return (Avatar);
Next a loop is run to retrieve the avatar name. From critical observation the beginning of the avatar
name always starts at index m (from the previous code snippet). What is left now is to extract x and
y. The index of x always starts at value+m+1 and y at value+m+2. The results are then returned as a
whole unit (“Emperar Resident”, 33, 33). The exact format wanted. This is then stored in an array
AvatarItems mentioned earlier. Thus:
AvatarStuff[] myAvItems = {new AvatarStuff("Emperar Resident",33,33)};
4.2.6
Plotting Avatar Location
A for each loop is run through AvatarItems. The button method for displaying avatar location as
buttons on the screen is called. For each AvatarItems there is an avatar name, their x and y coordinates. The relevant parameters are slotted in to create the property of the ‘avatar button’. As shown
in the button creation code below.
public void myButtonMethod(string buttonName, int x, int y)
{
Button avatarButton = new Button();
AvatarButton.Name = buttonName;
AvatarButton.Height = 45;
AvatarButton.Width = 45;
AvatarButton.Content = buttonName + " (" + x + "," + y + ")";
AvatarButton.Background = new SolidColorBrush(Colors.Blue);
AvatarButton.BorderBrush = new SolidColorBrush(Colors.Yellow);
AvatarButton.Margin = new Thickness(-5 + (x * 7 / 4), 78 + (256 - y) * 7 / 4, 0, 0);
AvatarButton.HorizontalAlignment = HorizontalAlignment.Left;
AvatarButton.VerticalAlignment = VerticalAlignment.Top;
AvatarButton.Click += new RoutedEventHandler(Butt_Click);
LayoutRoot.Children.Add(AvatarButton);
}
Figure 15, illustrates the avatars location on the InterLife map on the app as well as showing its
coordinates. Figure 16 on the next page, shows the exact location in-world.
26
Figure 15. Screenshot of avatar at location (33,33) on the InterLife app
Figure 16. Screenshot of avatar at location (33,33) in-world
27
4.2.7
Twittledoo – in-built Twitter Client for Inter-Life App Messaging
The actual code for developing the main twitter client was obtained here [17]. However, the most
important things to note when developing a twitter client within an application will be discussed in
this section.
4.2.7.1
Registering an application name with Twitter - Twittledoo
In order to create a Twitter application one needs to go here [18]. As shown in the screenshot below
(figure 17). The Twitter client developed for this project was named Twittledoo. A Twitter Application Programming Interface (API) needs to be acquired for the desired application, in order to
communicate with Twitter servers.
Figure 17. Screenshot showing Twittledoo as a registered Twitter application
A registered Twitter application has an Open Authorization setting (OAuth), as shown in figure 18.
The consumer key and consumer secret are greyed out for security reasons.
28
Figure 18. Twitter page showing OAuth settings for Twittledoo
4.2.7.2
AuthConstants Class
This class stores values for the ConsumerKey and ConsumerSecret. These values should remain a
secret at all times and should not be exposed to the user. The strings shown in the example below
illustrate a typical example of what these values are:
namespace SecondLife.Twitter
{
public static class AuthConstants
{
public const string ConsumerKey = "GaaZvXv1PrI4l5ZeipXNg";
public const string ConsumerSecret = "tyP5x8KsbIEe7bYZEBmk4h1V7nKUZ8Le2MDNujiuY";
}
}
4.2.7.3
UserTwitterStuff Class
This class stores verified twitter credentials of the user, and these include the token, token secret,
user identification and username. The token serves an identifier or a key which tells the twitter API
that, the application in question is already verified. Below is a code snippet, showing the variables
in this class.
namespace
{
public
{
public
public
public
public
}
}
SecondLife.Twitter
static class UserTwitterStuff
static
static
static
static
string
string
string
string
Token;
TokenSecret;
UserName;
UserID;
29
4.2.7.4
UrlConstants Class
The class UrlConstants is a static class which holds variables that reference the URL endpoints that
are used in some sections of the application. These variables are the string RequestToken and string
AccessToken. The code snippet below shows the UrlConstants class.
namespace SecondLife.Twitter
{
public static class UrlConstants
{
public const string RequestToken = "https://api.twitter.com/oauth/request_token";
public const string AccessToken = "https://api.twitter.com/oauth/authorize";
}
}
4.2.7.5
OAuthClient Class
This is the backbone of the messaging client. It has methods for sending out requests to the Twitter
API as well as methods for receiving messages.
4.2.7.6
Twittledoo and Authentication Process
Figure 19. Shows the Authentication process and messaging for the InterLife app
Figure 19 shows the twitter authentication process for an app. A request token (oauth_token and
oauth_token_secret) is needed to start the authentication process for using an application as twitter
client. When the user hits the ‘Acquire’ button, the consumer key and consumer secret are sent out
30
first using the secure URL ‘RequestToken’ mentioned in section 4.2.7.4. The Twitter API returns the
request token of the application. This is needed for requesting the access token (oauth_token and
oauth_token_secret) for making secure calls after authorization. The Acquire Pin page and twitter
authorization homepage are shown in figure 20. The Acquire pin page pops up when the user hits
the ‘write’ button on the map page for the first time after installing the application.
Figure 20. Acquire PIN page of the phone and the Twitter Authorization homepage
After authorizing the app to use the user’s twitter credentials, a PIN is generated. This is shown in
figure 21. This PIN is needed to get the final token- the access token for making secure calls.
The access token is broken down into the oauth_token and oauth_token_secret as mentioned earlier. To get these values, the initial oauth_token, oauth_token_secret, comsumer_key and
consumer_secret as well as the PIN are sent out to the Twitter API using the secure URL ‘AccessToken’ in section 4.7.2.4. When the confirm button is hit these values are sent out in a query
request for the access token. In response the following are received; the access token, userid and
screenname associated with the twitter account. This process is hidden from the user. After confirmation the user can then navigate back to the map page and begin sending out tweets.
31
Figure 21. Generated PIN after authorization process is completed and confirming PIN
in the Acquire PIN page
So that the user does not have to go through the tiring process of twitter authentication these last
received values are stored using the StoreNewCredentials method shown here:
namespace SecondLife.Utility
{
public static class IsoStoreHelper
{
public static void StoreNewCredentials(string oAuthToken,
string oAuthTokenSecret, string userid, string screenName)
{
IsolatedStorageSettings settings = IsolatedStorageSettings.ApplicationSettings;
settings["oauth_token"] = oAuthToken;
settings["oauth_token_secret"] = oAuthTokenSecret;
settings["userid"] = userid;
settings["screen_name"] = screenName;
settings.Save();
}
The above code stores the user’s credentials in the phone’s memory using the IsolatedStorageSettings assembly. Twitter messages can now be sent from the InterLife app as shown in figure 22 and
they appear on twitter.com as shown in figure 23, both on the next page.
32
Figure 22. Twitter message sent from the InterLife app’s twitter messaging client
Figure 23. Twitter Message from the InterLife app on twitter.com
33
4.3
Testing
Testing the application was carried out on a step by step basis as development of the application
progressed. Both the White and Black Box testing methods were used for this project. The main
tools for testing and debugging the application were the Windows Phone Emulator and the Windows Phone HTC 7 device.
4.3.1
Testing for Suitable Encoding
The server side encodes data using a UTF-16 style format. Windows phone supports the little endian and big-endian Unicode formats, both UTF-16 with a different byte order (as their names
imply). Testing for a suitable style encoding was important so that the right format of data could be
exchanged between the InterLife server and Windows Phone.
4.3.1.1
Sending data using Unicode (little-endian)
Sending data from Windows Phone to the InterLife server using the little-endian style an “OperationTimedOut” response was received. This helped established the fact that the server could not
decode little-endian data. The encoding for sending data was switched to big-endian and that
worked successfully.
When receiving data, Windows Phone also needs to apply the right style of encoding to the data
string. This is discussed in the next 2 subsections.
4.3.1.2
Receiving data using Unicode (little-endian)
Applying the little-endian style encoding to the string received from the server, the output was as
follows:
“Ā㄀㘀 䔀洀瀀攀爀愀爀 刀攀猀椀搀攀渀琀\0℀\0℀\0”
Clearly, the string had the general format of avatar details - number of avatars, length of name, x, y
and z upon closer analysis. However, a more easily readable data string would be helpful. Thus,
next encoding to test out was the big-endian.
4.3.1.3
Receiving data using Unicode (big-endian)
Applying big-endian encoding, the output of the string received from the server looked like this:
“ 16 Emperar Resident\0!\0!\0!”
This was the nature of the string interpreted by Windows Phone. Even though it had special characters, this format nonetheless played a vital role in helping identify the best algorithm for
manipulating the server string discussed in section 4.2.4.
34
So clearly from these tests, it was established that the best encoding for sending and receiving data
between Windows Phone and the InterLife server was the big-endian.
4.3.2
Testing Range of Values for Plotting Avatar Locations
The InterLife Island 2D map image has a 255 x 255 pixel layout. Selected coordinates were used as
initial points for placing an avatar in-world to check these locations would show on the Windows
Phone’s apps 2D map. These coordinates included; (0,0) for the bottom left corner of the map,
(0,255) for the top left corner of the map, (255,255) for the top right corner of the map and (255,0).
The application encountered errors with all but (255,255). It however worked for (1,1), (1,255) and
(255,1). Further analysis showed the algorithm used to manipulate the server string, failed to work
for coordinates with either x or y being 0. The reason being that, the string manipulation method
splits the strings at ‘\0’ but the twist here is, ASCII character code for 0 is represented as null (‘\0’)
so there were extra delimiters ‘\0’ within the string! This is shown below:
“ 16 Emperar Resident\0\0\0\0\0!”
The consolation here is that, the extreme ends of the island are not likely to be accessed by users of
the InterLife Island. Nonetheless the problem still exists.
4.3.3
Multi-user Testing
The involved, testing whether the algorithm for string manipulation will work when multi-users
were online. Two avatars stood at random locations in-world and this was the image obtained – see
figure below.
Figure 24. Map Showing multi-users online
35
4.4
Software Maintenance
As seen during the testing procedures, the phone sometimes translated received strings into the
‘unknown’ character format ‘�’. This character was seen on the emulator and the windows device.
This indicates a serious flaw in probably the character main encoding algorithm of both the phone
and emulator. There is no certainty as to what the problem is. However, since the OS is a Release
Candidate version and not the final product, it will be given the benefit of the doubt. With this in
mind, in terms of maintenance, regular checks will be made to keep an eye out for the Ready to
Market version of the OS. As soon as the RTM version is released, the OS will be updated and the
application re-installed on the device to ensure it works properly.
Also, over time, phone manufacturers slate certain libraries and some forms of coding become deprecated. When a new operating system is released and these phones are updated, previously
installed apps on these devices are unstable when run. As such, constant updates will be looked at
to ensure the code within the app is adjusted according to any changes made.
4.5
User Feedback
To get user feedback about the application, a questionnaire was prepared with careful selection of
questions, pertaining to the general design of the system, user friendliness of the software amongst
a host of other pertinent questions.
Those who tested the app were actually impressed with the design of the user interfaces as well as
the whole structure of the system. However they were not too pleased about not being able to send
messages to avatars online due to the fact that the Inter-life messaging service was broken. On the
brighter side of things, they were impressed with the capabilities of the basic in-built twitter client
which is able to send messages out to twitter.com. A feature they wanted to see implemented was
the ability to receive twitter messages directly to the app and not have to log in online to view messages. They also suggested a ‘Clear’ button which will delete the stored twitter credentials from the
phone’s memory citing security reasons.
Still on the messaging capabilities of the software, majority suggested sending messages directly to
avatars online using a Second Life API. This way messages will be sent to Second Life servers and
on the whole any exchange of information will be done between the app and Second Life without
needing the Inter-Life server at all.
In summary user feedback was mostly positive and generally gave thumbs up to the app but still
maintained it could do with more improvements and a few tweaks. Indeed the software could do
with some more additional features.
36
5 Conclusion
5.1
Summary
Using a powerful Interactive Development Environment, Microsoft Visual Studio for Windows
Phone an application that shows avatar locations on a map was successfully developed on a Windows Phone device.
By communicating with the Inter-life server over a TCP socket connection. The app was able to
send queries to the inter-life server retrieving the details of any avatar online. The data sent back to
the app, was manipulated in different ways and the relevant details stored and used to plot avatar
location coordinates on a map.
In addition to plotting the exact location coordinates of avatars on the map. A twitter messaging
client was developed for sending messages to in-world users. A point well taking note of is that this
messaging service was specifically not tested, since at the time of development there was a major
fault with the Inter-life server twitter routing messaging service. However, as demonstrated in section 4.6 messages sent from the phone clearly show up on the twitter website. This gives an
indication the twitter client is functional. As soon as the Inter-life’s messaging service resumes the
code within the app could be modified to accommodate this.
5.2
Evaluation
5.2.1
What worked
The objectives outlined in section 1.2 were satisfactorily accomplished. First of all the application
was successfully developed on a device running Windows Phone 7.5 operating system. The core
functionalities of the application work well. Avatar details were able to be retrieved from the InterLife server and the data obtained was processed in order to display avatar positions in-world
exactly at the same location on the InterLife Island map within the app. A twitter client was successfully developed to handle messaging within the InterLife application. Though there is much
satisfaction with achieving the important goals of the project, there are still a few gray areas worth
looking into. Miscellaneous features such as splash screens were also used effectively. In addition
to that, an embedded code which alerts the user when there is no network access was also implemented.
37
5.2.2
What did not work so well
Firstly there was the issue with the unknown character error. These errors mainly popped up at login and retrieving avatar details from the InterLife server. Even though exception handlers were
embedded within the code to handle these errors, it still stopped the smooth flow of the app. The
issue was put before Microsoft and hopefully an updated version of the OS - RTM should have this
fixed.
In addition to the unknown character error problem, the string manipulation method for processing
returned avatar information from the server had some flaws within it. As seen in section 4.7.2.
Occasional glitches with the InterLife server sometimes hampered the smooth testing of the app.
For example, the server begins returning empty strings after the main Second Life servers were
updated and had to be reset before things run smoothly again.
Though messages can be sent from the twitter client successfully, it does not support receiving
messages so that part of the app is flawed. Exception handling within the twitter client did not handle errors properly. The future work section below touches on ways this application can be
improved.
5.3
5.3.1
Future Work
Region Expansion
This project can be expanded even further. It supports only the Inter-life Island. The app could be
developed such that, it covers a wide range of other islands in Second Life.
5.3.2
Traveling Across Regions
After region expansion, a teleportation feature could be implemented to help travel from one region
to another.
5.3.3
Real Time Chatting Experience
A real-time chatting experience would make the application more interesting to use. The messaging
system of the application currently relies on routing messages Twitter servers; the InterLife server
fetches these messages and then finally delivered in-world. In addition to the Twitter feature, the
app could be developed such that it communicates directly with Second Life servers. This will in
no small way enhance the messaging experience.
5.3.4
Empty Strings from Inter-life server
During testing, it was observed that, there were times when results obtained from the server contained empty strings. This happened regardless of an avatar being online. It was later discovered
38
that, Second Life servers occasionally get updated. When these updates occur, the Inter-life server
loses synch with the Second Life server. The Inter-life server needs to be rebooted manually when
this happens in order to restore synch.
Rebooting miraculously stops the empty strings but this is not a robust way of handling the situation. Hopefully the server could be reprogrammed to notice any changes or updates on the Second
Life servers and adjust to the changes accordingly.
5.3.5
Automatic Updates
One has to hit the refresh button constantly to update avatars on line. New code could be written so
that the updates happen automatically. A time interval could be set, for example to check updates
every minute, 2 minutes and so on.
5.3.6
Log out Button
A log out button unfortunately was omitted in this project. However, an expansion could see this
implemented.
5.4
5.4.1
Miscellaneous Bits
Pushing mobile hardware to its limits
This application’s functionality is restricted to just viewing avatars and their location on the map as
well communicating with them. This makes the application use not very exciting after a while. The
Institute of Computer Science and Mathematics at the University of Stirling could look into ways
of pushing the Windows Phone platform to its limits by developing a 3D Inter-life app.
5.4.2
Limited Knowledge of Programming in C#
Programming for Windows was interesting even though there was a lack of knowledge in programming in C#. This was overcome by reading loads of materials online and watching loads of
tutorials online as well. Even though it was quite exciting delving into all these materials, it was
time consuming. Hence, it may be a good idea for the Institute of Computer Science and Mathematics to introduce a module covering C# basics either on the Masters’ Program or Undergraduate
level.
39
References
[1] Technology Enhanced Learning, Projects, http://www.tel.ac.uk/inter-life/, September 2011.
[2] Second Life, Terms of Service, http://secondlife.com/corporate/tos.php, September 2011
[3] Philip Rosedale, Creator of Second Life, YouTube video, September 2011.
http://www.youtube.com/watch?v=C04wwLjJ0os, September 2011.
[4] Using the Linden Script Language, http://people.cc.ku.edu/~grobe/intro-to-LSL/, September 2011.
[5] Welcome To Second Life Wiki, http://wiki.secondlife.com/wiki/Main_Page, September
2011.
[6] Technology Enhanced Learning, Projects, http://www.tel.ac.uk/inter-life/, September 2011.
[7] Web 2.0 Asia, Samsung brings Second Life to mobile, http://web20asia.com/252, September 2011.
[8] .NET Framework Conceptual Overview, MSDN, http://msdn.microsoft.com/enus/library/zw4w595w.aspx, September 2011.
[9] Christian Nagel, Bill Evjen, Jay Glynn and Karli Watson, Morgan Skinner, Professional
C# 4 and .NET 4. Wiley Publishing, Inc., Indianapolis, Indiana, 2010.
[10] .NET Framework Conceptual Overview, MSDN, http://msdn.microsoft.com/enus/library/zw4w595w.aspx, August 2011.
[11] Webopedia, CLR, http://www.webopedia.com/TERM/C/CLR.html, August 2011.
[12] Webopedia, FCL, http://www.webopedia.com/TERM/F/FCL.html, August 2011.
[13] Christian Nagel, Bill Evjen, Jay Glynn and Karli Watson, Morgan Skinner, Professional
C# 4 and .NET 4. Wiley Publishing, Inc., Indianapolis, Indiana, 2010.
[14] Christian Nagel, Bill Evjen, Jay Glynn and Karli Watson, Morgan Skinner, Professional
C# 4 and .NET 4. Wiley Publishing, Inc., Indianapolis, Indiana, 2010.
[15] Winrumors, http://www.winrumors.com/idc-windows-phone-7-to-beat-iphone-sales-by2015-cement-2-position/, September 2011.
[16] Socket Overview for Windows Phone, http://msdn.microsoft.com/enus/library/hh202874(v=VS.92).aspx, MSDN, August 2011.
[17] Building a Twitter Client for Windows Phone, http://dotnet.dzone.com/articles/buildingtwitter-client#comment-55599, August 2011.
[18] Twitter, https://dev.twitter.com/apps, September 2011.
40
Appendix 1
41
Questionnaire: Second Life on a Mobile Msc Project
Please answer the following questions about the application developed in this project.
The grading ranges from poor, good, very good and excellent in questions 1-2. Check one.
1. How would you rate the general design of the application?

Poor

Good

Very Good

Excellent
2. How would you rate the user friendliness of the software?

Poor

Good

Very Good

Excellent
Answer Yes or No to the following questions (3-10)
3. Were you able to log in successfully?
Yes
No
4. Were you prompted to type in your username and password when you hit the ‘Sign
In’ button without any details in the ‘Username’ and ‘Password’ fields?
Yes
No
5. Go back to phone settings, and disable network connection; for example turn flight
mode on. Now launch the application again, and try signing in. Do you get a
message that asks you to check network status?
Yes
No
6. Do you get a message asking you to type your correct username or password when
you try to sign in with wrong data?
Yes
No
7. When trying to sign in with the right data, did a message pop up indicating there
was an unknown character error from the server?
Yes
No
42
8. If there is no avatar online, do you get a promt when you click the refresh button?
Yes
No
9. A. Do you see ‘miniature’ buttons on the map when there are avatar(s) on line?
Yes
No
B. Are their locations plotted correctly?
Yes
No
C. Is there a list of the avatar(s) below the map?
Yes
No
10. Does clicking on the ‘write’ button send you to the messaging authentication page?
Yes
No
11. How would you rate the level of difficulty in completing the messaging authentication process? Please tick one of the difficulties below.
 Easy
 Normal
 Hard
 Very Hard
12. Please write additional comments below:
43