Spindroid. Development and Marketing of an Android based Fruit Machine. G53IDJ Individual Dissertation Joint Honours ( 20 Credits )

Transcription

1 Spindroid Development and Marketing of an Android based Fruit Machine. G53IDJ Individual Dissertation Joint Honours ( 20 Credits ) Submitted May 2012, in partial fulfilment of the conditions of the award of the degree BSc. (Jt. Hons) Computer Science and Management. By Stephen Anthony Nutbrown (sxn09u) School of Computer Science and Information Technology University of Nottingham I hereby declare that this dissertation is all my own work, except as indicated in the text: Signature: Date:

2

3 ABSTRACT Fruit machines have been popular entertainment systems since first appearing in the 1890s. However, modern day Android apps have yet to capture the wide range of features which have kept these systems entertaining time after time. The Android market has produced huge success stories through the sales of applications distributed by the online store, driven by huge marketing efforts from developers. This project involves the creation of an Android based fruit machine, Spindroid, and research into the best marketing practises to publish the application to the android market. The project aimed to take the application through all stages of development and make use of surrounding literature to find the best marketing approach for the application. Finally this project aimed to discuss and evaluate the marketing and development processes undertaken. The dissertation was successful in producing the Spindroid application and publishing it to the market for beta testing. After comparing marketing approaches used by many top selling applications, the best practise identified is a combination of a free advert supported version and a premium version of the application. Finally, the project evaluates the success of the beta launch; achieving a five star rating from the Android market with over 110 downloads within the first two weeks. i

4 Acknowledgements I am grateful to my supervisor, Dr Colin Higgins, for his continuous support throughout the duration of this project. His helpful insight and availability for meetings, coupled with his quick response to s has been second to none. With many thanks to the University of Nottingham and the staff for the wide range of teaching allowing for this project to come together, and use of their lab environment for development. I would also like to thank the beta testers, of which there are too many to thank by name for their feedback throughout the beta stages of the application development. Finally, many thanks to my love Stacey Greenwood, my family and friends for helping me through the busiest times and putting up with the late nights filled with development time to keep to the deadlines of this project. ii

5 TABLE OF CONTENTS Abstract... i Acknowledgements..... ii Table of Contents... iii 1. Introduction and motivation General Introduction and Problem Description Motivation Aims Current and Existing Systems Initial Survey Literature Review Technical Literature Review Marketing for Android Literature Review Functional Specification + Technologies Topology Technologies required for implementation UML diagram Wireframes and creative files Wireframes Designs Creatives Implementation Website Implementation Android Application Implementation Web Service Implementation Testing Emulator Testing Device Testing Beta Testing Website cross browser tests + validation Summary of results Conclusion Evaluation What went well Challenges faced Future process improvements Future work on Spindroid Appendix References iii

6

7 1. INTRODUCTION AND MOTIVATION This section of the dissertation will give a general introduction and problem description. This section also gives the reader an overview of motivations behind the project and the aims to be accomplished. Finally, current systems and an initial survey are used to understand the climate into which the application will be launched. Moving on from this section is a literature review, which combined with the introduction outlined in the coming chapter gives a foundation on which to base the technical and functional specifications. 1.1 General Introduction and Problem Description Modern day slot machines are seen in many social areas such as pubs, bars, nightclubs and sports centres. They have stood the test of time since the 1890 s when coin operated slot machines first appeared (Fey, 1975). Android is an open source mobile device operating system, and since its release in October 2008, is now seeing over 700,000 devices registered each day. According to co-founder Andy Rubin Android is also boasting over 450,000 available applications with a combined download count of over 10 billion (The Guardian, 2011). The Android market is segmented into categories. As of January 2012 (Android Market, 2012), the cards and casino category hosts numerous apps which attempt to offer a real fruit machine experience for play money. The highest seller currently has over 1 million sales and sells at It has however been noted through the market ratings and comments that the app is missing many features which can be seen on real world fruit machines. Often these machines have feature boards, which after meeting certain conditions the user can move to, giving the option to take further risks in the hope of achieving a higher payout. This feature board can often progress to a further super feature, which varies from machine to machine, ranging from Deal or No Deal games to the classic casino roulette games. These additional features offer something different from repetitively simply spinning the reels and hoping to win. They add an element of excitement to the game and a dimension of choice which allows the user to feel involved, rather than being a game of pure luck. Other features, such as the ability to nudge wheels, or hold them are also missing on the top selling Android based fruit machines, creating a gap in the market which this project aims to fill. Social media links will be used to promote the game and to allow users to compete with other players, along with the inclusion of a leaderboard and website. This project does not aim to reinvent 1

8 the slot machine experience, but to improve it with the inclusion of these extra-added features. As this project aims to build on classic fruit machine, any reader not already familiar with the operation of a modern style fruit machine should refer to the game instructions found in the Appendix, figure 1.1A. 1.2 Motivation The main motivation behind many android apps is to earn money, whilst this is one of the motivations of this project; there are many other primary motivations. At the time of selecting this project, there was a clear gap in the Android market for this type of application. Further to this, smartphones are becoming more popular, with the majority of new phone sales in the UK being based on Android or ios operating systems. With the increasing number of users and app downloads, to be able to design and create applications for these markets would be supplementary to any Computer Science based degree. Finally, the opportunity to work on a system with a wide range of technologies 1.3 Aims The aims and objectives of this project encompass two themes, including the technical side of designing and producing the Android application, and the business side to market it. The primary aim of this dissertation project is to go through the entire process from start to finish, covering the design and development of the Android application. The secondary aim of this project is to research, through the use of surrounding literature, which is the best marketing strategy for Android applications, particularly those of this genre. Furthermore, this project aims to launch the application on the Android market, and to use download figures and market rating to analyse the success of the application. This dissertation aims to analyse the successful and unsuccessful processes which have been adopted during the development of the application. Finally, the project aims to analyse various areas where the project and the underlying process may be improved upon in future are identified within the evaluation of this project. 2

9 1.4 Current and Existing Systems This section will discuss the current and existing top 5 fruit machine applications when searching for slot machine available on the android marketplace. This section will consider the additional features the top 5 utilise, and discuss what this dissertation plans to add to the existing market. The figure below is based on information collected from the Android Market as at February 7th Name Sales Price Social Media Nudges Holds Feature Board Minigame Slot Machine + 100, No No No No Yes Slot Machine Slot Machine Brazilian Beauty Slot Machine Reels O Dublin Slot Machine 50,000-1M -5M 0.63 No No No No No 1, No No No No No 5,000 5, No No No No Yes 10,000 5,000-10, No No No No Yes Fruit machines already on the android market are seeing high numbers of sales, yet are currently lacking on the extra features. The Slot machine + application although having minigames is lacking a featureboard. All of the machines studied are lacking the ability to hold and nudge, which are features that have been used in the real world versions of these machines even before the modern electronic versions (the mechanical one arm versions). The research into the current applications which are available and their features makes it clear that 3

10 features are missing in the current market offering, particularly a feature board. This application plans to add all of the features above into one complete fruit machine experience. 1.5 Initial Survey This initial survey provides an insight into the preferences of the target audience. The target audience include those who meet three criteria: Own an Android device. Have used, or may use their android device for entertainment purposes. Have downloaded an Android application from the Android Market. Those who do not meet the criteria above will not be counted in the decisions made about the design of the application, as they do not fit in with the target audience and likely user base. Acknowledgements to SurveyMonkey.com for allowing the survey to be conducted online free of charge. The survey questions and reasons for each question can be found in the appendix 1.5A The survey was posted online in places likely to be of interest to the target audience such as online forums and also given to other Computer Science students. No personal data was collected that can identify any participant from the results. 129 participants filled out the survey, 76 of which fully met the criteria. 32% (24) of those who met the criteria answered yes to the final question whether they would play a slot machine for entertainment. This is particularly promising; as the Android Market is visited by millions of users for gaming which represents a huge number of potential downloads. Although this number only represents 76 participants and so is of questionable accuracy, it certainly acts as a strong indicator that there is a potential market for an app of this type. The initial survey showed that 90% classified themselves as familiar with slot machines. This result means that users are likely to come to the app already knowing what to expect, already understanding the fundamentals of how the game works. However, it is still important to note however, that 10% of participants are not familiar with the game, and so it is important to place instructions throughout the application to make sure that the game is easy to understand. The game may become extremely frustrating if the users do not understand 4

11 exactly what it is that they are supposed to be doing, particularly in areas of the game which are not as simple as just spinning, for example the feature board, nudges or holds. The survey has further strengthened the motivations of this project and highlighted the potential. 5

12 2. LITERATURE REVIEW The following literature review will concentrate first on the surrounding technical literature in order to understand both the range of design opportunities, and the possible potential pitfalls in developing an Android application. Secondly, this literature review will move to the marketing side of Android applications with the use of examples from both successful and unsuccessful marketing efforts. 2.1 Technical Literature Review This technical literature review will firstly look into the structure of an Android application, through the use of surrounding literature, particularly in comparison to the well-known MVC architecture. Next, screen-sizes and specifically density independent pixels will be discussed, followed by further reading into the efficiency and security of android applications. After concentrating on the Android development reading, this review will then move on to other technologies which are used to support the application, including Facebook SDK and the usage of SQL and PHP to provide the leaderboards. As further supporting technologies such as HTML, CSS and JavaScript which are used for the website and Facebook fan page are not core to the development of the application, these will be only briefly covered within the conclusion of this review Android Architecture Android applications are programmed in Java using the Android SDK, with heavy dependence on existing Android frameworks. Throughout the literature studied, including the Android Developers Guide (Android, 2012), it is suggested that developers with java experience will feel most at home beginning Android application programming. With the growth of Android, many books have been published to help developers learn how to develop for Android. Android Application Development (Rogers, Lombardo, Medneiks and Meike, 2009) is one of those books, which defines its audience as those with experience not only in Java, but also the technologies Android uses such as XML, SQL, GTalk(XMPP), OpenGL-ES and HTTP. It becomes clear when looking into Android development that a grasp of more than just the Java programming language is required to produce a successful Android application. As an introduction to Android, and in order to understand its potential, this technical reading review will now discuss some of the core Android concepts which 6

13 differ from those which are expected by Java programmers, and what they mean for the Spindroid project. Most object orientated programmers will be familiar with the model-view-controller (MVC) architecture pattern which strongly defines associations between the three parts of an application. When considering an Android application, typically one would assume the model to be a group of Java classes which store the required data and state information, the view to be represented by the mobile devices screen, and the controller to receive the input (touch events) and make calls to the model objects. For Android, this architecture is already implemented to an extent, but when compared to the usual MVC structure (Deacon,1995) there are some differences to watch out for as pointed out by Android enthusiasts (Musselwhite, 2011). The view is developed as a set of layout resources (coded in XML), which makes use of build-in classes such as android.view.view.button from the Android SDK. The layout file details similar to how HTML works, the positioning and sizing of the elements the view contains. However, the downfall to this is that XML is static, a view should be dynamic, able to move and change. For the Spindroid project in particular, the reels need to move and the images for buttons will need to change. This is where the android Activity comes in. The term View-Controller has been used a lot suggesting that the Activity should be a class which controls both the view and controller. As Dr Bagley (2012) points out, Most standard apps will probably follow the MCV pattern to some degree; however, as apps diverge from the standard, they will probably break it in some way. An activity in Android contains a UI thread which is responsible for updating the UI, but also holds the responsibility for the controller, as it is where the oncreate(), onpause() and ondestroy() methods are located. It is these methods which are responsible for the starting of the application and for the calls to methods which handle device events. This is where the clarity of the MVC approach becomes blurred. However, a single class which deals with the responsibility of the view and the controller breaks the standard architecture. The model is more straightforward, separated classes may be used for the model, which may also make use of Android s built in SQL Lite database and sharedpreferences in order to store data. Android activities are the core of any android application. Typically, an activity creates a window for a particular UI, and is intended to provide for one thing that the user can do (Android Developer, 2012). An activity has a lifecycle, which is diagrammatically represented below (Rogers, Lombardo, Medneiks and Meike, 2009): 7

