Nativescript Application for Continuous Improvement of Software Engineer’S Skills

Masaryk University Faculty of Informatics

NativeScript application for Continuous Improvement of Software Engineer’s skills

Bachelor’s Thesis

Lenka Šmitalová

Brno, Spring 2017

Replace this page with a copy of the official signed thesis assignment anda copy of the Statement of an Author.

Declaration

Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Lenka Šmitalová

Advisor: Mgr. Juraj Michálek

Acknowledgement

I would like to thank my supervisor, Mgr. Juraj Michálek, for his time and helpful advises that he has offered me. Great thanks also goes to my friends and family for the great support they have always given me.

iii Abstract

The goal of this thesis is to design and implement mobile application supporting the continuous improvement of software engineer’s skills. The application is developed in NativeScript with the use of Angular2 and TypeScript. In order to create such an application, this thesis discusses the aspects of software engineer’s work as well as inspect the possibilities of motivating a person to improve his skills. Next, the term gamification is introduced and the possible uses of itin the application in order to increase motivation. Finally, the thesis describes the application design, the implementation and possible improvements for the future.

iv Keywords gamification, NativeScript, mobile application, MongoDB, Loopback, StrongLoop, Angular2, TypeScript, Node.js

Contents

1 Introduction 1

2 Software engineer’s work analysis 3 2.1 System analysis ...... 3 2.2 System design ...... 4 2.3 System implementation and testing ...... 4 2.4 System deployment and maintenance ...... 5 2.5 System evaluation ...... 6

3 Motivation 7 3.1 Intrinsic motivation ...... 7 3.2 Extrinsic motivation ...... 8

4 Gamification 9 4.1 Game elements ...... 9 4.2 Gamification usage ...... 9

5 Technologies 11 5.1 NativeScript ...... 11 5.2 Angular 2 with NativeScript ...... 12 5.3 Database ...... 12 5.3.1 Firebase ...... 12 5.3.2 MongoDB ...... 13 5.4 Loopback framework ...... 14 5.5 Node.js ...... 14 5.6 Node Package Manager ...... 15

6 Application design 17 6.1 Use Case Diagram ...... 17 6.2 Data models ...... 18 6.3 Possible mini games ...... 19

7 Implementation 23 7.1 Project structure ...... 23 7.2 Application views ...... 24 7.3 Memory consuption ...... 26

vii 8 Conclusion 29

Bibliography 31

viii 1 Introduction

In these days, many companies struggle with a problem of employees not improving their skills. After some time, they get too comfortable with their jobs and they tend to do things mechanically without really putting their minds and hearts in the job. Because of the speed of information technologies (IT) development, it is crucial that every developer keeps his skills up to date. However, when they are assigned to long-term projects when their daily job tends to be really similar, it is hard to motivate them to do so. The goal of my thesis is to create a mobile application that will motivate and guide software engineers through the process of improving their skills in a longer period of time. The application is developed in NativeScript, a tool for building cross-platform mobile applications, using TypeScript and Angular 2. The introduction is followed by the software engineer’s work analysis. I present a basic job description, concrete aspects of work that need to be performed in order to fulfil their job description and identify those aspects, that could be improved with an application supporting the refinement of the skills. The third chapter defines the concept of motivation and introduces two different types of motivation. For each type, I introduce thefac- tors that can either enhance motivation or, on the contrary, diminish motivation. The fourth chapter introduces the term gamification. It suggests several ideas that can be used in application design in order to help increase one’s motivation. The fifth chapter describes the technologies I used for application development. The sixth chapter is focused on application design. The view of the system is presented by the use case diagram, where I identify functions of the system and how different types of roles within the system interacts with them. I also introduce the proposal of models stored in the database. The seventh chapter is concentrated on the implementation of the application. It describes the project structure as well as the views of the

1 1. Introduction final application. I also discuss main memory consumptions problems for each platform. In the conclusion, I discuss the final results as well as the potential improvements of the application in the future development.

2 2 Software engineer’s work analysis

