Final Report

Huning DAI, Nathan MURITH and Xuyang SHI{hd2210, nam2140, xs2137}@columbia.edu

E6998 Mobile Computing with iPhone and Android

10th December, 2009

Contents

1 Introduction 3

2 Related Work 4

3 Usage Model 53.1 Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.1 Update Friends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.2 Invite Friends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.1.3 Enter an address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.1.4 Send a Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.1.5 Detailed Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 PartyLine2.0 Screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3 PartyLine2.0 Screen and Application Flow Chart . . . . . . . . . . . . . . . 10

4 Architecture Design 124.1 The Big Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 The Mobile Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Implementation 16

6 Evaluation 196.1 Is PartyLine2.0 functioning . . . . . . . . . . . . . . . . . . . . . . . . . . . 196.2 Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.3 Stability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.4 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.5 Aesthetics, User Control and Freedom . . . . . . . . . . . . . . . . . . . . . 21

7 Limitations 21

8 Member Contributions 22

9 Lessons Learned 23

10 Conclusion and Future Work 23

A Acknowledgments 24

References 25

1 INTRODUCTION 3

1 Introduction

The PartyLine2.0 application is a collaborative notification system, based on the twitter[4]API, which allows people at remote locations to issue ongoing status reports that can in-clude pictures inline. The application remains stateless by distributing state among variousonline systems for information access and storage. This is made possible by the use of mul-tiple APIs and presumes internet access that is more or less constant. A short list of thosesystems that can be integrated into our application would include twitter ([4]), GlowFoto([1]) and TinyURL ([3]).

PartyLine2.0 allows remote stakeholders (already in attendance) to invite their friendsto attend a “good” party, show, or other event already in progress, by issuing invitationsor by sending status updates directly to their twitter friends or indirectly to their twitterfriends list.

In the initial version of PartyLine, the main stakeholders were college students who areusually pressed for time, fond of attending various parties and events and who usually arepretty computer and internet savvy. We strongly believe that if tools to help a studenttarget events based on their location, time and people already attending were easily acces-sible they would be used. It seems intuitive that the potential market is out there and thePartyLine would be, without a doubt, be used by students who already own mobile devicessuch as the iPhone, iPod Touch or the Android, who already have accounts on websitessuch as twitter, Facebook, mySpace or Linked’in, and who already rely on such tools andservices to organizes their daily lives.

In addition to the initial idea mentioned above, one can think of many situations inwhich such an application can be used with only very little modification in the originalconcept. Here are a few:

• Emergency Services: the same collaborative and notification application could beused for accidents of any kind. Imagine someone witnessing an accident, he/she caneasily and quickly take a picture of what appended and uploaded to the applicationwith precise location and description in order to make available to authorities.

• The concept can very well be adapted to an application for women who like to shopwhere they could broadcast images, location and descriptions of the latest pair ofshoes they bought.

• One could also see the application changed for hunters/fishers, where the currentlyhunting/fishing person notifies his buddies of where it’s all happening.

• And the list goes on...

2 RELATED WORK 4

Of course there exist many notification and geo-location applications for mobiel devicesout there, and we do not claim our application will revolutionize the mobile applicationworld. We believe, however, that PartyLine2.0 , as a whole meaning the mobiel applicationand the desktop application, is something that is not ubiquitously available and that it isan interesting application for several reasons: the desktop application is already up andrunning and available with any modifications needed and offers clear event view by locationor time; the stakeholders are already very familiar with and use on a daily basis servicessuch as twitter, Facebook, Flicker, mySpace so there is no adaptation time or new accountcreation needed; the target end-user is very likely to already be in the possession of andused to using mobile device such as the Android, iPhone or iPod Touch; our solution issimple, user-friendly, clear and especially easily adaptable and expandable to other eventnotification purposes and not just parties.

The PartyLine2.0 project was developed on the Google Android device. The choice ofdeveloping on the Android instead of iPhone was make for two main reasons: the AndroidSDK is much more easily accessible, the developer doesn’t need a Mac, Mac developeraccount or sign up to any developer communities in order to be able to use the iPhone SDKand start developing iPhone applications; and the fact that it uses Java for a programminglanguage, the most widely used and freely accessible language out there, providing us withmany more possibilities in terms of integrating libraries etc.

2 Related Work

