Readme.doc

weaverchurchΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 5 χρόνια και 1 μήνα)

267 εμφανίσεις

USAGE:


Client Side:


1
-
) Run the program in netbeans emulator

2
-
) Find available servers

3
-
) Connect one of them

4
-
) Listen to server res
p
onse

5
-
) If server not agreed, find another one

6
-
) If server agreed, press enter to play.

7
-
) Hit the stop for jackp
ot

8
-
) Having seen the result, decide to continue, or return to main menu to play with
another server or exit the game


Server Side:


1
-
) Run the program in netbeans emulator.

2
-
) Start the server if you want to accept incoming requests

3
-
) Having started

the server, wait for incoming requests

4
-
) If a user wants to play with you, accept it or reject it.

5
-
) If you’ve rejected opponent, you are still in wait state.

6
-
) if you have accepted opponent, you see the slot machine running until the client stops
i
t.

7
-
) Until the opponent exits or returns to his main menu
, this process continues.

8
-
) When opponent finishes playing game, you return back to your main menu

9
-
) At this point, you can wait for the next client or exit the program


CHALLENGES OF MY PROJE
CT


I’ve wanted my clients to connect to a specific device they
choose. Java’s high level
Bluetooth A.P.I.’ s ease the job of programmers when trying to connect to a service, but
it is up to
the
device implementation to use
which remote device
offering th
e same
service. In order to do that, I have used
Java’s
low level Bluetooth A.P.I.’

s
to have more
control. I have put all the code in the ServerFinder class for software re
-
usability. This
class is multi
-
threaded and requires thread synchronization. Anoth
er problem of
Bluetooth is upon receiving a message, you don’t know where to reply back. I have
written a generic class to send messages to opponents
. When a message is sent, you add
your address, name, message and a status number. The status number is use
d by the
recipient to understand what you intend to do. When the server replies back, it also writes
its address, name, message and its status number. Actually, both the client and server
code look the same in terms of sending messages and listening to opp
onents. They
only
differ in their functionalities and looks. To combine them easily and change the
architecture from server client to peer to peer
, I’ve used unique status number. Here are
their meanings


Server Side

1
-
) Game Request

4
-
) Stop the slot mach
ine

6
-
) Start the slot machine

7
-
) Client exited the game

10
-
) Generic error message


Client Side

2
-
) Game request accepted

3
-
) Game request denied

5
-
) Get the results from server

10
-
) Generic error message



Another challenge of this project is thread s
ynchronization and watching whether they
end appropriately or not. I tried to use synchronized block
s

to improve performance
instead of synchronized methods which lock the whole object. I have used the join
method of thread class to make sure that a starte
d thread has already finished its
execution before a correlated work is done in another thread to make sure that the first
thread has accomplished its task. Because in J2ME world, memory

usage is important, I
have applied l
azy

variable initialization tech
nique. Sprites and Tiles were easy to use and
improved my code writing.
I think that I did a good job in use case scenarios. Let me give
some examples. If the client searches for the service and doesn’t find a

server, it warns
the user and doesn’t hang for
ever to find one. If you try to connect to a server which is
already serving a client, without interrupting existing connection, the server tells the
second client it is busy. If two clients try to conn
ect to a server
, the server

doesn’t forget
the second
request while being busy with the first request.