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


Designing the User Interfaces of the System



Download 191.8 Kb.
Page5/6
Date19.10.2016
Size191.8 Kb.
#4082
1   2   3   4   5   6

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).

c:\users\nino\documents\visual studio 2010\projects\secondlife\secondlife\images\splashscreenimage.jpg c:\users\nino\desktop\dissertationguide\write-up+screenshots\login_details.png

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.

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.



c:\users\nino\desktop\dissertationguide\write-up+screenshots\mappg.png c:\users\nino\desktop\dissertationguide\write-up+screenshots\tyoemessagehere.png

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.

4Implementation Phase

Visual Studio Express for Windows Phone IDE


c:\users\nino\desktop\dissertationguide\write-up+screenshots\designerview.png

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.



Screenshot of the Windows Phone Emulator


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.

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.

c:\users\nino\desktop\dissertationguide\write-up+screenshots\codebehind.png

Shows a typical .cs code behind for the sign in page



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

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.

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 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.

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.

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++;

}

}


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 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.

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];



}
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)};


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.



c:\users\nino\desktop\dissertationguide\write-up+screenshots\screen.png

Screenshot of avatar at location (33,33) on the InterLife app



c:\users\nino\desktop\dissertationguide\write-up+screenshots\in-world.png

Screenshot of avatar at location (33,33) in-world


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.

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.

ventanas

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.

oauth

Twitter page showing OAuth settings for Twittledoo


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";

}

}


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 SecondLife.Twitter

{

public static class UserTwitterStuff



{

public static string Token;

public static string TokenSecret;

public static string UserName;

public static string UserID;

}

}



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";

}

}



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.

Twittledoo and Authentication Process


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 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.

c:\users\nino\desktop\dissertationguide\write-up+screenshots\authpageshot.png c:\users\nino\desktop\dissertationguide\write-up+screenshots\api.png

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.




c:\users\nino\desktop\dissertationguide\write-up+screenshots\pin.pngc:\users\nino\desktop\dissertationguide\write-up+screenshots\pincode.png

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.



c:\users\nino\desktop\dissertationguide\write-up+screenshots\testtweet.png

Twitter message sent from the InterLife app’s twitter messaging client



c:\users\nino\desktop\dissertationguide\write-up+screenshots\messgepic.png

Twitter Message from the InterLife app on twitter.com




Download 191.8 Kb.

Share with your friends:
1   2   3   4   5   6



The database is protected by copyright ©ininet.org 2024
send message
    Main page
green light
current location
user interfaces
mobile platform