PartyLine is an already existing desktop application and mobile-friendly webpage thatwas developed by Joshi Keerti, Nathan Murith, Joshua Weinberg and Green Zhang in thecontext of Columbia University’s User Interface Design class (COMS4170). While bothdesktop application and mobile-friendly webpage were built for PartyLine, the above men-tioned class’ emphasis was on the desktop application. The mobile part “developed” forPartyLine was a simple, tiny and unaesthetic html page readable from any mobile device’sinternet browser enabling users to send updates (this was done so the user could see theupdates in the desktop application). Since the mobile portion of PartyLine was developedsolely for demonstration purposes for COMS4170, we chose to build a full and actual mobiledevice application for PartyLine from scratch as nothing from the demo dummy versionis reusable for this project in order to make the PartyLine2.0 project complete.

It is more and more common to see individual developers or event companies integrateexisting web services like Facebook, Flicker, YouTube into their applications, even moreso since most of these services now offer API. The major difference between the tools outthere and our solution is that the applications out there provide a means to access anduse the various services, whereas we use these services as media (media as in providing a

3 USAGE MODEL 5

means to do something) to communicate for our application.

After doing a bit of research, we weren’t able to find any solutions out that are similarto PartyLine2.0. As mentioned, most available products offer means to access these webservices and do not use them as we do, or cannot be viewed as similar products. Theclosest product we found was Rave’s RaveAlert ([10]), an emergency notification system.One could of course argue that most email or desktop application offer similar, if notbetter, features as PartyLine2.0. Take for instant Microsoft Outlook or MacOS Mail, theyboth offer means to send events (mail, to-dos, meetings) to which you can ad commentsand pictures that you can then pickup and view on your mobile device, but they areboth heavyweight applications and not necessarily our stakeholders’ application of choice,and our most of the time way too complex for simple “Come check out this party dude”notifications.

3 Usage Model

We describe in this section the usage model of PartyLine2.0. The model is accompaniedby screenshots and a screen flow to help the user understand how PartyLine2.0 works andhow to use it.

3.1 Usage Examples

In this section we show you how to take advantage of PartyLine2.0 to broadcast to yourfriends parties your are currently attending.

To send your Twitter buddies and update about a party, follow these three steps:

1. Go to: PartyLine2.0 on your mobile device.

2. Login using your Twitter username and password

3. Click “Send Party”

4. Fill in the information about the party, select the recipients and send update

5. Start over... send another party, view parties or log out

3.1.1 Update Friends

• Using PartyLine2.0 allows you to update your friends collectively or individually onthe latest events in real-time as things are happening to you.

• All you need is a twitter ID and you’re able to use the PartyLine2.0.

3 USAGE MODEL 6

• Login with your twitter ID and send party invites, update your buds on the game,or let Mom know everythings okay with a personal picture of you.

3.1.2 Invite Friends

• You can make a personal friend invitation by selecting any one of your friends listedunder the UPDATE ALL FRIENDS menu.

• Fill out your invite and event details and click send update. That’s it, you’ve justsent your first PartyLine2.0 invite.

3.1.3 Enter an address

• You can enter an event address manually and PartyLine2.0 will get the geo-coordinates.

• Or by clicking “GPS” PartyLine2.0 will gather the geo-coordinates and address fromAndroid automatically.

3.1.4 Send a Picture

• You can use PartyLine2.0 to send images of your PartyLine2.0 event.

• By clicking the “Add Pic” button when sending a party update you will be taken tothe Android’s camera to take a picture and add to the party update.

• By clicking the “Choose” button, you can choose a picture that was taken at anotherpoint in time and add that to the event.

3.1.5 Detailed Scenarios

User-Case #1:Sally is at a campus pizza party having fun, but is surprised that none of her friends areat the party. She decides to invite them using PartyLine2.0.

1. She opens the PartyLine2.0 Application from her mobile phone.

2. Logs in.

3. She snaps a picture of the pizza party.

4. She adds the picture, some description and location of the party and creates hertweet.

5. She picks a friend from her list.

6. Sends invite to Mary

3 USAGE MODEL 7

7. She picks a friend from her list.

8. Sends invites to Becky:

(a) Meanwhile, Becky, who is taking a break from studies, logs on to PartyLine.

(b) Becky sees a PartyLine2.0 invite that Sally has sent her to the pizza party onCampus.

(c) She clicks on the invitation tweet to view the party pictures and description.

(d) However she has a lot of work due, and decides not to attend the party. Shetakes a picture of herself buried in books, adds comments that she would notbe able to attend the party, and tweets to Sally.

(e) She logs off.

(f) Mary is back from work and logs on to PartyLine2.0.

(g) Mary sees Sally’s invite from the pizza party on Campus.

(h) Mary clicks on the invitation tweet to view the party pictures and description.

(i) Mary finds the party quite interesting, and makes up her mind to attend theParty.

(j) Mary takes a picture of herself all dressed up for the party and sends the tweetto Sally accepting the invite.

(k) Mary logs off.

9. Sally logs off and closes PartyLine2.0 and waits for Mary to join her at the party.

3.2 PartyLine2.0 Screenshots

In this section the reader will find screenshot of the PartyLine2.0 application in it’s currentstate of development.

3 USAGE MODEL 8

Login Screen Action Selection Screen

Choose Picture from File Manual Address Screen

Figure 1: PartyLine2.0 Screenshots Set 1

3 USAGE MODEL 9

Manual Address Screen 2 Sent Event Confirmation

View Events

Camera on the Emulator

Figure 2: PartyLine2.0 Screenshots Set 2

3 USAGE MODEL 10

3.3 PartyLine2.0 Screen and Application Flow Chart

This section provides the reader with the latest version of the PartyLine2.0 screen flow.Only minor errors were corrected from the version found in [16]. As per the current statusof development, nothing else has changes; our team strives to stick to our initial plan anddesign. We are not excluding eventual future changes, however, we were able so far todevelop and implement PartyLine2.0 according to our initial design decisions.

3 USAGE MODEL 11

Figure 3: PartyLine2.0 Screen and Application Flow

4 ARCHITECTURE DESIGN 12

4 Architecture Design

As previously mentioned, PartyLine2.0 is an application consisting of two components:the PartyLine2.0 mobile application, discussed here, and the PartyLine desktop applica-tion, which is not discussed here, that are to be taking as a whole. For demonstrationpurposes of PartyLine, some elements (i.e. web proxy) were implemented and are partiallyreimplemented or reused for PartyLine2.0and will be detailed below.PartyLine2.0 is live and realtime update application by definition and therefore requiresto be connected to the internet. We make the assumption that the device has connectivitycapabilities which is reasonable for devices such as the Android or the iPhone which offervery satisfying WiFi, 3G and EDGE connectivity. These are after all the key developmentand marketing points of the latest generation mobile devices.

4.1 The Big Picture

Here we present the over design architecture for the project and we detail the mobile partof it in the next section. We the best way to understand the architecture is through thefollowing image.

4 ARCHITECTURE DESIGN 13

Figure 4: PartyLine2.0 Overall Design Architecture

Here are additional comments about the aboute architecture:

proxy.php is the actual web proxy used when called from the desktop or mobile applica-tions. It essentially calls update lib.php. The proxy and it’s functions are sued byboth the mobile and the desktop application, though only few of these are used bythe mobile application.

update lib.php contains the definition of the functions used by the proxy. It uses HTML

4 ARCHITECTURE DESIGN 14

“post” and “get” methods to call the various APIs. It contains functions to call theTwitter API to log in, or get friends and events for example.

glowUpload.php is proxy to upload a picture to GlowFoto. It essentially calls the Glow-Foto API and passes it a picture that is on the server and that was uploaded fromthe device (we had to integrate and set up our own different server (essentially aFTP server supporting PHP) as the CS server, to which we do not have adminrights, doesn’t support FTP and PHP) and returns the URLs of the picture and thethumbnail on GlowFoto.

glowDelete.php this deletes the picture off the server once it is uploaded to GlowFoto.

PartyLine.html is the webpage linked the flash .swf of the desktop PartyLine application.

The chosen design architecture, i.e. make use of proxies, was arose for several reasons.First of all, it was the approach used when developing PartyLine (desktop) and seeing thatthis project is a whole, we did not want to drastically change the design. This approachalso provided solutions for various security problems (due to the API calls) we encounteredboth on the mobile device and on the desktop version. And finally, the most importantreason is that using proxies we make the whole project more scalable and portable. Indeed,if say we wanted to move the application to the iPhone, there would be less implementationto do, instead, there are proxies to call.

