Homework 4
|
Modified: |
Overview
Homework 1b and 2b implemented a client/server TicTacToe game using the MVC pattern.
Homework 4 refactors Homework 1b or 2b to implement a peer-to-peer TicTacToe game with a user playing against another nearby over Bluetooth for iOS and Bluetooth or TCP for Android. Note that an iOS Bluetooth implementation is not interoperable with an Android implementation.
Equipment on Library Reserve
3 Android devices - all should work using TCP, use the Motorola Xoom only for Bluetooth. The Chinese need a device driver which should already be installed on the Library computers.
2 iTouch devices - for Bluetooth only. You will need to have a valid certificate to install to these devices or use two Macs for testing in the simulator.
Android Bluetooth
Bluetooth is not emulated. To complete the assignment, you will need access to at least one Android device.
An Eclipse project and a Bluetooth USB dongle is provided that should run on Mac or Windows to allow testing of your app on one Android device.
The JavaTicTacToeBluetooth project runs on the console window. Things to keep in mind:
- The UUID of the Android and JavaTicTacToeBluetooth project must match.
- It assumes the client plays first and plays O.
- When executed it first checks if a TTTService server exists, if so it attempts to connect as a client, if not it starts as a server and waits for a client connection.
- When the game is over, the JavaTicTacToeBluetooth project disconnects and repeats 3. above, creating a little delay after each game.
- Execution can be stopped by clicking the red rectangle.
The JavaTicTacToeBluetooth project may provide some insight into implementing peer-to-peer but keep in mind that this example takes turns between the remote and local players while Android is event driven, and that the Bluetooth implementation for Java on a PC is different in many (most) ways than Android.
You will need to use service discovery (SDP) to locate a server providing the desired service. Be aware that Bluetooth devices cache a service reference after the provider no longer exists. The solution is to close the Bluetooth service programmatically, restart the Android device or change the UUID.
Debugging a real device is tricky but can be assisted by placing debugger breakpoints in the code and logging statements at key locations. For example:
Log.w("TTT SDP ", "Connection failed!");
displays in the Eclipse debug LogCat:
Time pid Tag Message TTT SPD Connection failed!
Hints
Use the AndroidSDPHelloServicePeerActivity.java or AndroidIMBluetoothP2P.java example in Android Bluetooth as a starting point, they are peer-to-peer Android apps.
Download
Java TicTacToe Bluetooth peer-to-peer Eclipse project for testing with your Android peer-to-peer app.
Import into Eclipse and execute. Game interaction is in the console. After game over, the connection is closed.
iOS requires setting to 32-bit execution in Eclipse:
Select the project | Properties | Run/Debug Settings | Select the Configuration | Edit | Arguments
-d32
apk files can be installed over the Web but not had luck so far installing this one directly, downloads but won't install.
Super Manager is a task manager that can install downloaded apk files and is useful for other purposes.
Android TicTacToe Bluetooth peer-to-peer apk for installation to an Android device. With the above running, you should be able to play TicTacToe over a Bluetooth connection or download to two Android devices. After game over, the connection is closed.
Testing a phone for Bluetooth functionality
Unfortunately Android devices are a an adventure when it comes to using Bluetooth, many do not implement even basic functionality correctly.
To test your phone for the homework:
PC - Download RFCOMMServer, import into Eclipse and execute.
Phone - Download the AndroidSDPHelloServiceClient, it should install OTA.
If the above works, great. You phone implements SDP, at least for the client and probably for the server also.
If not, try the following:
PC - Download RFCOMMServer, import into Eclipse and execute.
Phone - Download the AndroidHelloServiceClient, it should install OTA.
If that works, your phone does not implement SDP correctly but should function for the homework as a client with some modifications to the BluetoothP2P class discussed in class.
If you tried the two tests above, probably your phone won't work for the assignment. Stop by and we can try a few other tests.
When all else fails
Two phones and a tablet are on reserve in the library, the PCs have Eclipse and Android installed or you can use your laptop.
The tablet works as either SDP client or server, cheers to Motorola.
The Chinese phones, up to now, only work as a client without SDP functionality.
You will need to implement the work-around discussed in class notes.
To use your computer for debugging the Chinese phones, Windows requires a USB driver:
Download http://www.4shared.com/get/0MvyztbR/usb_driver_MT65xx_Android_ZTE_.html
7-zip will open the RAR downloaded.
Device manager - Use usb_driver directory for location
64 bit Windows - Thanks to Ed Drummond
For 64 bit Windows, Java programs require the 64 bit version of BlueCove.
http://snapshot.bluecove.org/distribution/download/2.1.1-SNAPSHOT/2.1.1-SNAPSHOT.62/
-Download the .JAR files only. (You probably only need bluecove-2.1.1)
-Put it where the bluecove 2.1.0 JAR file is.
-Point to the new file in eclipse (right click project -> Properties -> Java Build Path -> Libraries Tab -> Add JAR)
Android TCP
Due to the problems encountered with Android devices and Bluetooth, the assignment can be completed as P2P using TCP.
Allow the user to enter the IP number of a remote device to play against. If no remote device is found at the IP entered, the local device should wait for a connection.
To determine the IP address of a real device, install IP Address Widget from the Market which is one of the Android phone apps.
iOS
Note: The following references HW6 instead of HW4, you can use either for your work.
Download
Completed iPhone homework example (without source code).
Includes two directories:
Simulate: Built to be run in simulator.
iPhone: Built to run on iPhone/iTouch.
Resources
Apple GameKit Overview
Extra
TicTacToe Peer
Peer-to-peer networking is appropriate when no single device has special status.
The first TicTacToe instance can be started on any device, later devices would see TicTacToe devices and the user could choose which to connect.
A working example is provided that requires two simulators (two different Macs) or two real devices.
When testing your app, project folders can be transferred between machines by USB drive or over Bluetooth, which requires setup on both machines.
Simulation
Simulation of Bluetooth is performed over a local area network that transmits Bonjour service discovery broadcasts. Generally, IUS LAN does not connect machines on a physical network but a virtual network, for management reasons. However, the following Macs have been connected together on a local network and can be used for the assignment:
LF115
- B1-B3
- B4-B8
Library Macs (near Reference Desk)
US 100 Lobby
Download HW6 to two of the above machines, then navigate to the HW6/Simulate folder, open HW6.xcode and run.
iTouch/iPhone
- Go to the library and locate the iMacs.
- Check out two iTouch devices from the Reserves Desk.
- HW6 is installed, find and run on both devices, follow the prompts.
Frameworks
Add the necessary frameworks to the Xcode project (at right) by:
- Select Frameworks
- Double click
- Add | Existing Frameworks | GameKit.framework
- Repeat to add any additional frameworks at right.
Testing
- Real devices require a developer certificate be installed on the computer. See Installing application to the iPhone/iTouch. If you already have a certificate, see the part about transferring to another computer.
- Go to the library and locate the iMacs.
- Check out two iTouch devices from the Reserves Desk.
- Download the HW6 example.
- In Xcode, open the HW iPhone project directory.
- Set Active SDK to Device 3.1.3
- For each iTouch.
- Connect an iTouch.
- Run HW4 on both iTouchs and play a game.
TURN IN
Upload files to OnCourse as:
- a single compressed directory named HW4 containing the complete project for the HW4 application.
Hints
One approach is to compare the peerID of one peer with the other, the alphabetically highest plays X and the other plays O.
The didChangeState: delegate method provides one point where both peerID's are available, it is called for a variety of reasons, the one of interest is GKPeerStateConnected, which both peers receive.
-(void) session: (GKSession *) session
peer: (NSString *) peerID
didChangeState: (GKPeerConnectionState)state {switch (state) {
case GKPeerStateConnected:
{
NSLog(@"%@ connected to %@",session.peerID, peerID );
if([session.peerID compare:peerID] == NSOrderedAscending) ...
break;
}
}}
Another approach utilizes the fact that only one peer, the one chosen by the other, receives the callback to:
- (void)session:(GKSession *)session didReceiveConnectionRequestFromPeer:(NSString *)peerID
You could initialize both peers to play X and re-initialize the one receiving this callback to play O.
Personally, I like comparing peerID's because it adds an element of randomness to who plays X or O.
GKSession* session = [[GKSession alloc] initWithSessionID: @"TicTacToeID"
displayName:
nil
sessionMode: GKSessionModePeer];