14 As per the Android SDK documentation, these activities are placed within a stack, able to start new instances of different activities. For example a standard application showing a menu (Activity A) may start a new activity (Activity B). At this point activity A is placed in the background, and has the onstop() method called. Activity B lives through its lifecycle, and upon completion is removed from the stack. Activity A is then restarted using the onrestart() and onstart() methods. This is the structure that will need to be implemented for the SpinDroid application. It is also important to recognise that during this time garbage collection is automatically run by the Android operating system. Any variables for which a strong reference is held will not be removed, those with a weak reference however will be. As the onstart() method is called again, it is important to make sure that any important variables 8

15 which need to be kept are not reset at this point, but also important to ensure that hard references are held to vital variables in order to avoid possible null pointer exceptions. Having discussed some of the structural differences expected when creating an Android application, this literature review will now turn to the issue of supporting multiple screen sizes and resolutions. Android differs from ios significantly as it has to support a huge range of devices, from tablets to small phones. Furthermore, the impact of this problem is doubled as the majority of Android devices allow the user to turn the phone horizontally to show a landscape view. Whilst this is a helpful user aid, it requires careful consideration when designing android applications, as outlined in the Android developer article Supporting Multiple Screens (Android, 2012). In order to understand the effect this has on the design of Spindroid, some important terms need to be defined. For the remainder of this dissertation, the term Screen size refers to the physical size of the screen. Android categorises these into four general size groups, small, normal, large and extra-large, where extra-large is tablet devices, and large phones being devices such as the HTC One X. Screen density refers to the number of pixels within a given area on the screen, referred to throughout this document as dpi, or dots per inch. Resolution refers to the number of physical pixels on the screen, and density-independent pixels ( dp or dip ) is a pixel unit equivalent to one physical pixel on a 160 dpi screen. For example, if a screen has 320 dots per inch, a measurement of 1dip unit would show as two pixels, making it the same physical size as one pixel on a 160 dots per inch screen. With such variation in resolution, the Android SDK tries to make it easier to develop, by allowing the use of density independent pixels as a measurement for views, which are well illustrated in the diagrams below from the Android Developer Guide (Android, 2012). Figure 1. Example of an application without support for different densities, shown on low, medium and high density screens 9

16 Figure 2. Example of an applications supporting different densities, shown on low, medium and high density screens. Measured using dip Figure 1, as seen above, measures the size of a ButtonView on the screen with the use of pixels, resulting in the physical size of the button changing on screen. In figure 2, the buttons remain nearly the same size regardless of pixel density. It should be noted that although these ButtonViews are now the same size, they do not necessarily take up the same percentage of the height or width of the screen, as some devices may have wider screens, resulting in a larger area of black to the right. This problem is overcome by creating additional layout files, which specify alternate widths and heights measured in dip for larger or smaller phones. What this means in terms of developing Spindroid, is that to support multiple screen densities, it is good practise to provide image resources of different resolutions and will require the development of additional xml layouts. As this has to be done for many activities, it is documented throughout the developers guides and Android documentation and may become extremely time consuming. A possible solution may be, as recommended by the Android Developer guide is to explicitly declare in the manifest file which screen sizes the application supports. Whilst this makes it easier for a developer, it vastly limits the potential audience for an app. Methods concerning the efficiency of an Android application is rarely featured in the reviewed Android development books. The reason for this is that apps are built using Java, and also take advantage of garbage collection. It appears that as long as the developer takes care not to leak activities or include unnecessary processing, efficiency should not be an issue for the Spindroid app. However, this does not mean that it need not be considered during implementation, but that sticking to regular design patterns should be enough to ensure the application is efficient enough to run smoothly and not excessively drain the devices battery. The security of Android applications is mostly provided for by the framework (Manning, 2009). As per the Android SDK documentation, the Android OS isolates data and code 10

17 execution on a per-application basis. This means that one application cannot directly alter or tamper with the memory or tasks of another. After considering surrounding literature, on the Android application side, permissions are going to be key for security. The application, when installed on a user s phone, needs to request certain permissions. These permissions are stored in the manifest xml file, and need to be granted for the application to be installed. Spindroid will need the permission for internet access, but some permissions such as access to the phonebook will not. As explained by Dieter Gollmann (2005), for the database to store data securely it will need to to prevent SQL injection attacks. This requires ensuring to strip any strings which are used to create dynamic SQL queries (such as usernames, passwords or any other data which will be input in any form) of certain characters. Oracle published a useful document (Oracle, 2008) to help with exactly that. Finally, supporting technologies for the application such as HTML, CSS and PHP need little introduction. These technologies are neither new nor the focal point of this dissertation, however the help of W3C validation checks to ensure the cross browser compatibility and accessibility of the browser based content should be acknowledged. JQuery is a popular JavaScript library for some attractive animations which will be considered for the web design. In conclusion, the surrounding literature has brought to attention some important points to consider during the application design, particularly those of structure, multi-device support, security and efficiency. 2.2 Marketing for Android Literature Review This section of the literature review will concentrate on the marketing side of the application. Although there is a wide range of literature on digital marketing, this review will concentrate mainly on a book for the exact purpose of marketing Android applications, the book by Jeffery Hughes (2011) is aptly named Android Apps, secrets to selling your android app: Marketing. This review will also look at additional online materials and real life results from the experience of established Android developers. It is important first recognise the importance of marketing Android apps. There are hundreds of thousands of applications on the Android marketplace, most of which have very few downloads, but some such as Draw something which was recently sold to Zynga for

18 million that seem to grab all the attention. Jeffery Hughes describes the Android market as self-perpetuating, as once an app is recognised and makes it s way to the markets featured list, the list will catapult them into realizing dramatically higher sales. When marketing for Android, the question is about what separates those apps which do extremely well from the other 200+ apps which are delivered to the android market each day. Simply put, the developer needs to build a great Android app and devise a stellar marketing plan to capture the hearts and minds of thousands (Hughes, 2011). Of course in reality, that feat is not quite as simple as it sounds. The literature goes into marketing principles to get applications noticed, including newer tools of marketing such as social social media to get the marketing message in front of a tech-savvy (target) audience. When considering other big hitting apps, it becomes almost instantly apparent that many of the top apps on the market make use of social media for advertising. First this review will consider the top 10 selling apps currently on the Android market, to find just how many of them actually include social media integration, and which ones. Secondly this review will look at monetising the app and the range of choices from ad support to in-game sales, particularly with reference as to how the methods outlined in the surrounding literature can be applied to Spindroid. Appendix figures 2.2A and 2.2B show a snapshot from the android market, showing the top 10 applications (As at April 2012). The sales figures on the Android market are given as large ranges, such as 100, ,000. It is Android s decision not to give out exact market sales numbers to third parties other than ranges for reasons beyond the scope of this dissertation. The ranges however are still useful in determining the top selling apps and their use of social media as a marketing aid. From appendix figure 2.2C, it can be seen that 6 out of 10 of the top Android game apps use at least one of Facebook, Twitter or Google+ to advertise their app through the sharing of high scores and achievements. Openfeint is a similar kind of social network aimed just at mobile device games, which can be built into games to implement a social network allowing users to make friends, send challenges or chat from within the games, as well as advertising other Openfeint enabled games. Hughes points out in his book Some apps, such as games, lend themselves well to the social media approach because the younger age groups tend to play the games and also tend to be consumers of social media advertising and marketing. Facebook as seen both by the results from the current top 10 selling apps and as pointed out in the literature studied is so important it cannot be ignored. With over 400 million users 12

19 Facebook should certainly be targeted for marketing. Marketing on Facebook can come in one of many forms, paid ads, creating a business page (fan page), or through utilising users Facebook wall to post messages that their friends can see. Twitter is often used by professionals to build excitement and post messages to groups of followers, particularly previous to an app launch. Surprisingly, Google+ did not get a mention in the Android marketing, but this reflects also with the results from the top 10 selling aps. From this literature review, it appears that to aid marketing the application it has been suggested by experts in the field and through the research from the Android marketplace that Facebook and twitter are great tools for boosting app sales. Other recommended marketing practises including YouTube videos and partnering with bloggers, which has been suggested by Hughes (2011) are outside of the scope of this project due to time restrictions. This review will now turn to the marketing strategy in terms of pricing and monetizing the application, again with reference to real world examples from the Android market and the use of surrounding literature. Android s official develop site currently has a section on monetizing android applications which unfortunately is incomplete. The section on the Android developer guide currently only includes in-app advertisement, although it does have a detailed guide on implementation of in app ads using Google s Admob service. The strategies to consider which have been used widely by many of the top applications on the market are as follows: Free with ad support. One off app payment In game money (Purchase additional in game items or features) Purchase of game-time. (Monthly Subscription) Hughes (2011) claims that offering a free app helps your customers gain confidence in your product and allows them to use it without risk. Various studies from analytics companies such as Flurry.com indicate that a free app strategy is a must going forward. This strategy is a combination of a free app which using adverts to gain revenue provided by Admob, and using a full version which can be installed upon receipt of a one off payment. This is no doubt the most popular strategy on the Android market as seen from the research above with 6 out of the 10 top apps having a free version available for download. In game money has been utilised in some of the top apps but is a rather less popular approach. For example the 13

20 application Death Rally on the Android market is free but allows users to purchase better cars for the game with real money. An issue with this approach is that it requires setting up an alternate payment method outside of the Android market and as per the reviews of this application can often by the cause of frustration if users uninstall the app, losing their purchased items. With consideration of applying this to Spindroid, making the coins have a monetary value, which once depleted can be reset or topped up is one possible approach. Even if the actual in game coins have no real exchange back value, the coins would allow users to continue playing or reach for high scores. However, linking this approach to the Spindroid would break the Android market terms and conditions, as the Android Market doesn't allow the distribution of real money casino apps. Furthermore, as this is likely to be classified as gambling, a gambling license would be required along with the surrounding ethical issues. The purchase of subscription time is used for some Android apps, although few of them are games. This strategy is mainly used for subscriptions to newspaper apps such as the Times. Some multiplayer online games do require this subscription charge which they use to put towards the maintenance of servers; however the approach is not necessary for this application as there are no large maintenance costs. After looking at the options available and the difficulties of certain strategies, the best solution for this genre of app based on the reading would be to offer a free version supported by ads, with a full version which can be paid for. Admob implementation uses the Admob SDK which is available for free via the Admob website, which according to many online blogs such as James Elsey s Monetizing your Android apps with Admob (AdSense), an easy guide, is simple to implement. In order to select a price for the app, the results from the survey conducted as well as the research into the Android top 10 selling game apps should be taken into consideration. However, as suggested by Porter s (1980) generic strategies one should adopt a strategy of product differentiation or price leadership. It is said that being stuck in the middle, or attempting to achieve both product differentiation and price leadership is a major strategic error, often resulting in being able to accomplish neither to a full extent. As the aim of this dissertation is to include features that do not already exist on the Android marketplace, it would be good practise to assume a price which does not strive to undercut competing apps. Undercutting other developers is likely to result in a price war. However, whilst noting that the app does not need to undercut others, if priced too highly it will result in the potential buyers being likely to be put off, or even attract other developers to create a similar app for a lower price. For that reason a price in line with, or slightly higher than other fruit machine 14

