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 nil

Daniel Funaki, Douglas Shaffren, Taiji Kamiya, Lawrence Tse

Greetings weblings! Thank you for surfing to our home in cyber-space, our website is full of wonderful ideas on how to improve your design by learning from... guess who, us!

we hope you enjoy your stay here. (c:

Milestone 2

For Milestone 2 we had to think carefully about the design of the backend. Our design philosophy was strict in that having a well engineered backend will make debugging subsequent
milestones easier to implement. We took care in designing the network messages to allow for expansion. Admittedly our design expectations for the network and the Squeak language learning curve were in direct competition with each other. This was remedied by working together, looking at examples and sharing knowledge openly with group members to accomplish our design goals.

Squeak has no official centralized API, so the hardest part about this phase was learning how to do complex tasks in squeak such as sending messages over a network. To learn networking in any language it’s always best to look at a chat program. So we did just that. We learned Squeak sockets by studying a chat program that was kindly implemented by a 2340 TA. Team nil endorses the learn networking in your language of choice by creating a chat program.

In the chat program, client just sends simple ‘String’ to server and sends back the ‘String’ to all clients. We had to do more complex task with our network. First, we decided to use Sixx to convert the message object into ‘String’ and send it as in the chat program. Next, we created ‘Message’ object which has ‘data type’ and ‘data’ fields. When we want to send an object, we could just assign appropriate data type and data, which is the object we want to send, to message object and send it. Finaly, we changed the way the chat program broadcast to all clients because we sometimes don’t want broadcast to every clients. With the 'Message' object and sixx we could easily send any data as we needed.

Since coming from a Java background creating the GUI using squeak was interesting. This is because Squeak has a different type of syntax, and everything is an object. The usage of morphs is a really nice concept and it was fun to learn. A difficulty that our one of our GUI members found was creating a button with an image as a background. Since the original button morph doesn’t support that functionality we had to research and found that the Iconic Button was a great morph to use. From then on, Iconic Button was used in numerous cases. The GUI in squeak was a pretty easy task to do, but just tons of adjustments and tweaking. So expect that!

Milestone 3

For this milestone we were required to create a design that will get us from this point to M6 this requires that we have
a PDA version of our desktop location based service application as well. We had to create a version that was practical,
and broad enough so that it would be easily maintainable and could be readily identified as to what was causing a problem
if such an error occurs. This proved to be more complicated than expected because our team had to decide on whether or not
we wanted to use Squeak's ability to reuse code and override the methods which were different or to create two systems
one for the PDA and one for the Desktop which basically contain the same functionality but no methods would be overridden.
Uploaded Image: m3 - v1.png.PNG

Uploaded Image: m3 - v2.png.png

Our team decided to use the latter. The reasons why are because
1. We did not find enough common variables and methods between the two for the PDA and Desktop.
2. Easier to maintain, and debug.
3. Porting two systems for networking would be more efficient with SiXX.
The two sepearte systems proved to be more benifical because with classes inheriting
from other classes, it would be harder to determine which class was producing errors when debugging would necessary with

Since network worked pretty good, we decieded to use same structure for the rest of milestone.

Helpful info:
Analyze which components can be reused and which ones won't, if you see a significant
distinction between two Classes but they both essentially do the same thing. You may want
to seperate them and save space-time, it may actually be better in the end. Use a schedule!

Uploaded Image: schedule.JPG

The test plans for this milestone required that we were able to check if the new addition of windows
showed up, SUnit can only test so much we needed to test for things we could visibly see, that was
the basis of which we created our test plans.

Our Scenarios for this milestone included how users would use our PDA location base server. From
beginning to end of the possible choices the user could make at this phase of our location based server
on both the PDA and Desktop versions.

Test plans - Testing Plans.doc
CRC cards - CRC.doc
Scenarios - Scenario.doc

Milestone 4

For this milestone we were required to create a PDA version of our desktop location based service application with
the same functionality. Using our UML from Milestone 3 this worked out well for us. Because we created two different
versions of our location based service we were readily able to locate the errors when sending messages across the network.

We needed some attention in order to use same classes such as server and network for both PDA and Desktop GUI.
Server and network shouldn’t care about whether their clients are PDA or Desktop.

The PDA also had a variable width and height that needed to be maintained more so than the desktop version because
of the location of the PDA windows needed to be maintained to get the maximum viewing window.

Uploaded Image: pda-login.jpg Uploaded Image: desktop - loginScreen.jpg
Uploaded Image: pda-park.jpg

Helpful info about PDAs:
Some of the difficulties in this milestone was configuring squeak on the PDA.
unless your really good at pointing the PDA pen to the exit screen, you may want to
take the exit button off of the menu and put it in the project space, then save the image.
This way you won't have to fight the menu to exit Squeak on the PDA.

Test plans - Testing Plans.doc
CRC cards - CRC.doc
Scenarios - Scenario.doc

Milestone 5

The goal for this milestone was to implement an air graffiti service. This ment that people who are in a certain location can leave notes for everybody in the place to see. This ability will add more functionality to our location based service so that it will actually become more useful for people to use. If an important message needed to be
given to somebody, the user can create and drop a note at their location and leave it on the ground. We needed a way to implement the notes such that a note will have a certain radius from which it was dropped. People who search for notes that are within the radius of the note they will be able to see it.

The implementation for the GUI of both the desktop and PDA version are pretty simple but at the same time, complicated. I can reuse numerous of code from the previous Milestone, and all the thing I did was added more GUI. The GUI setup is pretty easy to maintain, because the client is in charge of the main window and from the main window, he is in charge of keeping the sub windows. The way to implement this makes it easy to reuse code and also made it easier to edit code later or add some more windows to it. The color scheme took a while to implement but it was fun to make the windows much better looking. Being able to edit the color of the morph and it’s border made it more interesting and doesn’t have to make it so dull. The bottom two line on the bottom edit a morph’s borderColor and the Morph’s color.

MorphName borderColor: Color #color#
MorphName color: Color #color#

Uploaded Image: desktop-choosePlace.jpg
Uploaded Image: desktop-park.jpg

Helpful info:

Test plans - Testing Plans.doc
CRC cards - CRC.doc
Scenarios - Scenario.doc

Milestone 6

When a client writes a broadcast note, client sends it to his server. When the server gets the note, the server stores it into his database. Whenever a user moves to another location, the client will tell the movement to the server. Based on this information the server will check if there is broadcast note around the client. If there are broadcast notes, the server will put those notes into a message object and sends it to the client. When the client receives the message, the client will check the category in the broadcast notes with his filter system. If some notes pass the client's filter, the client will tell the GUI to display those notes.

The GUI for M6 was again easy to implement since we reuse all our previous functions and windows. But for M6 we had to add more windows and also more morphs. We had to use the checkBoxMorph and radioButtonMorph. I got the classes online and edit it to my preference. For the PDA version of our GUI, I enhance the look and feel of it by adding a 3d look to it. All of the buttons and images are created by me under photoshop.
The function call “addMorphToBack” or “addMorphToFront” was useful in making sure the background image doesn’t cover up the necessary components that the users need to interact with. For this milestone, we had implemented a filter system and I created constant under the main GUI so if we need any of it, we just call LocationViewerWindow #constantName# . This way, we don’t have to hardcore numbers everywhere and get it very confuse if we need to edit the numbers in the future. The radioButton Morph and CheckBoxMorph was very interesting to use and really helpful. Also I found out during this phase of the project that I can made the color as transparent.

MorphName color: Color transparent.

This will make the color of the morph transparent and we can see the color underneath it.

The pictures below are the login screen for the PDA, the choose place screen for the PDA, and the Main Window for the PDA
Uploaded Image: m6_pda_login.JPGUploaded Image: m6_pda_choseplace.JPGUploaded Image: m6_pda_mainWindow.JPG

Below are the screen for the Filter Sytem, the choose type of message screeen, the two different viewing message screens and the two different creating message screens.

Uploaded Image: m6_pda_checkMessage.JPGUploaded Image: m6_pda_createMessage.JPG

Helpful info:

Test plans - Testing Plans.doc
CRC cards - CRC.doc
Scenarios - Scenario.doc

Links to this Page