Behind each computer system is at least one software engineer that is involved in its creation. The basic job description of a software engineer is to apply principles of software engineering to the process of the software development, which has several phases. In following sections of this chapter, I describe selected phases of this process and identify those aspects of each phase, which could be improved by providing the application which supports learning new skills. My approach of the subject in this chapter is inspired by the book Systems Analysis and Design Methods 5e (Whitten; Bentley; Dittman [1], 2000)

2.1 System analysis

The very first step in software development is to explore the system proposal. Software engineers must thoroughly determine whether creating a new system or improve an existing one is the best option. When creating a system proposal, they must consider and analyse several things:

∙ Identify problems and opportunities, negotiate the scope of the project and assess its worth.

∙ Analyze problems and opportunities, analyse system processes and establish system improvement objectives.

∙ Define, analyse and prioritise system and software requirements.

∙ Identify user needs.

In order to accomplish the most reasonable result, the possible solutions must be identified, analysed, and compared. The best solution is then recommended to the management which has to approve it before software engineers can start working on the detailed system design.

3 2. Software engineer’s work analysis 2.2 System design

When designing an application, software engineers have to research technical criteria and options as well as consider requirements and ideas proposed by a client. They need to find a reasonable compromise between feasible proposals and the customer vision. In this phase of software development, software engineers have to design the application architecture, the system database, system and user interfaces. The application architecture is mainly concerned with the selection of components, their interactions, and the constraints on those that are necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design[2]. In the system database design, a detailed model of a database, or databases if more than one is required, should be produced. It should contain all the information necessary to create the database, which means an engineer must determine the data to be stored and define the relationships between different data elements. When designing the system interface, one should identify following inputs and outputs:

∙ inputs from and outputs to other systems,

∙ highly automated inputs and outputs,

∙ inputs from and outputs to external databases.

For more information about identifying system interfaces see Sys- tems Analysis and Design in a Changing World (Satzinger; Jackson; Burd [3], 2011)In user interface design, one need to specify the types of consumers using the system and what human-computer interaction will be necessary.

2.3 System implementation and testing

After designing the system, the realisation of the proposal can finally begin. During the system implementation, the product is built according to the proposal defined in the previous phase. This stage includes following steps:

∙ building and testing the databases,

4 2. Software engineer’s work analysis

∙ writing the source code in the selected programming language and link it with the database,

∙ detailed testing.

When building databases, an engineer must choose the appropriate type of database according to data necessary for storing. For example, this may be a relational database, an object-oriented database, a document-oriented database, etc. The process of writing the source code of the project is the main one where the application with the support of continuous improvement can help upgrade the skills of the software engineer. Written code should be efficient, well documented and with proper logging, especially if there are more engineers working on the project. An efficient code should be understandable, bug-free, without code repetition, and well structured. A well-documented code is easier to understand and combined with good logging can help find and fix problems, if any occurred, much faster. The process of testing the system is an important part of system implementation. It can be accelerated with well-written unit tests. Unit tests are automated and when properly written they can help greatly particularly in teams with multiple software engineers. Well documented code, good logging of the written code, and unit test writing are all aspects of software engineer’s work that can be improved by an application supporting learning. With proper regular expression and the use of source control such as git, it is possible to check whether the committed code is properly documented, contains unit tests and uses logging.

2.4 System deployment and maintenance

After the system has been properly tested and proved to be stabilised, it can be transitioned to the end user. Since the deployment of the system will most likely reveal some bugs even after detailed testing, the system maintenance is a very important part of system development. When maintaining the software, the software engineer should cor- rect faults that have been exposed during system operation, improve the performance of the system if any possible enhancements were

5 2. Software engineer’s work analysis indicated during system evaluation, and add new or modify existing functionalities in order to make the system more efficient for the end user.

2.5 System evaluation

The system evaluation is the final stage of system development. In this phase, the effectiveness of the system is measured and the potential enhancements are evaluated in order to keep the system up to date.

6 3 Motivation