21 apps (which do not contain the extra features such as social integration and feature board) may be a good choice. Jeffrey Hughes (2011) suggests conducting cost analysis to determine the number of hours required developing the application, a set expected rate for those hours, and the expected number of app downloads. It is recognised however the difficulties of doing this for new entrants to the Android market, particularly single developers who have no costs other than the value they put on their own time. As this is a dissertation project, the value of the developer s time is paid for in the form of the degree, rather than the monetary value obtained through the market, which makes this kind of cost analysis much less useful. The price will therefore be based upon the average of the top 5 paid slot machines in the market, as seen in appendix figure 2.2B, the average of which is As this application has extra features, a suitable price would be around 1.50 as an entry price. As recommended in the Android marketing literature studied, it is best to target a higher price and be able to reduce the cost using promotional sales than to price an app too low to begin. From this amount, the Android market will take 30% commission; this amount is the same regardless of pricing. In conclusion, this review has researched the Android developer SDK with reference to both the official SDK and published books on Android development, looking into the possible difficulties which may be faced with different screen sizes and densities. With the use of marketing literature and research based on the current Android Market, a marketing strategy to integrate Facebook using both a fan page and posting to users walls has been decided upon, with the use of Facebook s SDK. The pricing and distribution strategy has been considered, suggesting the best marketing practise for this genre is to make both a free ad supported version and a non-free one off payment version, similar to the other applications on the market. 15

22 3. FUNCTIONAL SPECIFICATION + TECHNOLOGIES This functional specification will be a blueprint for how the application works and how users can interact with the application. The first section will outline the topology for how all of the components of the full product will connect and work together. The technologies and the reasons for their selection will then be discussed individually. Wireframes will then be discussed, showing the roughly how the application will be navigated, allowing a deeper insight into the structure of the app itself. UML diagrams will be considered for the application, followed by some finalised creatives built on the ideas generated during wireframing. Finally, prior to implementation, it is important to first devise plans for the organisation of files (Version control) and quality assurance which will be discussed. 3.1 Topology The topology needs to allow for a web server and a database server to store high scores and serve a web page to help with advertising. The mobile device should be able to connect to the database server to upload and download the current leaderboard. The mobile device needs to utilise the Facebook API to send messages to the wall and allow authentication. Finally, the device needs to be connected to the android market for app distribution. The layout of the components and the flow of data required are outlined below: 16

23 As seen above, there is a service layer between the device and the database. This is because the database server as stated by 1&1s terms and conditions do not allow for direct access to the database. The main reason outlined (1&1.co.uk, 2012) is security. Some service needs to be placed on the web server to allow access to the database, this service is used to ensure only certain queries can be ran on the database, as outlined in the service. This will require a server side script language, PHP. In order to create the service layer, it needs to be understood exactly what services will be required. The first service will be a get leaderboard service, which will provide data for the mobile device or website to show the leaderboard. Another service should be responsible for allowing users to create accounts, and one more service to allow users to update their high score. The services, as discussed within the literature review need to ensure the security of the database by making sure to disallow any possible SQL injections. 3.2 Technologies required for implementation This section will first discuss the technologies required for the website, web service and database. Discussion on the technical requirements for the Android application development 17

24 will then follow, finishing with the supporting technologies and software needed for design, organisation and quality assurance Website HTML, CSS, JavaScript and jquery A website is needed for the advertising, but also to host images that should appear on messages shared on Facebook (Facebook does not host these images). The website will be coded in HTML 4 rather than the newer standard HTML5 to ensure compatibility with older browsers, particularly as the website does not need any HTML5 elements or offline storage. The choice of HTML4 has been selected to also ensure compatibility with Android devices, ultimately Android users are the target audience there it is likely that the site is viewed on mobile devices. The stylesheets will be coded in separate CSS files, making it easy to change the styles throughout the whole site in one place. This helps in keeping the same standard across the whole site. In order to show off some of the features which Spindroid has, particularly those that are an improvement on the existing market applications, JavaScript will be used for some image animation. The jquery library has some very nice tools for easily creating Javascript lightboxes and slideshows, which may be used in a banner or similar to show off the application. META tags will play an important part in the website, particularly tags which will aid with search engine optimisation and for the pages which may be shared on Facebook. Using the Facebook API requires meta tags to allow recognition of which image to show in the users feed, these tags are well documented on the Facebook developers website (Facebook developer, 2012 ). These tags will be customised for each of the pages on the site. Before creating the website a brand theme must be created. As with the name of the application, Spindroid, the chosen theme for the application and website will rely heavily on the colour green, the same colour as the Android logo. This will allow users to easily identify the colours and easily see the purpose of the site, to advertise an Android application. The website should use standard HTML coding practises, and be validated using the W3C validator to ensure compliance to these standards. The use of Wordpress was experimented with for this part of the project. Initially, a very quick demo of Wordpress was set up and tested to find if it fits the requirements of the site. Wordpress was originally a blogging tool, which has been developed by a large community 18

25 into a tool used for developing many sites, even stores. The theming and skinning options, along with the excellent user interface to add pages makes Wordpress a good choice for sites which will require many pages. After experimenting with Wordpress, it was found that it would no doubt take longer to install a custom theme for the pages than it would take to just hand code the pages. There will only be the need for a few pages, a homepage, leaderboard and a support page and so it will be more time efficient to hand code the website than create a full Wordpress theme. Hand creating the site using HTML and CSS also allows for slightly more customisability, and so this was the option chosen. The website is hosted using 1&1, and is registered with the name of the application, Web service PHP, JSON Due to the restrictions on direct access to the database from the Android device for security reasons, a service layer has to be created on the web server to collect and serve data the required data. This service needs to be responsible for creating accounts, logging in and uploading a leaderboard, and also displaying the leaderboard. PHP is the server side script of choice, as it has pre built functions for database queries. In order to create an account, data needs to be received by the service, which will utilise HTTP POST from the android application to pass the parameters. The PHP service will then be able to access the database and create results to be passed back to the device, such as a result code to signify the user has successfully logged in. As PHP is server side, it means that the username and password for the database can be hidden within the code and never sent to the clients machine, however it does have some security issues which unless considered may allow a user to run malicious scripts on the web server or attack the database. For that reason security needs to be a concern when working with the input parameters, which should be stripped of any special characters such as apostrophes or slashes. The JSON data format is well suited to the mobile environment (Riva & Laitkorpi, 2009). The use of object orientation is useful to create leaderboard items, consisting of a name and score. These can be sorted when called in the database query using SORT. PHP has a tool for creating JSONs (Javascript Object Notation) which can be parsed by the java JSON library (org.json). These objects can then be easily used to populate the leaderboard on the Android application once received. Care with threading and efficiency needs to be considered when accessing the web service (more on this in the implementation section). To prevent creating 19

26 and sending the whole leaderboard table, a parameter can be used to be sent to the PHP identifying how many results are required. Please refer to the example of the URL taking in the amount parameters along with the results shown which can be seen in appendix A. The usage of the JSON request should follow the steps: 1) Device creates URL including parameter for how many results required. 2) Device uses HTTP to open the URL, awaits response. 3) PHP script calls database query, using parameter for how many results (after security check), and adds SORT to sort by score in descending order. 4) PHP script then creates JSON from the database result, and shows on HTTP as JSON format. 5) Device receives result 6) Device parses objects and adds to leaderboard table. This fills all of the requirements to show a leaderboard within Spindroid, whilst also allowing the device to select how many results to show, improving efficiency rather than pulling all results from the service. Efficiency is important due to mobile internet speeds and data usage restrictions, but also to make sure not to cause unnecessary strain or bandwidth usage on the server Database MSSQL A simple MSSQL database is required to store user accounts and scores. The database needs to a unique identifier (username), the score, a password and an address. The address is used only if the user forgets their password which would disallow them from submitting highscores. The database does not require any table relationships, but simply one table holding the aforementioned data. The password is necessary to ensure that users can update their highscore, and only their highscore. Field Type Null? Username Varchar(15) Not null Score Int(15) Not Null Pass Varchar(50) Not Null Varchar(50) Null allowed 20

27 As an improvement, which is currently outside of the scope of this project in the future achievements may be added to the database which would allow the achievements to be shown on the website for each user. Currently however, this is not core to the project and may be considered post launch as an update Android Application Eclipse, Android SDK, Logcat, DDMS These software packages are chosen for the development environment. Eclipse is used as it is recommended by the official Android developer website, and as the Android plugins are available for eclipse simplify building and running for the Android emulators.. System messages from the Android device or emulator are important for debugging. The logcat details from the device/emulator shows information about the phone state, details, and every user interaction, along a stack trace of any uncaught exceptions. This tool also allows a filter, to show only messages from the Spindroid application as messages from other services can cause unnecessary noise making the log difficult to analyse. DDMS is a tool which comes with Android, called the Dalvik Debug Monitor Server (Android, 2012). It provides useful tools such as screen capture, thread and heap information. It can be used for incoming call and SMS spoofing and has a plug in for eclipse which makes it easy to access from within the IDE. It is an aid to debugging throughout development process, looking into the memory usage and finding any possible leaks. It also helps to create screenshots which need to be posted on the android market when marketing the application. A typical DDMS debugging screen can be seen in the appendix, figure A. These are all features of the Android SDK to help with development Marketing Admob SDK, Facebook SDK. Admob is the most used android advertisement provider, owned by Google. As discussed in the literature review, the app will be delivered in two forms, a free version with advert support and a paid version without adverts. Admob targets adverts by using genres and age groups, to try to aim advertised products at the correct target audience. The Admob adverts require a library (.jar file) to be imported into the project. Once imported, it contains the classes needed to create an Adview. An Adview is a subclass of View, similar to how the other views such as ButtonView and TextView work. The Adview displays small HTML5 ads that respond to selection. This means that the view can be placed in the XML layout files 21