Note that the mobile version currently also make direct API calls to the internet whichwe would ideally like to avoid by only calling the proxies, however, due to (mainly) the fileupload problem this is not yet the case. Eventually, we would like to have all API calls gothrough the proxies on the server.

4.2 The Mobile Device

As we did above, the mobile device design architecture is best describe through a simpleUML model showing only the important and interesting aspects of PartyLine2.0. It isstrongly recommended to the reader to look at the well commended and written source codeto get the inner most details of the implementation. As discussed in previous documents,our design follows the model-view-controller design pattern. We also previously mentionedthat not all API calls are made through the proxy when done from the mobile device, wewill eventually correct that and make the whole design more consistent.

4 ARCHITECTURE DESIGN 15

Figure 5: PartyLine2.0 Mobile Device Design Architecture

5 IMPLEMENTATION 16

We now detail the above UML to help the reader understand the design architecture.The basic components, such as the details about the various screens and how their compo-nents (text fileds, spinners, etc) are connected are intentionally left out for space reasons.These components as well as, for instance the camera or the content provider, are genericJava and Android implementations that the user can read about elsewhere.

us.cu.android.PartyLine.model is currently empty. In the future, it will contain classesfor the models of system that we will use with the maps portion of the application.For example a model will be needed for an event which is defined by a name (String),comments (String), address (String), picture (String), etc.

us.cu.android.PartyLine.view contains the classes for the various screens used in Party-Line2.0and are not detailed here. The basis for creating screens and their componentsis generic to all Android applications and the reader can easily find more informationon this else. The screens, and the intents the represent, are passed various types ofinformation such as the list of friends to populate the spinner in the “Enter PartyDetails” screen. The screen and intent flow is described in section 3.3.

us.cu.android.PartyLine.tools contains, as the name suggests, three tool classes thatare used alongside the controllers and viewers. For example, PartyLine2.0 onlyconsiders the events that were posted in the last 12 hours, the class “DateTime”computes now minus 12 hours so the proxy call request the events only since nowminus 12 hours.

us.cu.android.PartyLine.controller is a much more interesting package. The “Friends”and “FriendsTimeline” classes are two controller classes that are in charge of passingjust an array of friends or events to the viewers. They are therefore in charge ofquerying the proxy, getting the results (xml formalt) and cleaning and compiling therequired info (going from xml to array of strings with only the needed information).A big piece of this package is the proxy. This classes interfaces with the proxy onthe web server and is in charge of making all external/internet calls to the variousservers and APIs. This class typically calls the web proxy when a user wants tolog in, for example, or uploads the pictures to a temporary server before submittingthem to GlowFoto via an API call (not currently working due to the server’s lack ofFTP support). This class also contains the attributes for the various server and APIaddresses. This class will typically be modified in the future in order to have all APIcalls made through the web proxy.

5 Implementation

This section addresses the project on a lower level, the implementation level. The readershould keep in mind that PartyLine2.0, from an implementation point of view, is not

5 IMPLEMENTATION 17

a complex project. As previously mentioned, the mobile application for PartyLine wasimplemented in order to complete a tool and make an application final: PartyLine2.0. Weremind the reader of this as this section will only briefly discuss the code cornerstones ofPartyLine2.0 , and should keep in mind that PartyLine2.0 is a simple application in termsof code complexity and therefore doesn’t extensive discussions and analyses. The previoussection along with this one will be sufficient for a rather full understand of the lower levelsof PartyLine2.0.Note that all features initially presented in the project proposal were implemented and arefunctional. We have made use of one external library, SimpleFTP ([11]), to upload thepictures from the Android to the FTP server before calling the GlowFoto API (GlowFotorequires that the file be on a public machine which is why we can’t do it directly from thedevice).We have included below a screenshot of the Eclipse project structure that help the userunderstand how the project was implemented. The reader should recall that the applicationwas developed using the “model-view-controller” design pattern.

5 IMPLEMENTATION 18

Figure 6: Eclipse Project Code Structure

We now provide the reader with a couple comments on the implementation of Party-Line2.0 (recall section 4.2):

Android intents are one of the important implementation details one needs to keep inmind when looking at the code. The screen flow of the project (i.e. going from oneintent to another) requires that we pass intent extras to each new intent that are then

6 EVALUATION 19

