Android Card Game

ACKNOWLEDGEMENT
The project has been benefited from the joint efforts of many individuals. It has been
a pleasure for us to acknowledge the assistance and contributions that were very
important and supportive throughout the project. We would like to extend our sincere
thanks to all of them.

We owe special thanks to a number of people who has devoted much of their time and
expertise without which it would have been very difficult for us to complete our
project entitled “Android Card Game”.

We would like to provide our special thanks to Dr. Roshan Chitrakar, for providing
technical support with enormous suggestions which helped us to coordinate our
project.. We would also like to thank Er. Birendra Bista, Head of Department of
Software Engineering for his valuable guidance throughout the project development
period. A special thanks goes to Nipesh Shrestha for helping in the making of App
Logo and Er. Rabindra Acharya for giving valuable suggestions for our project.

Furthermore, we wish to express our heartfelt gratitude to our teachers, classmates,

and families who have always served as the strongest source of inspiration and have
been knowingly or unknowingly the part of this project and lent support and views
during the entire development time.

Sanjay Adhikari

Ruman Dangol

Nepal College of Information Technology

Balkumari, Lalitpur, Nepal

I
Android Card Game

ABSTRACT
In the fast growing field of software engineering and development and even more
rapidly growing sector of game development the future is hard to predict. We are
working with this game as our college project which is a 1 credit course and as part of
our degree we choose this type of work for doing better with development cycle,
development period, graphics, scripting, adopting new technology, animation.

In general software project is a project focusing on the creation of software.

Consequently, Success can be measured by taking a look at the resulting software.

In a game project, the product is a game. But and here comes the point: A game is
much more than just its software. It has to provide content to become enjoyable. Just
like a web server: without content the server is useless, and the quality cannot be
measured. This has an important effect on the game project as a whole. The software
part of the project is not the only one, and it must be considered in connection to all
other parts: The environment of the game, the story, characters, game plays, the
artwork, and so on.

Teen Patti [Show Flush] is a card game based on Android Platform which is specially
designed for the people who can utilize few minutes of their leisure time In this
project, we have used different tools like Android Studio, By this project, we will be
helping people to spend some time in game. This project will help to connect with
other people through entertainment. It can help people to play TeenPatti without
having to buy deck of cards. Furthermore, it can be played without having real
friends. It serves 4 players [android itself].

Keywords: Teen Patti, Show Flush, Card Game,Gam.

II
Android Card Game

LIST OF ABBREVIATIONS
API Application Program Interface

CD R/W Compact Disc Rewritable

CUI Command-line User Interface

ER Entity Relationship

Fig Figure

FP Function Point

GUI Graphical User Interface

JRE Java Runtime Environment

LOC Lines of Code

PM Person per Month

RDBMS Relational Database Management System

SQL Structured Query Language

SRS System Requirement Specification

XML Extended Markup Language

SDK Software Development Kit

AVD Android Virtual Device

III
Android Card Game

Table of Contents
1 INTRODUCTION ................................................................. - 1 -
1.1 Problem Statement ..................................................................................... - 1 -

1.2 Project Overview ........................................................................................ - 1 -

1.3 Project Objectives ...................................................................................... - 2 -

1.4 Project Scope and Limitation ..................................................................... - 2 -

1.5 Significance of the Study ........................................................................... - 3 -

2 METHODOLOGY................................................................ - 4 -
2.1 Software Development Life Cycle: ............................................................ - 4 -

2.1.1 Analysis Phase .................................................................................... - 4 -

2.1.2 Design Phase ....................................................................................... - 5 -

2.1.3 Coding Phase ...................................................................................... - 5 -

2.1.4 Testing Phase ...................................................................................... - 5 -

2.2 Technologies Used ..................................................................................... - 5 -

2.2.1 Reasons for Choosing SQLite as Backend Database .......................... - 5 -

2.2.2 Reasons for Choosing XML as Layout Design .................................. - 6 -

2.3 Required Tools ........................................................................................... - 6 -

2.4 Approach used ............................................................................................ - 7 -

3 LITERATURE REVIEW .................................................... - 8 -

3.1 Review........................................................................................................ - 8 -

3.2 Android Studio ........................................................................................... - 8 -

3.3 Comparison with Existing Systems............................................................ - 9 -

4 PROPOSED RESULT ........................................................ - 10 -

5 TEAM MEMBERS AND DIVIDED ROLES .................. - 11 -

6 REQUIREMENT ................................................................ - 12 -
IV
Android Card Game

6.1 Requirement Analysis .............................................................................. - 12 -

6.2 System Requirement Specifications ......................................................... - 12 -

6.2.1 Functional Requirement .................................................................... - 12 -

6.2.2 Output Requirements ........................................................................ - 14 -

6.2.3 Security Requirements ...................................................................... - 14 -

6.2.4 Hardware Specifications ................................................................... - 14 -

6.2.5 Software Specification ...................................................................... - 15 -

6.2.6 Permission Required ......................................................................... - 15 -

7 System Design ...................................................................... - 16 -