28 for the application, with their size and location specified. In the activity which hosts the adview, the adview needs to be initiated, and the method adview.loadad(new adrequest()); is called to retrieve a new advert. Admob will then pay per user click. The SDK is fully documented and available to download from their website found in the references section of this document. (Admob SDK, 2012). The Facebook SDK for Android allows the ability to share messages on a user s feed/wall. Calls to create a message on the users wall is more complicated than the Admob calls due to the security and authentication requirements. An API secret token must first be obtained by the developer for the app, which needs to be generated using the Android keystore hash. The Android keystore is a unique key used to sign the application files (.apk) before putting it on the market to show it was created by a particular developer. This allows the developer to then publish updates, and allows the android market to authenticate the developer. This hash of this keystore can be obtained, which is used to generate a secret key, which then authenticates with Facebook from the Android application. The generation of this secret key can be seen in the appendix, figure 3.2.5A. The key is used to initialise a Facebook object within the application. A call is made to Facebook (using the Facebook object) to receive the Facebook session token for a user, this call is shown within a webview which overlays the current activity, allowing the user to complete authentication (enter username/password). When the user is signed in, a session token is received. Only once the session token has been granted for a user can they post to their wall using the app. The post to the Facebook wall does not hold images; however it can contain a link to a web page with meta tags to show the correct image when loaded. The meta tags need including on the website as discussed earlier in section This will then share a comment from the user, a link to a the Spindroid website (and image pulled through the websites meta tag ), along with a caption and title as seen in Appendix figure 3.2.5B. As a result of the Facebook SDK being difficult to implement, some third party SDKs have been made to make this task easier such as SimpleSDK (Link in references). However to fully understand the mechanisms behind the process and to enable future tweaks if required, the decision was made to directly use the Facebook SDK Design Photoshop, Smush.it The final design and graphics are created using Photoshop. The reason for the choice of Photoshop is that it is a full suite of tools which will allow the developer to create the designs, allowing to easily resize appropriately for different screen densities. The graphics 22

29 and look of applications on the market are said to make a great difference to the sales (Hughes, 2012). Photoshop will also be used for the website design. PNGs will be the image type of choice for the vast majority of the images for transparency support. This is important for example when placing the buttons on the background of the machine to ensure not all images have right angle edges. The android documentation suggests that PNG s transparency is fully supported. Reducing the file size is important as ultimately these files will need to be downloaded on mobile devices through their mobile network provider, usually charging for data usage. Images often have meta tags attached which are not required but increase the filesize. Larger installations may put off potential customers, and so it is important to optimise this where possible. Smush.it is a service provided by Yahoo to do exactly that, to reduce the image size of PNG and gif files to improve performance.this will allow the images to be easily optimized, reducing the file size for the download for the end-users Organisation Subversion, Microsoft Project. Subversion is a version control system, making it easier to keep backups and make changes without worrying about versioning. A SVN instance will be created using the Nottingham University servers, which will allow the project to be updated and downloaded from any location. This is particularly useful for working on more than one site, for this project this makes it easy moving between the University computer lab and home, but on larger projects also makes it easy to work with teams making use of the SVN merge options. SVN version control also helps with quality assurance, as if any new issues are created, it is simple to roll back to a previous version. It is important with any project to ensure backups are made and to be certain that nothing is going to get lost or go missing with multiple versions. Microsoft Project 2010 will be used to create Gantt and Pert charts necessary to plan the timing of the project and make sure to keep the project on time. The initial estimates can be found in the appendix (3.2.7A). Microsoft Project is a fantastic tool for time management, however again with only one developer (meaning not many tasks running in parallel) it far exceeds the requirements of this project. It will be used for simple Gantt charts at the start of the project, and will be updated / modified if current progress strays from the estimations and targets to ensure the project is complete. 23

30 3.2.8 Quality Assurance Lint warnings, Test Devices, Emulators and Beta Testing This section of the dissertation will outline the tools, technologies and methods for testing, however further details into the actual results, bugs and resolutions will be covered in more detail in section 4.0. Android Lint will a be the first tool used during development to help minimise the possible problems, particularly cross Android version issues. Android Lint will show warnings in the Eclipse IDE for code which does not conform to best practices or may be the cause of accessibility problems. Some examples from the android lint website (Android Tools, 2012) of issues which may be detected include:missing translations (and unused translations) Layout performance problems Unused resources Inconsistent array sizes (when arrays are defined in multiple configurations) Accessibility and internationalization problems (hardcoded strings, missing contentdescription, etc) Icon problems (like missing densities, duplicate icons, wrong sizes, etc) Usability problems (like not specifying an input type on a text field) Manifest errors A full list of the checks which are performed by Android Lint can be found on the Android Lint website (Link in references). Appendix figure 3.2.8A shows the eclipse plug-in detailing lint warnings. The physical test devices which will be used for testing are detailed in the appendix section 6.2B. The range will test a range in screen sizes, densities, and Android versions. However these devices still leave many versions and sizes untested. The Android Emulator which is provided with the Android SDK will be used to test alternate configurations, and will also be particularly helpful in reproducing any reported issues during beta. As there is such a wide range of devices, there is always the worry that some issues may not be encountered and may progress all the way into the release of the application. To this end a public beta utilised prior to any launch ensures the application functions correctly on all systems for which the application is compatible. The Google market allows for the distribution of a free beta test, and will also report issues along with a stack trace of any crash bugs which occur. Furthermore, the address bugs@spindroid.co.uk has been set up to receive any bug reports, which should be easily composed through the application itself during beta testing. 24

31 3.3 UML diagram The UML diagram for this project contains 23 classes. It is too large for this format and so has been added to the electronic resource submitted with this project, in the folder named UML Diagram. 25

32 4.0 WIREFRAMES AND CREATIVE FILES This section will discuss the initial wireframes used to understand and design the user flow for the application, followed by the final design creatives. 4.1 Wireframes Wireframes are created to plan functionality, rather than exactly how activities will look. They are used a technical guide to for the specifications before creating the creative graphics for the screens. Creating wireframes is common practise for the creation of applications which will require human interaction. They show the flow, and how the user will travel between different states. The initial wireframes are shown below, along with numbered descriptions of the actions triggered by particular interactions. Although during the wireframing stage of development every effort to represent where elements will be placed, the wireframes below are not final representations of the application design. The wireframes may be altered during the design stage to improve the visual appearance; however the flow and core functionality will remain the same Splash and Menu 26

33 4.1.2 Settings Activity 27

34 4.1.3 Leader board Activity 28

35 4.1.4 Game and Feature Pages 4.2 Designs Creatives The creative images are created using Adobe Photoshop as discussed in section 3.0. The use of layers allows for the images to be cut out to PNG files which will be used as the image resources for the application. All of these creative have been submitted electronically and are available within the creative folder. 29

36 4.2.1 Logo The logo is an adaptation on the Android logo. It is the same colours, however with the right arm up to look like familiar one armed bandit machines seen in large casinos. The body shows the fruit machine reels. This logo is aimed to represent the application on the website, splash screen, store and on the Android menu. The logo makes it easy to visualise what the application represents, drawing from the Android logo and the familiar looks of one armed bandits Website Creative 30

37 The website includes a colour scheme which compliments the logo. The simple design allows for pages to be linked across in the top navigation. The Facebook Like button is included to allow people to like the page and join the Facebook fan page. The main container of the content is the green box in the middle, which will contain information on what Spindroid is, as well as any promotions. The area in the header is not shown in the creative files, as this is to be filled with a jquery banner, showing different screenshots from the application Menu Creative The creative for the menu has 4 image buttons, again keeping with the colour scheme of the application and logo. The full design and all files have been created bespoke to Spindroid for a unique look, other than the top section of this image which was purchased and heavily edited. All of the conditions of the licensing and a receipt for the payment have been kept. Please see the original in the appendix figure 4.2.3A. 31

38 4.2.4 Game Creative The game keeps with the style of the rest of the application. The buttons at the bottom are representative of those on a real fruit machine. The display at the top will be for displaying wins, credits, the stake and also bonus options. 32

39 4.2.5 Feature board Creative The featureboard again follows the same style as the rest of the application, showing similar buttons to those on the main game. The help button is shown on the right which can bring up extra help describing how the feature board works. Please see the appendix 1.1A for usage instructions. 33

40 4.2.6 Mini-Game Creative This creative file contains all of the images used to create the minigame. The back of the card shows the Spindroid logo. These cards will be turned over by the user, adding to the collectable coins or features. When Lose is turned, the user will return to the featureboard. Some screens such as the settings screen will use the default Android preferences layout. The leaderboard will make use of a simple table and so a creative file has not been made for these screens. (These PSD files are included within the submitted electronic dissertation files). 34

41 5. IMPLEMENTATION This section will describe in more detail the techniques used for implementation. As this project includes a large amount of code, only the sections of particular interest will be discussed, including code which is core to the main functionality of the application and those which caused particular difficulties. The challenges faced during implementation will be discussed in detail, along with their resolution. 5.1 Website Implementation The website files which are discussed within this section of the dissertation will be also submitted electronically and available within the website folder, or viewable at spindroid.co.uk. The website has been designed and implemented to be easy to navigate, complimentary to the branding and to give a platform for news and updates. It has been developed to meet the w3c web standards, and has been validated. The main website consists of three pages; home, leaderboard, and support. There is also a download link shown in the navigation which directs straight to the android market. The website uses a central stylesheet and the same layout across all pages. This is for consistency to make it easy to change a style across the full site. As is common practise, the main content of the page is held within a container div. Divs allow for the page to be split up into areas when coded, with the positioning of them defined within the HTML and CSS. The page body has a repeating background with a container div with a width of 980px in the center of the document to hold the content. The idea of having a container on top of a body with a repeating background allows the user a consistent visual experience whilst allowing for different screen resolutions. The container is split into two divs, with IDs left and right. The left section is a column which holds the logo, the right section holds the navigation, sliding banner, main text area and footer. 35

42 The meta tags for the site help with search engine optimisation, accessibility and to provide the description to any social media on which the page is shared. The meta tags along with a description of each tag can be found in the appendix, figure 5.1.A. The leaderboard page and support pages make use of PHP. The use for PHP on the leaderboard is to access the SQL database and bring the correct results. The PHP outputs the HTML for the completed leaderboard table, which is sent to the user s browser. A full snippet of the PHP code with descriptive comments can be found in the appendix, figure 5.1B. 36

43 To ensure ease of use for users, in case there are any broken links anywhere on the site a 404 page will allow the users to be redirected to the homepage, after being alerted that they have attempted to access a page which does not exist. For this, a.htaccess file has been created in the root directory, redirecting users to the 404 page. The 404 page uses a meta tag to wait for a period of time (20 seconds) and route the user back to the homepage. The support page is very simple; it collects information using a HTML form, which is then posted to the thankyou.php page. The php page uses the method mail() to the information to admin@spindroid.co.uk, after checking for any possible injection attacks using the PHP post. Finally, to allow the user to share a page on Facebook with the details of a particular in game achievement, achievement pages have been made showing the achievement icon along with a description. These are very simple pages based on the same layout, located in the achievements folder. There were no unexpected challenges whilst creating the website or the, leaderboard or support page. 5.2 Android Application Implementation As outline within the literature review, the Android application makes use of activities to define the different areas of the application. The activities which are needed for the application are discussed within this section with a discussion about implementation and any difficulties for each activity. For screenshots to aid with the illustration, please see the appendix section 5.2. The possible user flow through the activities is outlined in the image below. 37

44 SplashActivity MainActivity SlotMachineActivity Leaderboard Activity Achievements Activity Settings Activity Featureboard MiniGame SplashActivity This is the launcher activity, meaning it is the first activity to open with the application. This activity was originally planned to show the splash screen and then move on to the main menu of the application. This used a TimerTask which then triggered the next activity, MainActivity (The menu). The problem with this approach was that the TimerTask was idle time, not loading any resources, simply displaying the Spindroid logo to the user before fading away. When moving from the main menu to the actual game it was found that it took around 7 seconds to move from the menu to the actual application. This was due to loading and resizing images based on the device (different sizes and densities), and setting up the view. This problem was fixed by moving the initialisation from the MainActivity to a separate thread which is ran on the SplashActivity. A loading bar has been created on the SplashActivity which is updated by the separate thread at certain points during the initialisation and resizing of the images. For this a singleton class was made, which will store strong references to all of the resources, and holds methods for loading those resources which are called during the SplashActivity. This means that when the MenuActivity starts, it can retrieve those references to images already loaded into memory and display them on the view without additional loading. The use of the Android AsyncTask is used to create and manage 38