This chapter quotes from the article “Intrinsic and Extrinsic Motiva- tions: Classic Definitions and New Directions” (Ryan; Deci [4], 2000), if not cited otherwise. A motivated person is somebody who is energised or inspired to do something. In general, people can have a different level and different orientation of motivation. The level of motivation is related to the amount of motivation that one have, whereas the orientation of the motivation is related to the type of the motivation and concerns the basic attitudes and goals that gave rise to action. In Self-Determination Theory, a theory presented in Intrinsic Moti- vation and Self-Determination in Human Behavior (Deci; Ryan [5], 1985), the most basic distinction is defined between intrinsic and extrinsic motivation. Intrinsic motivation refers to doing something because it is rather enjoyable and satisfactory while extrinsic motivation refers to doing something because it leads to a separable outcome [5].

3.1 Intrinsic motivation

When intrinsically motivated, a person is much more inclined to complete an activity because of the satisfaction it brings them self rather than for some detachable consequence. For humans, intrinsic motivation is not the only type of motivation, but it is a very important one. From birth onwards, humans are displaying an omnipresent readiness to learn and explore without requiring any outer incentives to do so. This natural motivational tendency is a critical element in personal development because it is through acting on one’s inherent interests that one grows in knowledge and skills. According to Cognitive Evaluation Theory, a sub-theory developed within Self-Determination Theory, optimal challenges, positive feedback, and freedom from demeaning evaluations are predicted to facilitate intrinsic motivation. However, it is important to remember, that intrinsic motivation will only occur for activities that hold inner interest for an individual.

7 3. Motivation 3.2 Extrinsic motivation

Even though intrinsic motivation is an important kind of motivation, most of the activities people do are not, strictly speaking, intrinsically motivated. When extrinsically motivated, a person is inclined to fin- ishing a task in order to obtain some separable outcome. Extrinsic motivation has been many times characterised as an impoverished form of motivation with invariantly non-autonomous behaviour. The Organismic Integration Theory, another sub-theory developed within Self-Determination Theory, introduced several different forms of extrinsic motivation with various degrees to which they are autonomous. It fosters the concept of internalisation which, when thought about as a continuum, describes how one’s motivation for behaviour can range from unwillingness to passive compliance, to active personal commitment.

Figure 3.1: A taxonomy of human motivation

8 4 Gamification

This chapter quotes from the article “From Game Design Elements to Gamefulness: Defining "Gamification"” (Deterding; Dixon; Khaled; Nacke [6], 2011), if not cited otherwise. Video games, thanks to their design explicitly for entertainment and not utility, can motivate users to remain engaged in an activity with exceptional intensity and duration. Therefore, game design is a very useful approach for creating non-game products, services, and applications, more enjoyable, motivating, and attractive to use. Gam- ification is the use of game design elements in non-game context. It relates to a classic definition of a game as defined in games studies where a game is characterized as a rule-based formal system with a variable and a quantifiable outcome, each outcome is assigned a different value, the player exerts effort to achieve a desirable outcome, and the consequences of the activity are optional and negotiable [7, 8]. Gamified application use only elements of games that do not cause the creation of the game entirely [9].

4.1 Game elements

When identifying the set of game elements, there are several ap- proaches we can use. One of them is to treat game elements as a set of features shared by games. This approach can be interpreted in several different ways, the most preferred interpretation is to accept elements that are characteristic of games. These are elements found in most (but not necessarily all) games, readily associated with games, and found to play a significant role in gameplay. Game elements, or game design elements, are defined on varying levels of abstraction. These levels are defined in Table 4.1 ordered from concrete to abstract as well as several examples for each level.

4.2 Gamification usage

The use of game elements in non-game context can, when used correctly, increases one’s motivation. For example, the possibility of gain-

9 4. Gamification ing achievements slightly motivate the user of the application to use it, even though there is not much of an external reward apart from the virtual one. The increase of the motivation can be even bigger, it the user can compare his results with other members.