loaded bundles in the “onCreate” method. The “send” intent requires the usernameand password in order to complete the proxy call. Going from one intent to another(i.e. from “send” to “taking a picture” back to “send”)goes through three intentsand these do not store username and password unless they are passed to each intentand returned to the original one.

Android TextViews were also a minor problem. The settext (to update a screen’sTextView) only works when user new stringBuilder (which we figured out muchlater).

Proxy.java is probably the most important file of the project it contains everything neededto communicate with the remote PHP proxies or make direct API calls. This classalso does minor work as in cleaning up XML web responses to return only the desiredinformation (i.e. a twitter friend or event name) and not a entire XML web response.

Friends.java & FriendsTimeline.java are contained in the controller package. The es-sentially return the list of twitter friends or event titles used to populate the spinnersof the “send” screen. They do a little more work than simply cleaning a XMl webresponse which is why the were not included in the proxy.java class.

6 Evaluation

In this section we briefly discuss and introduce ideas and metrics with regards to theevaluation of PartyLine2.0. As for any other project of this type, a proper evaluationof the accuracy, stability, performance, scalability and aesthetics is the key issue to theproducts success. PartyLine2.0 has been and will continue to be examined, tested andevaluated with respect to the following). NB: the testing and evaluation were both doneon the emulator and device itself.

6.1 Is PartyLine2.0 functioning

The first and foremost evaluation criterion that we used is simple: “is the applicationfunctioning?”. By that we simply mean can the user log on to PartyLine2.0 and sendevents to his/her twitter friends, and is that sent event visible of the desktop PartyLineapplication? If so, the overall goal and purpose of PartyLine2.0 will have been achieved.We do not mention accuracy or correctness of the above here as there is a special sectiondedicated to this. If an event can be sent from the PartyLine2.0 mobile application andview on the PartyLine desktop application, we can admit that, overall, PartyLine2.0 isfunctioning.

6 EVALUATION 20

6.2 Accuracy

Is also important in this project. Indeed, each event that can be sent from the mobile ap-plication or view on the desktop application contains location (geo-coordinates) and timeinformation that are crucial to the application’s purpose. These were obviously thoroughlychecked. Once again, this project has the opportunity to benefit from the desktop ap-plication in terms of accuracy checking. Indeed, each event is completely displayed andtherefore can be checked for accuracy of event times and locations. PartyLine2.0 offerstwo ways to assign a location to an event, the first is the manual entry of and address,that address is the then translated into geo-coordinates by the [5], the second is throughthe use of the built-in GPS locator. These two input options enabled us to crosscheck thelocation accuracy of events sent from the mobile application.The list of events and list of friends that PartyLine2.0 displays when sending and event caneasily be crosschecked for correctness, completeness and accuracy with the twitter accounton the web.

6.3 Stability

Throughout the testing of the mobile application, both on the emulator and on the device,we have monitored the stability of the system. Testing enabled us to detect a couple ofsituations were the application crashed, and therefore enabled us to correct several bugs inthe code. As for any other IT project or application, it is impossible to say PartyLine2.0is bug-free, however we have no longer encountered crashes after a large number of test.We will, of course, take the user’s feedback into consideration to correct potential futurebugs and/or errors.

6.4 Performance

Performance evaluation and optimization is on very large focal point for PartyLine2.0.Indeed, because PartyLine2.0 uses a range of different services and APIs, it is constantlygoing back and forth to the internet to get the latest data for the user (i.e. twitter friends,events, upload photos, geo-coordinates, etc.).As discussed in the previous section, Party-Line2.0 is not currently optimal in terms of speed and performance. This will be workedon and hopefully improved in the near future. In the meantime, one useful metrics (bothfor evaluation and general PartyLine2.0 information purposes) is the time the applicationtakes for an update cycle (log in, send update, log out), or how many events can be sentin X seconds/minutes/hours. We have yet to setup a proper testing session to gather dataand be able to get these figures.

7 LIMITATIONS 21

6.5 Aesthetics, User Control and Freedom

Aesthetics, user control and freedom is not so important in terms of stability or function-ality of the application, however a good user interface design coupled with nice aestheticscan lead to better usability, end-user performance and an overall more enjoyable use of theapplication. We made sure the user interface design stays simple, consistent, error-free andprovides user feedback. As we did in the past and did for other evaluations criteria, wehad feedback from test subjects to evaluate, modify and correct the application in termsof aesthetics, and user interface design.

