background image

which  we  will  import  from  the  previous  view  controller 
(category view controller). 

When a question is presented to the user, they must choose 

a possible answer. It would not be right to derive the answers in 
the  order  they  are  written  to  the  database.  So,  we  create  a 
condition that randomly shuffles the answers "arc4random" and 
it saves them temporarily in a table of "NSMutableArray" type. 

When the temporary table is filled with the four scrambled 

numbers  of  responses,  we  display  the  answers  shuffled  to  the 
user, setting the text in every label. 

In  order  to  ensure  the  proper  operation  of  the  answer 

method,  we  set  tags  on  each  label,  which  receives  the  correct 
answer  with  numbers  "999"  and  "0"  for  the  wrong.  We  also 
equate the labels to the corresponding buttons to implement the 
method of the correct answer. 

We create a method -(IBAction) which we connect with all 

the  buttons.  Depending  on  the  user's  choice,  if  the  answer  is 
correct,  the  method  that  increases  the  points  for  every  correct 
answer  and  the  method  of  the  next  question  are  running  in 
sequence.  If  the  answer  is  wrong,  the  method  of  the  next 
question is executed. 

Finally,  to  arouse  the  interest  of  the  user,  the  moment 

he/she is choosing an answer, at the same time a hidden second 
timer of ten seconds with a countdown is "triggered". With this 
timer we created a method on the total user points. We have set 
the maximum number of points at one hundred. The time of ten 
seconds  starts  counting  the  moment  that  all  the  answers  are 
displayed. This means that the faster the user answers the more 
points he/she gets. 

V.

 

C

REATING NETWORKING PART

 

In  our  interconnected  world,  it  is  very  important  for  an 

application  to  exploit  the  communication  abilities  of  modern 
mobile  phones,  such  as  Wi-Fi,  Bluetooth  or  near  field 
communication  (nfc).  Each  of  these  technologies  has  its 
advantages  and  disadvantages.  For  example  if  you  create  an 
RSS  Feeder  you  have  to  use  Wi-Fi.  In  that  case  neither 
Bluetooth  nor NFC are functional.  Depending on the category 
your  application  belongs,  it  is  recommended  to  use  the  most 
suitable networking technologies. 

 In  our  application,  we  selected  Wi-Fi  and  Bluetooth 

because  of  their  diversity.  In  the  first  case,  Wi-Fi  technology 
gives  us  the  ability  to  connect  with  other  users  in  a  local 
network, but  also  with  the  tethering  technology,  which  allows 
the use of a mobile phone as an intermediate (access point) so 
that an internet access is provided to another connected device, 
either  via  cable  or  wirelessly.  Bluetooth  on  the  other  hand,  is 
ideal  for  use  when  the  users  are  less  than  ten  meters  far  from 
each other and on places where Wi-Fi is not available. 

A.

 

Networking architecture 

For  creating  online-network  games,  developers  require  to 

know  that  they  actually  have  a  choice  between  two 
architectures, which are: client - server and peer users

 

(peer-to-

peer) [3]. For the implementation of the game, the architecture 

peer-to-peer  was  chosen.  The  user  who  hosts  the  game  is  the 
server, while all the other players are the customers. 

In  the  client-server  model,  the  server  is  responsible  for 

everything and determines what the “truth” is. The clients send 
update  messages  to  the  server  all  the  time  and  the  server 
informs all the clients respectively. The clients do not have the 
capability to communicate with each other. 

In  the  peer-to-peer  model,  all  participants  are  equal  and 

they  all  do  the  same  job,  but  we  must  ensure  that  each 
participant  sees  the  same  things  as  the  rest,  since  there  is  no 
central administrator. 

B.

 

Client-server state machines 

When developing networking applications, it is handy for a 

developer to create state machines. State machines give us the 
opportunity to understand the logic of our application. Bellow 
we present a sample of our quiz application state machines. 

Starting  from  the  client,  it  is  good  to  create  a  diagram 

which  describes  the  possible  states  of  the  objects  in  the  class. 
This makes the usage of the objects simpler. 

Overall, we create four states. If the client chooses to join a 

game he enters the state "Idle", in which he remains idle. Then, 
he  moves  to  the  "Searching  for  Servers"  state.  When  the  user 
decides  to  connect  to  a  specific  server,  the  client  goes  into 
"Connecting  to  Server"  state,  where  he  tries  to  connect  to  the 
server  and  finally  moves  to  state  "Connected"  once  the 
connection is successfully established. If at any time during the 
last two states the server drops the connection, the client moves 
back to “Idle” state. 

The state machine of the server in relation to the client has 

only three situations.  By choosing  to become a server, a  user 
gets  into  the  state  "Idle"  in  which  he  waits  without  doing 
anything.  Then,  he  automatically  moves  to  state  "Accepting 
connections". When the user presses the "Start" button to start 
the game between users, he is transferred to the "Ignoring new 
connections" state. This means that no new clients are allowed 
to connect. 

C.

 

Identifying error and disconnection reasons 

In networking applications, the connection between devices 

is  often  sensible.  It  is  suggested  that  the  developer  identifies 
networking errors and disconnections and demonstrate them to 
the  users  of  his  application.  Ιn  our  application  in  specific,  we 
produced an alert message that warns users about the following 
errors: 

a)

 

Quit reason: No network. 

b)

 

 Quit reason: Conection dropped. 

c)

 

Quit reason: User quit

d)

 

Quit reason: Server Quit. 

 

D.

 

Packet structure 

For  all  messages  the  developer  has  to  follow  a  specific 

format. Each package must be at least ten bytes. Different types