Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Our Group consists of:
We are all second year CS majors at Tech and this the first experience everyone has had with Squeak. The project for this semester was to construct an application that provided an original location-based service. The application allows users to specify their current location and view the locations of others. Users were also able to read notes assigned to a location and write notes to leave at their location. For our original location based service we implemented a Restaurant Finder. Based on the users location, they can search for restaurants or check wait times, make reservations, and view the menu of a selected restaurant in the area. Users can also access our service away from their desk, with the personal digital assistant (PDA) versions of the service.
Below are descriptions of each step of the process along with our files and some of the issues we had with each other, squeak, the PDA, and life in general.
M2 - Build a Simple Location Service
Download our files: M2turnInFiles.zip
- To form your team.
- To get more experience building classes.
- To build a simple network server.
- To try your hand at building simple GUI elements.
- To use SUnit for more complex tests.
For this milestone we created a basic location based service. The GUI was built using a variety of submorphs and we decided to make the GUI larger than we actually need to leave room for any extra functionality we would have to add later. The network was implemented using SIXX and in this milestone if a client sent an update to the server, the server would resend the entire world to all of the connected clients.
For this milestone, we created the network and backend classes (person, place, etc) completely seperately. When it came time to integrate the two we had some issues that took a little bit of time. Better communication earlier on and a little cooperation between the two different programmers would have helped with this issue.
Because Squeak is an open source language and you can make whatever changes you want to different classes, you have to be very careful about what you change. One of our group members had changed something in what he thought was a completely unrelated class earlier and it ended up effecting the project. Best solution to this is to constantly create new images and if you can't figure out what is wrong just replace the image you are using with a working image.
When we were integrating the GUI, backend, and network together, we ran into a strange problem. One of our group member's was getting weird problems when images were being transferred over the network. The images were being sent, but they were being corrupted. This would then cause a squeak error when the GUI tried to display the image. After a few hours of trying to solve this problem, we found out what it was.
It happened because earlier in our M2 process, we had investigated some Squeak plugins to help in building the GUI. While installing one of the plugins, we were instructed to change a line of code in the concreteStream method of the FileStream class. We were instructed to change it to return CrLfFileStream instead of StandardFileStream. We saw no problems with this, because there was a comment in that method that even mentioned that precise change. Here is what the line said: ^ StandardFileStream "may change this to CrLfFileStream"
This turned out to be the issue. A quick change back to ^StandardFileStream fixed our problem. So if you change this for some reason, beware.
For this milestone one aspect of our network wasn't working correctly. For some reason the variables weren't getting updated on the client when we expected them to. So when the user added themselves to a Location, it wasn't getting displayed when the map first did an update. If you clicked the update button again, you would show up properly. You could also just use the change location button to reload your current location, that would work as well. This issue would stay with us for quite a while.
Check out our M2 GUI!
M3 - Design Everything
Download our files: M3turnInFiles.zip
- Plan, Analyze and Design the Entire System
For this milestone we designed our entire application all the way through M6. This included creating CRC cards to handle scenarios we created from discussions about what we wanted the user to be able to do. Developing a thorough test plan, detailed class descriptions, and a basic UML for our final application. Another very important part of this milestone was creating a team timeline to keep us on track through the rest of the semester.
The way our network was designed, sending the entire updated world to all the clients everytime a change was made, required a lot of time and was not very effective. Before you jump to conclusions about how things should be designed and how to develop them, it is a good idea discuss alternatives and there pros and cons. We didn't think this design decision through and it showed as our world got bigger and the server had more clients.
Read the instructions very carefully for this part of all of the milestones. We didn't understand that they were suppose to be very specific and ended up losing a lot of points because of it. It is always a good idea to check out the cases pages and any examples they have for anything you are not sure about.
It is important to get the professors approval for your project as early as possible. This will leave you with lots of time to deal with new problems or issues that arise because of any changes the professor makes to your project idea.
Remember to keep things simple. The worst mistake your group can make is to bite off more than you can chew. This project was not meant to be extremely difficult but could be made so by poor design decisions. If you keep everything simple from the begining it will be easier to go back and change or add things as needed.
M4 - Create a PDA Port
Download our files: M4turnInFiles.zip
- Learn more about building graphical user interfaces.
- Learn how to develop for the constrained resources of a PDA.
The purpose of this milestone was soley to take our application and port it to a PDA. Basically what this meant was changing your GUI so that it could be viewed and used on a PDA's tiny screen. Since our desktop GUI had a lot of buttons and required a lot of screen space, we changed to the GUI for our PDA to have different modes. This effect was created by layering submorphs so that only certain functions would be shown at a time.
As many groups discovered, PDA's have limited memory and when you use the regular sqeak image you can run out of memory quickly. We solved this problem by deleting certain things out of our image that we didn't need like squeak games and various other applications to shrink the image down a bit. Another solution was to use a smaller squeak image one created especially for PDA's. We didn't use the latter option, because when we tried it originally, we had network problems. Instead of spending extra time trying to find and add in what might have been the problem, we just stuck with the first option, and removed some unnecesary classes.
For some reason our scroll pane for the map display had not been working correctly up until this milestone. The scroll pane's scroll bars would never resize to the normal, draggable smaller bars. Instead, it filled up the entire bar. This meant, that you had to scroll with just the slow arrow buttons . This was not very user friendly. Finally, through lots of trial and error, we came up with a fix or workaround to this problem. Apparently, when you call the extent function on a TwoWayScrollPane, it resizes the scroll bars. Even if you don't change the extent, it resizes it. So, all we did was set the scroll pane's extent equal to that same scroll panes extent, and it worked. Now, everytime we changed maps, our scroll pane's bars would resize properly. Also, for some reason, in a TwoWayScroll pane, there doesn't seem to be a left arrow key on the horizontal bar. We never figured out why this was, or how to fix it.
In our case, our desktop GUI required a lot of screen space. Since the PDA had less screen space we changed our PDA GUI so that it had different "modes" or "views". Each of these views was created by layering submorphs on top of each other and hiding other morphs. This created a nice looking, and user friendly way to get all the options in our GUI. For example, you click the login button, and the login fields show up by themselves. You can then enter the ip address and port number of the server you want to connect to, click the connect button to connect to that server, and then click the done button to return to the previous view. We thought it was a very good method of shrinking down the GUI. Also, we had to switch the position of the map window with the control panel so that when the user uses the keyboard function on their PDA they can see what they are typing into our text fields.
Check out our M4 PDA GUI!
M5 - Implement an Air Graffiti Service
Download our files: M5turnInFiles.zip
- Learn more about building graphical user interfaces for desktops and PDAs.
- Learn about developing location-based services.
For this milestone, we implemented a location based service called Air Graffiti. This service allows the user to read notes left at a location or write notes to leave at a location. The user can also search for notes located within a certain radius from them. To implement this we added more functionality to our desktop application and a new "mode" to our PDA application.
We finally fixed the update button for this milestone. Now you only have to click once to have you information updated. To fix this it was as simple as changing our network so that when an update occurs, the client doesn't have to ask for the update, the server automatically sends the update to the client. This was a really nice addition to our project.
In this milestone we began to see the issue with our network design and the downfalls of sending the whole world back and forth over the network. To fix this we set the network up so that instead of sending the entire world to the server and then to the clients it only sends the updated object. The server updates itself as well so that it can send the world to new client connections. When we first set up the network with the old design (the entire world was getting sent to clients) the problem wasn't apparent in the beginning. Between computers, using sixx for objects (not images) seemed very fast just updating the world. However, once we started updating multiple objects at greater intervals, the large chunks of data we started sending starting slowing our GUI down so that there would be a noticable (few seconds) delay between actions happening. Once we switched to the new method, the actions and changes became almost instantaneous.
When they tell you at the begining of the class that descriptive variable names are important, they mean it. For some reason, in this milestone we had an issue with the variables extent and location. We used both of those names, in quite a few different classes for our project. During this milestone, we weren't all on the same page as to exactly what location meant and exactly what extent meant. In our code they keep getting interchanged with one another. Location is a textual name for a place and extent is a coordinate, normally so something can be displayed on the map, so this wasn't good. It took us a lot of extra time to go back and figure out which code was using those two variables right and which code wasn't. To make life easier, pick good, descriptive variable names from the start and try to keep everyone one on the same page.
Check out our M5 GUI!
M6 - Design Your Own Service
Download our files: M6turnInFiles.zip
- Learn more about building desktop and PDA graphical user interfaces.
- Exercise your creativity.
For our final milestone we implemented our Restaurant Finder service. This service allows the user to search for and find restaurants based on different criteria and search radius. Once finding a restaurant, the user can then check the wait time, view the menu, make a reservation, and add a critique. The Restaurant Finder service was created for both the PDA and desktop versions of the application.
With the new functions that we added to our application we ran out of space on our desktop GUI. This forced us to implement buttons that were used to change the "mode" the GUI was displaying. Different buttons, restaurant, users, and notes, would display different morphs that allow the user to complete different tasks. This is the same idea we used to make the PDA version of our application and it would have made it easier from the start if we would have realized this idea would be needed at the end too. It provides for a much nicer looking interface, while being very user friendly.
Make sure that when you are using variables you actually remember to instantiate those variables in the class first. We had an object we were adding to a collection, and for some reason, one of its variables would always get overwritten by the last object entered into that collection. We spent a good hour trying to figure out why things were not working and it turned out that even though we had all the accessors and modifiers the actual instantiation was not there. In our case, everytime we tried to use that variable it was creating a static variable and that's not what we wanted.
Check out our M6 GUI!
Our Final Project In Action
Here's a picture of what our final submission looked like, running and connected to a server:
Link to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu