View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Team: Mad Scientist's Union 42

Hello future students of the wonderful language of Squeak. 2340 is a class full of wonder and excitement. I will now tell you the tale of a group of students who used creativity and just a little bit of planning to create a LOCATION BASED SERVICE for PDAs specifically milestone 3.
Kimberly Spreen
Stephen Schulze
John Dibble
Timothy Liu

A brief overview

There was project assigned one spring long ago in the year 2005, for a 2340 class at the Georgia Institute of Technology. The project was a new and daring concept that turned more than a few heads towards the rookie squeak programing class. The Location Based Service project for PDAs was proposed as a as a subsitute for normal boring smalltalk homework. Little did the faculty realize that the project would save thousands of lives and eventually be the savior of the georgia tech campus.

The project was to design a program that could be used on PDAs where one could place their avatar somewhere on the georgia tech campus map. People would be able to see each other and interact by leaving notes for each other. The final milestone was left up to the programmers creating the project.

Uploaded Image: bigscreen.JPG

Little known at the time the assignment was given out, a powerful monster was stirring in the deep.

Milestones 1 and 2 were preliminary steps in completing the final project. They were to program the inital structure and protocols for the project. Minimum requirements were a server that was capable of handling multiple clients that could connect and exchange information and edit their descriptions. The server would hold user locations on the campus map as well as user details. A high security system was also implemnted so that each user would have a unique username and password.

Spring 2005 M3: Design Everything


Early the morning of Febuary 17 Godzilla attacked!

As the rest of the campus was rampaged by the fire breathing monster, a small group of 2340 programmers united in the college of computing in a couragous attempt to defeat the monster.

They were The Mad Scientist's Union #42, the last stronghold of hope for the Georgia Tech campus.

Having finished milestone 1 and 2 they began their design for the rest of the Location Based Service. Initial meetings planned milestones 4 and 5.

Milestone 4 was to implement an air graffiti service on the project where a client could add notes to areas on the campus map that other people could search for and read. Notes could be left in specific proximity to people so that they could search for notes that are closest to them. A notes class with author, location, date and a message was formed. Searching methods for the notes were also added to the UML for the server and client.

Milestone 5 was much easier to plan as the pretty much the only major difference for porting the program to a PDA was to configure the GUI to resize based on how big the screen was. These methods were planned and added to the UML.

Uploaded Image: lilscreen.JPG

The time to plan milestone 6 was at hand. During this time thousands of Tech students had suffered at Godzilla's mighty wrath. time was running out. The union of programmers met several times with different ideas for milestone 6, none of which seemed adequate for the creativity that milestone 6 required. Then late one night after several heated debates over new ideas involving the ability to form gangs in the program, Stephen Schulze, after silencing the group, presented an idea that promised a brighter future for all who remained on tech campus.

It had been found that groups of students large enough could scare away godzilla, but no one ever knew where he was or where he would attack. The new system that would be implemented for Milestone 6 would enable everyone who had the program to know when godzilla was near. A warning sound would play ensuring that people would then find a group of people as quickly as possible. Groups of students would also be able to unite to scare godzilla away. If planned correctly a group of students could scre godzilla into areas on campus where gun turrets were setup to kill godzilla. This plan offered a ray of hope in a time where the student government thought that all was lost.

The mad scientist union created new senarios based on the new idea and drew in new use case diagrams and modified the UML accordingly. They were ready to begin the final assault on godzilla.

Spring 2005 M4: Create a PDA Port



There were multiple obstacles that needed to be overcome before we could port our service to the PDA. The biggest was that the window containing the map would constantly refresh, so it would cover up any windows that were placed above it – since the PDA had only room for one window at a time, so any extra pop-ups we made, such as the window for changing user description, would not be displayed. This problem was fixed by using the Morph class’s ‘refreshWorld’ function to redraw things – it only refreshed the contents of our window without refreshing the window itself. The fix was simple, but finding it was time consuming.

The second obstacle was designing our GUI such that it would fit on the PDA. Our GUI was originally structured such that the map was on the left hand side, and the buttons on the right, so it was designed with a greater horizontal length. The PDA on the other hand was vertical, and smaller. So, we decided that the best solution would be to put the buttons below the map.

The third obstacle was compatibility with the PC version. Our server kept track of all data as if it were the size of the PC version, but the PDA has smaller size, so things had to be scaled, including the user icons and map images. This was easy enough to resolve, and the PDA client handled conversion so the server would not have to keep track of who was using what type of client.

The fourth obstacle was a hardware issue. Our PDA died – it turned out that the model had a flaw that would make it shut down permanently if the battery was completely drained. We were unable to fix it, and had to get a new PDA from the TA. Due to this, our ability to test on the PDA was hampered for a time.

Why simple is sometimes better.

Before we had actually put our code on the PDA to test, we had heard terrible rumors that other groups had been having problems with their networks when testing on the PDA. You can imagine that we were pleasantly surprised when our network worked perfectly on the first try. We believe that our network worked so well because it used an extremely simple design. Clients and the server communicate by sending Arrays of Strings, the first String being a command that the receiver would use to determine what to do with the remaining Strings, which were data regarding what was being sent. From the Design Roundtable, it seemed many groups had used more complex designs.

Memory problems

The only problem with running our service on the PDA itself was that it eventually would run out of memory, and it was somewhat slow at times. To solve this as best we could, we eliminated all transcript statements, as we had a lot of them building up every time data was sent or received.

Spring 2005 M5: Implement an Air Graffiti Service


Due: 4/14

Time was running out. Godzilla's rampage had brought a reign of destruction and terror to the students on Georgia Tech campus. But while the managment majors were being eaten outside, the engineers work furiously to find a solution. President Clough, able to find no other option, ordered the International Affairs majors out into the streets to distract Godzilla from doing harm to Student Center. He destroyed them all. Meanwhile, the Mad Scientists Union #42 was working to find a way to finish godzilla for good.

The first step was to create a way that people could communicate with each other. A highly complex note system was developed. One is able to log onto the server with the client program and leave notes on precise locations on the map. People are then able to search for notes based on where they are located. For example, they are able to search for all notes within a radius of 40 of their current location. In this way people can leave notes for others warning them that the certain place may be where godzilla hangs out a lot.

The first obstacle we ran into was were to store the notes in the program. We needed to decide if the server would contain all of the notes, or whether the server would transfer all of the notes over to the client on logon. Finally, we decided that the client didn't really need all of the notes, and that the notes would be transfered when needed. That way when searching for notes, the clients would send a query to the server, the server would then look it up and find the notes, and send them back to the client.

The second problem we ran into was how to search for the notes. We needed a way that the client compputer could send a point to the server as well as a searching radius, and from that information, the server could determine what notes were in the radius. Using a method called tolerance which takes in a point and a radius we were able to do exactly that.

However, that brought up the problem of mapping a point to a particular point on the big map. We put in one point, but it could be mapped to a number of places on the big map. We created 2 sets of points. One was their location on the present screen, and one was referring to their point on the whole map. In this way were were able to create a system in which we could search for notes that were closest in a particular area, and it would not be confused for pixels on the entire map.

The mad scientist union #42 was finally ready for the last step in the program.
The final showdown would begin. Brain against brawn.

Godzilla was going down....

Link to this Page