7.1 Data Structure Design .............................................................................. - 16 -

7.2 Block Diagram ......................................................................................... - 17 -

7.3 Use Case Diagram .................................................................................... - 18 -

7.4 System Sequence Diagram (SSD) ............................................................ - 28 -

7.5 Sequence Diagram.................................................................................... - 32 -

7.6 Design Class Diagram(DCD) ................................................................... - 36 -

8 Testing .................................................................................. - 37 -
8.1 Testing Methods Used .............................................................................. - 37 -

8.1.1 Static vs. dynamic testing ................................................................. - 37 -

8.1.2 Testing Levels ................................................................................... - 37 -

8.1.3 Unit Testing ...................................................................................... - 38 -

8.1.4 Integration testing ............................................................................. - 38 -

8.1.5 Component interface testing ............................................................. - 38 -

8.1.6 System testing ................................................................................... - 39 -

9 Project Task and Time Schedule ....................................... - 40 -

9.1 Project Scheduling.................................................................................... - 40 -

V
Android Card Game

9.2 Gantt chart ................................................................................................ - 41 -

10 Conclusion ............................................................................ - 42 -

11 Further Extension ............................................................... - 43 -

12 Bibliography ........................................................................ - 44 -

APPENDIX................................................................................. - 45 -

APPENDIX B ............................................................................. - 48 -

VI
Android Card Game

List of Figure
Figure 1: Incremental Model .................................................................................... - 4 -

Figure 2: Block Diagram ........................................................................................ - 17 -

Figure 3 Use cases Diagrarm .................................................................................. - 18 -

Figure 4: System sequence diagram for play game ................................................ - 28 -

Figure 5: SSD for View Leader Board ................................................................... - 29 -

Figure 6: SSD for Change Setting .......................................................................... - 29 -

Figure 7: SSD for change Name ............................................................................. - 30 -

Figure 8: SSD for change Avatar ............................................................................ - 30 -

Figure9: SSD for capture Screen ............................................................................ - 31 -

Figure 10: SSD for exit ........................................................................................... - 31 -

Figure 11: Sequence Diagram for Play Game ....................................................... - 32 -

Figure 12: Sequence diagram for view Leader Board ............................................ - 33 -

Figure 13: Sequence Diagram for Change Setting ................................................. - 33 -

Figure 14: Sequence Diagram for Change Name ................................................... - 34 -

Figure 15: Sequence Diagram for Change Avatar .................................................. - 34 -

Figure 16: Sequence Diagram for Capture Image .................................................. - 35 -

Figure 17: Sequence Diagram for exit app ............................................................. - 35 -

Figure 18: Design Class Diagram for Teen Patti .................................................... - 36 -

Figure 19: Main Screen of Game ............................................................................ - 45 -

Figure 20: Game Panel............................................................................................ - 45 -

Figure 21: LeaderBoard of Game ........................................................................... - 46 -

Figure 22 Setting Activity ....................................................................................... - 46 -

Figure 23: Set up Boot Amount Fragment .............................................................. - 47 -

Figure 24: Update Profile Fragment ....................................................................... - 47 -

VII
Android Card Game

List of Tables
Table 1: Required tools ............................................................................................. - 6 -

Table 2: Comparison Table ....................................................................................... - 9 -

Table 3: Team Members and Divided Roles .......................................................... - 11 -

Table 4: Data Structure Table ................................................................................. - 16 -

Table 5: Test cases .................................................................................................. - 39 -

Table 6: Project scheduling ..................................................................................... - 40 -

Table 7: Gantt Chart................................................................................................ - 41 -

VIII
Android Card Game

1 INTRODUCTION
Teen Patti[1] (तीन पत्ती), meaning 'three cards' in English) (also known as flash or
flush) is a gambling card game that originated in the Indian sub continent The game,
which is actually a simplified version of poker is popular throughout south Asia.
Boats out of India call it "flush" to escape any legal negativity surrounding the game
where it is played legally.

1.1 Problem Statement

People in order to play Teen Patti use traditional style by buying the cards and
finding the players. This type of traditional system is burdensome and takes more time
and cost. So there must be a easier system which must help us to play. So we figured
out a way to eliminate the traditional system with digital, portable, easier and simple
way to play teen Patti, our Android application called Android Card Game
(TeenPatti).

There are many android based Teen Patti games available in android play store. The
android based application lacks features regarding betting and user interaction with
the important yet unavailable to play offline.

1.2 Project Overview

Android game is now very popular. Many users are using android devices. Games are
played for entertainment and time management. The android game helps the user to
get fun. The users want android game to be simple but very entertaining.

In order to meet customer requirement, the android game should be able to support in
low space memory. And also, the interface between user and the game should be
comfortable. Android is widely used because of open source. The users can change
the system as their wish. So, game should also not be restricted.

Our project, Android Card Game (Teen Patti) is a android-based game which main
motive is to provide the entertainment and fun which allows user to spend times. This
game also provides facts about cards including tricks and history. This documentation
provides the scope and context of the project to be undertaken. It also provides a

-1-
Android Card Game

schedule for the completion of this project, including a list of all the deliverables and
presentations required.

1.3 Project Objectives

The aim and objective of the project is to provide the good interface to play card game
as we are playing in real world. The Main goal of this project is to provide fun. After
the investigation of the data collection about the Teen Patti game, the core objective
of this projects are:

 Introduction of Teen Patti game for all users.

 Develop an application with user friendly
interface.
 Save the record of the previous games.

1.4 Project Scope and Limitation

This Report describes all the requirements for the project. The purpose of this
research is to provide a virtual image for the combination of both structured and
unstructured information of our project “TeenPatti”. TeenPatti is a single-player
strategy game on the Android platform. The player will progress through levels which
require precise manipulation of the environment.

Mainly the scopes of project are listed below:

 Learn how to play Teen Patti.

 Play some time for fun
 Check their luck
 Enable user to update their profile
Even though the proposed system provides a lot of features there are some limitations.
They are:

 The system doesn’t have multiplayer mode to play

 Lack of side show features

-2-
Android Card Game

1.5 Significance of the Study

The study investigates the need of a system ie. Android based Teen Patti which offers
facilities to play game similar as real world. We have tried to design the project in
such a way that user may not have any difficulty in using this application (game)
without much effort. This game can be really used by end users who have android
running devices with minimum SDK version 15. That language we use to develop this
game is mainly Java, XML for designed and SQLite for database.

-3-
Android Card Game

2 METHODOLOGY
We have planned to work following these methodologies for the application of
knowledge, skills, tools and techniques to a broad range of activities in order to meet
the requirements of our project, Android Card Game “Teen Patti”.

2.1 Software Development Life Cycle:

The framework we will be using for developing this project is Incremental model.
This model combines linear sequential model with the iterative prototype model. New
functionalities will be added as each increment is developed. The phases of the linear
sequential model are: Analysis, Design, Coding and Testing. The software repeatedly
passes through these phase in iteration and an increment is delivered with progressive
changes

Figure 1: Incremental Model

2.1.1 Analysis Phase

In this phase, analysis will be performed in order to find out the requirements of the
system. The outcome of this phase would be a SRS which is an acronym for “System
Requirement Specifications”.

-4-
Android Card Game

2.1.2 Design Phase

In this phase the SRS would be translated into the system’s design. Context Diagram,
DFD, ER – Diagram, Use Case Diagram and Class Diagram will be developed.

2.1.3 Coding Phase

In this phase, coding will be done according to the design and a working system will
be developed by the end of this process. Implementation of project is done.

2.1.4 Testing Phase

In this phase, the system will be tested. With each testing a list of changes to the
system developed, is suggested and the changes will be applied to the software and
the software would be delivered as a successive increment until a satisfying system is
achieved.

2.2 Technologies Used

 SQLite, for database for storing all the application data

 XML to develop interactive user interfaces
 Shared Preferences to store the data which is frequently changed and accessed
from all classes throughout the activity

2.2.1 Reasons for Choosing SQLite as Backend Database

 Scalability and flexibility

 High Performance
 High Availability
 Storing data Protection
 Comprehensive Application Development
 Management Ease
 Lowest total cost of ownership
 Support all android devices
 android built in features

-5-
Android Card Game

2.2.2 Reasons for Choosing XML as Layout Design

 fast and reliable

 platform independent
 High Availability
 free
 Built-in supports
 Device independent due to DP and SP

2.3 Required Tools

During the development of the system, we required various tools essential for the
project. Our projected could not have been completed without these tools. Here are
some list of tools used in the project.

Tools Purpose

Notepad++ Basic Text Editing

Android Studio Game Development

Inkscape To Generate Icons

Adobe Fireworks pads To Generate Assets

Ms-Word Preparing Reports

Rational Rose To Draw UML diagrams

Ms-Excel Gantt chart

Emulator Testing the application

Table 1: Required tools

-6-
Android Card Game

2.4 Approach used

In a game project, the product is a game. But and here comes the point: A game is
much more than just its software. It has to provide content to become enjoyable.

In the world driven by technology, Having a deck cards is not always available. Even
more, we cannot play Teen Patti alone in real life. So considering this we built a
android game to provide a infinite fun and entertainment with ease UI.

-7-
Android Card Game

3 LITERATURE REVIEW
This section consist the literature study on the Android Card game. Our project is
looking forward to entertain the user so that they can spend their time for their own.
We found various similar products that have already been developed in the Play Store.
Unlike those entire products, Our TeenPatti app provides many unique features like
taking screen shot, reading the facts about card and teenpatti itself. This app provides
the way to play game.

3.1 Review

With the improving devices and technology, Android has become very useful day by
day which is obviously going to add more expectations to the services provided by
them in the future. Even though some services might seem overwhelming and some
might seem insufficient, there will always be some areas for improvement. Hence our
project is looking forward to define all the possible services so that the user can have
good experience.

3.2 Android Studio

[2]
Android Studio is the official integrated development environment (IDE) for
Android platform development. It was announced on May 16, 2013 at the Google I/O
conference. Android Studio is freely available under the Apache License 2.0.

Android Studio was in early access preview stage starting from version 0.1 in May
2013, then entered beta stage starting from version 0.8 which was released in June
2014.The first stable build was released in December 2014, starting from version 1.0.

Based on Jet Brains IntelliJ IDEA software, Android Studio is designed specifically
for Android development. It is available for download on Windows, Mac OS X and
Linux and replaced Eclipse Android Development Tools (ADT) as Google's primary
IDE for native Android application development.

-8-
Android Card Game

3.3 Comparison with Existing Systems

On comparing our project with other similar games, we came to conclude with the
flowing features:

Apps Teen Patti Indian Ultimate TeenPatti by

TeenPatti
Features Poker by Artoon Ultimate-Games

Ease of use Medium Low High

Offline Mode Yes No Yes

Screen Shoot No No Yes

Facebook Connect Yes No No

Multiplayer Yes Yes No

Guide to play No No Yes

Facts about cards No No Yes

Choose own Profile Yes No Yes

Frequently asked No No Yes

question

Decision Making No N Yes

Notification Yes No No

Level Yes No Yes

Table 2: Comparison Table

-9-
Android Card Game

4 PROPOSED RESULT
Android Card Game “Teen Patti” will be able to provide users with the services to
play games in their own mobile. The end product will have the following end results:

 Users will get to change their details.

 They will also have the power to promote the flow of information.
 Users will able to play or stop the background music.
 Users will able to change their profile (name and Icon).
 Users will able to view their total bid
 The product will be able to give users with a proper UI/UX so that they can
enjoy the game.
 The product will able to provide the real world environment to play game
 The product will able to declare the winner in the toast

- 10 -
Android Card Game
5 TEAM MEMBERS AND DIVIDED ROLES
We have divided our projects work based on team members.
Name Roles
 Project Manager
Sanjay Adhikari
 System Developer
 System/UI Designer
 Database Expert
 Security Expert
 End user Documentation
 System/UI Designer
Ruman Dangol
 Department Process
Expert s
 End user Documentation
Table 3: Team Members and Divided Roles
- 11 -
Responsibilities
 Review and approve all
project deliverables
 Day to Day responsibility to
keep project on track for
successful delivery of
Android Card Game “Teen
Patti”
 Define and execute
development requirement
 Develop User-friendly
Interface
 Test System interfaces
 Define Database Scheme
and security issues
 Develop Documentation
 Define and execute
development requirement
 Participate in analysis ,
requirement, gathering and
preparation of specifications
 Identify improvement
opportunities
 Develop Documentation
Android Card Game

6 REQUIREMENT

6.1 Requirement Analysis

Requirement analysis, in software engineering encompasses those tasks that go into
determining the need and conditions to meet for a new or altered product, taking
account of possibly conflicting requirements of the various stakeholders, such as
beneficiaries and users. It is the early stage activity of requirement engineering which
encompasses all activities concerned with eliciting, analyzing, documenting,
validating and managing system requirements.

6.2 System Requirement Specifications

6.2.1 Functional Requirement

 Provides user to play Teen Patti game with real world environment.
 Provides user to share their best hands[cards they got] with their friends.
 Provides user to view and set their own profile.
 Guides user with frequently asked questions to play and learn games.

 Data Entry Model

The following inputs formats were applied:
 Automatic input:
Profile name of Bot [android player] is automatically generated
The total bid of all players [user and android player] are generated
during new table creation
 Direct Entry using keyboard
Change name, Boundary setup for Pot
 Backup facility
User details and records related to user for declaring winner. This is kept in
the database
Game settings i.e. background music, user progress, user level are stored in
Shared Preference.

- 12 -
Android Card Game

 Output to user
 Soft Output Requirements
a. Winner Declaration
b. Screen shot
 Interface required
Users are provided with a android interface which includes all the navigation
of the game on the main page. They can choose to play the new game and get
a real world environment like other players with certain bid amount and deck
of cards on the table and on assistant to keep their records. They can choose
either to continue play [in game it is called Chaal] or fold the cards However
User first need to provide their profile name so that it is easier to call player
with his/her name.
The user would be working with the following windows, Their functions are
also listed below:
o Game Panel
This is the main page of Game which provides the real world
environment. This layout presents the poker table and poker table
includes :
a. Assistant
b. Names of each players
c. Total pot they can used at most
d. Avatar of each players
e. 3 set of Cards for each player
f. special image to represent blind players
g. Option to fold
h. Option to choose single Chaal
i. Option to take screen shot
j. Option to show own cards

o User Profile Window

It is used to display the profile of the user containing only the
information which user has shared with the system. It will be showing
the bid which user earns it on the game. Moreover, It will also be

- 13 -
Android Card Game

showing the avatar [user profile image] of user along with the level and
percentage of progress to reach next level.

o About us window
It contains all the information regarding the developers and designers
of the website and is beneficial for business deals or short overview of
the creators.

6.2.2 Output Requirements

The user requires following output from the system:

1. Game panel to play the game

2. Computer bots and Well shuffled set of cards
3. Acknowledgement of game through the guide, facts and frequently asked
questions.

6.2.3 Security Requirements

User or players are first forced to provide their valid name so that it is easier to call
them. At first, players are provided 5000 bid and regularly added 50 bid per hour The
system ensure that no bid loss when playing game. Therefore each player have been
given their account with their name and avatar. Name and Bid are saved in databases
and Level and Progress are stored as cache in Shared Preferences. This will kept the
information safe from intruders as well as those who are authorized to manage
database only.

6.2.4 Hardware Specifications

Well This project is android based games so that the first hardware requirement is the
user must have an android device. This is low space game so higher specification of
hardware is not a compulsory/

a. Processing Speed:
b. Memory:–MB or Higher and 10 MB free Space
c. input: Virtual Keyboard and touch panel or stylus
d. Output: Android device itself
e. Display: 256 SVGA display with some basic animation

- 14 -
Android Card Game

6.2.5 Software Specification

a. Operating system: android OS

b. Minimum Android version: Ice Cream Sandwich
c. Minimum SDK: 15
d. Target SDK: 23
e. Program: No special program Required

6.2.6 Permission Required

a. Read and Write External Storage

b. Prevent phone from sleeping
c. Run at startup

These are the minimum requirements for running the game in one’s personal android
device.

- 15 -
Android Card Game

7 System Design
Upon using the application user are provided with mainly three options namely – New
Game, Leader Board and Exit. Other than this, Use can navigate to different activity
namely: Setting, Guide, Facts, FAQ and About app. The user provide their name and
one avatar to represent the profile image. These data would be saved onto database
and game setting stored into Shared Preferences.

The saved data can later be altered if the users want to do so. Altering here means
changing names. or avatar and changing setting ie music and sound. Other than this,
The saved data like user level, user progress would not be altered by the users. They
are updated through system itself.

Designing according to the requirement specification, we have made an attempt to

make sure that the system design actually confirms the user requirements of the
system. In order to do so, we frequently looked into the following matters:

 Verification of input and output formats.

 To make sure that design of layouts are accepted by the user.
 To make sure that security specification are met.

7.1 Data Structure Design

The descriptions of the data type that will be used in the new system are as below.
The data types are identified as following:

Data Types Size

Character varying (n), Varchar (n) Variable length and limit

Integer 4 bytes

Long Standard

Double Standard

String Standard

Table 4: Data Structure Table

- 16 -
 Android Card Game

7.2 Block Diagram

When any user first launches the app. S/he should have to register their profile, in
order to store these data, we have used SQLite data which is available on the android
phone, it doesnot need any external libraries.

Change Profle

SQLite SQLite
User
(Device) (Device)

Update Bid

SetUp Profile SetUp Profile

Figure 2: Block Diagram

- 17 -
Android Card Game

7.3 Use Case Diagram

Use case is a list of steps, typically defining interactions between a role and a system,
to achieve a goal. The following figure shows the interactions between the roles
involved and the TeenPatti

Figure 3 Use cases Diagrarm

- 18 -
Android Card Game

Use Case UC1: Play Game

Scope: TeenPatti or Kitty Card Game

Level: user goal

Primary Actor: User

Supporting Actor: Android Bot[system]

Stakeholders:

-User: wants to play Teen Patti game

-Bot:: participate in game

Preconditions: profile must be saved

Post conditions: Winner must be declared fairly.

Main Success Scenario:

1. User set the maximum pot that he can use.

2. User selects appropriate option to continue the game

3. User can play the blind.

Alternate Flow

*a At any time System fails: (User restarts the game and send crash report)

1a. User does not have sufficient bid to bet

1. display the toast message that s/he cannot play game

2. Wait for an hour to get bid.

2a User selects Fold option

1. stop the game

2. User looses the game whatever the results

3a: User sees the cards

1. User no longer being blind

2. cannot power to show unless all player are seen player

- 19 -
Android Card Game

Use Case UC1: View Leader Board

Scope: TeenPatti or Kitty Card Game

Level: user goal

Primary Actor: User

Stakeholders:

-User: wants to see user total bids, avatar, level, progress to reach next level

Preconditions:

Post conditions: User name must be saved

Main Success Scenario:

1. User sees the data

Alternate Flow

*a At any time System fails: (User restarts the game and send crash report)

1a. Database generate errors

1. Notify User

Frequency of occurrence: normal

- 20 -
Android Card Game

Use Case UC1: Change setting

Scope: TeenPatti or Kitty Card Game

Level: user goal

Primary Actor: User

Stakeholders:

-User: wants to see change setting preferences like Sound Music

Preconditions:

Post conditions: App should run smoothly

Main Success Scenario:

1. User Navigate to setting fragment

2. User change any one setting

Alternate Flow

*a At any time System fails: (User restarts the game and send crash report)

2a. Shared Preferences Unavailable

1. Notify User

Frequency of occurrence: normal

- 21 -
Android Card Game

Use Case UC1: Change Name

Scope: TeenPatti or Kitty Card Game

Level: user goal

Primary Actor: User

Stakeholders:

-User: wants to change the profile name

Preconditions:

Post conditions: User must have bid more that 250 bid

Main Success Scenario:

1. user choose for changing name

2. user proceed
3. user inputs new name
4. setting changed

Alternate Flow

*a At any time System fails: (User restarts the game and send crash report)

2a. User does not have sufficient bid

1. Notify User
2. close the dialog box

3a Format of name is wrong

1. set the error

2. Notify the user
3. wait for correct input

4a. Shared preferences cleared

1. Notify the user

Frequency of occurrence: normal

- 22 -
Android Card Game

Use Case UC1: Change Avatar

Scope: TeenPatti or Kitty Card Game

Level: user goal

Primary Actor: User

Stakeholders:

-User: wants to change the profile Image

Preconditions:

Post conditions: Avatar should be displayed to the user

Main Success Scenario:

1. Navigate to the Setting fragment

2. choose the avatar you like

Alternate Flow

*a At any time System fails: (User restarts the game and send crash report)

3a. Avatar does not load correctly

3. Notify User
4. close the app

Frequency of occurrence: normal

- 23 -
Android Card Game

Use Case UC1: Capture Screen

Scope: TeenPatti or Kitty Card Game

Level: user goal

Primary Actor: User

Stakeholders:

-User: wants to Screen shoot of the current table

Preconditions: Game should being played

Main Success Scenario:

1. user choose for Screen Soot

2. User view the captured Image
3. user can share with their friends
4. Image saved to particular directory

Alternate Flow

*a At any time System fails: (User restarts the game and send crash report)

4a. The directory not found

1. create the new Directory

Frequency of occurrence: rare

- 24 -
Android Card Game

Use Case UC1: Exit System

Scope: TeenPatti or Kitty Card Game

Level: user goal

Primary Actor: User

Stakeholders:

-User: wants to close the game

Preconditions: app should be in ideal state

Main Success Scenario:

1. user navigate to main screen

2. User view exit the system

Alternate Flow

*a At any time System fails: (User restarts the game and send crash report)

Frequency of occurrence: one time

- 25 -
Android Card Game

Use Case UC1: Update Bid

Scope: TeenPatti or Kitty Card Game

Level: Back end

Primary Actor: System

Supporting Actor: Services

Stakeholders:

-System: System wants update bid

-Services: Reminds the system in every hour

Preconditions: Device should be powered on

Main Success Scenario:

1. Services got notified in every hour

2. services call the system to update bid
3. System update bid

Alternate Flow

*a At any time System fails: (User restarts the game and send crash report)

1a. Device is powered off

2. Wait for the device powered on

Frequency of occurrence: every hour

- 26 -
Android Card Game

Use Case UC1: Manage Level

Scope: TeenPatti or Kitty Card Game

Level: Back End

Primary Actor: System

Stakeholders:

-System wants to keep track of user level and update it as rule of game

Preconditions: Game should being played

Main Success Scenario:

1. System gets the current performance

2. System synchronizes the user performance in each winner declaration.
3. System compares and increment the level by 1

Alternate Flow

*a. At any time System fails: (User restarts the game and send crash report)

2a. System fails to retrieve performance

1. notify the user

3. close the application

Frequency of occurrence: no of game played

- 27 -
Android Card Game

7.4 System Sequence Diagram (SSD)

A system sequence diagram (SSD) is a fast and easily created artifact that illustrates
input and output events related to the systems under discussion. An SSD shows the
particular course of events within a use case, the external actor that interact with the
system, the system acts as a black box and the system events that the actor generates.

Play game

Figure 4: System sequence diagram for play game

- 28 -
Android Card Game

View Leader Board/

Figure 5: SSD for View Leader Board

Change Setting

Figure 6: SSD for Change Setting

- 29 -
Android Card Game

Change Name

Figure 7: SSD for change Name

Change Avatar

Figure 8: SSD for change Avatar

- 30 -
Android Card Game

Capture Screen

Figure9: SSD for capture Screen

Exit Application

Figure 10: SSD for exit

- 31 -
Android Card Game

7.5 Sequence Diagram

A Sequence diagram is an interaction diagram that shows how processes operate with
one another and in what order. A sequence diagram shows object interactions
arranged in time sequence. Sequence diagrams are typically associated with use case
realizations in the Logical View of the system under development. A sequence
diagram shows, as parallel vertical lines (lifelines), different processes or objects that
live simultaneously, and, as horizontal arrows, the messages exchanged between
them, in the order in which they occur.

Figure 11: Sequence Diagram for Play Game

- 32 -
Android Card Game

Figure 12: Sequence diagram for view Leader Board

Figure 13: Sequence Diagram for Change Setting

- 33 -
Android Card Game

Figure 14: Sequence Diagram for Change Name

Figure 15: Sequence Diagram for Change Avatar

- 34 -
Android Card Game

Figure 16: Sequence Diagram for Capture Image