As we did in previous cycles of development (i.e. LoFi prototype), we have the advan-tage of having our targeted user constantly surrounding us, and we used that advantage.Indeed, recall that the target end-user, or stakeholder, for PartyLine2.0 is students andyoung professionals. This offers us a very large test bed and therefore we could easilyconduct test runs. The number of test subjects was approximately 20 students who werechosen from various backgrounds (i.e. not only engineers). Having the end-user test theapplication provided a lot of feedback, especially in terms of stability and UI design, thatwe incorporated in the design, development and implementation cycles.

7 Limitations

This section discusses various limitations in PartyLine2.0. It is important to note that alldesired features and functionalities were implement in version 2.0 of PartyLine and arefully functional, which is why we discuss ideas and limitations with regards to the overallPartyLine concept and potential future work.

Localization probably one of the major problems or limitation is the localization featureof PartyLine2.0. The localization feature of PartyLine2.0 offers reverse geo-coding sothe user can automatically get an address from the current location without havingto know it or enter it in the event. This is based on the geo-coordinates provided bythe GPS device. If the user is indoors, it is very likely that the GPS won’t pick up asignal. Because the project was developed using the emulator and a device without amobile service plan, we were not able to get geo-coordinate localization from cellularnetwork or WiFi triangulation.

Video PartyLine2.0 currently “only” supports pictures (which was the initial idea ofPartyLine). In the future, other media will be supported such as video or audio.

Timeline the mobile PartyLine2.0 application currently only support event sending andevent viewing in “map mode”. We could envisage implementing the “timeline mode”of the desktop application in the mobile one, but the initial intention was to keep themobile application lite and different from the desktop application. We only chose to

8 MEMBER CONTRIBUTIONS 22

implement the ma mode on the mobile device to facilitate the user going to a eventhe/she wishes to attend.

APIs are another major problem or bottleneck for PartyLine2.0. Indeed, this initialPartyLine application was based on the twitter API, which we have kept in thearchitecture and design. Twitter only allows 140 character status updates, whichmeans we have 140 characters to contain event title, description, image, location, etc...This is why we used the TinyURL API, to encode the previously mentioned data.In an nutshell, PartyLine2.0 relies on many different services and API which can amajor problem. For example, GlowFoto which we use to host PartyLine2.0 eventimages just recently removed the feature of having a direct link to the original sizeimage, the only provide a direct link to the thumbnail. The Twitter API changes thelogin procedure form time to time which prevents PartyLine2.0 user to login. Thereare a great number of API call and internet traffic due to number of APIs (Yahooand Google for address geo-coding and reverse geo-coding, GlowFoto for pictures,Twitter, etc).

8 Member Contributions

The PartyLine2.0 project was developed as a group project and each one of the project’steam-members contributed to the proper development of the application. In this section,we details each team-member’s responsibilities and contributions a bit more in detail.

Huning DAI was the lead user interface designer. He was responsible for the creation of“everything the user sees” (most screens). He also implemented the necessary linksbetween the screens and the backend of the application. Huning DAI also took partin the extensive application testing and debugging.

Nathan MURITH was the team lead and lead architect. His responsibilities were ev-erything and anything that had to do with administravia (writing reports, creatingvideos, submitting assignments, getting the presentations ready, etc) and managedthe project (set up milestones, divided the work, project website, SVN repository,etc.). In addition, Nathan Murith was responsible for setting up the various servers,implementing, testing and deploying the various PHP proxies. In terms of the mobileapplication, Nathan Murith was responsible for the backend (“controller” part of the“model-view-controller” design pattern). He implemented the mobile application’s“proxy” code (calls to various APIs, data cleanup (i.e. return timeline or just friendsnames), call to the PHP proxies, etc). He also implemented the various tools neededfor the proxy calls (FTP file upload, current date and time minus 12H, etc.)

Xuyang SHI was responsible for the “View Event” portion of PartyLine2.0. In otherwords, he implemented everything that had to do with the maps portion of the

9 LESSONS LEARNED 23

application. He also implemented a couple function of the backend in order to satisfythe viewing of event. He was, in addition, responsible for the localization part of theapplication (frontend of the GPS feature and its functions).

9 Lessons Learned

