Douchebag Jar The Instant Karma App
A fullstack mobile application development project
Douchebag Jar The Instant Karma App Ett fullstack utvecklingsprojekt för mobilapplikationer
Frida Nilsson Dan Gryttman
The Faculty of Health, Science and Technology Computer Science Bachelor Thesis 15hp Supervisor: Katarina Asplund Examiner: Jonathan Vestin Date: 20210531
Preface
We want to thank our supervisors at Ubitech AB, Martin and Viktor, for your guidance, your patience and for your dedication. We would also like to thank our supervisor Katarina for helping us with the thesis, and reminding us that a thesis is also part of a project. Finally, we want to thank Elin, as she is the reason why we needed an app like this.
i ii PREFACE Abstract
Mobile applications are everywhere in today’s society, they come in many flavours and are an integral part of many peoples daily lives. The limits to development of mobile applications are expanding with each new idea of how the technology could be potentially used, and it is a field that is most likely going to continue to influence the world we live in. In this thesis, the objective was to develop a proof of concept for a mobile application for social interaction which is tightly anchored to the real world. The idea of the "Douchebag Jar" application was intended as a way for friends and coworkers to stay connected and keep having fun at each other’s expense by introducing a karma-based punishment/redemption system. The goal was to learn about mobile application devel- opment and the technologies behind it, get first hand experience with app development and become familiarised with tools used by professional app developers. The process of development involved researching and incorporating a number of technologies (e.g. cloud hosted databases) to create an application that was as complete as possible, within the given time frame. As a result of this project, a stable and func- tional version of the Douchebag Jar application was created and successfully deployed on multiple Android devices. The journey towards the finished proof of concept of the application was a learning experience in which various fields of computer science was delved into.
iii iv ABSTRACT Contents
Preface i
Abstract iii
List of Figures x
List of Tables xi
1 Introduction 1 1.1 Problem description ...... 2 1.2 Purpose and goal ...... 2 1.3 Ethics and society ...... 3 1.4 Methodology ...... 4 1.5 Stakeholders ...... 5 1.6 Delimitations ...... 5 1.6.1 Pandemic ...... 5 1.6.2 Time ...... 6 1.7 Work Distribution ...... 6 1.8 Disposition ...... 6
2 Background 7 2.1 .NET ...... 9
v vi CONTENTS
2.2 Xamarin.Forms ...... 9 2.3 Prism ...... 11 2.4 Entity Framework ...... 12 2.4.1 Language Integrated Query (LINQ) ...... 14 2.5 Microsoft Azure ...... 14 2.5.1 Cloud computing in general ...... 15
3 Implementation 17 3.1 Overview ...... 17 3.2 Back end ...... 19 3.2.1 Cloud hosted back end ...... 19 3.2.1.1 Server and SQL database ...... 19 3.2.1.2 Web API ...... 19 3.2.1.3 Authentication Service ...... 24 3.2.2 Local back end ...... 24 3.2.2.1 Authentication ...... 25 3.2.2.2 Authorisation ...... 25 3.2.2.3 Database accesses ...... 26 3.2.2.4 ViewModels ...... 26 3.3 Front end ...... 27 3.3.1 XAML ...... 28
4 Result 31
5 Discussion 35 5.1 Cloud hosted back end ...... 35 5.2 Local back end ...... 36 5.3 Front end ...... 38 CONTENTS vii
5.4 Working methods ...... 38 5.5 Conclusion ...... 39
References 40
Appendix 48
A Work distribution: implementation, thesis 51
B Code implementation: databinding for lists of lists 55
C Application: views 57 viii CONTENTS List of Figures
2.1 MVVM ...... 12
3.1 An overview of the mobile application in relation to the cloud hosted back end...... 18 3.2 An overview of the architectural pattern in the mobile application .... 18 3.3 Database design...... 20 3.4 Overview of the structure handling HTTP requests with database querys 21 3.5 A model representing the User entity in the database ...... 21 3.6 The model representing the Crime-entity ...... 23 3.7 Configuration of relationships and keys in database entity models .... 24 3.8 Overview of data binding for lists of lists ...... 27 3.9 Wireframe of the View showing the users Jars ...... 29 3.10 View showing the users Jars ...... 29 3.11 NavigationPages defined by TabbedPage ...... 30
B.1 Code snippet from JarsPage.xaml showing the ListView binding to My- JarCollection and the properties contained ...... 55 B.2 Code snippet from JarsPageViewModel.cs showing the ObservableCol- lection
ix x LIST OF FIGURES
C.1 Login Page ...... 58 C.2 Account Page ...... 59 C.3 Crime History Page ...... 60 C.4 Jar Page ...... 61 C.5 Owned Specific Jar Page ...... 62 C.6 Friend’s Specific Jar Page ...... 63 C.7 Settings Page ...... 64 C.8 About Page ...... 65 List of Tables
3.1 NuGet packages installed ...... 23
A.1 Work distribution implementation ...... 52 A.2 Work distribution thesis ...... 53
xi xii LIST OF TABLES Chapter 1
Introduction
Today smartphones and social media are a prevalent source of entertainment and social interaction between friends, family and coworkers, often through games or liking each others photos [1, 2]. The impact of the smartphone in today’s society is proven by the sheer amount of active users worldwide which are around 3.6 billion users [3]. Thus it is relevant to continue developing meaningful and useful things in an area which affects a myriad of individuals. Our goal is to develop a proof of concept (PoC) of a mobile application for human interaction that connects to real life actions directly, while allowing plenty of space for each groups individual humor and jargon. The application that is to be developed was inspired by the comedy tv-series New Girl [4], in which a group of friends have implemented a punishment system referred to as "The douchebag jar". The douchebag jar is simply a glass jar, in which members of the group must put money upon behaving "douchey". The concept reminds one of the classical swear jar. The mobile application is meant to allow users to create virtual douchebag jars for their different social circles, to which they may force their friends to pay virtual tokens for arbitrary reasons defined by the users themselves. Tokens paid to a jar can thereafter be redeemed by the paying user by verifying in the app that they have performed an act
1 2 CHAPTER 1. INTRODUCTION of goodness, also defined by the users themselves. The design and functionality of the app should be intuitive, appealing and easy to use for an every day person. Creating such an app means delving into the various fields of knowledge that has been taught during our time as university students and immersing ourselves further into software engineering, trying out technologies which are previously unfamiliar to us and marrying them together with the help of documentation and guidance from the dedicated supervisors from Ubitech AB.
1.1 Problem description
Mobile applications can be developed for as many reasons as can be imagined, they have their uses within our daily lives as well as in industries and many other areas. What they have in common is that they are usually meant to be used by humans in a frequent manner [5]. This means that mobile applications usually must be, among other things, responsive, user-friendly and maintain a reasonable level of performance at a reasonable cost. The question we are asking ourselves before going into development is: do the technologies used in this project offer the tools needed to make a responsive, user-friendly, maintainable app at a high enough performance level at a reasonable cost?
1.2 Purpose and goal
The purpose of this degree project is to see if it is possible to develop an application for social interaction based on actions outside of the application. The goals are:
• To make as good an application as we could with the time we had.
• To learn about the techniques, tools and technologies used in professional app- development. 1.3. ETHICS AND SOCIETY 3 1.3 Ethics and society
Throughout the recent years the question about sustainability has grown more important, due to the arising issues of global warming and other threats to our environment [6]. Applications have a part in this as they use energy when being developed as well as in use. The task is how to find the balance between developing sustainable, environmen- tally friendly and meaningful applications while at the same time scaling well with the amount of users and providing a user-friendly experience [7]. This project is an attempt to create a proof of concept for an application that is simply for entertainment and is more of a way for us to explore and learn about tools and techniques used in software engineering, rather than creating a revolutionary product designed to benefit society. Building applications which have no real value to society could be considered wasteful in terms of resources. At the same time though, as this application is a proof of concept, we do not expect to give the application an abun- dant amount of resources, as would have been given if the application was to be fully deployed. This project also gives us the opportunity to familiarise ourselves with the technologies that are associated with creating an application and its limitations, which in turn could spark new ideas on how these technologies could be utilised in a meaningful and sustainable way. For social applications specifically, the question often arises about what responsibil- ity an app developer holds for the content being put out there by the application users. This question comes up in a variety of contexts, for example: harassment versus friendly banter in online gaming, politicians and/or organizations expressing problematic opin- ions on social media, or the spreading of pseudoscience and misinformation [8, 9, 10]. In our case, one might take in to consideration the possibility of this application being used as an instrument for bullying. As for this project, the application will only be tested by a small group of users, making it possible to manually monitor user behaviour. If the application were to be released to a bigger market in the future, a system for curbing 4 CHAPTER 1. INTRODUCTION unacceptable behaviour and mental abuse would need to be implemented.
1.4 Methodology
The initial step of this project was designing the application and specify what func- tionalities it was to provide along with what services would be needed to accomplish desired functionalities. This was done with the help of the supervisors at Ubitech, by iteratively creating wireframes [11] to lay out the structure of the application and make it possible to consider different approaches. The supervisor also proposed a set of tools and technologies that were further evaluated before beginning the implementation. The implementation and evaluation of the project was inspired from some of the rules in the agile method Extreme Programming [12]:
1. Pair programming: Pair programming was used for learning the new technolo- gies and tools that were presented. In our case one of us programmed while the other observed and provided feedback.
2. Small releases: Throughout the project there were small releases of the project and based on the response from the releases, reevaluation and changes were made to the project.
3. Refactoring: Refactoring is the process of modifying the code and structure so that it is simple and easy to understand. Continuous refactoring has been done throughout the project to keep the structure and code simple and understandable.
4. Collective ownership: The idea of collective ownership is that the code is owned by all developers and can therefore be changed by anyone. This ensures quality to the project since both of us can make adjustments as we see fit. 1.5. STAKEHOLDERS 5 1.5 Stakeholders
The project is dedicated to the Swedish consultant company Ubitech, which takes full ownership of the project after it is finished. The project is as mentioned a proof of concept (PoC) (see section 1) whose purpose it is to demonstrate that the Douchebag Jar is a feasible idea. What Ubitech wants to do with the PoC is up to them, but if they want to continue further development they have a PoC which ensures that the project is possible.
1.6 Delimitations
Delimitations are bound to be a part of every project, and this project is no different. Here are the delimitations that we have encountered during the project.
1.6.1 Pandemic
The pandemic during the project is a delimitation, as it hindered us from working at Ubitech’s office. There it would have been much easier to ask questions to the super- visors and get instant answers, which would have saved time compared to messaging them and wait a while till they answered. However, the main hinder the pandemic introduced to the project was that it took away the possibility of a larger distribution of the application, which could have provided more feedback on issues that we could improve upon. For example, if the project was being developed at the office there would have been a possibility to access a Mac, which meant the application could potentially be deployed to iOS. The advantage of having the application deployed to iOS is that there could have been more feedback and evaluation as iOS holds around 53% of the mobile operating system market share in Sweden as of March 2021, making it a relevant mobile operating system to aim for [13]. Another example of the distribution problem 6 CHAPTER 1. INTRODUCTION is that it would also be easier to distribute the application if we could meet people, as it is difficult to remotely transfer large files to phones if the application is not registered to the Play Store. While there, we could hook up their phones to one of our computers or laptops and just transfer the application’s APK-file to their phone.
1.6.2 Time
Time is also one of the delimiters to the project, as we with more time could implement more features, learn more and improve what we already have done. This could really be said to all projects, but in our case it would really show if there were more time, since we implement features and design a mobile application.
1.7 Work Distribution
The work distribution for the implementation can be found in table A.1 in Appendix A and the work distribution for the thesis can be found in table A.2 in Appendix A.
1.8 Disposition
This thesis is structured as follows. In Chapter 2, we present the tools and the technolo- gies used throughout the project. We also discuss why we use them and how they are used. In Chapter 3, we describe the technical implementations of the projects, which is includes the back end as well as the front end. In Chapter 4 the result of the project is presented. In Chapter 5 the project’s process is discussed, including tools, technologies and working methods. Chapter 2
Background
Developing an application requires a number of tools and technologies depending on what kind of functionalities the application is meant to provide. In this project, the application created was to include the following features:
• An easy to use graphic user interface
• Authenticated registration and sign in
• Storage of data
To identify the tools and technologies suitable for developing such an application, the advice of the supervisors at Ubitech AB was sought. As per the supervisors recom- mendations, the application was developed using the cross-platform development tool Xamarin.Forms (see section 2.2), which uses the C#-language (and the .NET platform (see section 2.1)) to handle logic and XAML1 to create the user interface. It was also suggested that using the Prism framework (see section 2.3) would be beneficial for this project to further help decoupling the applications graphic elements from its back-end logic.
1Extensible Application Markup Language (XAML) is a markup language used for designing applications.
7 8 CHAPTER 2. BACKGROUND
A few different options were considered for the authentication and storage needs of the application, among them Microsoft SQL Server Express2 and identityserver43. It was finally decided that the application would be developed using the Microsoft Azure platform (see section 2.5) which, among a wide range of services, offers cloud based storage and authentication services with self-sign up. In addition, Azure offers the ability to host a RESTful API4. The main reasons for choosing Microsoft Azure for this project was the convenience of not having to host the database ourselves, as well as a curiosity of cloud based "serverless" computing. Another factor that played a part in this decision was the fact that both Xamarin.Forms and Visual Studio are Microsoft products, so choosing a cloud computing platform that is provided by the same company was expected to make development a rather seamless experience, as opposed to choosing a platform provided by another company.
For the purpose of accessing the database from the application while enforcing the separation of concerns5, a RESTful API for handling all database accesses was needed. As the application was to be developed using .NET Core, it was suitable if the API also was a .NET Core application. In this case the API is an ASP.NET Core web application. To allow the use of database queries with C# in the web application, an object-relational mapping framework (ORM) was needed. Two options were considered, Entity Frame- work Core (see section 2.4) and Dapper. Whereas Dapper is faster and reportedly easier to learn due to it being a more lightweight option, Entity Framework Core was the ORM chosen for this project as it is very well documented and can auto-generate handlers.
Below the chosen tools and technologies are discussed in more detail.
2Microsoft SQL Server Express is a relational database management system, free to download, distribute and use. 3Identityserver4 is a middleware providing authentication and authorization services. 4A RESTful API is an API that uses HTTP requests to access and use data. 5Separation of concerns (SoC) is a design principle for separating software into distinct section, each addressing a separate concern. 2.1. .NET 9 2.1 .NET
.NET is an open-source development platform created by Microsoft. .NET includes libraries, languages and editors that can be used to develop applications on different platforms. Companies and organizations such as General Electronics, UPS, Stack Overflow and many more use the .NET platform to build their architecture [14]. The languages that are supported for writing .NET applications is C#, F# and Visual Basic (VB). C# is an object-oriented language, F# is a functional programming language and VB is also a object-oriented language but is more approachable than C#. For working with mobile applications there is Xamarin.Forms (see section 2.2), a .NET for mobile which uses the C# language. The project will be built for Xamarin.Forms where .NET will be the main environment upon which the project will be developed.
2.2 Xamarin.Forms
Xamarin is a tool for building apps for both Android and iOS by using the .NET environment (see section 2.1). Xamarin uses the C# language to add functionality to the app, and XAML for designing the interface. Xamarin is a convenient tool for cross- platform development, since it ensures that 90% of the code can be shared between platforms [15]. There is an extension of Xamarin called Xamarin.Forms, which this project is utilizing. Xamarin.Forms implements an API that creates shared UI elements among platforms that transforms the shared UI elements into native controls on each particular platform [16]. This is a time and effort saving feature for cross-platforming development, since it means that the UI only needs to be implemented once for working and having the same structure on all platforms, instead of implementing one UI for each platform. While this is true in theory and in practice, it is not perfect. The appearance of the application may alter somewhat between different platforms. This is because each platform has a distinct appearance based on its implementation, and there is nothing 10 CHAPTER 2. BACKGROUND really Xamarin.Forms can do about it [17].
Xamarin.Forms will be the main environment in which the app makes calls to the web-API for fetching and storing data. Xamarin.Forms will also be used to design the layout of the app, by using views that are filled with information displayed to the user. An example of a view is the login/register view which is the first thing the user will see when they start the app for the first time. The view will display information on how the user can login or register to the app. When the user has successfully done so, it will move on to a different view.
Xamarin.Forms was the choice for this project for a number of reasons:
• It uses the .NET environment and the C# language, which was the preferred language for development
• It was suggested by the supervisors at Ubitech AB, who work with Xamarin.Forms professionally and thereby have much experience and knowledge to share
• It allows for quick development for both Android and iOS.
Although Xamarin.Forms comes with a lot of features to facilitate efficient and speedy application development across both Android and iOS, it also comes with a smaller community compared to the the platform-specific developer communities. This means there are less accumulated communal knowledge and experience to draw benefit from when learning how to develop applications with Xamarin.Forms. Another note- worthy detail about Xamarin.Forms is that applications built with this tool are in general larger than native applications. This is a result of Xamarin.Forms having to work with multiple platforms at the same time, making the applications overly complicated due to code overhead [18]. 2.3. PRISM 11 2.3 Prism
Prism is a tool for adding improved structure to XAML applications in Xamarin.Forms and WPF6. Prism implements several design patterns, but the design pattern that will be discussed is the Model View ViewModel (MVVM) (see Figure 2.1) since it is the design pattern that is implemented in the project. The purpose of the MVVM design is to separate the logic and the user interface. There are advantages to separating logic and user interface, namely it is easier to test and maintain code but it also improves code re- use opportunities [19]. The view, view model and model is explained in the following listing:
• View: This citation summarises the view well: "The view is responsible for defining the structure, layout and appearance of what the user sees on the screen" [19]. Typically the view in a Xamarin.Forms application is what is displayed on the screen to the user.
• View model: The view model creates properties that the view binds to, where changes to the view model’s properties updates the view by a raised Property- Changed event. The view model works as a middleman between the view and the model, where it is responsible for updating both the model and the view.
• Model: The model is thought of as a non-visual class, where it contains all the backbone data for the project.
There are two methods for binding the view to the view model, view first compo- sition and view model first composition. In view first composition the app consists of view that depends on view models. This is a more visual approach since you start with the views first and base the view model on it. In view model first composition the app consists of view models, where views are mapped to view models. The view model first
6Windows Presentation Foundation (WPF) is a tool for creating user interfaces for Windows application. 12 CHAPTER 2. BACKGROUND composition is a more logical approach, since the view model is based more on coding than having something visual like a view [19].
Figure 2.1: MVVM
2.4 Entity Framework
Entity Framework (EF) is an object-relational mapper (ORM) that works as an interface between .NET and databases. EF creates .NET objects based on each respective entity in a database, and can create entities based on the .NET objects. The reason as to why EF was developed was that previous solutions were troublesome and prone to error because of the many steps involved in fetching, converting and updating the database. A neat feature of EF is that it supports LINQ (see Section 2.4.1) queries which makes 2.4. ENTITY FRAMEWORK 13 the process of retrieving data from the database more intuitive [20]. Here is a quick walk-through on how EF works. The EF API builds an Entity Data Model (EDM) which is an in-memory representation of the entire metadata. The EDM includes the conceptual model, the storage model and the mapping between them:
• Conceptual Model: The conceptual model is based on the domain classes and the context class.
• Storage Model: The storage model is based on the database schema, and the source that it is based on depends on which approach that is used.
• Mappings: This includes information on how the conceptual model maps to the storage model.
The EF API then helps fetching data by translating LINQ queries to SQL queries and converts it back into entity objects [21] There are three approaches that can be followed when working with EF [22]:
• Database First: In the Database First approach there already exists a database, and the goal is to model entity and context classes based on the already existing database. The benefit with this approach is that there are typically no hinders to manually modifying the database and it is always possible to update the EDM.
• Code First: In the Code First approach the idea is to translate domain classes to entities and then create the database. This approach focuses on the domain requirements and if there already exists domain classes this approach might be more suitable, since the database can be generated from the domain classes. It also give more flexibility and control over the configuration, since the EDM is manually setup.
• Model First: In the Model First approach the idea is to create the EDM first and then based on the EDM generate a database from it. 14 CHAPTER 2. BACKGROUND
This project will use EF Core which is the newest version of EF. In this version the Database First and the Code First approach is supported, and this project will go with the Database First approach. The web-API will use EF for interacting with the database, where EF will create classes based on the entities in the database and update tables in the database.
2.4.1 Language Integrated Query (LINQ)
LINQ is a way for C# to interpret queries, where it introduces type checking and IntelliSense support to queries [23]. Queries can be made to all types of data structures such as arrays, lists and so on. This project will use LINQ to make queries to the domain classes that EF generated from the entities in the database.
2.5 Microsoft Azure
Microsoft Azure, commonly referred to as Azure, is a cloud computing platform pro- vided by Microsoft. It provides a wide set of cloud services, hosting of web-applications and SQL-databases for instance. Azure is a cost based cloud computing platform where the payment method is a currency called credentials. Some services offers free limited resources, and starts only to cost when the user has exceeded the limited resources. Azure offers a wide range of services for software development that is meant to facilitate developers with all the tools needed for building, testing, deploying and man- aging applications and services, all by utilizing Microsoft-managed data centers. In this thesis, only the services provided by Azure that is relevant to the development of the application in this project will be described further. There were several reasons as to why Azure was used in this project. The first one was the ability to set up a database that would be hosted and managed as part of the service, while also hosting a RESTful API for accessing said database, thereby 2.5. MICROSOFT AZURE 15 completely removing the need for setting up a physical server locally. Another reason for choosing Azure for this project was the opportunity to try cloud based computing, which has been a growing trend for the last decade due to it being a flexible, scalable and cost effective option [24]. Another service offered by Azure that was relevant to this project is the Azure Active Directory (Azure AD). It is a service that enables organizations to manage their resources and control who has access to specific parts of the organizations resources. An application can be registered to Azure AD, enabling Azure AD to handle the authenti- cation and login of users. Azure AD returns useful information about the user upon a successful login, for example their username and their unique token, which then can be used to store and fetch information about them from the database. To summarize briefly, Azure is the platform which binds the project together. It hosts the database and the web-API, connects the Xamarin.Forms application with the web-API and connects the web-API with the database.
2.5.1 Cloud computing in general
The interest for using cloud computing services has grown over the last couple of years [24]. Due to deploying faster network connections and better hardware to the cloud providers, cloud computing has become a competitor to locally deployed server instances. The selling points for cloud providers are their services which typically are hosting and running applications [25]. While it is true that many of the cloud services can just be deployed on local server instances, the main benefit of the cloud is that it removes the hassle of maintaining the server from the customer. Another benefit of cloud computing is that cloud providers also implements security to their services, which removes the struggle of implementing it yourself [24]. It is also easier and sometimes cheaper to get resources from cloud provides when starting a project compared to buying your own server [25]. This leads to scalability which in both cases 16 CHAPTER 2. BACKGROUND involves the customer to invest more money in buying resources. The advantage with cloud computing in this case is that it is often faster to gain more resources and it is also easier to specify how much you want as well [26]. The services of the cloud can be summarised into three types: Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) [26]. Azure uses the IaaS model which maintains the infrastructure for the application, i.e. servers, databases, storage and security while the customer manages the software for the appli- cation. Chapter 3
Implementation
The project which is the base for this thesis was in essence a full-stack development of a mobile application, meaning that the development process spanned all the way from abstract ideas down to, among other things, the details of data storage.
3.1 Overview
To identify the needs of the application it was necessary to begin by defining what functionalities it would contain, how it was to be used and what the criteria was to consider the application as being finished. The final implementation of the application created for this project features a cloud hosted back end, constituted by a database, a web API and an authentication API, which are all deployed in the cloud via Microsoft Azures "serverless computing" services. An overview of this structure is shown in figure 3.1. The application software on the actual mobile phone features a logic-handling back end and a front end constituting a user interface consisting of multiple views that may be interacted with to make use of the applications functionalities. These two ends of the application are mainly implemented according to the MVVM-architectural pattern,
17 18 CHAPTER 3. IMPLEMENTATION
Figure 3.1: An overview of the mobile application in relation to the cloud hosted back end. with the exception of cloud back end accesses. An illustration of this architecture is shown in figure 3.2.
In the following sections, more detailed descriptions of the parts constituting the front end and back end of the application are presented.
Figure 3.2: An overview of the architectural pattern in the mobile application 3.2. BACK END 19 3.2 Back end
In this section, the back end functionalities of the application are presented more in- depth. The first part will go into the details of the cloud hosted back end, and the second part covers the back end which is implemented in the mobile application itself.
3.2.1 Cloud hosted back end
Two Microsoft Azure accounts were registered and used to set up and configure the back end functionalities that were to be hosted in the cloud using Azures services.
3.2.1.1 Server and SQL database
An SQL database was set up via Microsoft Azures portal using a Free Trial subscription. The database was configured to be a single database with no elastic pool1 at the lowest tier, meaning it has a storage capacity up to 2GB. The server on which the database is hosted was created at the same time [27].
Database design
The database design was sketched up using the program draw.io2. The design is shown in figure 3.3. The tables specified by the design were added to the database using Microsoft SQL Server Management Studio 18 [28].
3.2.1.2 Web API
In Visual Studio 2019, an ASP.NET3 Core Web Application was created with an API template. The API template included auto-generated Start-up code that could be mod- ified to, for example, add services or configure the Http request pipeline. It also in-
1Azure SQL Database elastic pools are used to manage multiple databases dynamically 2draw.io is a free, open-source diagramming software application 3ASP.NET is a free, open source framework for building web applications using .NET and C# 20 CHAPTER 3. IMPLEMENTATION
Figure 3.3: Database design.
cluded a readily generated API Controller, which is an object that derives from the Microsoft.AspNetCore.Mvc.ControllerBase class and has the ApiController attribute. The API Controllers purpose is to serve HTTP API responses. An overview of how a client interacts with an API Controller to query a database is shown in figure 3.4. For each entity in the database, a "model" object was created to represent the data within it. An example of this is shown in figure 3.5. The model in the figure also contains additional information about the relations to other entities in the database, which will be described later in this section. The use of models is that the API can automatically serialize the data into some format (in the case of this project, JSON4 was
4JavaScript Object Notation, JSON, is a text-based format commonly used for transmitting data 3.2. BACK END 21 the format used) and then write the serialized data into the body of a HTTP response message [29].
Figure 3.4: Overview of the structure handling HTTP requests with database querys. Image credit: Microsoft Documentation [29].
Figure 3.5: A model representing the User entity in the database 22 CHAPTER 3. IMPLEMENTATION
The Object-Relational Mapping (ORM) tool, Entity Framework Core, was installed using the NuGet Package Manager5. All NuGet packages installed are listed in table 3.1. To apply Entity Frameworks functionalities on the data models, an instance of the class "Database Context" was created by deriving from the Microsoft.EntityFramework- Core.DbContext class [29]. The instance of DbContext, in this project called DoucheCon- text, represents a session with the database, which may be used to query and save instances of the database entities [30]. In the DoucheContext class, a DbSet property (e.g. public DbSet
5NuGet is the package manager for .NET, available in Visual Studio 2019 6Scaffolding is a code generating technique available in, among other frameworks, Entity Framework 3.2. BACK END 23
Figure 3.6: The model representing the Crime-entity
scaffolded controllers use dependency injection7 to inject the registered instance of Db- Context into the controller, which is then used by each of the methods in the controller.
Microsoft.EntityFramework Microsoft.EntityFramework.SqlServer Microsoft.EntityFramework.Tools Microsoft.VisualStudio.Web.CodeGeneration.Design Swashbuckle.AspNetCore
Table 3.1: NuGet packages installed
The API was tested locally using Swagger UI, an open-source tool for interacting with APIs [34], and published to the previously set up Azure server. The published API was tested using Postman API, a tool for API Development and testing [35].
Core 7Dependency Injection, DI, is a design pattern allowing for creation of dependent objects outside of a class, and providing those objects to other classes 24 CHAPTER 3. IMPLEMENTATION
Figure 3.7: Configuration of relationships and keys in database entity models
3.2.1.3 Authentication Service
In the Microsoft Azure portal, an organisation was registered in the Azure Active Direc- tory. The application was registered to the organisation and a self-service sign up was set up with user flows, allowing users to register with their Microsoft account and log in to the application.
3.2.2 Local back end
In Visual Studio 2019, the Prism Template Pack was installed using the "Manage Ex- tensions" tab and a "Prism Blank App (Xamarin.Forms)" was created. The Prism for Xamarin.Forms framework includes the MVVM design pattern, which was largely used in this implementation. 3.2. BACK END 25
3.2.2.1 Authentication
A static class, AuthHelper, was created to contain all functionality related to authenti- cation. It was created with a Microsoft tutorial [36] as reference material, and uses the REST API Microsoft Graph to send requests to the Azure Active Directory, to which the application was registered as mentioned in section 3.2.1.3. The AuthHelper class also uses the Microsoft Authentication Library, MSAL, which allows it to retrieve tokens from the Microsoft Identity Platform to authenticate the user and grant access to the Microsoft Graph API [37, 38]. Upon successful authentication, AuthHelper recieves an AuthenticationResult [39] containing information about the authentication. The results contain, among other things, the users unique ID8. The unique ID is used in the application upon login to determine if the user is new, and thus must be stored as a new tuple in the database, or if the user is returning.
3.2.2.2 Authorisation
Authorisation in this version was mainly implemented by flagging users as active/in- active using the IsActive attribute in the User-table in the database. Newly registered users are by default flagged as active, granting access to the application beyond the login screen. The user may choose to deactivate their account, flagging them as inactive, meaning that access to the application beyond the login screen is denied even upon a successful authentication. Further authorisation in the application was prepared for by defining user roles, "default" and "developer", which is stored in the users unique tuple in the User-table in the database. Each newly registered user is assigned the default-role, and may be manually assigned an elevated developer-role. The developer-role was not granted any special privileges in this version of the application, the role assignment implementation
8Each Microsoft account has a unique ID that is automatically assigned by Microsoft upon creation. 26 CHAPTER 3. IMPLEMENTATION is merely a preparation for future expansion which may require a more a extensive implementation of authorisation.
3.2.2.3 Database accesses
A static class, DbHelper, was created to contain all functionality concerning database accesses. It supplies the applications ViewModel classes, as well as the AuthHelper class, with the ability to read and modify the information held within the database.
3.2.2.4 ViewModels
For each view in the application, a ViewModel class was created which derives from BindableBase [40], which is an implementation of the INotifyPropertyChanged [41] interface. In Xamarin.Forms, databinding is used to link the front end objects to prop- erties in the back end [42], and the implementation of INotifyPropertyChanged allows for the target property (in this case, the UI objects) to be updated automatically when the source property is in any way changed by raising events. For each UI object in the front end XAML code, properties to which they were bound using data bindings were created in the corresponding ViewModel. In the simplest case, this means that the target objects is simply bound to a string or integer property. In the more complex case of this application, where views are meant to display lists of lists, the source property in the ViewModel is an ObservableCollection of other ViewModels. An overview of this structure is shown in figure 3.8 and an example of how this was implemented in code can be found in figures B.1, B.2 and B.3 in appendix B. All ViewModels that are directly linked to Views were implemented to also handle navigation, by implementing the INavigationService interface. Each pair of View- ViewModels were registered for navigation in the App class9 by overriding the Reg-
9The App class in Xamarin.Forms is the core of the application 3.3. FRONT END 27
Figure 3.8: Overview of data binding for lists of lists
isterTypes method. This enables the ViewModels to freely navigate to another target View using the INavigationService.NavigateAsync method whenever desired [43].
The ViewModels in the application also define actions that may be performed by the user through the UI. Binding the UI controls (e.g. buttons or selectable lists) to the defined actions in the ViewModels were done using the DelegateCommand- and EventToCommand Behaviour implementations which is provided by Prism [44, 45].
The application features a number of dialogs, providing feedback to the user and receiving user input to direct defined actions. The dialogs were implemented using both the older interface, IPageDialogService, and the more rich interface IDialogService, both provided by Prism [46]. The IPageDialogService was used to display simple dialogs for user feedback (e.g. "Login successful!"), while the IDialogService was used to create custom dialogs that handle user input for more complex application interaction, such as creating Jars and naming them.
3.3 Front end
In this section, the front end (i.e. the user interface) implementation is presented and further explained. 28 CHAPTER 3. IMPLEMENTATION
3.3.1 XAML
The user interface was created using XAML and based off of the wireframe designs mentioned in section 1.4 Methodology. For comparison, a wireframe created early into the project is shown in figure 3.9, and the corresponding View from the final release, screenshotted in the application, is shown in figure 3.10. The UI was iterated upon between releases of the application as the wireframe had been created without prior experience with XAML and without knowledge of sizing of widgets. The XAML code defining the user interfaces contain a variety of components, most commonly Labels for displaying text, Buttons for user interaction and ListViews for displaying lists of information, which may also be interacted with. Each component connects (binds) to the back end ViewModels by data binding as explained in the section 3.2.2.4 ViewModels. 3.3. FRONT END 29
Figure 3.9: Wireframe of the View showing the users Jars
Figure 3.10: View showing the users Jars 30 CHAPTER 3. IMPLEMENTATION
As can be seen in figure 3.10, three main views may be navigated to using the navigation bar at the bottom of the screen. This feature is implemented by layering a TabbedPage [47], on top of the selected View. The TabbedPage defines the three views as NavigationPages, as shown in figure 3.11.
Figure 3.11: NavigationPages defined by TabbedPage Chapter 4
Result
The work produced a user friendly application with a focus on social interaction based on experiences outside of the application. These are the user functionalities provided by the application:
• Register and sign in with an email.
• Logout from the application.
• Delete your account.
• Change your username.
• Create, delete and leave a jar.
• View crimes you have been reported for.
• Redeem yourself.
• Report other users.
• Accept or decline invitations to other users jars.
• Invite other users to a jar.
31 32 CHAPTER 4. RESULT
Screenshots from the application can be found in Appendix C. Due to delimitations (see section 1.6), some features that were planned to be imple- mented or fixed, were left unfinished:
• Auto-updates of views after a change has occurred.
• The ability to change a jar’s name.
• The ability to re-invite users that had left a jar.
• Visual bugs.
• The possibility to port the application to iOS devices.
The application has been developed using recommended technologies and tools based on advice from the supervisors. The recommended tools and technologies used in the project includes: Xamarin.Forms (see section 2.2), Entity Framework (see section 2.4), Microsoft Azure Active Directory (see section 2.5) and Prism (see section 2.3). During the development process the application was evaluated by techniques also based on advice from the supervisors. The recommended evaluation technique that was used was to have small releases during development (see section 1.4). The small releases were then evaluated by the supervisors, with the purpose of gaining feedback on the performance, stability and user-friendliness of the application. The evaluation on the user-friendliness was based on the supervisors’ impressions of the application’s design, as well as their feedback from testing the application’s stability by input tests (e.g. attempting to break naming conventions, cause integer overflows etc.). The evaluation on the app’s performance was based on how well it worked on the mobile phones that it was tested on as well as how it performed when there were up to four concurrent users. 33
Evaluation of the final release concluded that the application is in a state not far from a release candidate. In order to fully achieve release-ready status, the visual bugs and the auto-update of views that were left unfixed would need to be addressed. The final release version of the application was deemed as user-friendly in the sense that the application’s functionalities are easy to use, the interface is self-explanatory and the user is served with feedback on how to use the application when attempting to use the application incorrectly. Feedback from the supervisors on code quality stated that the code is maintainable and reasonably well-structured. The total cost of the application was reasonable as the cost of hosting the application on Microsoft Azure came around at a price of 150 SEK. By working with the supervi- sors’ recommended techniques, technologies and tools, the goals in section 1.2 were achieved. 34 CHAPTER 4. RESULT Chapter 5
Discussion
In the following sections evaluations of the different parts of the project are made. These evaluations are based on feedback from the small releases to the supervisors as well as acquaintances and the impressions from self judgment.
5.1 Cloud hosted back end
Configuring the services needed for the application through the Microsoft Azure Portal was mostly easy, but parts of it were confusing. Microsoft Azure offers a large set of services and it was easy getting overwhelmed when deciding upon which services were necessary for the project to work. We also had to be picky when choosing the services for the project, as some specific types of services were costly and the more services we used the more money it would draw from our wallets. Setting up the server with the database and REST-API was relatively quick, as there were plenty of tutorials and documentation available on how it is done. For authentication using the Azure Active Directory there were also plenty of documentation and tutorials, however, each tutorial would describe a different method of setting the authentication up. This caused a lot of confusion, especially since neither source provided an explanation of
35 36 CHAPTER 5. DISCUSSION pros, cons or reasons for opting for one method over another. There is much going on under the hood of Azure AD which is not inherently self-explanatory, neither explained in documentation, which made it difficult to work with as we are not familiar with these kind of working methods. As time was of the essence in this project, we decided to opt for the method of using authentication with Azure AD that we found to be the easiest, leaving us with a working self sign-up and authenticated login, without the possibility to see who has signed up via the Azure portal. The database and API implementation works well for our application, but it comes with some quirks that would need to be addressed if it were ever to be used in a larger scale project. One of the drawbacks with the database is that its resources are not fully utilised, because the elements primary key is auto-incremented and assigned in the application instead of the database. This is a functional but very inefficient way of handling auto-incrementation as it requires an extra database access each time a new tuple is posted to the database. Most of the relations between the entities are fine, but there exists some cross-relationships which seem non-intuitive. For example, the relationship between the jar and crime entities (see Figure 3.3) does not make sense since a user in practice is the only entity that could commit crimes. The reason for these known issues being left unfixed is that we found the Microsoft SQL Server Management Studio to be very slow and hard to work with, and so we decided to opt for quick fixes that we felt confident in implementing in code on the client side in order to save time and energy to progress other parts of the project.
5.2 Local back end
Implementation of the local back end in Xamarin.Forms with Prism was very much a "trial and error" experience at first, when figuring out the works of things such as 5.2. LOCAL BACK END 37 databinding, authentication and database accesses with LINQ-queries. Once each of these parts started falling into place, we were able to pick up speed in the develop- ment process significantly, and focus on implementing as much functionality as the time frame would allow, while also putting more effort into researching architectural decisions and continuously refactor the code. The development of the application was tedious, as the project had to be built and thereafter be deployed to either a virtual phone or a regular phone. The process of doing so typically took at least ten seconds each time, which does not seem to be a long time at all, but typically when you test functionalities you do small but frequent changes and this extra time adds up in the end.
The local back end of the application is completely functional and fulfills all the needs, but still leaves a few things to wish for in terms of giving the application an overall polished feeling. The implementation of the navigation bar introduced an issue upon navigating backwards in the application. This is because it is not able to keep track of what the previous view was, and therefore always ends up navigating to the Account View, which is the first view, when the back button is pressed. Another problem the applications back end has is the order of execution when refreshing properties after a dialog interaction. Upon displaying a dialog, the application usually receives input from the user that is to be reflected in some way, such as when adding a new Jar with a custom name. The order of execution causes the back end to refresh its properties before it has received the new information from the dialog. In order for the properties to update correctly after a dialog’s interaction, one must therefore reactivate the tab, meaning one has to navigate away from and then back to the view in question. These issues are the main difference between our proof of concept and a release candidate, in terms of the local back end.
These issues were left unaddressed in favour of implementing more core functional- ities (e.g. pending jar requests or deleting jars) and safe input, based on feedback from our small releases. 38 CHAPTER 5. DISCUSSION 5.3 Front end
The front end of the application is where the least time and effort was invested. As neither of us can be considered front-end developers, UX designers or even remotely familiar with markup languages, we decided to keep this part simple and focus on the application being easy to use and understand. The UI ended up fully functional and contains all the information the user would need to correctly use the application, complete with error messages. Navigation is convenient with the navigation bar at the bottom, and it is sectioned in a way that makes sense. There are however some problems with the front end. One of the problems is that fast toggling between tabs may result in visual bugs, e.g. duplicate elements in lists. This is likely due to an order of execution issue which is hard to address, similar to the refreshing issues discussed in the previous section 5.2 Local back end. Another problem is spacing and long strings. Multiple interactions with the applica- tion requires the user to enter a string, e.g. when naming a new Jar. If the entered strings are too long, they are overlapped in the view, resulting in a mess of characters that are difficult to read. This is a result of not properly spacing the UI elements, combined with not restraining the string length enough.
5.4 Working methods
Pair programming, collective ownership, refactoring and small releases are each meth- ods that have worked well for us during this project. Pair programming was especially important in the earlier stages of development, as we initially had a lot of new things to learn as quickly as possible, and it served us in the long run as we both had an overview of the entire application, rather than just pieces that we had individually worked on. 5.5. CONCLUSION 39
Collective ownership and refactoring has gone very much hand in hand, and it has improved the code quality and maintainability of our application as we have been always able to discuss and test our ideas with each other. Setting the goals for the small releases was difficult, as we could only guess how long each part would take to develop. Though our time estimation was not always accurate, the concept of small releases helped us stay on track with development and kept us focused on where we should invest our time. The feedback provided from the releases were also a major help in identifying issues that went undetected when self- testing the application, as well as improving the user-friendliness of the application.
5.5 Conclusion
The project as a whole has been a learning experience from start to finish. The in- troduction of multiple tools and technologies previously unfamiliar to us proved to be manageable, and the product is complete enough to be called a proof of concept. During the process, challenges mainly arose in the shape of vague documentation and time constraints. Most of the challenges were conquered by seeking advice from supervisors, researching and reading documentation, stubborn "trial and error" and compromises. 40 CHAPTER 5. DISCUSSION Bibliography
[1] Bendas D. and Myllyaho M. (2012) Games as Part of Mobile Entertainment. Department of Information Processing Science, University of Oulo, Finland. Accessed: 07.06.2021.
[2] Rosenthal von der Pütten A.M., Hastall M.R., Höcker S., Meske C., Heinrich T., Labrenz F., and Ocklenburg S. (2012) Likes as social rewards: Their role in online social comparison and decisions to like other People’s selfies. Computers in Human Behavior, 92:76–86.
[3] Statista: Unknown Author. (2021) Number of smartphone users worldwide from 2016 to 2023. https://www.statista.com/statistics/330695/ number-of-smartphone-users-worldwide/#:~:text=The%20number% 20of%20smartphone%20users,a%20combined%201.46%20billion% 20users. Accessed: 10.05.2021.
[4] IMDB. New Girl Tv Series. https://www.imdb.com/title/tt1826940/. Accessed: 07.06.2021.
[5] Büyüközkan G. (2007) Determining the mobile commerce user requirements using an analytic approach. Computer Standards Interfaces, 31:144–152.
[6] Unknown Author: Earth.org. (2020) The Biggest Environmental Problems of 2021. https://earth.org/
41 42 BIBLIOGRAPHY
the-biggest-environmental-problems-of-our-lifetime/. Accessed: 08.06.2021.
[7] Arndt H-K., Dziubaczyk B., and Mokosch M. (2014) Impact of Design on the Sustainability of Mobile Applications. Information Technology in Environmental Engineering, pages 13–24.
[8] Mathew B., Dutt R., Goyal P., and Mukherjee A. (2019) Spread of hate speech in online social media. WebSci ’19: Proceedings of the 10th ACM Conference on Web Science, pages 173–182.
[9] Microsoft Xbox support: Unknown Author. (2021) Know the difference be- tween trash talk and harassment. https://support.xbox.com/en-US/help/ friends-social-activity/community/trash-talk-vs-harassment. Ac- cessed: 07.06.2021.
[10] Hirsh J. (2019) Why Social Platforms Are Taking Some Responsibility for Content. https://www.cigionline.org/articles/ why-social-platforms-are-taking-some-responsibility-content/. Accessed: 07.06.2021.
[11] Young N. (2019) What is wireframing? https://www.experienceux.co.uk/ faqs/what-is-wireframing/. Accessed: 08.02.2021.
[12] Cohen D., Costa P., and Lindvall M. (2003) Agile Software Development A DACS State-of-the-Art Report. Accessed: 10.05.2021.
[13] Statcounter: Unknown Author. (2021) Mobile Operating System Market Share Sweden. https://gs.statcounter.com/os-market-share/mobile/sweden. Accessed: 26.04.2021. BIBLIOGRAPHY 43
[14] Microsoft .NET: Unknown Author. (2021) .NET customers showcase. https: //dotnet.microsoft.com/platform/customers. Accessed: 07.06.2021.
[15] Microsoft Documentation: Unknown Author. (2020) What is Xam- arin? https://docs.microsoft.com/en-us/xamarin/get-started/ what-is-xamarin. Accessed: 09.02.2021.
[16] Microsoft Documentation: Unknown Author. (2020) What is Xam- arin.Forms? https://docs.microsoft.com/en-us/xamarin/get-started/ what-is-xamarin-forms. Accessed: 09.02.2021.
[17] Conner V. and Hård G. (2014) Migrering av existerande mobila applikationer till Xamarin Forms. (Swedish).
[18] Vartanova N. (2019) Pros and Cons of Mobile Development with Xamarin. https://www.iflexion.com/blog/xamarin-pros-and-cons. Accessed: 06.04.2021.
[19] Microsoft Documentation: Unknown Author. (2017) The Model-View-ViewModel Pattern. https://docs.microsoft.com/en-us/xamarin/xamarin-forms/ enterprise-application-patterns/mvvm. Accessed: 23.02.2021.
[20] Entity Framework Tutorial: Unknown Author. (2020) What is Entity Framework. https://www.entityframeworktutorial.net/ what-is-entityframework.aspx. Accessed: 06.04.2021.
[21] Entity Framework Tutorial: Unknown Author. (2020) How Entity Frame- work Works? https://www.entityframeworktutorial.net/basics/ how-entity-framework-works.aspx. Accessed: 12.04.2021.
[22] Kanjilal J. (2015) Explore the different approaches to model entities in Entity Framework. Accessed: 06.04.2021. 44 BIBLIOGRAPHY
[23] Microsoft Documentation: Unknown Author. (2016) Language Integrated Query (LINQ). https://docs.microsoft.com/en-us/dotnet/csharp/linq/. Ac- cessed: 09.02.2021.
[24] Alejandro S. (2016) Why has Cloud Computing become so popular. https://www.linkedin.com/pulse/ why-has-cloud-computing-become-so-popular-alejandro-galvan-santana. Accessed: 06.04.2021.
[25] Ranger S. 2018 What is cloud computing? Everything you need to know about the cloud explained. https://www.zdnet.com/article/ what-is-cloud-computing-everything-you-need-to-know-about-the-cloud/. Accessed: 07.06.2021.
[26] Aljamal R., El-Mousa A., and Jubair F. (2017) A Comparative Review of High- Performance Computing Major Cloud Service Providers. Accessed: 11.05.21.
[27] Microsoft Documentation: Stein S. et al. (2020) Quickstart: Create an Azure SQL Database single database. https://docs.microsoft.com/en-us/ azure/azure-sql/database/single-database-create-quickstart? tabs=azure-portal. Accessed: 02.09.2021.
[28] Microsoft Documentation: Ghanayem M. et al. (2020) What is SQL Server Man- agement Studio (SSMS)? https://docs.microsoft.com/en-us/sql/ssms/ sql-server-management-studio-ssms?view=sql-server-ver15. Ac- cessed: 02.09.2021.
[29] Microsoft Documentation: Wasson M. et al. (2021) Tutorial: Create a web API with ASP.NET Core. https://docs.microsoft.com/en-us/aspnet/core/ tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio. Accessed: 02.09.2021. BIBLIOGRAPHY 45
[30] Microsoft Documentation: Unknown Author. (2021) DbContext Class. https://docs.microsoft.com/en-us/dotnet/api/microsoft. entityframeworkcore.dbcontext?view=efcore-5.0. Accessed: 02.09.2021.
[31] Microsoft Documentation: Unknown Author. (2021) DbSet
[32] Microsoft Documentation: Unknown Author. (2020) Configure One-To-Many Relationships using Fluent API in Entity Framework Core. https://www.entityframeworktutorial.net/efcore/ configure-one-to-many-relationship-using-fluent-api-in-ef-core. aspx. Accessed: 09.02.2021.
[33] Microsoft Documentation: Unknown Author. (2020) Configure Many-To-Many Relationships using Fluent API in Entity Framework Core. https://www.entityframeworktutorial.net/efcore/ configure-many-to-many-relationship-in-ef-core.aspx. Accessed: 09.02.2021.
[34] Swagger: Unknown Author. (2021) Swagger: API testing. https://swagger. io/solutions/api-testing/. Accessed: 08.02.2021.
[35] Postman Introduction: Unknown Author. (2021) Postman Learning Center: Getting started. https://learning.postman.com/docs/getting-started/ introduction/. Accessed: 08.02.2021.
[36] Microsoft Documentation: Unknown Author. (2021) Build Xamarin apps with Microsoft Graph. https://docs.microsoft.com/sv-se/graph/ 46 BIBLIOGRAPHY
tutorials/xamarin?WT.mc_id=Portal-Microsoft_AAD_RegisteredApps& tutorial-step=3. Accessed: 03.05.2021.
[37] Microsoft Documentation: Unknown Author. (2020) Microsoft Graph API. https://docs.microsoft.com/sv-se/azure/active-directory/ develop/microsoft-graph-intro. Accessed: 03.05.2021.
[38] Microsoft Documentation: Unknown Author. (2019) Overview of the Microsoft Authentication Library (MSAL). https://docs.microsoft.com/sv-se/ azure/active-directory/develop/msal-overview. Accessed: 03.05.2021.
[39] Microsoft Documentation: Unknown Author, Microsoft Documentation:. (2021) AuthenticationResult Class. https://docs.microsoft.com/en-us/ dotnet/api/microsoft.identitymodel.clients.activedirectory. authenticationresult?view=azure-dotnet. Accessed: 03.05.2021.
[40] Microsoft Documentation: Unknown Author. (2020) BindableBase class. https://docs.devexpress.com/WPF/17350/mvvm-framework/ viewmodels/bindablebase, 2020. Accessed: 03.05.2021.
[41] Microsoft Documentation: Unknown Author. (2021) INotifyProperty- Changed Interface. https://docs.microsoft.com/en-us/dotnet/api/ system.componentmodel.inotifypropertychanged?view=net-5.0. Ac- cessed: 03.05.2021.
[42] Microsoft Documentation: Unknown Author. (2021) Xamarin.Forms Basic Bindings. https://docs.microsoft.com/en-us/xamarin/xamarin-forms/ app-fundamentals/data-binding/basic-bindings. Accessed: 03.05.2021.
[43] Prism Library: Unknown Author. (2017) Navigation Basics. https://prismlibrary.com/docs/xamarin-forms/navigation/ navigation-basics.html. Accessed: 04.05.2021. BIBLIOGRAPHY 47
[44] Prism Library: Unknown Author. (2017) Commanding. https:// prismlibrary.com/docs/commanding.html. Accessed: 04.05.2021.
[45] Prism Library: Unknown Author. (2017) EventToCommand Behavior. https://prismlibrary.com/docs/xamarin-forms/behaviors/ eventtocommandbehavior.html. Accessed: 04.05.2021.
[46] Prism Library: Unknown Author. (2017) Prism Library: Dialogs. https:// prismlibrary.com/docs/xamarin-forms/dialogs/index.html. Accessed: 04.05.2021.
[47] Microsoft Documentation: Unknown Author. (2016) Xamarin.Forms Tabbed- Page. https://docs.microsoft.com/en-us/xamarin/xamarin-forms/ app-fundamentals/navigation/tabbed-page. Accessed: 04.05.2021. 48 BIBLIOGRAPHY Appendix
49
Appendix A
Work distribution: implementation, thesis
51 52 APPENDIX A. WORK DISTRIBUTION: IMPLEMENTATION, THESIS
Task Dan Frida Create database X X Create Web API X X Connecting database, Web API and Azure X X Authentication X X Creating testbed X X Account page X Jar page X Tabbing X Creating jars X Joining jars X Specific jar page X Change username X Delete account X Report X Redeem X Add member to jar X Safe input X X Crime history X Pending requests X About page X Log out X Leave jar/delete jar X Refactoring X X
Table A.1: Work distribution implementation 53
Task Dan Frida Abstract X 1. Introduction X X 1.1 Problem description X X 1.2 Purpose and goal X 1.3 Ethics and society X X 1.4 Methodology X X 1.5 Stakeholders X 1.6 Delimitations X 1.6.1 Pandemic X 1.6.2 Time X 1.7 Work distribution X 1.8 Disposition X 2. Background X 2.1 .NET X X 2.2 Xamarin.Forms X X 2.3 Prism X 2.4 Entity Framework X 2.4.1 LINQ X 2.5 Microsoft Azure X X 2.5.1 Cloud computing in general X 3. Implementation X 3.1 Overview X 3.2 Back end X 3.2.1 Cloud hosted back end X 3.2.1.1 Server and SQL database X 3.2.1.2 Database design X 3.2.1.3 Web API X 3.2.1.4 Authentication Service X 3.2.2 Local back-end X 3.2.2.1 Authentication X 3.2.2.2 Authorisation X 3.2.2.3 Database accesses X 3.2.2.4 ViewModels X 3.3 Front end X 3.3.1 XAML X 4. Result X 5. Discussion X 5.1 Cloud hosted back end X X 5.2 Local back end X X 5.3 Front end X X 5.4 Working methods X 5.5 Conclusion X
Table A.2: Work distribution thesis 54 APPENDIX A. WORK DISTRIBUTION: IMPLEMENTATION, THESIS Appendix B
Code implementation: databinding for lists of lists
Figure B.1: Code snippet from JarsPage.xaml showing the ListView binding to MyJarCollection and the properties contained
55 56APPENDIX B. CODE IMPLEMENTATION: DATABINDING FOR LISTS OF LISTS
Figure B.2: Code snippet from JarsPageViewModel.cs showing the ObservableCollection
Figure B.3: Code in JarViewModel Appendix C
Application: views
57 58 APPENDIX C. APPLICATION: VIEWS
Figure C.1: Login Page 59
Figure C.2: Account Page 60 APPENDIX C. APPLICATION: VIEWS
Figure C.3: Crime History Page 61
Figure C.4: Jar Page 62 APPENDIX C. APPLICATION: VIEWS
Figure C.5: Owned Specific Jar Page 63
Figure C.6: Friend’s Specific Jar Page 64 APPENDIX C. APPLICATION: VIEWS
Figure C.7: Settings Page 65
Figure C.8: About Page