Figure 17: Sequence Diagram for exit app

- 35 -
Android Card Game

7.6 Design Class Diagram(DCD)

Figure 18: Design Class Diagram for Teen Patti

- 36 -
Android Card Game

8 Testing
We wanted to make sure that all the elements of the developed worked functioned
properly. For this, we created a test plan for our work, in which elements such as
validation, reliability and user acceptance will be tested. The system will be tested for
normal condition, primarily.

8.1 Testing Methods Used

The different testing methods used in our project development are:

8.1.1 Static vs. dynamic testing

The reviews, walkthroughs, or inspections are referred to as static testing, whereas

actually executing programmed code with a given set of test cases is referred to as
dynamic testing. Static testing is often implicit, as proofreading, plus when
programming tools/text editors check source code structure or compilers (pre-
compilers) check syntax and data flow as static program analysis. Dynamic testing
takes place when the program itself is run. Dynamic testing may begin before the
program is 100% complete in order to test particular sections of code and are applied
to discrete functions or modules. Typical techniques for this are either using
stubs/drivers or execution from a debugger environment.

Static testing involves verification, whereas dynamic testing involves validation.

Together they help improve software quality. Among the techniques for static
analysis, mutation testing can be used to ensure the test-cases will detect errors which
are introduced by mutating the source code

8.1.2 Testing Levels

Also the testing was carried out on different levels for a proper integration and better
functionality of the product. The different testing levels used are discussed below

- 37 -
Android Card Game

8.1.3 Unit Testing

Unit testing, also known as component testing refers to tests that verify the
functionality of a specific section of code, usually at the function level. In an object-
oriented environment, this is usually at the class level, and the minimal unit tests
include the constructors and destructors. Developers usually write these types of tests
as they work on code (white-box style), to ensure that the specific function is working
as expected. One function might have multiple tests, to catch corner cases or other
branches in the code. Unit testing alone cannot verify the functionality of a piece of
software, but rather is used to ensure that the building blocks of the software work
independently from each other.

8.1.4 Integration testing

Integration testing is any type of software testing that seeks to verify the interfaces
between components against a software design. Integration testing works to expose
defects in the interfaces and interaction between integrated components (modules).
Progressively larger groups of tested software components corresponding to elements
of the architectural design are integrated and tested until the software works as a
system.

8.1.5 Component interface testing

The practice of component interface testing can be used to check the handling of data
passed between various units, or subsystem components, beyond full integration
testing between those units. The data being passed and the range or data types can be
checked, for data generated from one unit, and tested for validity before being passed
into another unit. One option for interface testing is to keep a separate log file of data
items being passed, often with a timestamp logged to allow analysis of thousands of
cases of data passed between units for days or weeks. Tests can include checking the
handling of some extreme data values while other interface variables are passed as
normal values. Unusual data values in an interface can help explain unexpected
performance in the next unit. Component interface testing is a variation of black-box
testing, with the focus on the data values beyond just the related actions of a
subsystem component.

- 38 -
Android Card Game

8.1.6 System testing

This refers to testing for the better support of the web application to the system
specified and performance on the different systems and hardwares. This helps to get
an insight on the hardware specifications that were specified in the requirement
analysis of the project. The different testing methods and levels assure that the
quality of the product is maintained with a better performance and best level of data
security and integrity.

Table : Testing Table

Test No. For Test Expected Actual Evidence

Method Result Result

1. setUpProfile Null data Valid name null Test 1.1

entry

2. setUpProfile Valid name Profile Profile Test 1.2

format successfully successfully
setup setup

3. stopMusic() Stop Music stops Music plays we heard

background when app even when music even
music closed application after app
closed closed

4. stopMusic Stop Music stops Music stops We did not

background when app when app heard music
music closed closed after exiting

Table 5: Test cases

- 39 -
Android Card Game

9 Project Task and Time Schedule

The project schedule has been designed as per requirements and constraints involved.
This project is scheduled to be completed in about 2 months. Requirement analysis
have been given more emphasis. Research and database management is to be done
first and well documented. Debugging and Testing is to be done prior to the
completion of the project.

9.1 Project Scheduling

We have found the planning of this project here which now leads us to the Analysis
part of the project.

Start Date End Date Project states and Objective

September 2 September 10 Project Proposal, meeting with supervisor about our

idea

September 11 September 29 Planning , thinking about game story , levels and

Learning Technology

September 30 October 10 Construct SRS document, choose tools, and

environment

October 11 November 14 Start designing and implementation

November 15 December 02 Developing, Testing and enhancement running with

writing the report

December 03 January 22 Final revision of the report and testing on the

constructing level/levels.

February 03 Project submission

Table 6: Project scheduling

- 40 -
Android Card Game

9.2 Gantt chart

Table 7: Gantt Chart.

- 41 -
Android Card Game

10 Conclusion
Android Card Game “Teen Patti” is looking forward to entertain the user. Android
Card Game “Teen Patti” has interactive UI/UX. The user can use it smoothly.
Android Card Game “Teen Patti” is game made for fun. It is designed to check the
luck of the user. Android Card Game “Teen Patti” provides user to select avatar
which entertain the user.

