This has links to the trivial implementation code I wrote, but most importantly, links to the API automatically generated by javadoc. I've upgraded the code by adding javadoc-compatible comments and then generated the API.
Here's the API created by javadoc. To do this, I created a subdirectory, jdoc, in the folder containing my Java source. Then I ran the following command line while in the directory with my sources. It creates the documentation as web pages, and places them in the jdoc subdirectory ( -d jdoc option).
javadoc -d jdoc *.java
This resulted in a big collection of files that can be accessed on my
site at the following location:
http://www.ccs.neu.edu/home/futrelle/teaching/jug/cellcode/jdoc/ or via
this simple relative link.
You might want to follow the Index link on the page to get a quick overview
of everything that's documented there.
To learn more about javadoc, here is the basic link:
Much more can be found by searching w. google on javadoc.My code updated with javadoc comments:
Looking over two references (below) taught me some basics which shouldn't be too hard to implement in a simple system. The simplest system that can communicate is two phones and one base station. That's a good system to shoot for as the next step in our work. Let's assume that "space" has a few channels, which is represented by an array of Channel2 objects. (I'm using '2' now to indicate that this is the second version of the system. Current classes all end with '1'.) Channel2 objects have to be pretty 'dumb' since they're just messages in space, with no memory or anything, such as phones or base stations have. Let's assume that each channel has fields:
The other part of all this is to build the functionality you need into each step function -- which should call any other functions it needs that you can design. Just think through the steps: Check a channel, when one is found, dial a number. If the other phone is busy, shut down for a random number of steps. If OK, send some talk messages and check for returned messages (maybe each channel will need incoming and outgoing messages -- makes sense). After a while, turn off the inUse flag and the base will know you've hung up. Think through the problem this way and you can make progress on your design. Implementation should proceed in very small steps, getting one small piece working, then another, and so forth.
To get closer to real cell networks, we'd have to set up distinct channels for the base stations and phones, as well as separate voice and control channels. This gets complicated fast and is exactly the thing we don't want to jump in and try to do now. It would be too much, and we wouldn't be able to see the forest for the trees and I'm afraid the quarter would be over before we even figured out what to do.
A couple of easier-to-read references than the previous:
Important -- Designing your system aided by javadoc: You should rough out your code, starting with empty methods, and add javadoc comments to it and produce your own description of the API you're trying to build. This is the way to proceed.
Sitting around the lab on Tuesday afternoons is fun, but we need to have more structured discussions. So let's meet in a classroom during the Lab B time. I suspect that 149CN will be available, or 8CN. If all else fails, we'll meet in my office, 115CN. I'll check on Monday 2/4 and send email if we're not going to meet in 149CN.
We'll be able to discuss things via the whiteboard and do some real planning. Be sure to print out the new material on the site -- source code and javadoc documents and this page and bring your copies along to the Tuesday meeting. I really think we can make some progress by working in this way. N.B. If you want to print, sometimes you may have to open a web frame as a separate page to get it to print.
Part of the discussion should cover the issues of how we can work as a team.