Friendroid A Location Based Social Network
University of Illinois at Urbana Champaign CS428 : Software Engineering II Prof. Ralph E. Johnson Spring 2008
Author: AndroidLBS Group
i
Contents
Acknowledgements v
1 Introduction 1 1.1 Friendroid ...... 1 1.2 The Team ...... 1 1.3 Explanation Of Terms ...... 2 1.4 Note To The Reader ...... 2
2 Requirements and Specification 3 2.1 Friendroid Map ...... 3 2.2 Managing Friends ...... 4 2.3 Managing Zones ...... 4 2.4 Friendroid Settings ...... 4 2.5 XMPP Connectivity ...... 4 2.6 Location Sharing ...... 7 2.7 Friendroid Chat ...... 7
3 Architecture and Design 9 3.1 Android Architecture ...... 9 3.2 Friendroid Architecture ...... 10 3.2.1 Location Service ...... 11 3.2.2 XMPP Service ...... 13 3.2.3 Communication Layer ...... 14 3.2.4 Persistent Storage ...... 15 3.2.5 Presentation Layer ...... 17
iii Contents
4 Future Plans 19 4.1 Immediate Extensions ...... 19 4.2 High-Level Goals ...... 19
5 Appendix 21 .1 Installing Friendroid ...... 21 .2 Eclipse Android AIDL Workaround ...... 21 .3 Downloading Sources ...... 22 .4 Smack and Openfire Server ...... 22 .5 Positron ...... 24 .6 Core Android Packages ...... 25 .7 Sequence Diagrams ...... 25
iv Acknowledgments
First of all, we would like to thank the following individuals for their contributions to the success of our project:
• Everyone in the AndroidLBS team for countless hours of hacking the Android platform and troubleshooting bugs
• Prof. Johnson for providing us with invaluable knowledge of Software Engi- neering concepts and tales
• Class TAs, Nick for his guidance throughout the project and Maurice for his help in open source licensing
• AceInTheHole group for providing great feedbacks during the code review session
AndroidLBS Group May 2, 2008
v
Chapter 1 Introduction
1.1 Friendroid
Location-based services (LBS) open a new realm of possibilities for mobile software visionaries. We wanted to take this opportunity to develop a modularized and scal- able LBS application based on Google’s new Android Platform. We will utilize GPS capabilities, Internet connectivity (3G/WiFi), and other relevant technologies to build a system that connects busy people (professionals, students, Hollywood socialites) with their peers, friends, and families in real-time. Users will be able to autonomously share their current locations for various purposes. Imagine being on a business trip in a distant city and having Friendroid automatically notify you of an old acquaintance (possibly from your Facebook network) who happens to be in the same part of the city. Friendroid can help you reunite with old friends or simply keep up-to-date on the whereabouts of your closest friends. You can even notify others of a particular point of interest, such as your favorite restaurant. If you want to mark a private rendezvous zone, you can even do that, too. Welcome to the next generation of social networking. It’s Friendroid!
1.2 The Team
We are a group of graduate students currently studying software engineering under the instruction of Professor Ralph Johnson at the University of Illinois at Urbana- Champaign. At the moment, many of us are also working in full-time positions scattered across the US. In fact, our team’s wide range of locations could have been one of the reasons why we were all drawn to this project and its goal of connect- ing people. As a result of being unable to meet in person, our team of eight has managed all development coordination through wiki-ing, Skype conference calling, and Subversion source controlling, with attempts at pair programming whenever possible. The team consists of the following members: 2 1. Introduction
• Andrew Cox ([email protected])
• Sunitha Garapati ([email protected])
• Peter Gebhard ([email protected])
• Mohamad Setiawan ([email protected])
• An-Hoe Shih ([email protected])
• Yu-En Tsai ([email protected])
• Ovidiu Tudosa ([email protected])
• Ajay Vasisht ([email protected])
1.3 Explanation Of Terms
• POI - A point of interest, or zone may be defined as a circle on the map view
• Activity - A view on a Android UI
• XMPP - Extensible Messaging and Presence Protocol
• Openfire - A real time collaboration (RTC) server dual-licensed under the Open Source GPL and commercially, formerly known as Wildfire
• Eclipse - An open Source IDE, a project aiming to provide a universal toolset for development
1.4 Note To The Reader
The concepts in the document assume familiarity with the following programming languages, techniques, technologies, standards, libraries and frameworks:
• Java SDK 1.5 and/or 1.6
• Android SDK M5-rc15
• UML 1.0
• Object oriented architecture and design Chapter 2 Requirements and Specification
2.1 Friendroid Map
Immediately upon starting Friendroid, a detailed map of your location is displayed using Google Maps technology. This view appears with the current user in the cen- ter, and any friends within its vicinity marked with pins on the map. Since what one considers to be within their ”vicinity” can vary between people, this value is definable through a user setting. The map is the primary view of friends for the current user, and it is constantly updated based on his or her current location. Loca- tion tracking is based on Android’s GPS support. Location sharing is carried out by means of XMPP. The map view will also be constantly updated with any changes in the location of the friends in the vicinity. Please see figures 2.1 for details.
Figure 2.1: Friendroid Map 4 2. Requirements and Specification
2.2 Managing Friends
Using XMPP as a communications back-end, Friendroid allows the user to maintain a list of their contacts (”buddies”) similar to other forms of instant messaging. With Friendroid, however, the buddy list is not used only for chatting. It is a personal network, and it will be those friends to whom you phone’s user’s current location is broadcasted instantly and continuously. The current user can add, delete and edit a new friend into the network. In the current version a new friend should be configured on every existing system. Future plans should consider storing the buddy list into a centralized server (e.g. the XMPP server), or, if that is not possible, buddy list synchronization among all the phones in the system. Information about the friends in the network should be persistent in between subsequent runs of the application. Please see figures 2.2 and 2.3 for details.
2.3 Managing Zones
Points of interest (POI) may be defined as zones on the map view. After a POI marker is pinned on the desired map location, the Location Editor can be used to define the zone’s name and its relevant radius. Additionally, the location zone can be made private and sent to a friend. Zone information should be persistent in between subsequent runs of the application. Upon creation of a zone, a user should be able send the zone to given Friendroid user or all of them. Please see figures 2.4 and 2.5 for details.
2.4 Friendroid Settings
On the settings editor, the current Friendroid user should be able to configure his local Friendroid settings. These settings include: XMPP server, XMPP port, XMPP user and password, radius of the vicinity displayed on the map view. User local settings should be persistent in between different runs of the application. Please see figure 2.6 for details.
2.5 XMPP Connectivity
Since Friendroid’s messaging system is built using XMPP standards, its foundation should be open and extensible. This should allow Friendroid to be configured to work with a wide range of existing public and private XMPP servers, including GTalk. Due to some adjustments in the GTalk implementation from Android SDK 2.5. XMPP Connectivity 5
Figure 2.2: Friend Creation
Figure 2.3: Browse Friends 6 2. Requirements and Specification
Figure 2.4: POI Definition
Figure 2.5: POI Display 2.6. Location Sharing 7
Figure 2.6: Friendroid Settings
M5, that are not compliant with the XMPP standard, the current Friendroid version does not support GTalk. Future plans may address compatibility with GTalk.
2.6 Location Sharing
A core feature of Friendroid is location awareness and location sharing, both of the current user and all of the friends from the network. Changes in the location of the current user will be detected by the GPS system and broadcasted into the Friendroid network by the local Friendroid system. Conversely, the local Friendroid system should be able to receive location updates from the Friendroid systems of all the friends connected to the Friendroid network.
2.7 Friendroid Chat
Friendroid should provide chat support for all the friends in the Friendroid network. In the current version only a two-way chat will be implemented, that is, the current user can chat with only a single user at a given time. On the receiver’s end, the chat invitation should be notified asynchronously, with no respect to current screen of 8 2. Requirements and Specification the Friendroid system. By acknowledging the notification, the receiving friend will be redirected onto the chat screen where he or she will be able to send and receive chat messages. The receiving user can also ignore the notification and, later, still be able to switch to the chat screen and go on with the chat. Future plans should address multiple users in a chat room and multiple chat rooms. Please see figures 2.7 for details.
Figure 2.7: Friendroid Chat Chapter 3 Architecture and Design
3.1 Android Architecture
Android is a software stack for mobile devices that includes an operating system, middleware and key applications. The following diagram shows the major compo- nents of the Android operating system.
Figure 3.1: Android Architecture
There are four building blocks to an Android application: Activity, Intent Re- ceiver, Service and Content Provider. Not every application needs to have all four, but Friendroid uses some combination of all these. All the components making up an Android application are listed in a file called AndroidManifest.xml. This is an XML file where one declares the components of the application and what their ca- 10 3. Architecture and Design pabilities and requirements are. Please see the Android manifest file documentation for complete details. Activities are the most common of the four Android building blocks. An ac- tivity is usually a single application screen. Android uses a special class called an Intent to move from screen to screen. An intent describes what an application wants done. You can use an IntentReceiver when you want code in your application to ex- ecute in reaction to an external event, represented by an Intent. A Service is code that is long-lived and runs without a UI. A good example of this is a media player playing songs from a play list. Friendroid uses two services, one implementing an XMPP client and the other to maintain the current locations of the friends in the network. A content provider is a class that implements a standard set of methods to let other applications store and retrieve the type of data that is handled by that content provider. Android also provides a SQLite database where applications can store relevant data.
3.2 Friendroid Architecture
Figure 3.2: Friendroid Packages
Friendroid is basically structured as four main packages organized to maximize internal coherence within each package and to minimize external coupling among 3.2. Friendroid Architecture 11 packages. The four packages are androidlbs, which contains classes supporting the presentation layer and classes that are application specific, provider, containing sup- port for persistent storage, service implementing the two services that provide the main loops and share points of the application and last but not least, tests, with Friendroid’s test suite offering unit and acceptance tests based on Positron. Conceptually the two Friendroid services, AlbsLocationService and AlbsXmppSer- vice, play a major role in the overall design as they embed functionality shared ei- ther among them or with the activities, which describe the user interface. Activ- ities come and go, being created, activated, passivated, resumed by the Android framework, while the two services provide messaging and location synchronization capabilities in the background. AlbsLocationService is also the sole accessor of the content provider, all the activities going through its interface before accessing any data stored by the content provider.
3.2.1 Location Service
The location service is the core of the Friendroid application. Beside exposing an in- terface to Friendroid’s persistent storage, the location service, implemented in Alb- sLocationService class, also implements the core of the location tracking system by means of GPS. The first responsability of the location service are to present an uniform interface to the application, describing methods that should work with any implementation of a content provider. Thus, the direct service interface provides methods for friend and zone manage- ment as well as methods to register and unregister service subscribers. interface IAlbsService { /*register callback interface*/ void registerCallback(IAlbsLocationServiceCallbacks cb); /*remove a previously registered callback interface*/ void unregisterCallback(IAlbsLocationServiceCallbacks cb); /*get friend by id*/ AlbsFriend getFriend(in String id); /*get all friends*/ List
/*add a zone to the content provider*/ boolean addZone(in AlbsZone zoneInfo); /*remove a zone to the content provider*/ boolean removeZone(in AlbsZone zoneInfo); /*update a zone in the content provider*/ boolean updateZone(in AlbsZone zoneInfo); /*get all zones for the local user*/ List
The second responsibility is to maintain the location information for all the friends in the network, as seen by the current user. This information is obtained at runtime as soon as Friendroid application starts up and is updated by means of XMPP every time a change in the location of a friend is detected in the system. AlbsLocationService has an incoming interface with the AlbsXmppService. The in- terface is implemented as the AIDL callback interface of the AlbsXmppService, which provides the capability to listen to location and presence notification updates com- ing from the other Friendroid systems in the network. For broadcasting current locations the location service gets a reference to the xmpp direct interface to send location change notifications into the network. The third responsibility of the location service is to provide subscribers with no- tifications about changes in the current location of any participant, e.g. the main view of the application (map view) subscribes to those notifications to update the map according with the new coordinates (see Location Sharing sequence diagram in appendix 6). This is implemented in the following AIDL callbacks interface: interface IAlbsLocationServiceCallbacks { /*when the location of any of the friends changed the * service will call its subscribers */ void locationChanged(in AlbsFriend friendLocation); }
Location service is in fact the only module which gets direct access to the con- tent provider, all the rest accessing it using the location service AIDL interface. This approach should allow for future changes of the implementation of the stor- age provider, e.g. move all the contact information into the XMPP server. The location management is implemented by configuring a GPS provider object to send notifications of changes in the current location. The frequency of notifica- 3.2. Friendroid Architecture 13 tions is controlled by telling GPS the minimum time between updates (in millisec- onds), so that the Friendroid system will not be flooded by a huge flow of GPS mes- sages. Friendroid also configures the minimum change in the distance that would trigger a GPS notification. The current setting is location changes of over 10 meters sent at intervals of at least 2500 milliseconds.
3.2.2 XMPP Service AlbsXmppService provides the application with messaging support wrapped up in an Android service running in the background. All the communication with the XMPP service is done through two interfaces: one direct interface where client classes that have obtained a reference to the service can call directly into the ser- vice and a callback interface which is to be implemented by a client class in order to obtain notifications from from the XMPP service. The two interfaces are specified as AIDL interfaces. Below there is the direct AIDL interface to the XMPP service: interface IAlbsXmppService { /* Register callback interface */ void registerCallback(IAlbsXmppServiceCallbacks cb); /* Remove a previously registered callback interface */ void unregisterCallback(IAlbsXmppServiceCallbacks cb); /* Broadcast current location to a list of friends */ boolean broadcastLocation(in AlbsFriend myself, in List
As one can see from the direct interface, the XMPP service is also responsible for passing a public zone to certain friends as well as providing chat functionality. For a detailed description of the dynamics of zone sharing and chat processes please refer to Share Zone sequence diagram and Chat Sender, ChatReceiver respectively, in appendix 6. Additionally, the XMPP service also implements a callback AIDL interface for subscribers: interface IAlbsXmppServiceCallbacks { 14 3. Architecture and Design
/* when a new friend has logged in, notifiy subscribers */ void onNewFriendPresentMsg(in String friendId); /* when a friend broadcasted his location, notifiy subscribers */ void onLocationUpdateMsg(in AlbsFriend friend); /* when a friend sent a chat message, notifiy subscribers */ void onNewChatMsg(in String friendId, in String strTextMsg); /* when a friend sent a zone info, notifiy subscribers */ void onNewZone(in String friendId, in AlbsZone zone); /* when XMPP connection is established */ void onXmppConnected(); }
3.2.3 Communication Layer
The communication layer is represented by classes making up the XMPP client sup- port. Friendroid’s XMPP client is built on top of the Smack java library. Smack is an Open Source XMPP (Jabber) client library for instant messaging and presence. A pure Java library, it can be embedded into your applications to create anything from a full XMPP client to simple XMPP integrations such as sending notification messages and presence-enabling devices. The Friendroid XMPP client is implemented in a class called AlbsXmppClient, which provides a Friendroid friendly XMPP interface to the rest of the applica- tion. Beside basic functions for sending messages and roster management, the in- terface also allows the application to register message receiving and presence notifi- cation listeners in AlbsXmppClientReceiveMessage class and AlbsXmppPresenceChange respectively. In addition, AlbsXmppClient implements an interface to the XMPP Personal Event- ing via PubSub protocol. This protocol is designed to ’publish’ notifications to ’sub- scribers’ and therefore was a promising method to send location updates to friends. The protocol especially shines if the user has a long list of friends: the location up- date would only be sent once to the server, as opposed to an individual copy sent to each friend from the client. However, the conclusion was eventually reached that the protocol is not a good match for the project. This was mainly due to the fact that there is no way to specify a list of recipients for each published event - which was functionality required for the project’s user stories. Thus, the project settled on using the basic messaging component of XMPP instead of PubSub. Ideally, func- tionality could be added to the server-side handling of PubSub to make it more attractive for this project. Originally, the PubSub implementation utilized a library called su-smack that can be found here. However, as development progressed and knowledge was gained, it became clear that su-smack was not specifically required. 3.2. Friendroid Architecture 15
This knowledge combined with the fact that integrating su-smack into the Android environment was non-trivial, the library was completely removed from the project. AlbsXmppClient also implements an interface to transmit/receive any java.io. Se- rializable class. This functionality was intended for the simplification of tranferring different types of information, particularly for advanced user stories that have not been implemented. Specifically, it was desirable for AlbsFriend class to be serializ- able. Unfortunately, this was not possible due to the class’s inheritance from the Android interface android.os.Parcelable. To get around this, a container class Alb- sFriendFields was created to be used as a member of AlbsFriend. AlbsFriendFields holds all data members of AlbsFriend and is serializable itself, thus providing a seri- alization interface for the class as a whole. AlbsXmppClient is wrapped within the AlbsXmppService, which provides a sec- ond abastraction layer to the Friendroid application. In fact, AlbsXmppService is a Android service providing the main loop for the unique instance of AlbsXmpp- Client and an observer interface to the location service and the activities making up the presentation layer. Consequently, the subscribers (e.g. activities) besides being able to send message through the AlbsXmppService interface can also receive incom- ing messages from the other phone participants.
3.2.4 Persistent Storage
Two types of information are stored in the persistent storage: Friendroid system settings and and friends and zone information. Whereas the former one is stored in a file on the Android local file system, friends and zone information are handled by an Android content provider. Using a content provider, Android applications can store their data in files, a SQLite database, or any other mechanism that makes sense. A content provider, however, is useful if you want your application’s data to be shared with other ap- plications. A content provider is a class that implements a standard set of methods to let other applications store and retrieve the type of data that is handled by that content provider. In Android, this is the only way to share data across packages; there is no com- mon storage area that all packages can share. Android ships with a number of content providers for common data types (audio, video, images, personal contact information, and so on). However due to the specific nature of the Friendroid in- formation that had to be stored, we implemented a custom content provider over the SQLite Android database. All content providers must implement a common convention to query for data, and a common convention to return results. This is enforced by having each of them extend from the Android standard class an- 16 3. Architecture and Design droid.content.ContentProvider. As services, activities and other Android entities a custom content provider has to be declared by a provider clause in the Android- Manifest file. The class implementing the Friendroid content provider is called AlbsContent- Provider and can be found in the edu.uiuc.cs428.provider package. As a database interface the AlbsContentProvider provides read, write access to two SQLite tables: albs contacts, storing the friends from the Friendroid network and location descriptions storing information about zones of interest on the map.
Field Type Description id INTEGER Android private key id TEXT UNIQUE Contact’s unique id first name TEXT First name last name TEXT Last name nick name TEXT Nick name email TEXT Email address phone number TEXT Contact’s phone number enable broadcast TEXT Privacy field
Figure 3.3: albs contacts table
Field Type Description id INTEGER Android private key area name TEXT UNIQUE Zone nick name latitude DOUBLE Zone center latitude longitude DOUBLE Zone center longitude radius DOUBLE Radius from center private zone TEXT Privacy qualifier
Figure 3.4: location descriptions table
Even though different modules of the Friendroid can obtain a reference and query the content provider directly, we decided to isolate the access within only one module, namely the location service module, AlbsLocationService. The primary rea- son for this design decision was to allow for future changes of the content provider, especially those concerned with saving the Friendroid network information into a centralized location (e.g. on the XMPP server) rather than locally on each participant phone. 3.2. Friendroid Architecture 17
3.2.5 Presentation Layer This is the top most level of the application. The presentation tier displays infor- mation related to different features of the application such that location tracking, Friendroid network status, Friendroid friend configuration, zone definitions, Frien- droid chat etc. The presentation layer consists of a set of Android activites each carrying out a specific tasks: AlbsSettingsEditor - configure global Friendroid settings, AlbsFriend- sList and AlbsFriendEditor - friend management, AlbsChatActivity, AlbsChatRoomAc- tivity, AlbsCheckbox - Friendroid chat management, AndroidLBS - location tracking on the Google map and zone management. 18 3. Architecture and Design
Figure 3.5: Friendroid System Class Diagram Chapter 4 Future Plans
Our team is currently developing Friendroid as part of a graduate course, so devel- opment is expected to significantly slow or halt indefinitely after the course is com- pleted. Still, the team is eagerly looking forward to the Open Handset Alliance’s first release of physical Android phones. At that point, some additional develop- ment will likely be required to bring our application up to a fully-functional state.
4.1 Immediate Extensions
Beside the high-level goals there are also some aspects to be addressed by future Friendroid developers, which derive from and may complete the existing function- ality. Among them, storing the buddy list into a centralized server (e.g. the XMPP server), or, if that is not possible, buddy list synchronization among all the phones in the system, compatibility with GTalk, multiple user chat and multiple chat room management are only few of them.
4.2 High-Level Goals
Beyond integrating our application with actual Android phones, other future devel- opment includes the possibility of enabling our tool to utilize a user’s existing social networks, such as Facebook. This type of mobile social networking has always been one of the team’s higher-level goals. Enhancing the POI feature for more specific de- scriptions and user reviews is also a possible area of focus. We feel the combination of location-based services and social networking is an inevitable path for the mobile platform. As of April 30, 2008, the Friendroid application is still closed source. The team recently submitted Friendroid to Google’s Android Developer Challenge, and we are currently awaiting the judges’ comments. A decision about the application’s licensing will be decided soon after a response from Google.
Chapter 5 Appendix
.1 Installing Friendroid
To run Friendroid, you must first download Google’s Android SDK. Be sure to download Version m5-rc14 from here. Once the SDK package has been downloaded, it can be uncompressed in wherever you wish. The extracted SDK contains several directories, however, the ”tools” directory will contain the emulator used to run An- droid applications. Run the emulator by either double-clicking on the executable or by running it from the command line. The Friendroid (codename: AndroidLBS) application can be downloaded from here. Next, you can install the Friendroid application by using the command line from within the ”tools” directory (replace
.2 Eclipse Android AIDL Workaround
Ideally, Eclipse should manage the .aidl file for us and automatically compile it to generate the corresponding .java file. However, the current Eclipse Android plugin has a limitation that it does not support Parcelable subtypes (for more info please refer to this link). To work around this issue, we need to manually compile the .java file outside Eclipse. Thus, we decided to check in the generated .java file into the repository. However, we would also like to archive the source .aidl files, so here we purposely renamed the .aidl file to add an ’ ’at beginning of each .aidl file name and at the end of its extension to prevent interference from Eclipse. The following script is to be configured as a custom project Builder with the Eclipse so that it will be executed every time the project is rebuilt. The purpose of the script is to run the aidl compiler on all the checked in AIDL interfaces, by utilizing the above described workaround. echo %ALBS_HOME% 22 5. Appendix
pushd %ALBS_HOME%\src\edu\uiuc\cs428\service copy _AlbsFriend.aidl_ AlbsFriend.aidl copy _AlbsZone.aidl_ AlbsZone.aidl copy _AlbsSettings.aidl_ AlbsSettings.aidl copy _IAlbsService.aidl_ IAlbsService.aidl copy _IAlbsLocationServiceCallbacks.aidl_ IAlbsLocationServiceCallbacks.aidl copy _IAlbsXmppService.aidl_ IAlbsXmppService.aidl copy _IAlbsXmppServiceCallbacks.aidl_ IAlbsXmppServiceCallbacks.aidl copy _IAlbsSettingsService.aidl_ IAlbsSettingsService.aidl aidl -I%ALBS_HOME%\src IAlbsService.aidl aidl -I%ALBS_HOME%\src IAlbsLocationServiceCallbacks.aidl aidl -I%ALBS_HOME%\src IAlbsXmppService.aidl aidl -I%ALBS_HOME%\src IAlbsXmppServiceCallbacks.aidl aidl -I%ALBS_HOME%\src IAlbsSettingsService.aidl del AlbsFriend.aidl del AlbsZone.aidl del AlbsSettings.aidl del IAlbsService.aidl del IAlbsLocationServiceCallbacks.aidl del IAlbsXmppService.aidl del IAlbsXmppServiceCallbacks.aidl del IAlbsSettingsService.aidl popd
.3 Downloading Sources
One can download a copy of Friendroid source code at this SVN URL.
.4 Smack and Openfire Server
All device-to-device messaging is performed via the XMPP client library Smack along with the server Openfire. Both are projects under the Ignite Realitime Soft- ware Community as open source. Any compatible XMPP server should also work, however we exclusively developed with the Openfire server. A few alterations were .4. Smack and Openfire Server 23 made to the Smack library to make it compatible with Android. This was performed by Davanum Srinivas and posted here. The XMPP protocol set and the Smack library provide all the features inherit with implementing instant messaging. These include: • User account/password for server authentication
• Server connect, disconnect and login
• ’Roster’ functionality used to determine which of the user’s friends (or bud- dies) are currently online and/or available
• Simple text message send to a friend (asynchronous through server)
• Simple text message receive from a friend (asynchronous through server) To configure Openfire please follow the instructions below (derived from Open- fire 3.4.4): • Install Openfire. Use all default installation options
• Launch Openfire.
• Launch Administration console (’Launch Admin’ button)
• Under the Server tab, navigate to Server Settings/Offline Messages.
• For Offline Message Policy, select Drop. Click Save Settings.
• Under Users/Groups tab, choose Users/Create New User.
• For Username, enter user1, for Password and Confirm Password, also enter user1
• Click Create User.
• Repeat previous two steps using user2 instead of user1. Repeat again using user3.
• Under Users/Groups tab, choose Users/User Summary. Under the username column, click user1.
• Navigate to User Options/Roster
• Click Add New Item
• For JID, enter [email protected] servername is replaced with the name of the server (listed under Server Manager/Server Information) 24 5. Appendix
• Enter user2 for Nickname
• Click Add Item.
• Under JID column, click the entry just created
• Click Edit
• Set Subscription to Both
• Click Save
• Repeat previous eight steps supplying user3 in all cases instead of user2
• Return to Users/Groups tab, Users/User Summary.
• Choose user2. Repeat steps above to add user1 and user3 to user2’s roster. Repeat again for user3 (add user1,user2 to roster).
.5 Positron
Positron provides an instrumentation and some support classes to help writing ac- ceptance tests. It is provided as a jar that gets bundled with your application. Ac- ceptance tests are written in junit, extending a custom base class. Positron can be downloaded from here. In order to get Positron to run with An- droid, one should create a subclass of positron. Positron in the same java package as is listed in the AndroidManifests.xml file in the package attribute, then over- ride suite() to declare which tests to run and setUpSuite() and tearDownSuite() to perform one-time initialization and tear-down. This is necessary due to current lim- itations of the
.6 Core Android Packages
• android.util - contains various low-level utility classes, such as specialized container classes, XML utilities, etc.
• android.os - provides basic operating system services, message passing, and inter-process communication.
• android.graphics - the core rendering package
• android.text, android.text.method, android.text.style, and android.text.util - supply a rich set of text processing tools, supporting rich text, input methods, etc.
• android.database - contains low-level APIs for working with databases.
• android.content - provides various services for accessing data on the device: applications installed on the device and their associated resources, and content providers for persistent dynamic data.
• android.view - is the core user-interface framework.
• android.widget - supplies standard user interface elements (lists, buttons, lay- out managers, etc) built from the view package.
• android.app - provides the high-level application model, implemented using Activities.
.7 Sequence Diagrams 26 5. Appendix
Figure 1: Chat Sender .7. Sequence Diagrams 27
Figure 2: Chat Receiver 28 5. Appendix
Figure 3: Share Zone .7. Sequence Diagrams 29
Figure 4: Manage Friend 30 5. Appendix
Figure 5: Location Sharing