Working on this project was another great collaboration opportunity. It was also extremelyinteresting to start working and developing on the iPhone and Android. If we were to do theproject again, we would definitely like to try implementing an application on the iPhone.The Android was extremely interesting and straightforward for any Java developer but itlacked the “new and unknown” aspect the iPhone would have had for our team. On a moreadministrative level, we would look into ways to schedule a greater number of milestonesand definitely figure out some ways to enforce these in a more strict manner.

10 Conclusion and Future Work

We now provide a few concluding comments and remarks on future work. The first andforemost remark is that PartyLine2.0 is now complete and offers a collaborative notificationsystem for partiers. Unlike its competitors, PartyLine2.0 is live and is not “simply” anarchive of past or future events. Using the mobile both the mobile and desktop portions ofthe application, PartyLine2.0 offers an easy, clear and complete way to effectively notifyyour twitter friends with ongoing events. We do claim PartyLine2.0 is perfect or bug-free, it is currently still at the stage of academic project but is close to being a final anddistributable application. In future, we plan to port PartyLine2.0 onto the iPhone (work inprogress) and tune up the current Blackberry webpage. We would also like to implement ancontext-driven rotating ad feature for potential future revenue sources. In addition to thesehigher-level changes, we will make the necessary changes so that localization works boththrough GPS and with cellular or WiFi network triangulation. Audio and video supportwill supplement the current picture only feature. We will also “clean up” the proxy andbackend parts of the application so that the device and desktop parts only make calls toone server containing all proxies. And finally, we would like to set up our own server farm(depending on the usage) to make PartyLine2.0 more stable and scalable.

A ACKNOWLEDGMENTS 24

A Acknowledgments

Although we have not received any direct help or contributions for the mobile part of thePartyLine2.0 application, we would like to thank the following people for the work relatedto the desktop portion of PartyLine2.0 :

Joshua WEINBERG - Columbia University undergraduate student for his helpand contribution as team member of the PartyLine project, desktop application. Hehas also been of great help in understanding the sever side of web application suchas PartyLine2.0.

Green ZHANG - Columbia University graduate student for his help and contri-bution as team member of the PartyLine project, desktop application.

Keerti JOSHI - Columbia University graduate student for her help and contribu-tion as team member of the PartyLine project, desktop application.

REFERENCES 25

References

[1] Glowfoto upload api, 2008. http://www.glowfoto.com/api_upload.php.

[2] Google Maps API for Flash, 2008. http://code.google.com/apis/maps/documentation/flash/.

[3] Tinyurl, 2008. http://tinyurl.com/.

[4] twitter, 2008. http://apiwiki.twitter.com/.

[5] Yahoo! maps web services - geocoding api, 2008. http://developer.yahoo.com/maps/rest/V1/geocode.html.

[6] Android - An Open Handset Alliance Project, 2009. http://code.google.com/android/.

[7] Android Developers, 2009. http://developer.android.com/.

[8] iPhone Dev Center, 2009. http://developer.apple.com/iphone/index.action.

[9] Mobile Computing with iPhone and Android, 2009. http://www.cs.columbia.edu/

~nieh/teaching/e6998/.

[10] Rave Alert, 2009. http://www.ravewireless.com/products/ravealert.

[11] SimpleFTP, 2009. http://www.jibble.org/simpleftp/.

[12] Welcome to PartyLine, 2009. http://www.columbia.edu/~nam2140/nm/PartyLine2.0.html.

[13] Huning Dai, Nathan Murith, and Xuyang Shi. Development Video, March 2009.http://www.columbia.edu/~nam2140/nm/PartyLine2.0_files/PartyLine.mov.

[14] Huning Dai, Nathan Murith, and Xuyang Shi. Development Video 2, March 2009.http://www.youtube.com/watch?v=v3_638ORa3w.

[15] Huning Dai, Nathan Murith, and Xuyang Shi. Homework 2 - Project Proposal.Technical report, Columbia University, February 2009. http://www.columbia.edu/

~nam2140/nm/PartyLine2.0_files/hwk2.hd2210.nam2140.xs2137.pdf.

[16] Huning Dai, Nathan Murith, and Xuyang Shi. Homework 3 - Initial Mockup. Technicalreport, Columbia University, February 2009. http://www.columbia.edu/~nam2140/nm/PartyLine2.0_files/hwk3.hd2210.nam2140.xs2137.pdf.

[17] Bill Dudney, Chris Adamson, and Marcel Molina. iPhone SDK Development, 2009.