45 the additional thread which calls the initialisation methods, which allows it to also control the UI to update the loading bar. Upon completing the loading of the resources required for the main game, the SplashActivity then starts the MainActivity (menu), and finally calls its own finish method. The reason for calling the finish() method here on the SplashActivity is to avoid being able to use the physical back button on devices to go back to this activity from the main menu, the SplashActivity should only display once MainActivity The MainActivity shows the menu. The first section of this activity is to set the layout from the MainActivity.xml file which defines the background image, and where the ImageButtons should be shown on the screen (See Section for creative). This activity also uses a MediaPlayer object to start the background music. Finally, this activity creates the button listeners which are used to start the activities for the SlotMachineActivity, the Achievements activity, the Leaderboard activity or the Settings activity. As per the lifecycle of an activity outlined in the literature review, the onpause() method is called before moving to the other activities. In this method the MediaPlayer.stop method is called to stop the music playing Settings The settings activity differs from the others as it extends PreferenceActivity. This allows a call to addpreferencesfromresource () to add to a list of settings. This is a standard Android settings page which will be familiar with most Android users, as it is the same style menu as seen throughout the operating system. The settings are stored in the Android Shared Preferences, which can easily be fetched from within any other activity, however custom buttons with custom listeners can also be added by using setonpreferenceclicklistener(). For the Report a Bug and the About Spindroid options on this menu, the listener calls custom actions. The report a bug option opens up the default client and addresses an to bugs@spindroid.co.uk, and the About Spindroid button simply opens up a dialog box showing a string of information such as the version code, and information about the application Achievements The achievements activity is opened from the MainActivity (Menu) and uses the achievement.xml file. The leaderboard xml file shows a tableview within a scrollview, which enables the tableview to be scrollable if future achievements are ever added. The tableview shows a set of image buttons, set as default to show an inactive image. Once achieved, the 39

46 Android local database sets a Boolean value to signify that particular achievement has been achieved. If an achievement has been achieved, the active image will show instead of the inactive image. The image buttons may be selected, causing a dialog window to show, detailing how the achievement may be achieved Leader board The Leaderboard activity is responsible for connecting to the web service to allow the user to create accounts, update highscores, and view the high scores set by others. The leaderboard activity uses the leaderboard.xml layout defined in the layouts folder. In order to carry out these tasks, the leaderboard activity needs to have more than one thread. If the main thread which controls elements of the UI is blocked by waiting for incoming connections, the interface will appear to freeze, and if blocked for long enough will cause an error message dialog to be displayed to the user allowing them to force close the application, as illustrated in the image below: This is not the experience expected and so an additional thread is created to handle connections. The thread cannot directly make changes to the user interface, which is the first and main difficulty encountered with the leaderboard activity. The resolution to this is to create a new thread, have this thread download and process the information needed, and then post runnable objects to the UI thread to update. Android provides a class called AsyncTask to make it easier for the developer to handle threading. It makes it possible to publish updates from the background thread to the UI thread, but also contains methods for onpreexecute() and onpostexecute() which are first invoked on the UI thread before and after the thread works on background tasks. This makes it possible to add a loading dialog to show onpreexecute(), and to dismiss when onpostexecute() is called. By handling the workload and waiting for connections in this way it is possible to show a user friendly dialog and avoid 40

47 possible freezing problems. An inner class for each section which requires a HTTP connection, has been created inside the leaderboard activity which is responsible for communicating with the web service and parsing the leaderboard JSON, as well as log in authentication and registration. Those such as log in and register which require parameters are sent to the PHP using HTTP POST SlotMachineActivity The slot machine activity is the main game activity, which is home to the model and controller of the game itself. This section will first discuss the use of the assetpreloader which initiates image resources during the splash screen. Then the use of the Kankan.wheel library under the apache license in order to show the animation of the wheels spinning will be considered. Finally, this section will explain how the featureboard can be triggered and passed the data required (betamount), as well as accepting the returned results. The assetpreloader is a singleton class, meaning it has one static instance which can be retrieved using getinstance(). There are methods in the assetpreloader class which are responsible for initialising the images, which are called during the splash screen. Once the assets are pre-loaded, during the slot machine activity they can be retrieved by calling the static method assetpreloader.getinstance(). Public methods are available such as getreelsymbols() which will return the array of pre-loaded bitmaps to be added to the reels. This means that the loading is done in advance of when the image resources are required. This was to overcome the issue of lagging when moving from the main menu to the slot machine activity. In order to make the animations of the reels spinning requires a lot of work creating custom surface views and image manipulation. An open source library, the Kankan wheel project (Kankan, 2012) is available for creating reels, similar to the feel of the date pickers and spinners available on ios. The library is on the apache license, which allows free integration or modification into the Spindroid project, providing an acknowledgement statement is shown within the application. This acknowledgement is shown in the About section of the settings menu. The Kankan wheel library has a Kankan.WheelView, which extends the view class. The library has a class for OnWheelScrollListner which can be extended to add the behaviour required when the scrolling starts and when it stops. The WheelView class has the method scroll(int itemstoscroll, int Time), which allows the wheels to spin when pressing the spin 41

48 button. To create the effect of randomness for the wheels, each wheel has the ReelSymbol objects (ReelSymbol.java) added in different orders. Then, when spinning, the number of items to spin through is generated by using wheel.scroll( (int) (Math.random() * 50), timetospin);. The reason for the negative 350 is to ensure a negative number is generated, which makes the wheel appear to spin downwards like a real fruit machine rather than upwards (positive). The ReelSymbol objects are initialised during the splash screen, and include the bitmap image, an int to signify which fruit is showing, and another int to identify the trail number showing. This makes it easy to make comparisons when the final wheel stops by comparing the fruitnumber int to check if they are the same. It also makes checking the trail number easy by counting the sum of the trailnumber ints for each reel. A challenge appeared when introducing some of the additional features to the game, such as nudges and free spins. As nudges have been added, it means that it is not correct to check for a win only when the last (3 rd ) reel stops spinning, as a win may come from nudging the first or second reel. To get around this, an int for the number of reels spinning has been made which increments when a reel starts spinning, and reduces each time it stops. This means each time a reel stops spinning, a check can be made to find if it is the last reel to stop, and if so can then check for a win. Holds are implemented by using Boolean values to check if a reel is held and if so, when the spin button is pressed that reel does not spin. Win spins and free spins also require some extra logic. A win spin is a guaranteed win. In order to accomplish this, the first reel is span, then the fruitnumber is stored. The second wheel is then nudged until the middle reel symbol fruitnumber is equal to that of the first reel, and then finally the third wheel is nudged until a match is found. During these nudges it is important the buttons are disabled from additional user input, and also that the trail is not updated (as the feature board should not be triggered by win spins). Once a win is found, if the user has more than one win spin, the process should automatically repeat. The main challenge in creating this activity has been to ensure the logic is correct for the numerous scenarios available. An edge case example of where this becomes a challenge is if a user holds all three reels. The spin button and bet max button are disabled whilst the reels spin, however if all three reels are held and the spin button pressed, as the last wheel never stops spinning (as none ever start), it s not possible to put the button re-enabling code only when the reels stop spinning. To fix this, checks have been added to check if all three are held before spinning, and the method to disable the buttons is not called. Another difficulty arose when the user may use nudges to arrive on the bonus number (4), and then achieve holds. Using a real world fruit machine 42

49 hold and nudge features use the same buttons which is reflected in the Spindroid design. As a result, the hold buttons (which are also the nudge buttons) have ambiguous functionality. To fix this problem holds are disabled from the bonus if the user has nudges. Many more of these edge cases caused challenges during implementation and resulted in additional variables to keep track of certain states within the game. For these reasons, although not exclusively, as discussed further in section 6 it has been essential to thoroughly test the functionality of the application. Finally, the SlotMachineActivity is responsible for calling the Featureboard when the trail reaches above 8. Android uses Intent objects to call activities, which allow for extra information to be added. The activity is called using the method startactivityforresult which allows for data to be returned from the activity upon finishing. Two integers are passed to the feature board activity when started. The first is the bet amount which is used to determine the amount which the user can win. Secondly, the trail number signifies the starting point of the feature board, if it is Feature, Superfeature or Frenzy. This can be added to the intent by using the putextra(string identifier, int) method to add this required data. When the feature board closes, the last activity is resumed. On resuming the slot machine activity, as, the onactivityresult() method is used the slot machine activity can receive a result in the form of an intent when the featureboard closes, including the amount won, or the feature to start Featureboard The featureboard activity uses the featureboard.xml layout. From the featureboard the user may progress to the minigame activity, collect a prize and exit to the slot machine activity, or lose which also returns to the slot machine activity only without any prize. The implementation is based on the Kankan.wheel library to provide the number spinner in the centre of the feature board. As the WheelView only requires integer values, textviews can be added rather than images, and there is little pause when loading this activity, and less need for preloaded assets. To make a pleasing user experience, when moving on the leaderboard the squares highlight to indicate the current position. To allow this, a recursive loop with the use of a handler is used to allow for delays between each move. For example if the user is on the first square and spins a 5, instead of moving 5 spaces instantly, it is more visually pleasing to see each square highlight whilst moving, with a short pause between. The Android Handler class allows 43

50 messages or runnable objects to be processed. This is particularly useful as a method already exists to send delayed messages for processing. The recursive loop first takes in an integer, representing the number of squares to move. Then, reduces it by one, and posts the same message (with an integer one lower) back to the handler with a short delay. When the number of squares left to move finally reaches 0, no more messages are sent. A Message is an object, with a public int value for what. This integer is used to signify what message is being sent, and is handled appropriately by the handler. The same handler is used to handle messages for the question mark squares, allowing recursion through the possible features until the user selects to stop the feature. Similar to the SlotMachineActivity, the Featureboard activity uses intents to pass on about the current state to the minigame activity, which is triggered when all five mini game symbols are lit MiniGame This section will first discuss the initialisation of the minigame, followed by the animations used to turn cards over, and finally how data is passed back from the minigame to the featureboard. The minigame first initialises to the state which is indicated by the intent which started it. This intent contains the data regarding the currently level reached on the features and coins lists. This is in the form of two integer values, which are used to loop through the textviews representing the current status of the game, changing the font to gold for the features or coins already collectable. The minigame uses a 3d card flip animation for which is based upon past work distributed as an online tutorial (Davies, 2009). The animation has been adapted to work with a MiniGameCard object. The MiniGameCard object stores the image of the front of the card, but also a tag which can be used to identify the image. This identifier is needed as the cards are shuffled each time the minigame is entered, so players cannot learn where the best cards are. It allows action of the card to be correctly identified and applied once it has been revealed. The animation is stored in cardflipanimation which extends the Android animation class. The effect is applied by using android.graphics.camera. The camera represents a virtual view as if we are looking at the card from a point, which can be rotated around the image. The back of the card is initially shown, and the camera is moved around to the left, 44