Level Description Example Game interface Common, successful Badge, design patterns interaction design leader-board, level, components and design achievements solutions for a known problem in a context, including prototypical implementations. Game design Commonly reoccurring Time constraint, patterns and parts of the design of a limited resources, mechanics game that concern turns game-play Game design Evaluative guidelines to Enduring play, principles and approach a design problem clear goals, variety heuristics or analyze a given design of game styles solution Game models Conceptual models of the MDA; challenge, components of games or fantasy, curiosity; game experience game design atoms; CEGE Game design Game design-specific Play-testing, methods practices and processes play-centric design

Table 4.1: Levels of Game Design Elements

10 5 Technologies

The application uses several technologies within itself. The main one is NativeScript with the use of Angular2. For database back-end, I chose Firebase at first but several problems occurred and thanks to the lack of good feedback through logging I switched to MongoDB and for communication with the database I used IBM StrongLoop’s Loopback framework. Using MEAN stack I was able to integrate MongoDB with NativeScript 2, Angular 2 and Loopback, where MEAN stands for – MongoDB, Express.js, AngularJS and Node.js1. In application, several packaged modules from Node Package Manager (NPM) registry are used2.

5.1 NativeScript

NativeScript is an open-source framework made available under the Apache 2 license. It was created and is supported by Telerik. This development tool enables building native iOS and Android applications, Windows Mobile is planned to be added in the future. The base code can be written in Angular2, Typescript or modern JavaScript. NativeScript renders the code specific for each platform with its native rendering engine. The result is a user interface with native-like performance and user experience3. In NativeScript core concept, the application consists of pages, where each page represents a separate application’s screen. For nav- igating between pages, you can use the methods of the Frame class of the Frame module. Typically, there are several files used for each page. Business logic is developed and stored either in JavaScript (JS) or TypeScript (TS) files, the design is developed and stored in XML4 files. Names of the XML files and JS or TS files must match. Specified styling is then defined in CSS5 files. Because of many differences between default settings for each Android and iOS systems, there should be

1. See https://www.codeschool.com/mean. 2. See https://www.npmjs.com/. 3. See https://www.nativescript.org/about. 4. XML – eXtensible Markup Language 5. CSS – Cascading Style Sheet

11 5. Technologies three different CSS files defined. One common for both environments and one special for each, Android and iOS, so the content will be displayed correctly for each platform.

5.2 Angular 2 with NativeScript

Angular 2 is a framework powered by Google used mainly for development of web applications. For NativeScript integrations with Angular 2 is defined an NPM module nativescript-angular. It enables using Angular functionalities from within NativeScript itself. In Angular, the application is made up of components. Each component is defined by a combination of HTML template, that can be defined in a separate file, and its class, defined in a TypeScript file,con- trolling the screen. The main component is app.component.ts. Each page is represented by its own component. Navigation between pages is enabled by an Angular Router, an optional service with its own library package, @angular/router. Navigable components and their paths are defined in special TS file placed in the root of the application andare commonly named app.routing.ts. For describing how the application parts fit together is used an Angular module class. Every application must have at least one Angular module, the root module that you bootstrap to launch the application6.

5.3 Database

5.3.1 Firebase Firebase database was my first choice for the database back-end. It’s a NoSQL database that is easily compatible with NativeScript thanks to official plug-ins that are available. Although supports many functionalities such as OAuth authentication, an open protocol to allow secure authorization7, cloud messaging, cloud functions and real-time database, the configuration with Angular2 was quite problematic so I preferred MongoDB over Firebase.

6. See https://angular.io/docs/ts/latest/. 7. See https://oauth.net/.

12 5. Technologies

5.3.2 MongoDB MongoDB is one of the most popular NoSQL databases with document oriented storage. Documents are stored in a binary-encoded serialisation of JavaScript Object Notation (JSON) format, Binary JSON (BSON), with more available data types for use. Each document is represented as a data structure composed of field and value pairs. A value of the field can be any data type that is defined inBSON and may include other documents, arrays and arrays of documents. The field name is a string value that should be unique for given object and must comply with following restrictions: ∙ The field name _id is reserved as a primary key for the collection. ∙ The field name cannot start with dollar$ sign( ) character. ∙ The field name cannot contain the. dot( ) character. ∙ The field name cannot containnull the( ) character. An example of data structure is shown in Figure 5.1 These BSON documents are stored in collections which are then stored in the database. Collections do not demand definition for document structure, which allows an adaptable scheme for data so you can match data-modeling choices to your application and its performance requirements8.