- 42 -
Android Card Game

11 Further Extension
With some minor change to be done in the project, it will be completed in one month
with documentation and made available to the users. The future extensions for the
project are:

 More responsive game design

 Users will notified with concurrent notification
 Game can be played by connecting through facebook.
 App can be played with different playing modes like hukam,joker

- 43 -
Android Card Game

12 Bibliography
[1] “Introduction of Teen Patti” [Online]. Available
https://en.wikipedia.org/wiki/Teen_patti [Accessed: 10-Oct -2016]

[2] “Learning Android Studio” [Online] Available :

https://en.wikipedia.org/wiki/Android_Studio [Accessed: 31-Oct-2016]

[3] Larman, C. (2008). Applying UML and Patterns. Pearson Education, Inc.
[Book][Accessed: 1 -Sept-2016]

[4]. UML-Diagram. (2016). UML-Diagram Website: http://www.uml-

diagrams.org/class-diagramsexamples.html [online] [Accessed: 12-Sept-2016]

[5] “Teen patti Rules and strategy to play” [Accessed on 15 Sept 2016]
http://www.octroteenpatti.com/learn-teen-patti/index.html

[6] “Android Animation” [Accessed on 2 January 2016]

https://developer.android.com/training/animation/index.html

[7] How to programmatically take a screenshot in Android?[Accessed on 4 Jan

2016] http://stackoverflow.com/questions/2661536/how-to-programmatically-take-a-
screenshot-in-android

[8] Play background music in all activities of Android app[online] [Accessed on 7

Jan-2016] http://stackoverflow.com/questions/27579765/play-background-music-in-
all-activities-of-android-app

[9] “ Creating a Splash Screen” [Online] Accessed on 27 Nov 2016]

https://developer.xamarin.com/guides/android/user_interface/creating_a_splash_scree
n/

- 44 -
Android Card Game

APPENDIX A
USER INTERFACE

Figure 19: Main Screen of Game

Figure 20: Game Panel

- 45 -
Android Card Game

Figure 21: LeaderBoard of Game

Figure 22 Setting Activity

- 46 -
Android Card Game

Figure 23: Set up Boot Amount Fragment

Figure 24: Update Profile Fragment

- 47 -
Android Card Game

APPENDIX B
Implementation

1. Code to check Teen Patti condition

//checking Pair condtion

public void checkPair() {
boolean userPair = isPlayerPaired(arr1); //A for
user
boolean bot1Pair = isPlayerPaired(arr2); //B for
bot1
boolean bot2Pair = isPlayerPaired(arr3); //C for
bot2
boolean bot3Pair = isPlayerPaired(arr4); //D for
bot3
CurrentGame.setReasonOfWon("Pair");
checkEachCondtion(userPair, bot1Pair, bot2Pair,
bot3Pair);
}

// checking Color condition

private void checkFlush() {
boolean userColor = isPlayerColor(userS); //A
for user
boolean bot1Color = isPlayerColor(botS1); //B
for bot1
boolean bot2Color = isPlayerColor(botS2); //C
for bot2
boolean bot3Color = isPlayerColor(botS3); //D
for bot3
CurrentGame.setReasonOfWon("Color");
checkEachCondtion(userColor, bot1Color,
bot2Color, bot3Color);

// checking the Run condtion

private void checkRun() {
boolean userRun = isPlayerRun(arr1); //A for
user
boolean bot1Run = isPlayerRun(arr2); //B for
bot1
boolean bot2Run = isPlayerRun(arr3); //C for
bot2
boolean bot3Run = isPlayerRun(arr4); //D for
bot3
CurrentGame.setReasonOfWon("Straight Run");
checkEachCondtion(userRun, bot1Run, bot2Run,

- 48 -
Android Card Game

bot3Run);
}

// checking the Double Run condtion

private void checkDoubleRun() {
boolean user1DoubleRun = isPlayerDoubleRun(arr1,
userS); //A for user where arr is value and users is
suit
boolean bot1DoubleRun = isPlayerDoubleRun(arr2,
botS1); //B for bot1
boolean bot2DoubleRun = isPlayerDoubleRun(arr3,
botS2); //C for bot2
boolean bot3DoubleRun = isPlayerDoubleRun(arr4,
botS3); //D for bot3
CurrentGame.setReasonOfWon("Double Run");
checkEachCondtion(user1DoubleRun, bot1DoubleRun,
bot2DoubleRun, bot3DoubleRun);
}

// checking for Trail

private void checkTrail() {
boolean userTrail = isPlayerTrail(arr1); //A for
user
boolean bot1Trail = isPlayerTrail(arr2); //B for
bot1
boolean bot2Trail = isPlayerTrail(arr3); //C for
bot2
boolean bot3Trail = isPlayerTrail(arr4); //D for
bot3
CurrentGame.setReasonOfWon("Trail");
checkEachCondtion(userTrail, bot1Trail,
bot2Trail, bot3Trail);

- 49 -