51 making it appear the card turning to its side, at which point the card is eventually invisible (it has no width). Then, using the SwapViews class the image is replaced for the image showing the front of the card. The front is shown at the same angle, with the camera moving around to the other side of the card until it is flat and face up at which point the animation ends. At the end of the animation, the tag on the MiniGameCard objectis used to identify the card and handle selection. The selection is always either to add to the features available, the coins available, or to lose which exits the minigame. Leaving the minigame uses an intent to pass back data to the feature board about the progress which has been made, before calling the finish() method. This allows the feature board to then add the progress made to the current state, where the user can continue to gamble or may collect their winnings FacebookActivity The Facebook activity is provided in the Facebook SDK previously discussed. Its layout is a webview, which shows on top of the current activity to allow the user to log in and authenticate. When the activity returns a result (if the user is authenticated or not), the Facebook object can then be used to post to users wall using the returned authorisation token. This activity is called from any of the Spindroid activities which are the points at which a user may share their progress on their wall (When they meet the requirements for an achievement). 5.3 Web Service Implementation The web service application needed to meet the following objectives: To serve the leaderboard JSON to the Android application. To allow accounts to be created from the application. To allow authentication and updating of the leaderboard. To meet these three objectives, three PHP pages have been created to access the database. The services are all stored within the website/services folder, named leadboardjson, updatescore and writeaccount. leaderboardjson.php is used to serve the leaderboard to the Android Application.. This uses JSON, as described in section After an array of results has been collected from an SQL 45

52 query, similar to the one used for the leaderboard on the web page. Instead of being printed out to the screen for the user to view, the server encodes a JSON using one line of code: print json_encode($rows); Where $rows is the array of records from the database. This prints out the encoded JSON to the screen, which can be parsed by the Android application to create the rows in the objects on the leaderboard activity. wrteaccount.php also works by running queries on the database. The first step is to check all of the required posted variables exist and are secure. A query then checks if the username already exists, returning an error code User Already Exists if it does. If not, it will allow the account to be created by entering the username, score, password and address. The query to check the if the account already exists is: SELECT COUNT(*) FROM Accounts WHERE username='".$username."'" Which can then be tested to see if more than 0 results are found. The query to update the database with a new account is: INSERT INTO Accounts(Username,Score,Pass,LastLI, )VALUES('".$Username."','".$Score."','".$Pass. "','".$LastLI."','".$ ."');" The second query to insert the data into the database could be unsafe if it allowed users to post any data into the variables. To help prevent any possible issues, the variables are checked, for example the Username variable is retrieved using: $Username = mysql_real_escape_string($_post['username']); This strips escapes any special characters that may be used for SQL injections. Finally, to update the leaderboard follows the same methods of connecting to the database and securing against SQL injection, but this time checks that a row exists with both the Username and Password supplied, and then uses another query to update that row. Different outputs are used to make sure that the Android application can identify which result occurs and guide the user respectively to try again or alert them that the post was successful. 46

53 6. TESTING The testing of this application aims to meet the following objectives: To ensure the application is consistent across the wide range of supported devices. To ensure the game logic meets the expectation of users. To find issues resulting in poor performance, or crash conditions. This section of the dissertation will discuss the methods of testing the Android application and website to ensure the final product of this project is of a quality which is ready to be published to the Android market. 6.1 Emulator Testing Android provides emulators for Android application development. The advantage of emulators is that no extra hardware is needed which allows the developer to test across the full range of devices. The android emulator configurations along with the test plan are further detailed in the appendix, testing across a range of device screen sizes and android versions (Section 6.1A + 6.1B). Emulator testing however isn t a perfect representation of real world usage. This is because of a number of differences between the Android emulators and the actual devices. Firstly, the android emulators emulate a rooted device which means that on the emulator there is less security; in particular applications on real devices may only access its own resources and not those of other applications. Secondly, there is the issue of mobile network performance. As the mobile network is used to send and receive data to the web service, it is important to test under these conditions. Finally, the user experience on an emulator may differ from that on a mobile device, for example buttons which may be easy to select with the on screen cursor using the emulator may be much more difficult to select using a real life touch event. The next section will outline the testing procedures and real devices which will be used for testing prior to the public beta test. 47

54 6.2 Device Testing As already discussed in section 6.1, emulator testing whilst being useful to test a wide range of configurations is not perfectly representative of real world usage. For this reason real device testing must take place. With the limitation of requiring reach physical device to test, a smaller range of devices can be utilised for real device quality assurance. The devices which will be tested against the test plan are outlined in the appendix (Section 6.2B). 6.3 Beta Testing Beta testing is the final stage of testing as it is important that users are able to test without running in to already known issues, to allow the participants to really get a feel for how the end product will function. The method for distribution will be through the Android Market, allowing users to test the application exactly as it would be as a final product.the beta test has tested a wide range of devices, with real users. Participants have been given the means to report bugs through the application. Any crash bugs are reported through the Android market, which will be complete with a stack trace of the issue. Further to detecting just logic or coding issues, the beta test has received feedback on possible improvements, and also overall feedback in the form of market ratings and comments which will be used to assess the success of this project. The beta test is still open for public testing, which will end on the 20 th May 2012, on this date the application will show a message to the users detailing that the beta is over and access to the application will be revoked (On the launch activity this message will show, before closing the application). Beta testers are appreciated for all of their input and support during this final stage of testing. Those who supply useful or informative feedback such as suggestions or issues are acknowledged within the About section of the application. Currently as at 06/05/2012, the beta test has been issued to 111 devices across the world (Statistics provided by Android Market). Of the 111 who have downloaded the application, 73 are still active installations. Of those active installations, 53 are running Android 2.3.3, 15 are using android 4.0.3, and 5 are running Android 2.2. A wide range of devices has been tested, as illustrated in the following diagrams: 48

55 The vast majority of users are from regions with the same native language (USA, and United Kingdom making 90% of downloads), with others from Netherlands, Ireland, Denmark and Australia. A steady rate of downloads has been seen, testing across this range (Appendix, figure 6.3C). For a full set of statistics in CSV format, please see the statistics folder submitted with this dissertation. The wide range of testing devices, regions and languages has helped the success of the testing effort. As seen in the testing results summary, section 6.5, a range of issues have been found from the beta testing performed. 49

56 6.4 Website cross browser tests + validation The website testing has been split into two sections. First, cross browser compatibility has been tested with the use of IE9, IE8, Firefox, Safari and Chrome which are currently the most popular browsers (Source w3c, see appendix 6.4). Secondly, each of the pages has been run through the w3c validator to check for issues which may be the cause of cross browser problems or accessibility problems. This will ensure that the website meets the w3c standards, and reduce the possibilities of cross browser issues. 6.5 Summary of results Emulator testing results: The detailed emulator testing results and corresponding solutions can be found in Appendix section The majority issues found were based on logic issues which are easily fixed, although the most concerning problem is surrounding the wide range of screen sizes categorised as x-large. These include ranges from 7 displays up to the 13.3 display on the upcoming Toshiba Excite. On some of the larger devices the elements were seen to not be positioned correctly and appear visually stretched. Some graphic re-design work is needed to fix this issue, particularly involving ensuring that the background is large enough to stretch without distorting the image, and ensuring the main button elements remain centralised for larger screens Device testing results: The detailed device testing results and corresponding solutions can be found in Appendix section A particularly interesting issue came up which would not have been possible to find using emulator testing. When the HTC Desire Z physical keyboard was slid out, the current activity restarted and re-called the oncreate() method. Pulling the keyboard usually puts the device in landscape mode which requires re-calling this method to recalculate the positioning for layout elements. The method is used for initialisation and causes problems when re-called. The solution was to change the manifest file to disable the listener for when the keyboard is slid out within the activities. This result highlights the importance of real device testing as well as thorough emulator testing. 50

57 6.5.3 Beta testing results. Beta testing results have been reported through the bug report system as well as the comment system available on the Android Market. An has been sent to the reporter for each bug to acknowledge the receipt to thank them for their support. Updates which resolve these issues are distributed automatically through the android market when the updated application file is uploaded. The bug report will always contain the version number of the application; however the user may choose not to disclose their handset model or Android version. The following issues have been found by the 111 testers so far, as at 05/05/2012: The detailed issues found from the beta testing can be seen in the appendix section 6.5.3, along with the corresponding solutions. Fixing these issues during the beta has resulted in very positive feedback from users of the application. It is important to ensure that the issues are fixed and sent out in updates to keep the users happy with the beta who may be future customers, but also to send out the update and check that the issue is truly resolved. One user who reported 2 issues in a marketplace comment, the jackpot not paying and the super feature issue, later came back to change feedback to reflect the updates and report that the issues are resolved. This highlights the importance of keeping the application up to date and keeping the users informed, as well as using beta tests to test on as wide a range of devices as possible. 51

58 7. CONCLUSION The Spindroid application has attracted over 100 beta testers with some very positive feedback from the users. The aim of this project to introduce new features that are not yet on existing market applications has been achieved, as comments such as Finally This is the first fruit machine I have found to include a feature board have been left on the market (Appendix Section 7). Whilst the project is in beta, the marketing through a combination of Facebook and the Android market has been successful as seen by the consistent increase in the number of downloads which have been reported. Improvements on this are expected when the application is released from beta. Following the research outlined in the literature review, the best marketing strategy for the release of this application has been selected to combine the use of a free advert supported version and a paid for version priced at the market average. The project has been successful in meeting the objectives to create and launch (Although only for Beta at this stage) a fruit machine for Android. The objective to find the select the best marketing strategy as a result of research into the market and surrounding literature has been met. The challenges faced throughout the implementation have been discussed with resolutions found to overcome those challenges, including the results from rounds of testing which have stressed the importance of thorough testing. 52

59 8. EVALUATION The evaluation of this project is split into four parts, what went well, the challenges daced, future process improvements and future work. 8.1 What went well The main accomplishment of this dissertation project is that the beta product has been released to the market and is seeing a steady increase in installations from across the world. The market ratings currently (As at 07/05/2012) have rated the application 4.8 stars out of 5, a high ranking for any application on the market. The uninstall rate is not too high, even in beta testing, with 73 of those installs still active. The image below is from the Android market. The beta testing is going well, although some problems found their way to the final test round,they are being picked up and reported through the market. The utilisation of a beta test has been useful in both testing interest and feedback from the target audience, and for finding issues. The analytics provided by the 1&1 hosting solution are showing over 300 total visits to the website, with the highest rated referring page being Facebook.com which shows the impact of social media. The project has met the target of creating an Anroid application and selected best marking practises which will be applied upon release of the application. Time tracking and sticking to the deadlines has been greatly supported by the Microsoft Project Gantt chart. The final aim, to find areas for improvements in the process are discussed in section 8.3. The project met the goals it set out to achieve, although not without challenges along the way. 8.2 Challenges faced Although the project met the aims it set out to, it was not without some unanticipated challenges. The first challenge came in the form of requiring a service layer between the 53

60 Android device and database due to 1&1s security policies. This was found early on in the process and was overcome with the use of server side PHP scripting and a JSON implementation. However, this was not expected when selecting the project and required a larger time commitment than expected. The next challenge came with screen sizes. Although understanding that this would be an issue when beginning the project, there was still amount of oversight. The design was created with the intention to work on most Andriod devices, and be clear, however suggestions some items are too small on smaller devices have come in the beta feedback. This is particularly difficult to fix, as without removing some of the content, everything needs to somehow fit on the screen which is simply not large enough to contain everything and still be easily visible. The challenge has resulted in alterations to the manifest to remove devices with small screen sizes. This was not a decision taken lightly, since it excludes some of the target audience, however it was felt necessary until a further re-design can be created for smaller screen devices. A similar challenge was faced with x-large screen sizes which are shown on tablet devices. The challenge faced here was that although there is plenty of room to support the content, the correct image resolutions and layout files still need to be provided. This is exactly the same as for other screen sizes, however the x-large category using Android s SDK has a much wider size range than any other screen size, ranging from the 7 inches HTC flyer all the way up to the 13.3 inch Toshiba Excite. In testing, it was found that the wide range could result in the displacement of images, which counters the applications visual pleasing aesthetics, and takes away from the user experience. Whilst the application does look good on some devices in the tablet category, due to the issues which may occur on the x-large screens, further work will need to be done to redesign how the layouts will stretch at the edges to make a x-large version that will both fit the smallest x-large screen, but also stretch appropriately for those even larger. 8.3 Future process improvements One major lesson which has been learnt from the development of this project is the importance of neat coding practises from the start. During the project there have been times needing large amounts of refactoring, for example when the decision was made to move the 54

61 asset loading to the splash screen. During these times, sections of code needed refactoring, introducing a few bugs and ultimately taking more time than it would have if it was originally implemented that way. The result is that whilst trying to fix issues a further time commitment has had to be made towards the end of the project to neaten the code, making it easier to be read for any future development. The change which is suggested for the future process is to write Javadoc with each method whilst developing as the small time to add this to each method for large projects is likely to be beneficial later on, particularly when changes need to be made, a secondary lesson from this is the importance of considering efficiency in the initial application design.. The next future process improvement as already touched upon in the difficulties is to take particular care during the creative designing stages of development to consider the range of devices. It was understood that different image resolutions and sizes would need to be created which are included in the project, however more attention should be paid to accessibility on the small screens, particularly how the text will look. Simply scaling the same layout with the use of different measurements in dp, and different image resolutions is not always sufficient to ensure accessibility on smaller screen devices. In future, further consideration needs to be paid to the effect of reducing the size of the layout for the smaller screens, although implemented successfully some changes are required to the design to make this aspect of the application more user-friendly. 8.4 Future work on Spindroid Spindroid has had a fantastic start, reaching a good number of devices with fantastic feedback already from the Android market. As with most applications however, there are updates and tweaks which will make the project even better. Continuous support is outlined by Hughes(2011) as a greatly important aspect to developing android applications. With new devices appearing all the time, some changes may be required in future for the support of different platforms, without which bad ratings will appear until eventually cause the project to lose the momentum it has gained. Support for the small screen devices should be added to the project, however this may require a full re-design all the way back to the stages of Photoshop for the layout files. The project works perfectly on normal large devices, which is the vast majority of android devices on the market, however further attention needs to be 55

62 paid to the range of sizes classified as x-large within the Android SDK to ensure the application scales properly for tablets and to add support for these devices. Additional features to keep the game fresh for existing customers and to keep the good developer review achieved so far should be added to the game through updates. To this end, simple additional minigames can be added which can be triggered from the featureboard. A skinning option would be simple to implement by changing the current images for others of the same size. This would allow themes such as a Halloween theme, a Christmas theme or even a particular brands theme. Further updates to the website and social aspects of the game are also under consideration, such as adding an online forum to emphasise a community of players, and the introduction of leaderboard promotions to attract new players. The database can also be extended to allow for achievements to be uploaded and attached to an account, so users may have a profile with more information than just their coins total (The achievements are currently stored locally). Finally, a story mode has been considered for future work. Like most games, the starting position would be relatively simple, the user can only spin the reels. Upon achieving a certain amount of credits they can then purchase (with in game coins) the ability to nudge for example once in every 10 spins. Then, with the coins they win from there on they can buy access to the feature board, holds, the super feature and additional minigames. This would allow for a smoother learning curve to the game and add another new element of interactivity, again which is not present on competing Android fruit machines. 56

63 9. APPENDIX Appendix 1.1A- Instructions The instructions can also be found in-game, however to fully understand the additional features in the dissertation it is important to outline the rules of the game. Main game The main game is played by selecting a bet amount and using the spin button to start the reels spinning. The aim of the game is to match 3 symbols the same, or to reach a high enough trail that starts the feature board. The trail is added from the numbers which appear on the fruit symbols. The trail ranges from 1 to 8, which is extended to 9(Start feature), 10(super feature) and 11(Frenzy feature). The trail also has a bonus round available if the user manages to get a trail of 4. The bonus round involves selecting a bonus from a range of nudges, holds, add again and start feature by using the spin button. If you achieve nudges, they can be used to move a selected reel of your choice by one place, helping you to match three symbols. Holds can be used to stop selected reels spinning on the following round. Add again will add the trail total again, ending in a total trail of 8. Finally, starting the feature can be achieved using the number 4 bonus, or through achieving a trail higher than 8. The higher the trail number, the better starting position when entering the feature board. Feature Board The aim of the feature board is to collect the highest amount of coins, or the highest feature. In order to do this, you must spin the number reel to move around the board. Each square has an action which is written on the square, for example +1 coins, +1 features, or perhaps an extra life. Some squares however, marked with lose, end the feature board. This means each time you spin, you re gambling to try to gain extra features or more coins, but hoping not to land on the lose squares. If you came to the feature board by getting a total trail of 9 or even 10, you will find that some lights are already lit when you enter the board. If you manage to light up all of the minigame lights by landing on the minigame squares, the minigame will be started. Similarly, if you light up all of the arrow feature lights the middle feature will be started! The middle feature gives you access to move around the middle area 57

64 of the board, which has no losing squares, however there are squares which will result in leaving the super feature. Any square which is landed on can be repeated by gambling higher or lower on the last number spun. The numbers range from 1-12, however if you guess wrong then you will be returned to the main game with nothing. At any point you may collect the coins or feature, or continue moving around the board in the hope to achieve a higher payout. Mini Game The minigame which can be started from the feature board by lighting all the minigame lights asks you to pick cards from a set of face down cards. These cards add to the features or coins, until the lose card is turned. The cards are all face down so you are unaware which card has what effect until turned. When the lose card is turned over, the additional coins and features they earned are shown when returning to the feature board. You may then continue to gamble by moving around the feature board, or collect the prize. Achievements Your progress through the achievements can be seen on the achievements page, along with the details on how to obtain each achievement. The achievement will automatically be triggered when the conditions are met. At this point, you will have the option to share the achievement on your Facebook wall with a message to tell your friends! leaderboard. You can submit your score at any time by going to the leaderboard screen from the menu. The leaderboard will show you a list of the top players from across the world for you to compete with. Just select the Submit Score button to register or log in, and submit your score. 58

65 Appendix 1.5A- Survey questions and reasons Question Reason Do you own an Android Device? Check if user meets criteria If yes, which device? Find which devices are best to support / target for builds Do you use your android device for Check if user meets criteria entertainment? Have you downloaded an Android Check if user meets criteria application from the market? Have you ever purchased (Paid for) and Find out the percentage of people that may be Android application from the market? willing to pay for an application. Approximately how much would you be This is going to be used in the marketing willing to pay for an advert-free android review to decide on the best marketing game application? strategy. Are you familiar with slot machines? How in depth do any instructions need to be? Do you regularly play slot machines? Find if those who don t regularly play, would be interested in playing for free. Would you play a slot machine for As above. entertainment if it did not include any transfer of money? 59

66 Appendix: 2.2A- Top 10 selling applications 60

67 Appendix: 2.2C Sales figures and social media use Android Name Sales Price Facebook Twitter Google+ Free version Notes available? Draw 1,000, Yes No No Yes Something 5,000,000 Cut the rope 1,000, No No No Yes 5, Shark Dash 10, Yes Yes No No 50,000 Angry Birds 100, Yes Yes No Yes Space 500,000 Football 10, Yes Yes No No Manager Handheld ,000 Grand Theft 100, No No No No Auto III 500,000 Where s My 500, Yes Yes No Yes Water? 1,000,000 Cut the Rope 100, Yes Yes No Yes 500,000 Doodle Jump 1,000, No No No No 5,000,000 Fruit Ninja 1,000,000-5,000, No No No Yes Uses openfeint 61

68 Appendix: 2.2C Top 5 slot machine applications Appendix: A- Examples of JSON service JSON leaderboard Example 1 Request: for 5 results, using amount = 5 as parameter. Call: Result: [{"Username":"Bikesprocket ","Score":" "},{"Username":"shell240","Score":"301231"},{"Username":"TestUsern ame","score":"15000"},{"username":"bman","score":"10421"},{"username":"gouldson90 ","Score":"9932"}] 62

69 JSON leaderboard Example 2 Request: for 10 results, using amount = 10 as parameter. Call: Result: [{"Username":"Bikesprocket ","Score":" "},{"Username":"shell240","Score":"301231"},{"Username":"TestUsern ame","score":"15000"},{"username":"bman","score":"10421"},{"username":"gouldson90 ","Score":"9932"},{"Username":"MMouse","Score":"4405"},{"Username":"Freddy","Score" :"2300"},{"Username":"Matthew","Score":"1010"},{"Username":"Evans","Score":"1000"},{ "Username":"NutterzUK","Score":"999"}] Appendix: 3.2.4A- The eclipse debuggins tools. 63

70 Appendix 3.2.5A- Spindroid application secret and keystore hash key Appendix: 3.2.5B Shared message shown on facebook 64

71 Appendix: A- Initial Gantt Chart 65

72 Appendix: A Appendix: 5.1 A- Meta tags used on the website <meta http-equiv="content-type" content="text/html; charset=utf-8" /> This tag defines the content type, telling browsers that the content is html using charset utf-8 <meta property="og:image" content=" This tag tells social media networks such as Facebook to use the image fb_logo if the page is shared. <meta property="og:title" content="spindroid - The Android Fruit Machine"/> This tag creates the title for the page if shared on social media. <meta name="description" content="the official homepage to the Spindroid Android Application! The fruit machine for Android. Download the application from the android market or visit the leaderboards to check your progress!"> 66

73 This tag is the description which will show on search results for google, below the title of the page. As per searchenginewatch.com (2012), the keywords tag which was once used for catching keywords typed into search engines is now rarely used as it was often misused to create spam or malicious websites. The only search engine that looks at the keywords anymore is Microsoft's Bing and they use it to help detect spam. To avoid hurting your site, your best option is to never add this tag. (searchenginewatch.com) 67

74 Appendix: 5.1B- PHP code used to create the leaderboard page. <?php // set up the database variables. $user_name = "dbo "; $password = "xxxxxx"; $database = "db "; $server = "db db.1and1.com"; // start connection. $db_handle = mysql_connect($server, $user_name, $password); //select a database, returns TRUE if found. $db_found = mysql_select_db($database, $db_handle); // set number of items to show. Will show less if less results exist $amount = 100; //If the database is found, run the query. if ($db_found) { // query to run $result = mysql_query("select Username,Score FROM `Accounts` WHERE 1 ORDER BY Score DESC limit 0,".$amount); // Start counter at 1, as top score is 1st, not 0. $counter = 1; // start adding html to the page to create table. echo "<table border=\"1\" align=\"center\" class=\"leaderboard\">"; // add headings to the table echo "<tr><th>position</th><th>score</th><th>username</th></tr>"; // create a row variable as an array, to store each row of results./ $row = array(); // this loops through all results from the DB while($row = mysql_fetch_array($result){ // create a new row, of class leaderboard echo "<tr><td class=\"leaderboard\">"; // put in the counter in cell 1. echo $counter; // next cell. echo "</td><td class=\"leaderboard\">"; // put in the score echo $row['score']; // next cell echo "</td><td class=\"leaderboard\">"; // put in username echo $row['username']; // end the table row echo "</td></tr>"; // add one to the counter for next loop. $counter = $counter + 1; } // end the table. echo "</table>"; // close connection. mysql_close($db_handle); 68

