Utökning av ett Spelkoncepts
Omfattning Genom Anpassning
för Mobila Plattformar
Mathias Bergqvist
Utökning av ett Spelkoncepts
Omfattning Genom Anpassning
för Mobila Plattformar
Examensarbete utfört i Datateknik
vid Tekniska högskolan vid
Linköpings universitet
Mathias Bergqvist
Handledare Karljohan Lundin Palmerius
Examinator Matt Cooper
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –
under en längre tid från publiceringsdatum under förutsättning att inga
extra-ordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida http://www.ep.liu.se/
Copyright
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page: http://www.ep.liu.se/
This report is a documentation of a master’s thesis work made at Linköping Uni-versity. It features the technical fundamentals, implementation, results and discus-sions within the field of mobile application development in the game industry. The thesis explored the game industry from within the industry, as the purpose was to further expand the game concept of the PC game theHunter by using a mobile plat-form.
In the age of the multi-touch smartphone, applications are a huge and competi-tive industry with many interesting development approaches. Using the fundamen-tal principles of system architecture and interface design for mobile development, a game companion application based in an Android environment was developed. Game data was provided by the game development studio Expansive Worlds. The results showed support for the platform, but clearly states that further development is needed to actually explore the mobile market further. Implications for the results of the study and future tasks are discussed.
1 Introduction 1 1.1 Purpose . . . 1 1.2 Method . . . 2 1.2.1 Project Planning . . . 2 1.2.2 Choice of Platform . . . 2 1.2.3 Implementation . . . 3 1.3 Limitations . . . 3 1.4 Report Structure . . . 4 2 Background 6 2.1 Related Research . . . 6
2.2 The Mobile Market . . . 7
2.3 Mobile Applications . . . 7
2.4 Game Companion Applications . . . 8
2.5 The Mother Game . . . 8
2.6 Free To Play Games . . . 9
2.7 End User . . . 9
3 Mobile Development Fundamentals 11 3.1 Multi-Touch Environments . . . 11
3.1.1 Fingers As Input Device . . . 12
3.2 Designing For Small Screens . . . 12
3.3 Design Considerations For User Interfaces . . . 13
3.3.1 Accessibility . . . 13
3.3.2 Feedback . . . 13
3.3.3 Visibility . . . 13
3.3.4 Colours And Fonts . . . 14
3.4 Acquiring Data . . . 14
3.4.1 Static Data . . . 14
3.4.2 Server Data . . . 14
3.4.3 Internet Resources . . . 15
3.5 Working In The Background . . . 15
4.1.1 The Presentation Layer . . . 17
4.1.2 The Object Layer . . . 19
4.1.3 The Data Access Layer . . . 19
4.2 Managing Activities . . . 19
4.2.1 The Application Manifest File . . . 21
4.2.2 Intents . . . 21
4.3 Server Connection . . . 21
4.3.1 Receiving Data . . . 22
4.3.2 Error Handling . . . 22
4.4 Login Session Management . . . 23
4.5 Runtime Sequence . . . 24
4.6 Implementing A Map Interface . . . 26
4.6.1 Google Maps Application Programming Interface . . . 26
4.6.2 Using A Custom Map . . . 26
4.7 Managing WordPress Data . . . 26
4.8 Loading Images . . . 27
4.9 Navigation . . . 27
4.9.1 Main Navigation Menu . . . 27
4.9.2 Action Bar . . . 28
4.9.3 Options Navigation . . . 29
4.9.4 Bottom Page Navigation . . . 29
4.10 Push Notifications . . . 29 4.11 Development Methodology . . . 32 4.11.1 Debugging . . . 32 4.11.2 Testing . . . 32 5 User Interfaces 33 5.1 Prototyping . . . 33
5.2 Mobile User Interface Patterns . . . 33
5.3 Design Components . . . 34
5.3.1 Colour Scheme . . . 35
5.3.2 Icons And Images . . . 35
5.3.3 Fonts . . . 36
6 Results 37 6.1 The Implemented System . . . 37
6.1.1 Architecture . . . 37 6.1.2 Data Management . . . 38 6.1.3 Session Management . . . 38 6.1.4 Graphical Profile . . . 39 6.1.5 Notification System . . . 39 6.1.6 Managing Maps . . . 39 6.2 The Application . . . 39 6.2.1 Player Statistics . . . 40
6.2.4 Game Interaction . . . 40 6.3 Application Performance . . . 41 7 Discussion 42 7.1 Result Discussion . . . 42 7.2 Usage . . . 43 7.3 Further Work . . . 43 7.3.1 Distribution . . . 44
7.4 The Future Of Game Applications . . . 44
8 Conclusion 46 A Prototypes 50 B Content Overview 57 B.0.1 Navigation . . . 57 B.0.2 Login . . . 57 B.0.3 News Feed . . . 59 B.0.4 Profile Pages . . . 59 B.0.5 Friend Pages . . . 61 B.0.6 Messages . . . 61
B.0.7 Bear Bait Manager . . . 63
B.0.8 Bait Purchasing . . . 64
B.0.9 Notifications . . . 64
Chapter 1
Introduction
When the multi-touch interface smart phone first was introduced to customers, the market for mobile applications quickly took a dramatic turn. Public exposure of the interface was a fact with the successful release of the first generation iPhone, developed by Apple Inc., in 2007 and was ever since been a market standard.
New software built exclusively for the most popular mobile operative systems are currently being published frequently. The condition of the mobile application market at current date is great, and mobile applications shows no tendency in lack of popularity whatsoever. Applications in the form of games are especially popular, which can be observed just by looking at the section for the most downloaded and purchased applications on mobile software stores.
This master’s thesis will explore the possibilities of taking advantage of the mod-ern mobile market to increase the popularity and versatility of a console based game by using state-of-the-art technology for development of a mobile companion appli-cation. It was made at the program MSc in Media Technology and Engineering at Linköping University.
1.1 Purpose
The main focus for this master’s thesis was to research successful ways to transfer a game concept from a PC based environment to a portal device environment. Find-ing out how to make use of the advantages that this specific format acquires was a big part of the research, but it was also important to realise the limitations of it and find cleaver ways to implement software technology. The main research questions of the thesis is shown in the list below.
• How can an already successful game concept be expanded to a broader audi-ence using smart phone technology?
• How does a mobile platform give a new dimension to an already existing game? • How can you take advantage of the exclusive benefits of the smart phone to
• How do you optimize a mobile interface so that it minimalistic but still rich in content?
• What type of feature could be implemented to make the application stand out in today’s mobile market?
The purpose of the development was to build a game companion application for multi-touch mobile devices by using state-of-the technology and data from a game studio. To do this from scratch, both an architectural model for the code and a graphical design for the GUI needed to be implemented. The aim was to expand the game concept of the game theHunter by adapting the game to portable devices.
1.2 Method
This master’s thesis is done in cooperation with the game development studio Ex-pansive World, which is a subsidiary of the game development studio Avalanche, as an extension and a complement to the re-launch of the popular game "theHunter". The whole development process took place at the Expansive Worlds HQ office in Stockholm, Sweden. This choice was made simply for the purpose of getting max-imum amount of feedback from the development team and the supervisor at the office. It was also important to be able to discuss ideas and questions that came up during the project. The time period for the master’s thesis was approximately twenty weeks.
1.2.1 Project Planning
During the start up phase of the thesis work, a lot of time was spent doing research on mobile development and platform tool usage. Finding reliable resources of in-formation early on in the process was valuable for the further process of the project. The literature mentioned in Chapter 2 and Chapter 3 was used as a base for the studies. Also, the article series in [1] by Cornelius was a great reference for starting to build up Android programming skills.
The base for the system architecture and prototypes for the user interfaces, fea-tured in Appendix A, was made during this early phase as well.
The concept of the product backlog, as proposed by Schwaber and Sutherland in [2], was used during the project planning. It is a ordered list of everything that might be needed in the product. The project was broken down into different sub tasks to better decide how to approach the implementation. The sub tasks was used to formulate user stories for the project backlog, which became backlog items. The backlog items was ordered by priority.
1.2.2 Choice of Platform
To approach development for portal devices, the mobile operative system Android was chosen as platform. The choice of platform was decided by the amount of pop-ularity and impact Android has on the mobile market. This is discussed further in
Section 2.2. Also, the availability of hardware components and earlier experiences with Android development was important faces to support the development. Fur-thermore, the application programming interface of Android is well documented and it is easy to find both literature and internet resources that facilitates the imple-mentation process.
The application developed is a native application. A native application is down-loaded and installed locally on the phone device. The alternative to the native de-velopment approach would be to create a web application, which runs in the mobile web browser.
The choice of developing a native application instead of a mobile site was much due to the fact that this format, in general, is preferred by users. In a research study made by Nielsen and Budiu in [3], it is clear that users prefer the particular format of the application above the mobile web site. Users simply performed better with the application format and found it easier to use. The success rate of the mobile application was 74 percent and 64 percent for the mobile web page. Success rate in this case means that the test users was able to preformed the task given in a proper manner. Other advantages with using the native format is that the Android API tools can be used to construct the application, which is something very advantageous for development purposes. Also, some built-in phone functions such as push-messages cannot be used on a mobile web page.
1.2.3 Implementation
Android applications are implemented using the Java computing language. Except for Java, additional languages used during the implementation was the markup lan-guages XML and HTML, the style sheet language CSS, JavaScript and the data inter-change format JSON. The API used was the non-public theHunter API provided by Expansive Worlds, the official Android API and the public API’s of Google Maps, and WordPress JSON.
The development was made using the multi-language integrated development environment Eclipse. Eclipse supports Android development by installing the An-droid Development Toolkit (which includes necessary platform tools and a built-in emulator execution component) plug-in, and is therefore an advantageous choice.
The code was backed up by using the version control system Git. Image process-ing and image editprocess-ing was made usprocess-ing the open source image editprocess-ing tool GIMP.
1.3 Limitations
Developing a mobile application for the specific platform of Android, directly results in the obvious limitation of the software being unavailable for mobile platforms not running the Android operative system. The most notable operative system being left out is the hugely popular iOS, developed by Apple. While a cross platform solu-tion for both Android and iOS usage would be possible, this was not a solusolu-tion being considered for this master’s thesis. This decision was made early on in the process,
the main reason being that the research sources was more extensive for native ap-plication development.
In addition to operative systems, the application will not be developed for com-patible usage with the popular multi-touch platform touch tablets. The implemen-tation of the application was limited down to only one type of platform due to both time consuming reasons and to limit the research of the thesis work to only con-cern mobile platforms instead of all multi-touch-related platforms. While there do exist touch tablets on the market that does run the Android operative system, the user interface developed for a mobile unit will not be the optimal choice for a touch tablet.
Limitations concerning the content of the application includes features that would require support usage of the game client. The game client is independently imple-mented by the client development team at Expansive Worlds. Therefore such a fea-ture would require support development, which was not an option for this master’s thesis, as this project had to be single-handedly developed.
1.4 Report Structure
This report will be divided into several parts, which will serve as the foundation of the study itself. The reader will first be introduced to the very basis and techni-cal fundamentals of the research. Further solutions, technitechni-cal implementations and details will be presented as the reader progresses. The chapters of the report is struc-tured as follows:
• Background
• Mobile Development Fundamentals • System Implementation
• User Interfaces • Results • Discussion • Conclusion
The background chapter will introduce the presumptions for the whole project and gives motivation behind the further work of this master’s thesis.
The fundamentals of mobile development is important for understanding the base of the implementation, and will therefore be explained in a separate chapter.
The system implementations chapter is an overview of how the actual applica-tion was implemented. It will display the system architecture, code structure and data management and give runtime examples.
User interfaces is a essential part of building an mobile application. This chapter will present UI patterns and design components used during the implementation.
The results chapter will present the final content of the mobile application and further statistics about performance.
In the discussion chapter, the process and results of the thesis will be analysed and the authors own thoughts about it will be emphasized. Usage and further work will also be discussed.
Chapter 2
Background
Mobile applications for multi-touch environments is a software development area that is relatively new compared to traditional PC-based software development. Least to say, software for this specific format is developed at high frequency at today’s date and mobile users are nearly overexposed with newly released third party software.
For developers, new frameworks and development solutions for mobile usage are also being released at high frequency, as well as new hardware that continues to push the limits for the performance of mobile phones.
2.1 Related Research
This master’s thesis is based on research questions about the concept of game com-panion applications. While there are several such mobile applications released on the market, there are not that much documented research results to be found on this quite new area.
However, application design and mobile usability are also a huge part of this master’s thesis and a lot of the of the research is based on studies on mobile user ex-perience made by Nielsen and Budiu in [3]. Nielsen made two separate diary studies to better understand the range of activities that people perform with their phones. Selected people from different countries and with various phone devices was given test cases to perform and usability problems that came up was taken into notice. Except for usability-testing sessions, additional interviews with the same audience was performed.
The article series on mobile applications development and the era of the smart phone, publicised as online course literature for the course "Excel with business -App Design", by Stevens in [4] was also one of the main influences and guidelines when going in to this project. The articles are based on research about success and failure in the mobile market during the latest couple of years. Concepts and devel-opment strategies are discussed from a developers point of view. Successful appli-cation design and promotion strategy’s are also discussed.
2.2 The Mobile Market
This brief introduction of the mobile market is based on facts from the article series in [4] by Stevens. The mobile market at today’s date is dominated by the multi-touch smart phone. In western civilization, a large part of the adult population own a smart phone and the numbers are constantly increasing among the younger population and third world countries as well.
Among smart phones, only two platforms dominates the market: iPhone and Android. The iPhone series and it’s operative system iOS are developed and pub-licised exclusivity by Apple, while the Android platform is used by many popular hardware manufacturers such as Samsung, Sony and HTC. Android is a linux-based operative system that is open source, which means that it is free to modify and dis-tribute among manufacturers. This, along with the fact that it is licensed though industry giants Google has made Android highly popular.
Even though there are many types of phones running Android and many differ-ent versions of the operation system floating around, there are still many similarities between two platforms. Even if the users changes phone device often, they will feel somewhat familiar. This, of cause, results in great rivalry between the two platforms. However the rivalry is not only a bad thing, as the developers will push each other to make as great products as possible. This is a fact both for software development and hardware development.
As today’s data, the sales of Android based devices has overrun the sales of iPhone devices. According to measurement made by Lundgren in [5], Android’s share of the global smartphone market is 64 percent.
2.3 Mobile Applications
Mobile applications are software features pre-installed or downloaded to the smart-phone. The application market is huge at the moment and many large corporations spend a lot of time and money on developing applications, according to Stevens in [4]. Applications can be purchased at a fixed price or free to download from App Store on iPhone devices and the corresponding Google Play Store on Android de-vices. The application stores are somewhat of a maze to explore, so most users won’t discover new applications simply through those. More likely, users will hear about new applications word-to-mouth from friends or through press coverage and ad-vertisement. Social media and online networks play a major role in the marketing process.
The purpose and category of applications varies a lot. Some applications are stand-alone applications like an alarm clock or a digital calculator, while some ap-plications are used as support feature to a web site, a company or, which is the case for this master thesis, a game. Some applications will even integrate with other soft-ware like the virtual keyboard or the e-mail client.
Because of the open application programming interfaces and simple distribu-tion through App Store or Google Play, there are tons of third party applicadistribu-tions sup-plied as downloadable content for smart phones. There is a huge difference between
traditional software development and application development for the mobile mar-ket. Indie development is huge, which can be seen just by taking a look at top list of the most popular application on the application stores. Some of the most successful applications are made by small development teams consisting of e.g. family mem-bers or close friend with no major corporation development experience, according to Stevens in [4]. Applications that are cheap, or even free, have earned millions of dollars of revenue that would otherwise have gone to the traditional big companies. This is especially the development when it comes to the game genre, which is the most popular genre of all mobile applications.
Although the reward for a successful application release is huge, the probability of failure is big. Mobile users are not very tolerant and if they do not like an applica-tion, they will spread the word all over the internet and tell their friends. A great idea and a well performed implementation is not enough to guarantee a successfully re-lease. That is why mobile application development is hard, but the reward can be huge for the lucky few that will succeed.
2.4 Game Companion Applications
The genre of the application developed for the master’s thesis is called game com-panion application. The definition of game comcom-panion application are software applications developed for mobile devices or tablets that are with the purpose of versatile the gaming experience and enhance the in-game data in meaningful ways, according to Sainsbury in [6]. Often, companion applications are made to coincide with the release or a new update of a major console game.
There are a couple of benefits for games that has companion applications. Pay-ers that are committed to the game can use the extended format to further increase in-game development using features that exceeds those of traditional game con-soles. Also, marketing purposes plays a major role. The broad distribution of the application format would encourage mobile and tablet users to checkout the full console version of the game. From an economical point of view, applications dis-tributed via the popular application stores Google Play and App Store provides sim-ple transactions for buying the software and in-game purchasable items.
2.5 The Mother Game
The mother game of which the application developed in this master’s thesis is a complement to is called "theHunter". TheHunter is a free to play pc game developed and published by Expansive Worlds game studios is Stockholm, Sweden. Game in-formation is available at [7]. It has approximately 1,5 million unique registered users world wide. This number continues to increase at a steady rate during current date. The game mixes game play elements of role-playing games, first person shooter games, and open world adventure games to create a unique and diverse hunting game. Capturing the realism of a real hunting experience is an essential feature of theHunter.
The game can be viewed upon as a pure hunting simulator, where the player (or multiple players in the supported multiplayer game play mode) walks around in a forest environment trying to find and take down different animals using various weapons and gadgets. The world is viewed from a first-person perspective. The player can choose one of multiple hunting reserves to start a new hunting trip in. Each reserve has a different, unique environment and a different set of huntable species. The game is based in an immersive, online world developed using state-of-the art technology. The graphics engine developed by state-of-the game studio Avalanche is used to create the game play and the game world.
While the hunting simulation plays the major role in the game, it also features character development, character customization and various competitions and mis-sions to attend. This gives depth to the game and keeps old players coming back as well as bringing in new ones. There is also a social aspect to the theHunter, as the players are able to connect to each other using messages and profile pages.
Platform wise, the game is based on two dependent interfaces. The client inter-face is installed locally on the users computer and the other interinter-face is a web page, available at [7]. The web based interface handles all the character configuration and customization as well as statistics, user interactions and purchases. New hunts are also started from the web page. The hunt itself and the actual game play is handled in the game client.
2.6 Free To Play Games
TheHunter is based on a business model for online games called Free To Play. Free To Play means that the user is not charged when joining or downloading the game. The profits of the game often comes from commercials or in-game sales of new game content. Instead of releasing a game with static content at a set price, free to play games often keeps evolving throughout development and new content is featured through downloadable update patches. This way, game designers are able to create multiple games on the same platform and focus on expending the content.
Free to play games has been increasingly popular in the last couple of years, es-pecially on the mobile application market. The business model made up 80% of the total market in 2012, according to LeJacq in [8].
2.7 End User
As this master’s thesis is focusing on creating a companion application for a game that is already published on the market, the main target group for the application are users that are already registered players of main game theHunter. While the content of the application itself is not intended to be a game from the traditional point of view, it will support features of a game.
One of the primary concepts of theHunter is to encourage an audience of people that may not usually be very interested in video games to play the game. This is because of the content being related to hunting. Hunting is a huge business and
enjoyed world wide by people in various aged. Real life hunters is one of the main target groups for the game theHunter. Of course, the game is also developed for people that in general takes an interest in video games and enjoys the type of game play that it provides.
Chapter 3
Mobile Development
Fundamentals
To build a great mobile application, both the underlying code and the application design are essential components. To know what the audience expects from a mod-ern day market application is important. There are constantly new development approaches and techniques being released, so the mobile development market is changing frequently [4].
This chapter will introduce some of the most fundamental principles for build-ing applications for multi-touch environments. The informations is based on stud-ies on mobile usability by Nielsen and Budiu in [3], the mobile application market by Stevens in [4] and the evolution of multi-touch devices by Buxton in [9].
3.1 Multi-Touch Environments
A touch device can be characterized by a heat or pressure sensible screen, which is used to register inputs from the user by using either his fingers or a pointing device. Screens with multi-touch sensibility are able to register inputs from more than one specific point at the screen at a time and thus allowing the user to use e.g. multiple fingers at the same time.
While the technology behind multi-touch hardware has been around since the late 80’s [9], it is not until the last decade that the technology was launched to the mobile market. Since the introduction of the first generation Apple iPhone in 2007, it has grown to become the industry standard. All of the most successful manufac-turers are currently using the multi-touch technology in theirs most popular prod-ucts on the mobile market. Figure 3.1 shows an example of a multi-touch mobile phone.
Figure 3.1: The Apple iPhone 5 is an example of a multi-touch smart phone.
3.1.1 Fingers As Input Device
When designing for mobile it is important to emphasize the strengths of fingers as input device, but also to be aware of the weaknesses that comes with it. The most common problem user will encounter is struggling to tap a tiny area that is much smaller than their fingers. This "fat finger"-problem is something that must be taken to account when designing interfaces. It is tempting to make touch targets small to save screen space, but this will instead result in a bad user experience. But instead it is important to think about the abilities that matter in the interface like the size of the area touched, single finger or multi finger input and touch target visibility.
User results form a research made by Nielsen and Budiu in [3] shows that typ-ing ustyp-ing the virtual keyboard is one of the thtyp-ings that users dislikes the most about multi-touch interfaces, as it often results in awkward results. It is therefore impor-tant to try to minimize the typing needs.
3.2 Designing For Small Screens
For a device to be considered as mobile, it must be easy to carry and thus relatively small. Even though manufacturers tend to make the screen size larger for each new mobile release, there has to be a limit to how big it can be. If the screen get too large, the device will be more considered as a touch tablet than a mobile phone.
On a smaller screen, the users must move around the page more to view the page content. As the horizontal space on a small screen is very limited and horizontal list scrolling scrolling equals bad user experience, a common way of displaying content is using vertical lists. This will result in scrolling problems. Nobody wants to scroll through a list of similar items if each item comes with a lot of details. That is why it is important to enhance the scannability by removing unnecessary information and adding visual content as images and highlighted keywords. Except for structure visual interest is also of essence.
3.3 Design Considerations For User Interfaces
There are a couple of rules of thumb to be considered when designing GUI for mo-bile applications. As momo-bile usability are getting better and better, the appearance of the interface is very important for the success of the product. All major software distributors spend lots of time and money on design [4]. Simply to say, mobile ap-plications need to look nice and be functional at the same time. Above everything else, the most important thing to remember is to keep the GUI from being overly complicated. The usability will be much enhanced by keeping it simple.
The design considerations in section 3.3.1 - 3.3.4 are all features that users find to be important as a result of a usability research in [3].
3.3.1 Accessibility
All pages in the application needs be easily accessed. It should not take many in-teractions to get from one page to another and the page hierarchy should not be too deep. Designers need to make sure that the main navigation menu is easily accessed and and that every navigation option given is relevant to the context. Common ways of displaying the navigation menu for easy access is at the bottom of the screen or in relation with the action bar at the top of the screen. Older versions of the An-droid API also supported the AnAn-droid menu button, located at the bottom left of the phone, for application navigation.
The main functionalities of the application needs to accessed easily for users not to be confused. Most smart phones have a physical button for easy navigation to the desktop screen. In the same manner, a similar "home" screen of an application with easy access could be very beneficial. That way users could always return to a familiar interface if they get to lost in the page hierarchy.
3.3.2 Feedback
Giving feedback to the user navigating the GUI is of great importance. When the user e.g. has clicked on a button or selected an option in a list view in the interface, some sort of visual feedback needs to be added that verifies this action. This may seem habitual, but it still crucial to not make the user confused. To all possible actions that could be performed in the interface, there should be a corresponding response. Even if the user performed a bad action, feedback should be displayed.
3.3.3 Visibility
It is important to highlight important content in the user interface and to not hide essential information. If an item (e.g. a hyperlink) is clickable, it should be clear just by viewing the page. The user should never have to wonder if he could interact with an item or not. By using familiar icons and figures in the right context, interface elements could enhance their visibility. Images could also be used to achieve the same effect. Patterns like list views and carousel side-scrolling patterns are great to make the user feel recognisable when viewing the interface.
3.3.4 Colours And Fonts
Using colors schemes in an appropriate way is very important. The whole visual appearance of the GUI is highly dependent on the colours used. The color scheme will make the whole application recognisable. Changing color scheme also changes the feeling of the application. The color scheme needs to be consistent and not change in different sub pages, as this would result in confusion. It is also important that the color scheme only consists of a limited amount of color shades as too many color would make the interface seem messy.
Colours that are in contrast to each others is an effective way of making page content stand out. Alert colors like red can be used for clarification. For dark coloured text to appear readable, the background needs to be light coloured and vice versa. Often, it is also beneficial to use sans-serif fonts when displaying interface text on a virtual screen. Users tend to find this more readable as in oppose to serif fonts, which are often used in physical books, newspapers and magazines. Except the colour of the text, the size and typeface of the font is also important. If the text is displayed too small or awkward looking, users will have a hard time reading it. As a lot of the content in an application often consists of text, this could be very fateful.
3.4 Acquiring Data
Most applications on the market are based on data collected from a server, so the acquisition of the data is essential. Regardless if the application is based on user generated data or not, server data is likely to be featured. There exists tons of ways of formats and standards for collecting data using server mark up computing lan-guages, so it is impossible to point out any standards.
3.4.1 Static Data
Static data in this case means non-server data used in an application like text strings and images. While data like this can be stored on a server (images are often accessed through URL hyper links) it can also be stored locally. XML (Extensible Markup Lan-guage) spreadsheets are a popular way of storing text data for easy access and often used during mobile application development, as presented by Meier in [10]. This data does not need to queried and no internet access is needed. Static date is there-fore beneficial in many situations where the data displayed is not user dependent.
3.4.2 Server Data
Data stored on a server needs to be accessed by using an internet connection and the data needs to queried. The database management system is designed to store, organize and remember the relationships between various pieces of data. Servers comes in different types and sizes and handles all the connections with the database. To communicate with the server, it is needed to use the language that it understand. Different type of servers uses different languages like e.g. SQL or Ruby.
AB BCBD
EFF BD AB B
AB B
Figure 3.2: The relation between the client (phone), the server and the database
In figure 3.2, an example of a server-client relationship is displayed. In this case the client is a smart phone running an application. An application script is executed on the client which makes request to the web server. To fetch the data, the client needs to be connected to the web server. The web server processes the application request, runs the script and returns content to the client. The web server typically runs along a database server, which sometimes are the same server, which reads and writes data to and from the database.
3.4.3 Internet Resources
When programming applications for mobile devices, developers will use different API specifications. The API will specify how a specific software component can com-municate with another software component by function calls. Both Android and iOS development take usage of separate API’s, which can be found as internet resources. Some software companies like e.g. the social networks Twitter and Facebook provide developers with open AIP’s, which can be found as internet resources. By using these kinds of resources, developers can acquire data without having to host a database server by their own. Often, the data will be available by just using a URL hy-perlink. By offering an open API, software distributors are providing non-company people with free usable data, but in return it could be very beneficial to let third party developers expand the ways of distributing the software.
3.5 Working In The Background
When developing for mobile, one of the most important things to have in mind is to move time-consuming processes onto the background. To ensure that the applica-tion response quickly to user interacapplica-tions or system events, moving the process to the background is trivial.This means that the processing of data (e.i. interacting with the server) will be made asynchronously. An example of working in the background is shown in Figure 3.3. The UI will be updated with content when it is captured with-out actually having to reload the page.
A solution for working in the background for Android application development is using threaded coding, as presented by in [10]. There is always one main
appli-A B
C DEFF
B
EC F B C F F
Figure 3.3: Sequence diagram showing a basic example of threaded coding.
cation thread where all the components like interface activities, services and broad-cast receivers start. Background threads is used for any non-trivial processing that doesn’t directly interact with interface like network lookups and database transac-tions. The synchronization of the main thread with background threads lets the ap-plication update views and other interface elements when the background process is complete.
3.5.1 Threaded Coding
Figure 3.3 shows an example of threaded coding in which the user presses a button on the phone device and the graphical user interface of the application gets up-dated. The phone loads data from the logistics by performing an asynchronous task in a background thread. The user can still use the phone interface for interaction, even though the page is not yet updated. The update will not cause a page reload or disturb the user from other interaction.
Chapter 4
System Implementation
This chapter will describe how the Android application "theHunter game compan-ion applicatcompan-ion" was implemented. The applicatcompan-ion itself was the main part of the master’s thesis and the implementation was the part that took the most time and ef-fort to finish. Developing this software for Android devices took a lot of architectural planning and data management, which will be displayed in this chapter. A lot of the implementation is influenced by material presented by Meier in [10].
4.1 System Architecture
The main architecture of the application is based on multiple layers to separate the representation of information from user management. The three layers used are: The presentation layer, the object layer and the data access layer. This is based on a architecture model called Three Tiers, presented by Eckerson in [11].
The idea behind the model is displayed in Figure 4.1. The mobile device holds the application code, which is represented by the blue, green and red figures. The yellow coloured figures represents web actions. The server is connected to the database and the client the way the matter is discussed is Section 3.4.2. Without internet ac-cess, these methods cannot be performed.
4.1.1 The Presentation Layer
The presentation of data is the topmost layer in the hierarchy and consists of activ-ities and interface helpers. Activactiv-ities in Android environments is what displays all the information and makes up the GUI. This is the layer that the user can access and interact with directly. All outputs are presented visually in this layer.
The communication between the activities and the controller classes are made asynchronous (in a different thread the way the matter is discussed in Section 3.5) through different data loading calls in the controller classes. These are made when a page is loaded or a user has interacted with the interface in such a way that new data needs to be loaded. Often, the data received from the object layer is in the form of a
A B ABCD E F FF CDE F A B FF FF A B C F BC FF C C C ! "# C $ $ % F $ $ C & F ' C ( "C
Figure 4.1: The layered system architecture of the application. This is the resource hierarchy of all files used in the application.
object list. The list contains items from the object structures. By letting the activities access these classes, object properties like e.g. the name of an animal or the price of an inventory item can be accessed easily and presented directly in the interface.
The helper classes are used to structure the interfaces of the activities and to handle external processes like checking for internet connections and managing alert dialogue windows.
4.1.2 The Object Layer
The object layer is where all the application functionalities and services is controlled. This is also the communications layer, which translates user interactions into server interactions by using controllers, which can be seen in Figure 4.1. All the processing between the two other layers is made in this layer, as the presentation layer never is allowed to communicate directly with the data layer. By passing all the communica-tions though the middle layer, the the system communication becomes linear.
When the data from the data access layer is received by the controller classes, it is in the form of a text string containing JSON data. The controller classes converts the string to lists or a single item of object structured classes and return it to the activities to be visualised. This is done by managing JSON data using the Java classes
❏❙❖◆❖❜❥❡❝tand❏❙❖◆❆rr❛②.
The object structures, also called models, are classes like e.g.❯s❡r,❆♥✐♠❛❧and
■t❡♠, which defines the structure of the objects used in the application. The con-trollers uses the models to send structured data classes back to the activities, which use those to display the data.
4.1.3 The Data Access Layer
The data access layer consists of database services. Information is stored and re-ceived here. The application uses a non-public API service for server communica-tions, which is marked as internet processing (IP) in Figure 4.1. For communications with the theHunter API, a special RPC class is used. The controllers in the object layer calls the❝❛❧❧✭✮method in the RPC class with the corresponding parameters. The RPC class then handles all the http connections and transfers the data back to controllers in JSON string format. This way, the data is kept independent. The data access process is explained more in detail in Section 4.3.
4.2 Managing Activities
The implementation of the presentation layer in Figure 4.1 is built around exten-sions of the Android❆❝t✐✈✐t②class. Activities use views and fragments to layout and display information and to respond to actions processed by the user. Each ac-tivity represents a screen that is presented to the use. The acac-tivity includes the inter-face design and handles the main UI functionality of the application. All the event handlers like onclick functions for buttons and drop down fields are handled within the corresponding activity class.
ABC
D E
ABC
F
ABC
E
A
EB
A
B
ABC
ABC
D E
ABC
F
ABC
BBB
BBB
BBB
In Figure 4.2, the structure of the activity management is displayed.
The❇❛s❡❆❝t✐✈✐t② Java file extends the❆❝t✐✈✐t②class and all other activi-ties in the application extends this super class. The❇❛s❡❆❝t✐✈✐t②class handles several options that are inherited by the sub classes. Connection detection, nav-igation management, action bar actions and notifications are all managed in the
❇❛s❡❆❝t✐✈✐t②. Each time a page is loaded, the update check in the❇❛s❡❆❝t✐✈✐t② is loaded first. A lot of the functionalities in❇❛s❡❆❝t✐✈✐t②, like e.g. the main navi-gation, are done in the same way regardless of what page is loaded.
Each activity defines the GUI by assigning a layout file connected to it, which is displayed in Figure 4.2. Layout files are based on an XML structure and stored in a separate recourse folder. Each layout file contains layout controls classes, provided by the Android API, making it easy to create a dynamic interface. The layout controls are then managed in the activity file. Except from a page layout, resource files are also used for storing static data (see Section 3.4.1) like text strings and colour values.
4.2.1 The Application Manifest File
Each Android application includes a manifest file that defines the structure of the application. This file is also based on an xml structure. It is stored in the root of the hierarchy and includes notes for how the activities, layouts, services and content providers are related to each other and will interact. The manifest file also specifies the metadata of the application. The metadata is information such as the API level required to run the application, the theme it is based on and the icon used on the phone desktop. Further, it also hold information about the permissions used. For this implementation, internet permissions was used for the application to be able to receive data from the server and push notification permissions is used to be able to provide the user with that particular feature.
4.2.2 Intents
Intents are used in the application to move between screens and to start up new activities. It is a widely used and powerful interapplication message-passing frame-work. Extra information in form of strings are often passed through intents. This feature is used to e.g. tell which user the profile page visited belongs to. Intents are also used to request an particular action to be performed on a particular piece of data. Starting a new intent automatic ends all actions of the current page being viewed and browses the new page.
4.3 Server Connection
The RPC class introduced in Section 4.1.3 manages all data interchanging and is the direct link between the API used in the application. A❤tt♣P♦stJava object is used to connect to the server and to receive data using a target URL referring to the API. This is an extension of a client-server relationship, which is introduced in Section 3.4.2.
4.3.1 Receiving Data
The following steps are followed in order to receive data:
1. As seen in Figure 4.1, the method❝❛❧❧✭✮in the RPC class is called from the controller classes with API parameters as arguments. The parameters are sent as an array list of value pairs together with the name of the API method. One parameter pair consists of the parameter name in the API and the value of the
parameter, e.g.❬✬✉s❡r◆❛♠❡✬✱ ✬❡①❛♠♣❧❡❯s❡r✬❪.
2. The target URL is built using the API endpoint URL (since the API is non-public, the endpoint URL and API access keys will not be published in this report) and the API method requested.
3. A❤tt♣P♦stobject is declared using the target URL.
4. A Unix time stamp and the API access key are added to the parameters. 5. The parameters are then hashed into a encrypted signature string using the
SHA1 encryption method.
6. The signature string are added as a header to the❤tt♣P♦stobject.
7. The❤tt♣P♦stobject is executed and a❤tt♣❘❡s♣♦♥s❡Java object is send back as a data stream, see Figure 4.1.
8. Check the status code for errors (Described further in Section 4.3.2). If no
errors was found, a❜✉❢❢❡r❡❞❘❡❛❞❡rJava object is used to convert the data
stream into JSON data, which is the data interchange format used in this ap-plication.
9. The JSON data is sent back to the controller class calling in a❙tr✐♥❣format.
4.3.2 Error Handling
Sometimes when trying to fetch data, internal server errors could be found. To catch these errors, the status code needs to be checked before proceeding with the decryp-tion of the data stream sent from the server.
If the status code equals 200, no errors are to be found and the data stream can be decrypted. However, if the status code equals 500, an internal server error is received. To handle server errors, a helper class called❙❡ss✐♦♥❍❡❧♣❡rwas im-plemented. When sending requests using the RPC class, session tokens are often used. Session tokens are explained more in detail in Section 4.4. When the ses-sion tokens expires, the errors will be captured by the❙❡ss✐♦♥❍❡❧♣❡rclass. The
❙❡ss✐♦♥❍❡❧♣❡rwill then return an error code and trigger the RPC class to run a functions that refreshes expired tokens.
If there was something wrong with❤tt♣P♦st, it will most likely throw the error code 500 back with the invalid token explanation. If this happen, the❙❡ss✐♦♥❍❡❧♣❡r will catch this and the data stream will not be decrypted and no data will be re-turned.
AB C C D EAD E FEE B C AB C E B C AB C B C C AB C E F EAD E A C B C D E F EAD E A C B C D E AD E FEE B C AB C E EB C A C A CEA CE C A C !" AB E # $ " BB %&# !AB E # $ B' %&# !AB E # $ " &D!% (AB E B )&* !AB E B C E C A C E )C B C C+ AB C %C+ F EAD E )C A,CC - +)C A C C CF D E A C D E( A' - ./B E B E 0 B C C+ AB E E 1E - C+ AB E CF A C B F A2CC B C %C+ C+ AB E C+ E 1E -AB E CF A F A2CC " %C+ AB E 1E -%C+ AB E " CF AB E )C B F A2CC )C B F F A2CC A C DEF A # $ B' %&# !AB E FEE B C AB C E F EAD E C B C D. E B C E C E ! 3B C AB C E F. B C A C
Figure 4.3: An UML class diagram of the classes that manages sessions in the appli-cation.
4.4 Login Session Management
The session management is what keeps track of the user currently using the applica-tion. A user logs in to the system using his registered e-mail address and password. The password is encrypted in the database. To use the application, it is a require-ment that the user already has an registered account on theHunter. Each time a users logs in to the system, a new session is created. The session will stay active until the users logs out of the system.
The application has a one-time-login feature, which means that as long as the session stays active, the user will not be logged out. If he shuts down the application and uses the phone for other purposes for a while and then returns to the applica-tion, he do not have to redo the log in process.
In Figure 4.3, the class diagram for session management is displayed. The class
❙❡ss✐♦♥✳❥❛✈❛is implemented using a programming design pattern called
Single-ton introduced by Gamma et al. in [12]. Only one instance of this class will be used
during runtime and it can be accessed from all other classes. This is central for the application, as the properties of the logged in user can be reached without having to do additional server calls for each time data needs to be fetched, which minimizes the amount of server calls and thus making the whole application run smoother.
The users private variables are stored in the❙❡ss✐♦♥▼❛♥❛❣❡r✳❥❛✈❛class. When a new session is created, a new refresh token, a new access token and the user
ac-count id are stored using the class❙❡ss✐♦♥❚♦❦❡♥s✳❥❛✈❛. A user is stored as the current session user that can be accessed globally through the Session class.
The access token is required to access most of the content in the database and needs to be sent as a parameter to the RPC class. Because of network security rea-sons, it expires every 10 minutes. When this happens, a token expire error will be thrown from the server (described further in Section 4.3.2) and the session tokens will be updated. All sessions are created and updated in the❙❡ss✐♦♥❯♣❞❛t❡r✳❥❛✈❛ class and functionality for logging in and out of the application and checking the
login status is managed in the❙❡ss✐♦♥▼❛♥❛❣❡r✳❥❛✈❛class.
The refresh token also expires, but only once every tenth day. A refresh token expire does not result in a token refresh, but that user being logged out of the appli-cation. This is to prevent the user from staying logged in for a long amount of time, if the user does not use the application frequently.
4.5 Runtime Sequence
Figure 4.4 displays en example of a runtime sequence. The example shown is when the applications (which is the actor in this case) opens up the friends page, which displays a list of all friends of the session user (the user who has logged in to the system).
From the figure, it can be seen that the activity file is the first one that is loaded when a new file is loaded from the call♦♥❈r❡❛t❡✭✮. First of all, the superclass
❇❛s❡❆❝t✐✈✐t②✳❥❛✈❛will run♦♥❈r❡❛t❡✭✮to check for internet connection, login status and notifications. When the operations in the base activity (not displayed in this figure) has finished loading, the content view will be set by connecting a lay-out file to the activity. All page content that is to be loaded from the server will be
processed in an asynchronous method called▲♦❛❞❋r✐❡♥❞s✭✮. The content will be
loaded in a background thread the way it’s described in Section 3.5.
The activity calls the❧♦❛❞❋r✐❡♥❞s✭✮method from the❯s❡r❈♦♥tr♦❧❧❡r✳❥❛✈❛
class, which uses the❙❡ss✐♦♥class to get the id of the session user. Some API calls will require the access token as a parameter for data access, but the call in this exam-ple only needs to have the user id. The controller class calls the❝❛❧❧✭✮-function in the RPC class, which fetches data from the database and returns it in a string which JSON data the way the process is described in Section 4.3. The controller uses JSON parsers to make a list of structured❯s❡robjects.
The class❯s❡rin this case represents the model in Figure 4.1. By calling the function❣❡t❋r✐❡♥❞s▲✐st✭✮, the activity class can access the list of friends loaded.
The helper class❋r✐❡♥❞s❆❝t✐❝✐②❆rr❛②❆❞❛♣t❡r✳❥❛✈❛is then used to display a
structured array interface. By iterating through the list of users and using the❯s❡r class to access the user name, online status and avatar image, the array adapter can display a scrollable list. Action events like clicking on a list item is handled in the activity class. The results can be seen in Appendix B.0.5.
This is just an example of a runtime sequence, but it covers the general principle for building most of the pages in the application and acquiring data using asyn-chronous calls.
AB C DE F ECB B CB CEE ECB AB C DE F BC C EC C C DAB C DE C E C C CEE ECB C D D B E BB E C !C B" !ECBAB C D E B BC C"" DAB C DE # E " C AB C DE $B C DE E ECB" BC C"" C ECB C !ECB C B C % C !E C & C C F B C F B ' BC C C FC ! C #! D C e 4 .4 : A runt ime sequ enc e diagr am sho w ing the p rocess o fdisp la y ing all fr ien ds fr iends p age . 25
4.6 Implementing A Map Interface
One of the central features of the application is based on a map interface. Map in-terfaces are a common feature in multi-touch smartphone application. Because of the freedom of finger manipulation and the built-in GPS functionality, a digital map is a great implementation. The map interface is used in the application as a feature where users can configure bear bait, placed as barrels, on the world map.
4.6.1 Google Maps Application Programming Interface
The implementation of the customized map in the application is made using the
Google Maps API, available at [13]. It is an open API that can be used for mobile
or web development. The maps provided by Google does not only distribute the world map, but also support customization of map components such as geographi-cal pointers and info windows.
The implementation of the map interface is made using a full-screen Java web view, with the map interface loaded into it. The map itself is implemented using HTML and JavaScript. For communications between the Java code the application is based on and the JavaScript code, a JavaScript bridge between the two modules is used. When a function is activated in the JavaScript, the bridge makes a call to the Java functions and sends the parameters from the map interface to the map activity. The Google Maps API is also used to initialize the map with its center position, zoom level, pointer placements and boundaries. The API feature Markers is used to place customized pointers (that looks like bait barrels) on the map. The map in-terface is based on longitude and latitude coordinates, so the markers are loaded into the map (using the bridge) as a list of the model class❇❡❛r❇❛✐t❇❛rr❡❧, which amongst other things contains the coordinates. When a user clicks on a barrel the API feature Info Box is used to display information about the selected marker. The info boxes and the map itself is styled using CSS. The map is presented in the content overview in Appendix B.0.7.
4.6.2 Using A Custom Map
The map itself is not a map provided by Google Maps, but a customized world map of all the playable areas in the game theHunter. This map is a big image divided into several sub images. Each sub image represents an area of the map. By using multiple finger controls, the user can zoom in an out of the map just as in a normal world map. The customized map is loaded using a URL link.
4.7 Managing WordPress Data
WordPress is popular tool for blog management and blog publishing on the web. It has an open API for fetching blog content, which is used in the application. The first page that opens up when the user has logged in to the system is news feed page.
This page will display the latest blog post published on WordPress by the Expansive Worlds employees (see Section B.0.3).
The two pages related to the news feed are the only two pages on the whole appli-cation that does not fetch data from the game server, but instead uses the WordPress
JSON API. Data from internet resources is described further in Section 3.4.3. As it
is an open API, there is no need for any authentication tokens or password keys to be sent as parameters. The data is simply acquired by making an http request with the url connecting to the WordPress API. The data is then managed by using a JSON parser.
4.8 Loading Images
Some images that are seen in the application are static images, created with image editing software, that are stored locally in an image folder in resources library. This is an example of using static data, see Section 3.4.1. However, others are content related and are only available through the game database. When images are loaded from the database, they will be in the form of a URL link. To turn this link into a digital image, a http connection is needed. Because of the internet requirement, the image loading can not be done in the main thread. The image loading process is implemented after the links are received from the object layer and done in the same background thread as the data loading.
To get bitmaps from the links, the Java classes❍tt♣❯❘▲❈♦♥♥❡❝t✐♦♥and
■♥♣✉t❙tr❡❛♠are used. The bitmap images that are returned are suited for usage on a web page, so sometimes they are to big to be loaded. In this case the image quality must be down sampled and the image scaled first, in order for the image to fit the application interface. Images are heavy to load and present in mobile application, so loading multiple images at the same time will slow down the performance. This fact was kept in mind during the implementation.
4.9 Navigation
The application uses a couple of different navigation systems, depending on the us-age area. Choosing the best solution for navigation for each situation was well con-sidered during the implementation. An overview of the navigation systems imple-mented can be found in Appendix B.0.1.
4.9.1 Main Navigation Menu
The main menu navigation is based on a menu interface called Ribbon Menu. This is a navigation method proposed by Tidwell in [14].
In Figure 4.5, the visual appearance of a Ribbon Menu is illustrated. The idea is that when pushing the menu button, a list of navigation options slides in from the left side of the screen. When pushing the button once again, the menu slides back. The menu button needs to be accessed, so in the application as well as in
Figure 4.5: The Ribbon Menu slides out from the left when pushing the top left but-ton in the action bar.
Figure B.1a, the button is placed to the left in the action bar. Easy access of the main navigation menu is important, as described in Section 3.3.1.
Implementation wise, the Ribbon Menu is a separate class, which extends from
the Java layout class▲✐♥❡❛r ▲❛②♦✉t. Each menu item is a link that leads to an
application page. All links are presented in a vertical list. The Ribbon Menu class handles the hide/shown saving states and triggers the in and out sliding animations. A callback method is implemented as piece of executable code that is passed
as an argument to the❇❛s❡❆❝t✐✈✐t②class. The callback method handles all the
onclick-events on list items that opens up other pages. To navigate between pages, the Java class■♥t❡♥tis used in the way it is discussed in Section 4.2.2. By imple-menting the callback navigation method in the❇❛s❡❆❝t✐✈✐t②class, all other activ-ities that extends from it can use the ribbon menu as well.
4.9.2 Action Bar
The action bar is the graphical item placed on top of the user interface the way the green bar is displayed in Figure 4.5. The action bar is a quite new instalment, but has become standard and replaced options navigation as the main navigation system in later versions of the Android API, according to Meier in [10]. As the ribbon menu is linked to the action bar, the action bar is also implemented in the❇❛s❡❆❝t✐✈✐t② class and will be accessed through all other activities.
The ribbon menu button is always visible, but some action bar icons will appear and disappear as additional components. These icons are notifications about new incoming messages, new friend requests and notifications when the users member-ship is about to expire. They will appear at the same time as the push notifications, as they handle the same content. For further information about push notifications, and the way notifications are handled, see Section 4.10. Clicking on an action bar menu item will bring down a drop down menu, implemented using the Java class
Intents. The action bar icon is removed when the user navigates to the correspond-ing page.
4.9.3 Options Navigation
Options navigation is triggered by using the Android menu button at the bottom left side of the phone device. Pushing this button brings up the options menu, a vertical-list-style menu, which also is implemented in the❇❛s❡❆❝t✐✈✐t②class. Clicking one of the options does not navigate the user to another page in the application, but brings up an external info window. Info windows are implemented using the Java class❆❧❡rt❉✐❛❧♦❣.
4.9.4 Bottom Page Navigation
Bottom page navigation is used only on profile pages which have a deep page hi-erarchy and needs further navigation. This is used to facilitate the accessibility, de-scribed in Section 3.3.1. By placing the panel at the bottom of the screen, the user can navigate freely between sub pages without being disturbed by the extra compo-nent. As there are only a few navigation options that can be done using the bottom navigations panel, tabs are illustrated by icons instead of text. Profile pages are dis-played in Section B.0.4.
The implementation features a layout inflater that changes the sub content of a view object dynamically when the bottom menu is used. It is all handled by an on click listener in the activity classPr♦❢✐❧❡❆❝t✐✈✐t②✳❥❛✈❛.
4.10 Push Notifications
Push notifications are messages sent from the application that gets sent to the status bar on the Android device. All notifications are handles in the❇❛s❡❆❝t✐✈✐t②class, which results in a check for new notifications on each page update. A new push message gets sent upon receiving new messages, new friends requests and when the user membership is about to expire. Users will receive direct visual feedback. The importance of feedback is described further in Section 3.3.2.
In Figure 4.6, a sequence diagram showing a notification example is displayed. In this case, a new message is received and a new push message is created upon a page update (see Appendix B.0.9). As❇❛s❡❆❝t✐✈✐t②is the super class for all other activities, the call for the♦♥❈r❡❛t❡✭✮-method happens on every page update be-fore the call to the♦♥❈r❡❛t❡✭✮-method in the subclass (like❋r✐❡♥❞s❆❝t✐✈✐t②in Figure 4.4).
❇❛s❡❆❝t✐✈✐t②first call the classes❙❡ss✐♦♥▼❛♥❛❣❡r✳❥❛✈❛and
❈♦♥♥❡❝t✐♦♥❉❡t❡❝t♦r✳❥❛✈❛to see if a login session if active and that the internet connection is okay. If it is, the▲♦❛❞◆♦t✐❢✐❝❛t✐♦♥s✭✮-method will start to check for new notification asynchronous in a background tread. In this case, messages gets
A BC D E FCBB C C C C CBB CB C B C C B C C C C B BE C ! C "C # C C $% C DC B B C & C CBB CB B DC B CBB C DC B CBB C C $ " B CBB C 'CBB C $ " B CBB C$% C C B C CBB C 'CBB C $ BC CBB C B$ B DC B CBB C C DC B &BC $ C &BC 'C !BC 'C$F C C e 4 .6: A seq uence of the man agemen t of th e n otifica tions system mad e in the A ctivity class . 30
show the complete process in receiving the message data from the database. This process is described in Section 4.5.
The class◆♦t✐❢✐❝❛t✐♦♥❋❧❛❣s✳❥❛✈❛is a helper class implemented using a
Sin-gleton pattern, which makes it globally accessible. It is used to keep track of which
notifications already has been sent out. By flagging a notification, the same push notice won’t be received on every page update. When a list of the model class
❈♦♥✈❡rs❛t✐♦♥▼❡ss❛❣❡✳❥❛✈❛(unread messages) is received from the controller, it is iterated through. The flag class is then used to check for existing notifications. If the unread message is not already flagged, a new flag is added by using the mes-sage id as a key. For each unread mesmes-sage that is not already flagged, a new push notification i created by using the Java class◆♦t✐❢✐❝❛t✐♦♥.
Is is important to understand that this example is not a complete session on checking for notifications, as it only covers the part of messages, and not friend re-quests and membership renewal. However, the principle for other notifications does resemble this example.