Figure 5.1: MongoDB BSON data structure example

8. See https://docs.mongodb.com/manual/.

13 5. Technologies 5.4 Loopback framework

The Loopback framework is a set of Node.js modules that can be used to quickly build REST Application Program Interface (API). REST stands for Representational State Transfer and it is a network-based architectural style that provides a collection of architectural constraints that helps the service to gain desirable properties like performance, scalability, reliability, visibility, portability, simplicity, and modifiabil- ity [10]. The core of Loopback application are models that represent data in a back-end system, such as a database. Loopback models connect to back-end systems via data sources that provide create, retrieve, update, and delete functions. The Loopback model API is used for interaction between the application and the data sources. Using these APIs, applications can perform any action that is provided by data sources and services9.

5.5 Node.js

Node.js (Node) is an open-source, server-side JavaScript runtime envi- ronment designed to build scalable network applications. It’s based on an event-driven architecture with ability of asynchronous input and output (I/O) operations. Node can simultaneously handle many connections without deadlocking the process since there are no locks. After invoking of an operation that might require network or file I/O, control is instantly returned to the caller. Upon each connection, the appropriate callback function is called. However, if there is no available task Node is sleeping [11]. Performing non-blocking I/O operations are allowed by an event loop. The event loop in Node is presented as a runtime construct. Node enters the loop immediately after executing the input script and exits the loop when there are no more callbacks to perform, which means that the event loop is hidden from the user10.

9. See http://loopback.io/doc/en/lb2/index.html. 10. See https://nodejs.org/en/.

14 5. Technologies 5.6 Node Package Manager

The Node Package Manager is a package manager for Node.js created to help smoothly share packaged modules of code among JavaScript developers. It combines a set of open source tools that can be used to describe Node packages. Each NPM package includes package.json file containing the metadata associated with it including unique name by which the package can by identified, version information, the source repository, dependencies, etc. An example of a package.json file structure is shown in Figure 5.2.

Figure 5.2: Example of package.json

In Figure 5.2 you can see there are two different properties with dependencies. The first one, dependencies property, specifies the set of runtime dependencies and the second one, devDependencies property, specifies the set of modules required by the package developer.

6 Application design

This chapter is focused on presenting the application design and sug- gesting the mini games supporting continuous improvement. First, I present the view of the system represented by use case diagram including the functions, system roles, and their interaction. Next, the reader is acquainted with the models defining the documents stored in the database and their relations.

6.1 Use Case Diagram

A use case diagram is a behaviour diagram defined in Unified Mod- eling Language (UML). In general, behaviour diagrams are used to describe the functionality of the system. Use case diagram represents user’s interaction with the system. It consists two main objects: ∙ Actor – an entity performing a role in the system (e.g.: a person, an organization, en external system, time) usually drawn like skeleton shown in Figure 6.1. ∙ Use Case – it represents a function or an action within the system drawn as an oval with name of the function inside shown in Figure 6.1.

(a) Actor (b) Use Case

Figure 6.1: Example drawing of use case diagram objects.

Between use case diagram objects several types of relationships can be defined e.g. association, generalization, extend relationship between two use cases, include relationship between two use cases1.

1. For more information about relationships in use case diagrams see http:// creately.com/blog/diagrams/use-case-diagram-relationships/. 17 6. Application design

When designing the application, I distinguished three types of roles within the system:

∙ User – software engineer using the mobile application on his device.

∙ Administrator – administrator of the Loopback application with the competence to maintain projects assignment and mini game creation.

∙ Time – role representing the automatic updates of the database at given time.