75 Appendix: 5.2 Final Screenshots Menu activity Slot machine activity 69

76 Feature board activity Minigame activity 70

77 Leaderboard activity Settings activity 71

78 Achievements activity Achievement unlock example 72

79 Achievement activity showing 15k achievement. Instructions example 73

80 Appendix: 6.1A Emulator Configurations These android emulators have been selected to fill in the gaps which have not been testable using the real devices available during testing. The Desire Z has a keyboard to test, using Android 2.3. The HTC One X tests Android 4.0 and higher screen densities. The below devices are to test a range of screen sizes, android versions, and densities Emulated Device Android Screen Keyboard HTC Evo 4G *480 Density: 217 Google Nexus One *480 Density: 252 HTC Flyer *1024 Density: 170 Desire HD *800 Density: 217 No No No No 74

81 Appendix: 6.1B Test Plan This is the test plan carried out on the test devices and emulators. The beta test will work also for user acceptance which can be based on the feedback from the beta test. For all forms or options, erroneous data and edge cases should be tested. Throughout tests and for all activities the visual appearance and the performance of the application should be monitored. Results are noted in the test summary section of this dissertation. Main menu Test case summary Pre testing criteria Test Steps Expected Results Play button starts main User is at the main menu Press the play button. Music stops activity Check correct activity Slot machine activity opens started Leaderboard button starts leaderboard activity (Connected ) User is at the main menu User is connected to the internet Press the leaderboard button. Check correct activity starts Music stops. Leaderboard Opens. Leaderboard loads from database Leaderboard button (disconnected ) User is at the main menu. User is not connected to Press the leaderboard button. Suitable error handling, user returned to main menu the internet Achievements button User is at the main menu. Press the achievements Achievement activity starts button Settings button User is at the main menu Press the settings button Settings activity starts. Sound (On) Sound is turned on in the Check sound is playing Sound should play when on settings. User it on the when enabled on settings. the main menu if activated main menu in preferences Sound (Off) Sound is turned off in the Check sound is not Sound should not play on settings playing when disabled in the main menu if not the settings activated on settings 75

82 Main Game Test case summary Pre testing criteria Test Steps Expected Results Spin button User is on the main game Press the spin button. Check the reels stop in the correct order Sound(on) User is on the main Press the spin button. game. Sound is enabled When wheels stop, in the settings should play correct sound Sound(off) User is on the main Press spin. Listen for game. Sound is disabled sounds when the reels in the settings stop Nudges User has nudges function Select nudge. Repeat for available all three reels Holds User has holds function Select to hold reel. available Repeat for all three reels Hold all (extreme) User has holds function Select to hold all reels available Bonus The user achieves a 4 on the trail Stop the trail on a bonus. Repeat until all bonuses tested Trail held User has trail held Spin the reels function available Trail correctly counts User has span the main Check that all the lights game wheel are fully functioning and that the trail total is correct The reels should spin smoothly, with the first reel stopping first, followed by the second then third. Three different sounds should play, one for each of the reels when they stop When the reels stop, no sound should be played The selected reel should move by one place. The number of nudges remaining should decrease The held reel should not spin. The reels should not spin, the trail should recalculate. The bonus should apply the correct bonus as shown on the display. When calculating the total trail, it should include the last trail total with the new numbers to get the new total trail. The trail total should be equal to the showing numbers on the middle line of reles, unless a feature is activated. 76

83 Trail lands above 8 User has achieve a trail Check for trail totals of Check for each entry that higher than 8 9, 10 and 11 that the when entering the feature board starts. featureboard, that the correct number of feature lights are lit for the starting position. Feature Board Test case summary Pre testing criteria Test Steps Expected Results User can move around the User is on the feature Press the spin button. User should move the board smoothly board number of squares the same as the number the reel lands on. User can gamble hi User is on the leaderboard Press the hi button. Test for both winning and losing situations If the reel returns a higher number after spinning, the effect of the active square is repeated. If the reel returns a lower number, return to featureboard. User can gamble low User is on the leaderboard Press the low button. Test for both winning and losing situations. If the reel returns a lower number after spinning, the effect of the active square is repeated. If the reel returns a higher number, return to featureboard. Square results correctly handled User is on the featureboard Test for each of the feature squares that the correct action is applied after landing on a square The correct lights, dependant on the square should light up. If the last light of the super feature or minigame, it should start the appropriate feature. Collect coins User is on featureboard with collectable coins Select collect. Press collect in the The coins should be added to the users balance following dialog Collect features User is on featureboard Select collect. Press The correct feature should 77

84 with collectable feature collect feature in the following dialog. Test for all available features. be collected when returning to the leaderboard. The feature should run automatically. Minigame Test case summary Pre testing criteria Test Steps Expected Results User can turn over cards, The user is on the Select a card. Observe The animation should be animation is smooth minigame the animation smooth and turn all the way over until face up. Correct action applied The user is the minigame Select a card, check the The number of features of after turning over card number of coins or coins available should features increases by the increase by the same same number on the number which is on the card. card turned over. Lose The user is on the Turnover the lose The user should be minigame card returned to the featureboard with the addition of the coins and features gained from the minigame. Leaderboard Test case summary Pre testing criteria Test Steps Expected Results Register User is on the leaderboard page, has internet connection. User has not previously registered Select the submit score button. The registration dialog should open. Enter in correct details. User successfully registers. leaderboard updates and shows user in correct position. Update Score User is on the leaderboard page, has Select update score. Enter password for The score should be updated in the 78

85 internet connection. the username at the leaderboard and User has registered prompt. Select ok. refresh correctly. already. Check top 100 User is on the Select show top The table should leaderboard page, has 100 button. expand after internet connection. refreshing, showing 100 scores exist in the top 100 scores. the database. Achievements Test case summary Pre testing criteria Test Steps Expected Results Share User has met the criteria for achievement When the dialog box appears, select share. Follow the facebook flow. Post should appear on facebook wall with correct link and image. Achievements activity User has selected achievements from Select each of the achievements. Check The achievement text should be correct. the main menu the achievement text is correct for the image shown. Achievement lights User is on the achievements activity Check the achievements light up after meeting the requirements. Close the application and restart. Check the achievements still exist The achievements once achieved should always be visible form the achievements page. The user should be able to see the colour images for those that have been achieved. 79

86 Settings Test case summary Pre testing criteria Test Steps Expected Results About User is on settings page Press the about button The about dialog should appear with the correct text Report a bug User is on settings page Press the report a bug button The user should be asked which client they would like to use to send an to bugs@spindroid.co.uk. On selection, the should pre populate with the version number and short message. Sound, Vibrate, Sound Effect toggles User is on settings page Check both the active and inactive states have the described effect within the game. The vibrate function should vibrate when the user wins if active. The sounds should play on the menu if active. The sound effects should play for the reels, win, and jackpot feature if active The correct sounds and vibrate functions work dependant on the settings selected on the settings activity. 80

87 Appendix: 6.2B Real test devices. Device Android Screen Size Resolution Processor Memory Version HTC Hero Inches 320* MHz 288MB Single core HTC Desire Inches 480* MHz 512MB Z Single core HTC One X Inches 720*1280 Quad-core 1GB 1.5 GHz HTC Sensation XE Inches 540*960 Dual-core 1.5 GHz 768MB Appendix: 6.4C Download rate from android market. Appendix: 6.4A- Browser Statistics by Month, provided by w3c. 81

88 Appendix: Emulator test results Problem found Environment Resolution Slow performance Android 3.2.3, large screen size Attempt to reproduce on real device. Could not reproduce, emulator slowness is a known Android problem. Can get nudges, then hit the bonus and win holds, ambiguous buttons act for holds and nudges. Not environment specific Make it so that it is not possible to get holds if the user has 1 or more nudges remaining. Superfeature images showing incorrectly when moving around the board (highlighted) Not environment specific The images have been entered into the array in the wrong order, fixed the ordering of active images. Spin button is disabled when spinning, but then does not become enabled after spin is finished. Not environment specific The spin button becomes enabled when the number of reels left spinning is equal to 0, rather than when the third wheel stop spinning. This was an issue caused by holds or nudges, if the third wheel was held. With the screen sizes varying so much within the x-large (tablet ) category, even with a unique layout for tablets, some larger devices still stretch images and look pixelated, or miss place images. HTC Flyer emulator configuration, HTC Excite (expected) emulator configuration It was expected that tablet versions should work well with a unique layout file for x-large screens. However the large range in size within this category means that the layout needs to be redesigned to allow stretching. The initial solution was to create separate layouts as suggested by the Android 82

89 developers guide, but further work into the appearance on the larger screens needs to be done. This is added to the further work section, and until fixed the tablet devices will not be supported. Progress has been made on fixing this issue but due to the requirement for much larger images this screen size will require a redesign for optimal visual appearance. Appendix Real device test results Problem Found Environment Resolution The hold buttons are too small HTC Desire Z Increased the size of the hold buttons. The activity restarts when the HTC Desire Z Disable landscape mode using phone changes orientation the manifest file which specified activity properties. The activity starts when the hardware keyboard slides out HTC Desire Z Disable keyboard changes using the manifest file. Takes too long to show HTC One X Add a loading dialog to the leaderboard, screen appears to async task responsible for freeze loading the leaderboard. Everything seems too small HTC Hero No possible solution, correct sizes shown but the device screen is relatively small. Resolution is to disable small screens for beta testing, support will need to be added after a 83

90 Vibrate function does not work when win is triggered HTC Sensation XE possible re-design. Add permission to vibrate to the manifest file. This was missed on emulator testing due to not having a vibrate function. Appendix: Beta test results. Problem found Environment (If known) Resolution When numbers make up a run on the win line, for Version Number 8 This is not a bug and is expected behaviour per the example 4,2,1 (7), if the user physical machines this nudges one number off the project aims to emulate. screen the total trail reduces, However this shows that the for example if the 1 is users may benefit from nudged away, the total is instructions on the main now 6 game as well as on the feature board. Instructions added along with Info button. Collecting jackpot feature did not add on the winnings but did say in the display the Version Number 10 For the jackpot feature, the call to setwin(int credits) was missing. This has been amount that should be added. credited System hangs mid spin Version number 9 As this is based on a heavily Running CyanogenMod's modified operating system nightlies(custom ROM ) Galaxy S II Modified Kernal to add root and CWM and not the default Android system, this is difficult to reproduce. Only one report of this out of 111 devices show whilst this is a big problem it is not happening for most 84

91 Crash on super feature, not sure of cause Version 9 users. Further research and perhaps a rooted real device is needed to find the cause of this issue. This will be added to further work. This was found to be an issue which makes it possible to cause an out of bounds exception when searching for the super feature images after moving around the board fully once. 85

92 Appendix: 7 Feedback from beta users. 86