The user can create an account, log in to or log out from it, and update the information. Each user can collaborate on a project, which means that he is able to check his assigned projects. Users can also participate in mini-games and check the achievements they have reached. The administrator can manage games, which means he can create new games and update or delete the ones that already exists in case they are outdated. He can also create new projects and assign them users that are collaborating on them. The role representing time updates is responsible for updating some databases according to the latest information. The final use case representing the system view is presented in Figure 6.2.

6.2 Data models

In the Loopback application, the data stored in the database are represented by models. In my application, I defined and used five models:

∙ Account – it represents the user of the application,

∙ Game – it represents the mini game used in the application,

∙ Achievement – it represents daily game progress,

∙ Repository – it represents the projects that are available for assignment,

18 6. Application design

∙ RepositoryContributor – represents the user’s assignment to a project.

Each account, apart from common data such as name or email, needs to have a contributorName assigned in order to participate in any game. Each game has a unique name, a common name that is displayed in the application and a gitSearchPattern used for checking the commits in the active projects in order to update achievements. Each repository has a unique projectName defined and contains a gitAddress property with the address of the source repository. Between account and game is defined a relation through model achievement. An achievement is created when an account joins the game and is deleted when an account leaves the game. Each achievement has accountID and gameID properties. It also contains a daysIn- Row property which represents how many days in a row has been fulfilled the conditions of the game (e.g. write a test a day, makeat least one commit a day). For quicker update process, it also contains properties holding the contributorName, repositoryLocalAddress, git- SearchPattern and lastUpdated. Another relation, between account and repository, is through a repositoryContributor model. A repositoryContributor has, apart from accountID and repositoryID, only localAddress property, which contains the address to a local copy of the remote git repository. The final visual representation of the data models is shown in Figure 6.3

6.3 Possible mini games

There are several possibilities for mini games design. As mentioned in chapter 2. potential mini games are unit test writing game, proper logging game and documentation game. Another game could be for regular committing to the main repository in order to keep the code up to date. Committing the changes is really important especially in teams with multiple engineers working on one project. Suggested game requirements should be as following:

∙ Unit test writing game – write at least one unit test per day.

19 6. Application design

∙ Documentation writing game – don’t commit any undocu- mented changes in a day.

∙ Proper logging game – don’t commit any new functions without proper logging in a day.

∙ Good collaborator game – make at least one commit per day.

Each game should be checked daily, and if the player meets the requirements, his achievement property daysInRow for the game will be increased by one.

Figure 6.2: Created Use Case Diagram for the application.

20 6. Application design

Figure 6.3: Final visualization of data models.

7 Implementation

The main purpose of this bachelor thesis was to create a multi-platform mobile application for continuous improvement of software engineer’s skills using a NativeScript framework. This chapter is mainly focused on describing the project structure

7.1 Project structure

The project is structured into the straightforward directory hierarchy. The main folder contains two directories: thesis-api and thesis-app. It also contains README.md, a file describing the requirements of the application and walk through the installation and the first run. The folder thesis-api contains the loopback application. It is structured into four directories. Most of the files in this directory are generated either by loopback application or by the added @mean- expert/loopback-sdk-builder NPM module. This module installs the client software development kit (SDK) used in the NativeScript application in order to enable the communication between NativeScript with An- gular2 and MongoDB. It is necessary to run this builder after every modification in Loopback application in order to have the SDKup to date. For this purpose I created script file buildSDK.sh located in folder scripts that will run the SDK builder according to the user input. The scripts folder also contains other important files. The Node.js shell scripts createGames.js and createTestData.js will create test data. File gitDiff.sh is bash shell script that takes four arguments: address to a local copy of the git repository of the project, name of the contributor, the pattern to compare the result to and a number of hours defining how long ago should the repository be checked for changes. It will update the local copy of the git repository, view the changes in the given time span, compares them to the pattern and return the number of matches. The common/models folder contains the model definition inside the JSON files. These models are used for creating the SDK for NativeScript in order to allow quite simple communication with the databases.

23 7. Implementation

The last folder, server contains mostly generated files. The datasources configuration is defined in datasources.json file. It can be generated using the Loopback data source generator1. The server.js file is the file that actually starts the application. I modified itinorder to allow repeated time triggered updates. For every achievement it runs the scripts/gitDiff.sh script and update the achievement if necessary. The directory thesis-app contains the NativeScript application. The custom code is in the app directory. It is structured into following folders: App_Resources, pages, shared. The application resporces are located in the folder App_Resources according to the platform. Each resource is defined multiple times in order to mach possible device resolution. Folder shared contains the files, that can be used without modification on both platforms like configuration files and utilities. The generated SDK is also installed into this folder. After creating global styles especially for buttons and backgrounds, I noticed the problems with pop-up windows. I was using the provided feature "ui/dialogs" but in iOS, the global styles affected styles of the pop-up windows and they were not readable anymore as shown in Figure 7.1(a). Therefore I defined several modal views that are located in folder modalViews which I then used as alerts. The final result is visible in Figure 7.1(b). The last one is pages and it contains the views that are presented in the mobile application. Each vies has its own directory containing the definition of the Angular 2 component infile view.component.ts containing the functional logic, HTML template for the component, and three CSS files: view-common.css, view.ios.css, view.android.css.

7.2 Application views

The application consists of eight different views: main, signUp, login, profile, updateProfile, projects, listOfGames, achievements. You can see view examples in Figure 7.2., Figure 7.3. and Figure 7.4. The first three serves mainly for logging into the application. The main view allows choosing whether the user wants to create an account or he already is a member and wants to log in immediately. According

1. See https://loopback.io/doc/en/lb3/Data-source-generator.html 24 7. Implementation

(a) Provided dialogs (b) Created dialogs

Figure 7.1: Provided and created dialogs view, Android is on the left.

to the decision either login or signUp view is shown. After successful sign-up, the user is logged in. These three views are using a simple back button for navigation, the rest is using a side drawer for more powerful orientation throughout the application. The next shown view is profile, which shows the account information including the number of active projects that user is assigned to and a number of active games. From this view is also possible to update profile information. The profileUpdate view displays only following properties: name, surname, contributorName. Other properties are not allowed to be changes. After submitting the data, the application is redirected back to profile view. The listOfGames page shows the list of all available games in the database with buttons for either joining or leaving the game. In case the user chooses to join the game he is already playing or try to leave the game he is not, he is alerted and navigated back to the page view. After joining the game, a local notification is created in order to alert the user once a day to check his game progress. This notification is removed when leaving the game. The projects shows the list of the projects the user is assigned to. After tapping on the name of the project, the information alert is displayed with the project name and the local address of the repository. The achievements view shows the list of the currently active games. After tapping on the name the pop-up window is displayed with the

25 7. Implementation information about how many days in a row is the user successfully playing the game.

7.3 Memory consuption

Since NativeScript is a framework that allows developers to build truly native applications for Android and iOS using only one code, it comes with some problems and challenges for both platforms. The major issue on iOS is with the navigation button. After navigat- ing to another page, the memory is not released properly which causes memory leaks. This behaviour slows down the application everytime it navigates to a different page and eventually could force the break of the app. The memory is released after closing the application. The memory leaks are visible in the Figure 7.5 On Android OD, the main challenge may come with garbage collectors. Nativescript uses two garbage collectors and in some scenarios, it is necessary to manually synchronise them. Nativescript provides a feature to trigger garbage collector in order to allow better memory management.

(a) Main page view. (b) Login page view.

Figure 7.2: Main page and login page views

26 7. Implementation

(a) Profile page view. (b) Update profile page view.

Figure 7.3: Profile page and update profile page views example

(a) List of games page view. (b) Achievements page view.

Figure 7.4: List of games page and achievements page views example

27 7. Implementation

Figure 7.5: Navigation memory leak on iOS

28 8 Conclusion

The main goal of this thesis was to design and implement the application with the support for continuous improvement of software engineer’s skills in NativeScript. In order to create such application, it was necessary to analyse the aspects of software engineer’s work and identify those that could be improved. I analysed the possibilities of how a person can be motivated and how to increase the motivation using an application by using game elements in order to support continuous learning. The application was succesfully implemented in Nativescript framework using Angular2 and TypeScript. For the server side communication, I used Loopback framework with the combination of MongoDB database. The mobile application allows user to create an account as well as login and logout. Each user can be assinged projects that he is working on and check these project from the application. A project is a source control repository that the user is one of the contributors. To support the continuous learning, the application contains minigames. A minigame defines the skill, that the user would be improving. After joining a game, the user can check achievements he gained while playing it. An achievement is simple count of days in row that the player fullfilled the condition of the minigame. In the future, the final application could be improved by the possibility of OAuth in order to support logging in by Google, Facebook, or Twitter accounts. In order to better motivate users more sophisti- cated achievements could be created as well as the possibility of social interaction with other players within the project or the company.

Bibliography

1. WHITTEN, J. L.; BENTLEY, L. D.; DITTMAN, K. C. Systems Analy- sis and Design Methods 5e. 5th. Columbus, OH, USA: McGraw-Hill Higher Education, 2000. ISBN 0072315393. 2. PERRY, D. E.; WOLF, A. L. Foundations for the Study of Software Architecture. SIGSOFT Softw. Eng. Notes. 1992, vol. 17, no. 4, pp. 40– 52. ISSN 0163-5948. Available from DOI: 10.1145/141874.141884. 3. SATZINGER, J.W.; JACKSON, R.B.; BURD, S.D. Systems Analysis and Design in a Changing World. Boston, MA, USA: Cengage Learning, 2011. ISBN 9781133713371. 4. RYAN, R. M.; DECI, E. L. Intrinsic and Extrinsic Motivations: Classic Definitions and New Directions. Contemporary Educational Psychol- ogy. 2000, vol. 25, no. 1, pp. 54–67. ISSN 0361-476X. Available from DOI: 10.1006/ceps.1999.1020. 5. DECI, E. L.; RYAN, R. M. Intrinsic Motivation and Self-Determination in Human Behavior. New York, NY, USA: Springer US, 1985. ISBN 978- 1-4899-2271-7. Available from DOI: 10.1007/978-1-4899-2271-7. 6. DETERDING, S.; DIXON, D.; KHALED, R.; NACKE, L. From Game Design Elements to Gamefulness: Defining "Gamification". In: Pro- ceedings of the 15th International Academic MindTrek Conference: Envi- sioning Future Media Environments. Tampere, Finland: ACM, 2011, pp. 9–15. MindTrek ’11. ISBN 978-1-4503-0816-8. Available from DOI: 10.1145/2181037.2181040. 7. SALEN, K.; ZIMMERMAN, E. Rules of Play: Game Design Fundamentals. Cambridge, MA, USA: MIT Press, 2004. ISBN 9780262240451. 8. JUUL, J. Half-real: Video Games Between Real Rules and Fictional Worlds. Cambridge, MA, USA: MIT Press, 2005. ISBN 9780262101103. 9. DETERDING, S.; KHALED, R.; NACKE, L.; DIXON, D. Gamification: Toward a Definition. In: CHI 2011 Gamification Workshop Proceedings. Vancouver, BC, Canada, 2011. ISBN 978-1-4503-0268-5. Available also from: hhttp://gamification-research.org/wp-content/ uploads/2011/04/02-Deterding-Khaled-Nacke-Dixon.pdf.

31 BIBLIOGRAPHY

10. FIELDING, R. T. Architectural Styles and the Design of Network-based Software Architectures [online]. Irvine, CA, USA, 2000 [visited on 2017-29-03]. Available from: http://www.ics.uci.edu/~fielding/ pubs / dissertation / fielding _ dissertation . pdf. PhD thesis. University of California. 11. TILKOV, S.; VINOSKI, S. Node.js: Using JavaScript to Build High- Performance Network Programs. IEEE Internet Computing. 2010, vol. 14, pp. 80–83. ISSN 1089-7801. Available from DOI: 10.1109/ MIC.2010.145.