SHARE2PLEYAPP FINALREPORT

by

Marinus Jacobus Otte Richard Vink

in partial fulfillment of the requirements for the degree of

Bachelor of Science in Computer Science and Engineering

at the Delft University of Technology.

Client: Share2Pley Supervisor: Felienne Hermans Contents

1 Introduction 3

2 Problem Definition and Problem Analysis4 2.1 Problem Definition ...... 4 2.2 Problem Analysis ...... 4 2.2.1 Scanning LEGO bricks...... 4 2.2.2 3D objects...... 5 2.2.3 Lego objects...... 5 2.2.4 Break down instructions ...... 6 2.2.5 Photo comparison...... 6 2.2.6 Database for the Application...... 7 2.2.7 Playful aspect...... 7 2.2.8 Application ...... 7 2.2.9 Requirements...... 8

3 Design 9 3.1 Layout...... 9 3.2 Use case diagram ...... 9 3.3 Structure ...... 11 3.4 Class diagrams...... 11

4 Implementations 16 4.1 SCRUM ...... 16 4.2 Implementations per week...... 16 4.2.1 Week 1...... 16 4.2.2 week 2 ...... 18 4.2.3 Week 3...... 19 4.2.4 Week 4...... 20 4.2.5 Week 5...... 22 4.2.6 Week 6...... 22 4.2.7 Week 7...... 22 4.2.8 Week 8...... 23

5 Code Quality 25 5.1 Model View Controller ...... 25 5.2 SIG...... 25 5.2.1 First submission ...... 25 5.2.2 Second submission ...... 25 5.3 Testing...... 25 5.3.1 Unit Testing...... 25 5.3.2 System Testing ...... 26

6 Process 27 6.1 Collaboration between the team members ...... 27 6.2 Collaboration between the developers and the client ...... 27 6.2.1 Changes of the requirements...... 27

1 CONTENTS 2

7 Conclusion 29 7.1 Conclusion...... 29 7.2 Evaluation ...... 29 7.3 Problem definition ...... 30 7.4 Discussion and Recommendations...... 30 7.4.1 Contact with client...... 30 7.4.2 Time spend on non-technical aspects...... 30 7.4.3 Final result ...... 30 7.4.4 Future development...... 30

A SIG analysis 32 A.1 Week 1...... 32 A.2 Week 2...... 32

B SCRUM 34

C Project Description 43

D Infosheet 44

E Flyer 45

Bibliography 47 PREFACE

This is the report for the Bachelor’s Thesis written by Marijn Otte and Richard Vink as part of the Bachelor Computer Science Program at Delft University of Technology. In ten weeks an application for Share2Pley has been made. The report contains all the information of this project.

We would like to thank our clients: Olav Bongarts and Jan Hendrikx. Thanks for giving us the opportunity to develop an innovating new type of software. Secondly, we want to thank Felienne Hermans who guided us through this project and gave us great feedback. We could always ask her for help, even if she was not officially at work.

Marijn Otte Richard Vink Delft, June 2015

1 SUMMARY

Share2Pley is a company that loans LEGO sets on holiday parks to people who are on a holiday. After these sets are returned, the completeness of these sets needs to be checked. Currently, this is done by weighting the returned set. This is not error-prone because each balance scale has a deviation of a few grams. A LEGO brick only weights a few grams, so if only one or two bricks are missing this will not be notified. On top of that, this method is labor-intensive. Share2Pley wants checking if a set is complete to be automated using a software application (app) for mobile phones. The goal was to develop an app that would guide the user, most of the time a child, to clear the LEGO set. The challenge is to make sure the set will be returned complete, and the user has fun in clearing the set. After some research and some changes through the process this has resulted in an app that guides the user to clear the set. For 30 bricks an instructions will be given to clear that brick, and for one brick is asked to take a photo. To check if a photo of the correct brick is made, image processing is used. For each instruction the child can notify if a brick is missing. As playful aspect a timer is implemented. A time limit is set, and if the child disassembles the set within the time, a complimentary message is given to the child. A report is made including the photo that is made and an overview of the missing bricks. This report needs to be shown at the information desk, so the deposit can be returned. The API of www.brickset.com is implemented. If the client decides to purchase more sets, they can be added easily through www.brickset.com.

2 1 INTRODUCTION

The purpose of this report is to discuss the application developed for Share2Pley. Share2Pley is a company specialized in loaning toys, especially LEGO sets. Most of the customers are people going on holiday. Sharing toys makes sure that families can leave their own toys at home. This saves space and gives children the chance to play with other toys then their own. Loaning toys at holiday parks sounds as an ideal solution. Especially using LEGO. This is because most of the time children like the building aspect of LEGO the most, which means that after the build children will play less to nothing with their set. Often the sets take a lot of space. When a LEGO set has been loaned the children can build the set. When the child is done playing, it can return the set to the reception. This saves a lot of money for the parents, and has almost the same fun factor for the child as buying a set. Loaning LEGO at holiday parks currently consists of a sequence of steps. First, before going on holiday, the customer will receive an e-mail with the latest information. This mail contains general information about the park, but also information about loaning LEGO from Share2Pley. By sending advertisements, parents know they can leave their children’s toys at home. At the park flyers of Share2Pley can be found and the advertisement of Share2Pley is displayed on the park’s tv channel. Another marketing strategy is that the location where the sets can be loaned is on the floorplan of the park. If a family decides to loan a LEGO set, a set can be picked up at the reception. The family gets a bag containing the bricks to build the LEGO set, the instructions and a plastic bag to put in the bricks after disassembling the set. Once arrived at their holiday spot, the children can build the set and play with it. At the end, the set has to be cleared and handed in at the reception. To do this, the child will disassemble the set brick by brick and put those bricks in the included plastic bag. When the set is handed in, it will be weighted at the reception. When the deviation is less than 10 gram compared to the official weight of the set, the set is defined as complete. The child will get a present in the form of a small LEGO set. The current clearing process does not work optimal. The deviation of the balance scale is often higher than 10 gram. A LEGO brick often weights about 5 gram, so it will not be noticed if 1 or 2 bricks are missing. A more efficient way of verification is desirable. A solution is an app which helps the user disassemble the LEGO wet, and return the set complete. The next chapters will discuss the development process of the app. At chapter 2 a problem definition is given. This problem definition will be analyzed so that the optimal solution will be implemented. Based on the results of the analysis a list of requirements is made. The chosen layout is explained in chapter 3. The requirements are used to create use case diagrams and class diagrams. Chapter 4 describes the implemen- tation phase. For each week the implemented functions are discussed. It also explains the opinion of the client after each implementation. The results of the code submissions to SIG are analyzed in chapter 5. Also, the different testing techniques are discussed. The collaboration between team members, developers and the client is analyzed in chapter 6. The changes in the requirements based on the opinion of the client are described as well. Chapter 7 discusses if the requirements are fulfilled and if all the goals of the problem definition are accomplished. It discusses the parts that went well, but also the parts that went less succesful. Recommendations for future work are given. Finally, a conclusion of the total project is given.

3 2 PROBLEM DEFINITION AND PROBLEM ANALYSIS

This chapter describes the problem definition set up by our client Share2Pley. It analyzes this problem defi- nition. Based on this analysis a list of requirements is made.

2.1. PROBLEM DEFINITION Share2Pley is a start-up company that loans LEGO to people who are on holiday. The challenge here is to make sure that the sets remain complete. Currently, this is done by weighting each set before and after loan- ing. Each change in weight results in a manual check which is error prone and labor-intensive. Share2Pley wants to automate this check, so that the error probability is minimized and the labor takes less time. The goal of the project is to:

• A. Develop and build a counting machine based on a LEGO database that can check each set for com- pleteness.

• B. Develop and build a software application (app) that helps the user to playfully disassemble the LEGO set and return the set complete.

• C. Develop and build a device that scans a LEGO building or a stack of LEGO bricks detects which bricks are present and which bricks are missing.

Based on this problem definition we have done research how we can fulfill these goals the best. This research is described in the next section.

2.2. PROBLEM ANALYSIS To fulfill the goals described in the previous section research needs to be done. All the possibilities are de- scribed and analyzed to find out which possibilities are achievable and what the best solution is to a given problem. The possibilities to check a set for completeness are discussed. One of them is to scan a complete LEGO building or a LEGO stack and check if all the bricks are present. Different playful aspects are described so that the client can choose which aspect will be implemented. Also all the possible operating systems (OS) are discussed to decide for which OS an app will be developed. The analysis described in this section is based on the research that was done before the implementation was even started. Throughout this report, it be- comes clear that the research done at the beginning was not the only research during the process. During the application development, it became clear that more research was needed. This to satisfy the demands of the client. This type of research does not have its own chapter, but will be part of other chapters.

2.2.1. SCANNING LEGO BRICKS The problem definition contains a goal to scan a LEGO building or a stack of LEGO and check if all present bricks are detected. For a LEGO building this is impossible, because there are always some bricks hided behind other bricks, and can therefore not be detected.For a stack of LEGO this is also impossible. Individual

4 2.2.P ROBLEM ANALYSIS 5 bricks need to be detected out of the stack. To detect bricks out of a stack, computer learning is necessary. Computer learning implies that a lot of examples are used to detect a piece of interest out of any picture. To implement this large amount of examples lots of storage is required, either local or online. If the developer decides to store this data locally, a lot of data is written to the local storage. This data can exceed 1GB, which makes the application hard to download and install. This means that local storage computer learning will not be implemented. When the data is stored, it also cost a lot of data but now this data will be stored on a server. Instead of having this data locally, the user has to download the data from the server every time a computation is executed. Hence, this requires a fast network which is often not available on mobile phones. This means that goal C from the problem definition cannot be realized. This is immediately communicated to the client.

2.2.2. 3D OBJECTS Scanning LEGO bricks is impossible, as described in the previous section, so alternatives need to be found. One of them is the use of 3D objects. The 3D objects could be used to implement the instructions to break down the set. The idea is to implement a 3D model of the build set. Step by step different bricks will be taken of the building. The child can change the angle of view, so it will be clear which brick is meant. If the child follows these instructions the total set will be cleared out, and the child would exactly know if a brick is missing. An option to mention if a brick is missing could be added, so that Share2Pley exactly knows which bricks are missing. This saves a lot of time to make the set complete again. The 3D objects can also be used to give instructions on how to build the set. If the application also contains build instructions, the paper instructions don’t have to be used anymore. Probably, children find this type of instructions more fun then building with physical instructions. The research is focused on the following API’s: Away3D [13], Flare3D [5], Yogurt3D [14] and Alternativa3D [16]. The demands of the desired API are: camera rotation, zooming and the movement of objects. Furthermore the API has to be good documented, free and usable for the development of android and iOS. All API’s were very alike to each other, which made it hard to compare them. Yogurt3D and Alternativa3D were less useful API’s to use for this application, because the documentation of both was limited, which made more difficult to use the API than Away3D and Flare3D. Away3D is the most useful API, because it is free, open-source and it has a wide documentation. However, in this stage of the research it became clear that the use of 3D objects is not recommended. It takes a lot of time to build all needed LEGO bricks as 3D objects, and on top of that is building 3D objects of LEGO bricks not a learning objective of the project. However, there are a variety of other LEGO applications which made use of 3D LEGO objects. To find out if these other applications could be useful for this project, research was needed. That is why the next step of research was finding out if other LEGO apps were open-source so that the 3D LEGO objects could be imported.

2.2.3. LEGOOBJECTS Nowadays a variety of apps and programs in which the user can build their own sets visually are available. The software with the most functionalities is Lego Digital Designer (LDD) [4]. This application makes it possible for the user to build LEGO objects in a virtual environment by using the official instructions or their own fantasy. Users also had the possibility to order visually build LEGO objects, so that they can build them in real life too. The functionality which made LDD interesting is the possibility to view step by step how a set is build. This feature could be interesting in the application for Share2Pley. LDD is a program made only available for computers, and its software is not open source. This facts makes it not possible to use its implementation for the demanded app. Another fact which made LDD not useful is that not all the required pieces are available in LDD. There are alternative options. One is the LDraw library [12]. LDraw is an open source library for LEGO CAD objects. LEGO CAD objects are LEGO computer-aided designs, which can be seen as 3D models of LEGO. Using these objects, the user can build models, instructions, rendering 3D photos and even make animations. A library is not a program, but a package which can be used when developing applications. An application which makes use of this library is LDView [2]. LDView can display LDraw objects, display a list of bricks out of these objects and LDView has tools to make objects transparant. LDView contains options to adjust the appearance of 3D objects. A disadvantage of LDView is that only one LEGO brick can be displayed at the time. This makes it impossible to use LDView for the desired application, because it cannot load whole models or buildings. LDView is a program which is used for computers. This program loads LEGO objects by using LDraw objects. These objects can sometimes have a size around 70 MegaByte. Using these objects, the worst-case scenario for the size of the objects can be 70*12 = 840 MB. Besides the high local storage, the calculation cost lots of memory and CPU usage. The makers of LDView even post on their website that 2.2.P ROBLEM ANALYSIS 6 high video cards are needed to display the objects fast and fluently. These video cards are not yet available for mobile phones. Concluding, the high local storage in combination with the high memory and high CPU usage, makes LDView not suitable to build the application upon it. Another example of an application which uses the LDraw library is BricksViewer [9]. BricksViewer is a java applet which could be ideal to display LEGO objects on an android phone which runs on Java. BricksViewer displays 3D objects using OpenGL [6]. OpenGL is a library supposed to display 3D objects optimal. OpenGL is efficient, because it uses the video card to display the models, instead of the CPU. Throughout the years, GPU became more powerful for mobile phones. It is even possible nowadays to run OpenGL on Android operating systems. BricksViewer uses LXF files to load models. These files are made inside LDD. The files can be loaded so that they can be displayed as 3D objects. Some of the models of Share2Pley can be found in the LXF format. This means that those models could be displayed in the appli- cation. Although, there is no build and clear function in the BricksViewer application. As the name implies, BricksViewer is only meant for viewing models. So it is difficult to find a good open source LEGO application or library in which the Share2Pley models can be displayed as 3D objects, and in which those models can be build and disassembled. Another option is to use the models of the LDD and to render each step to an image. All the images together are now the build and clear scheme for the given set. The images together have a smarter storage then the 3D models, this makes this option suitable for this product. Furthermore, it is important that all the sets are available in the LXF format, so that they can be opened with LDD. LDD has a function which displays step by step how the LEGO set is build. Each step can be captured as a screenshot. This shot can be converted to a POV-Ray file. With this type of file is rendering is possible. Rendering improves the quality. After the rendering, the images look like real photo. We now can make a photo of every instruction from every possible position. This makes it clear what the next step of instruction will be. LDD automatically chooses the best position, so this will be easy to implement. An alternative can be to automatically make a photo of 4 different perspectives. This helps the child to easier view what the instruction exactly has to be. A disadvantage of this option is that it costs more storage. LDD also keeps track how many bricks a set contains. A checklist of those bricks can be implemented, which will keep track of the bricks put in the bag during the clearance. Another option is to make a video capture of the building instruction of LDD. A pause button can be added here too, so that the child can build and clear the set on his or her own tempo. Implementing this option will provide a bit of a 3D environment, but it has only one perspective. At the end of the process it was found out that not all the files were in the LXF format. This means that using LDD was not possible too. Unfortunately, using LEGO objects is not possible.

2.2.4. BREAKDOWNINSTRUCTIONS As described above, using 3D object or LEGO objects is not possible in the project. Therefore another option to show the break down instructions needs to be found. Three options will be described. It is up to the client which option will be implemented. The first option is to use the paper instruction books. These books are also available in .PDF format so they can be integrated into the application. The disadvantage is that all the arrows in the instruction books that display where each brick needs to displayed are in the wrong direction. Also the instructions are in the wrong order, because breaking down a set is the reverse of building up a set. The advantage is that it is easy to develop, and in the building instructions are added simultaneously. Another option is to build the LEGO sets our self and make pictures of different steps which can be shown in the app. However, building these sets costs a lot of time. Building sets is not an objective of the project, so this is not the best option. The last option is to give the child step by step instructions to clear up a few bricks of a specific color. The advantage is that in the same time a playful aspect is added, as described in the section "Playful aspect" below.

2.2.5. PHOTOCOMPARISON A good method to realize the goal to return the set complete is to let the child randomly take a picture of a brick. These can be compared to the original image of the brick to check if a picture of the right brick is taken. If all pictures are taken correct, the chance that the set is complete is higher. If one brick misses, there is a bigger chance that other bricks miss as well. If a picture is not of a correct brick, the set needs to be checked manually which bricks are missing. There are no libraries for image comparison. Pat Cullen has written a class 2.2.P ROBLEM ANALYSIS 7 that compares pictures [3]. In this class it is possible to set a threshold for the maximum difference between two images. If the difference between two images is bigger than this threshold the images are most probably not the same, otherwise they probably are. The disadvantage is that the picture needs to be taken from the correct distance and with the same angle as the original image, otherwise the comparison goes wrong. We can give the child instructions how to take this picture by for example put the original image over the camera, so the brick can be exactly underneath this image. If this method does not work we can develop our own type of image processing. This can be comparing each pixel of the photo and the original image. By using this approach the problem that the picture needs to be taken from the right distance and the right angle stays.

2.2.6. DATABASE FOR THE APPLICATION To let users take photos and send those photos to Share2Pley for checking, the application needs a database. Usually these databases contain standard data in the form of strings. For the application, this is not sufficient and an alternative of data storing needs to found, because images need to be stored. A database in which images can be stored is the SQLiteDatabase [8]. As the name would suggest, SQLite is a light SQL service. This means that SQLite is a independent service, it does not need a server, no installation is needed to use SQLite and transactions always will respond. Transactions which will always respond are impassive for crashes and power loss. SQLite is widely used for the implementation of databases for apps. SQLite is the ideal solution for this problem, so this type of database will be used to store the images. The images will be stored locally. The company did not want to check the pictures by themselves but rather by the app using image processing, as described in the previous section. This means that no webserver is needed, and the photos and other information can be stored locally.

2.2.7. PLAYFUL ASPECT The target of the application is children in the age of 0 to 14 years old. By using the application the children follow steps to clear up the LEGO. It is important that the child has as much fun as possible in this process. This is an challenge since children most often don’t like to clear up. Some methods have been analyzed, which we will describe underneath. In the end, the client will decide which aspect(s) will be implemented. At first it is possible to implement a picture. At the beginning of the clear up process there is no picture yet, but after each step a part of the picture is added so that in the end a complete picture is shown. This might be fun for the smallest children, but children that are a little older probably do not get enthusiastic of this. An extra functionality would be to add a part of the picture by means of an animation, or let the child swipe this part to the correct place in the picture. Children like it to be the best or the fastest at something. It is possible to integrate a timer so the child gets to know how long it took to clear op the LEGO. From this result it is possible to create a high score, or give the child a small present if the time is smaller than a to determine time x. Another idea is to let the child first break down the whole set. After that the child gets instructions to clear bricks of a certain color, for example: put 23 red bricks in the bag. An option in which the child can notify that some pieces are missing can be added. This data can be passed to Share2Pley so they know the set is not complete, and of which color bricks are missing. This also makes it easier for Share2Pley to check the completeness of a set. Children like it to get complimented. A message after each step can be added which says something like: "Well done" or "Good job!". Finally, there is the possibility to add an image of a LEGO avatar who gives the instructions to the child. This avatar could also give compliments.

2.2.8. APPLICATION The client wants an application for a smartphone. There are currently three different types of operating sys- tems running on smartphones: Android, iOS and Windows. Most probably there is not enough time to make an application for all three operating systems. It would be better to make one good working app for one op- erating system than an application for three operating systems that do not work good enough. Since Android is the most used operating system it is the best option to make an Android application at first [11]. Since the development team never has developed an app before, each member will work through the book "Android programming, the big nerd ranch guide" from Hardy Brian Philips to understand the basics of de- veloping Android applications [1]. If the app meets all the requirements the development of an app for other operating systems can start. 2.2.P ROBLEM ANALYSIS 8

2.2.9. REQUIREMENTS After the research there was a conversation with the client. Based on the research and the conversation a list of requirements is created using the MOSCOW model. The MOSCOW technique orders the requirements by importance: must haves, should haves, could haves and won’t to haves. The must haves must really be implemented; without these requirements the software does not work. The should haves are requirements which have an high importance, but the app can work without them. Could haves are requirements which will be implemented if there is enough time. Won’t haves are requirements which can be interesting in further development after this project.

Must Haves

• Select which set is used. When starting the application, the child can choose which set he or she has loaned. Doing this will provide the right instructions for the proper set.

• Describing step by step how the set has to be cleared out. This will be done by giving the child step by step instructions to clear up a few bricks of a specific color.

• Playful aspect. A playful aspect will keep the child motivated to use the app and to have fun clearing out the LEGO set. This aspect will be time, where a virtual opponent or other users in the park as opponent can be created.

• Using the app to make a photo of the cleared set.

• Language free, small instructions can be implemented in English. Most of the sets are loaned at holiday parks. People from different countries are coming to the parks. English is the most used universal language, which is why some parts where language is needed is implemented English.

Should Haves

• Implementing the instructions to build the set. Paper instructions can be removed easily now.

• Checking photos at multiple steps in the process. This will provide a better check of completeness of the set during the process and gives the child the feeling that he or she is controlled, so probably puts more effort in returning the set complete.

• Filling in name and e-mail which provides user data to be available. If the set has been cleared out right, a message can be sent to a database. This can help Share2Pley find out who has completely cleared out the set.

• Database which only contains data for a month. If there are many users which all upload their photos the database will get full.

Could haves

• Making references to other LEGO related apps. This app won’t be used when the child gets home from their vacation. Using the references will make sure that children can play with LEGO on the phone after their vacation

• Checking if the photo made is of the correct brick, by using image processing.

Won’t haves

• Certificate to show if the set really is complete. There can be multiple sets added, which makes the app useful at home too. If someone clears out a set using the app, it can get a certificate. If the set is sold to another party, the seller can show that the set is complete. 3 DESIGN

After the research is done, the design for the application needs to be made so that the implementation will not be done without further thought. This chapter describes the phase of making the design of the applica- tion. The layout of the application is discussed, but also the design of the model. The design of the model will be written using Unified Modeling Language (UML). First use case diagrams will be made using the require- ments. Second, class diagrams will be made of the classes that will be implemented in the application. The UML is changed during the project, so the diagrams are corresponding to the final app.

3.1. LAYOUT The most important aspect of the application is the layout. The playful aspect can only be displayed using a well defined layout. This means that the main focus of the implementation will be the layout. In the appendix a flyer of Share2Pley is defined. see Flyer. This flyer is available at the holiday parks. The flyer shows the available sets in combination with the costs. The developers choose to use this layout for the application. This to provide a uniform layout for all the designs of Share2Pley. This means that the colors of the layout will be used in the application. The buttons are designed from the banners inside the flyer. The startscreen will be the same as the front of the flyer, but the image of the family will be removed. The sets need to be chosen as well. This can be done by implementing the same layout of the sets as in the flyer. The user can click a set to start disassembling. Implementing this will actually build a dynamic flyer. The user is acquainted with the physical flyer, so implementing a dynamic version of the flyer will make the user apprehend the application faster. The layout was sketched first. The sketched version of this layout was sent to Share2Pley. They approved the sketched version of the layout, so that it could be implemented. The layout of the app based on the sketches can be found at week 2.

3.2. USECASEDIAGRAM To give the requirements more detail, the requirements will be used to design use case diagrams. Using use case diagrams will give more insight in how the requirements will be implemented in the application. Two use cases will be made to cover all the actions of the user. One use case covers the main functionality as the other covers the ”extra” functionalities. The main functionality consists of: choosing a set, disassembling the set, taking a photo of a brick, an opportunity to indicate missing bricks, a timer screen and a results screen. Some of these were not directly requirements. Though, the combinations of them fulfill the higher requirements. Two of these requirements are the playful aspect and the high accuracy. Implementing an option for the user to indicate if they miss bricks and taking photos and check if they are taken of the correct brick are two actions which fulfill the high accuracy requirement. The fun factor is fulfilled by implementing a timer function. This will be in the use case too. Other requirements of Share2Pley were that the user should have the option to read more about Share2Pley and that references of other LEGO apps are available as well. For this, another use case is made to show the ”extra” activities. The use cases can be combined as well. To do this, a menu needs to be implemented to show which activity will get started. The menu can be viewed at week 2 as well. Because the menu is straightforward, it will not be included in the use case diagrams.

9 3.2.U SECASEDIAGRAM 10

Figure 3.1: Use case diagram of the application

Figure 3.1 displays the use case diagram of this application. The user fills in its name and chooses a set. At first the idea was to keep track of the name of the user, so that personal information about the user could be acquired by Share2Pley. At last, they did not want to acquire this information. But, filling in the name will be still available. This is done so that the user will get more involved. The name filling is actually a short version of logging in without a password. Now the user has the choice to either use this set, or open the build instructions. The user now can display the instructions and when done return to the choose set screen. If the user chooses the desired set, the user can use this set for the main functionality. The main functionality is the disassembling of a built LEGO set. At this point, the user can click if a brick is missing, take a photo of the brick which will be checked or continue if the last brick has been showed. Once during the instructions a photo needs to be taken. This photo is used to raise level of reliability within this application. The user randomly gets needs to verify if he or she really has the brick as shown in the instruction step. The photo check up uses image processing and thus verifies if the image is indeed of a brick. After the checkup has been done, the application continues at the next step of the main activity. When all the steps of the main activity has been done, the application checks if the set has been disassembled within the time limit. If so, it displays as nice message to cheer up the user. Otherwise it displays a message that the set has not been disassembled within the time limit. The last screen of the main activity displays the results screen. This screen shows the missing bricks, the taken picture and a message how well the user has disassembled the set. This screen will be saved to the image roll on the phone itself, so that the reception can verify if the checkup has been done right. As explained earlier, this application contains an about us activity and a reference activity. The about us activity contains information about Share2Pley and the reference activity contains other LEGO applications. The about us activity is created so that the user can get more information about Share2Pley and the reference activity is made so that this application is still usable after the vacation. References to other apps can be opened or downloaded or started from the reference activity. It first checks if the app is available on the phone of the user. When the reference-application is available, it will be executed. If this is not the case, the activity will check if the play store is available on the phone and opens this. If the play store is not available, the user will get redirected to the browser in which they can download the reference-application as well. 3.3.S TRUCTURE 11

Figure 3.2: Use case diagram extra activities

The menu between the use cases has also the option to terminate the app.

3.3. STRUCTURE Now that all the actions of the application are explained, the structure of the application can be designed. To make this application dynamical and easily adaptable, a good structure needs to be made. Therefore, design patterns are essential. The first option which was investigated was the model view controller (MVC) design pattern. A Model View Controller makes use of three different components. As the name implies, these components are: model, view and controller. The model is used to store the data, the view is used to display the application for the user and the controller is used to combine the model with the view, so that if the model is updated the view is updated as well. For now this looked like the ideal solution of the problem. The sets and bricks can be used as model classes, adapters between user interactions and the model can be made as controllers and the view makes takes care of the user interactions. When the model is adjusted, the view will know about this by the controllers. Other design patterns were observed as well, but none of them would fit in like the model view controller would do. Like for instance the factory design method is not usable for this application. The factory design methods lets the bigger classes create instances of subclasses. This type of software design pattern is unusable for this application, because no subclasses are necessary. Brick is not a subclass of set and other data classes do not have to be implemented. The logical action happens when the user interact with the system. For this the MVC is the best possible solution. Another aspect which has to be considered is the way the sets are implemented. The sets need to be avail- able at several points during the project. Instances of sets need to be passed through the whole application. To acquire this, a singleton class will be implemented. A singleton class is a class of which only one is avail- able. Once an instance of the singleton class is instantiated, it cannot be created again. Therefore, there is only one list of sets during runtime, when a singleton class is created for this application. Other options of this singleton class is to create new instances whenever they are needed. The disadvan- tage of using this type of development is that a lot of parameters have to be passed through. This will not provide an high code quality. Therefore, a singleton will be implemented. At first, the data, view and controllers are all saved on the application itself. Because the instructions had a large amount of data, the app itself cost a lot of storage. The application was around one hundred and fifty mega bytes. This made the application hard to install or to download. To solve this problem, the data was acquired from a server around week 7. This can be read in more detail in Implementations. The code of the sets and the controllers were adjusted.

3.4. CLASSDIAGRAMS Now that it is clear what the functionalities and the structure of the application are, class diagrams can be cre- ated. A class diagram offers a quick overview of the classes and methods that needs to be implemented. This application makes use of the model view controller design method as described above. The class diagrams will be shown of the model, controllers and the view. This makes the overview of the whole application less complex. 3.4.C LASSDIAGRAMS 12

Figure 3.3: Class diagram of all the models 3.4.C LASSDIAGRAMS 13

The model is based on the set and brick class. These classes store the data necessary to display the bricks and sets owned by Share2Pley. This model is updated when the sets and bricks are fetched from an API online. Whenever the view asks the model to be updated, the controller between it will calculate how to get the data. This will be passed on through the controller and then the view will be updated. An extra class named Missing is added to model as well. This class is used to store the data of the missing bricks inside the database. The missing class has different parameters than the brick class, therefore the extra class was made. Missing was only used in combination with the database. The next figure shows the class diagram for the controller classes of the application.

Figure 3.4: Class diagram of the controllers (1) 3.4.C LASSDIAGRAMS 14

Figure 3.5: Class diagram of the controllers (2)

The controllers are used to connect the views with the models. The first diagram displays 3 different AsyncTasks. AsyncTask is the class for threads used on Android devices. The threads are used to load the online data to the application, because internet connections can only be executed using AsyncTasks. All the data acquired online is in the xml format, therefore a xml parser is needed. This xml parser is included by using the XMLPullParserHandler class. The downloader class is exectued when downloading files. This is used by the PDFDownloaderTask to download PDF files from URLs specified in the xml. The SetLab class is in control of all the sets in the application. Whenever something happens to set, it automatically updates its content. Last is the DBHelper class. This class is made to use the SQLiteDatabase. It has operations to store and get data from the database. As described in the research chapter, SQLite is the best database to use when storing data locally. Now the view classes need to be specified: 3.4.C LASSDIAGRAMS 15

Figure 3.6: Class diagram of the View classes (1)

Figure 3.7: Class diagram of the View classes (2)

The view classes are either fragments or activities. View classes are used to display the content of the models by using the controllers. All the classes contain attributes and methods to present data on the corre- sponding views. It also consists of listeners to user interactions. So that if the user corresponds to a view, a message will be sent to the controllers which will get the required data. Every view needs a view class. There- fore all the big actions will be implemented as activity classes and the smaller actions will be implemented as fragments. 4 IMPLEMENTATIONS

After the design phase the implementing phase started. This chapter explains how SCRUM is used and dis- cusses the implementation phase sprint by sprint.

4.1. SCRUM To manage the product development SCRUM is used. Sprints of one week are used. The implementation took 8 weeks, so 8 sprints have passed. The development team consists of two members. Because of this, the roles of product owner and scrum master have not be assigned and the tasks of these roles are done by both team members. Real life conversations and weekly phone calls were attended by both and the user stories were made together as well. This worked well, because there was a good overview of what had to be done en what was realizable in a sprint. During the sprint both members often worked separately at home. There was good contact by phone and Skype so everybody knew well what the other team member was doing and how far the progress was. At the end of each sprint there was a meeting again, where the results of the sprints were discussed. Most of the time all tasks of the sprint were completed. All scrum plannings can be found in Appendix B.

4.2. IMPLEMENTATIONS PER WEEK This section describes all implementations, and all changes that have been made for each week of the imple- mentation phase. It also explains if and why some tasks from the sprint planning have not been completed.

4.2.1. WEEK 1 The first week of the implementation phase consisted mainly of setting up the project. Git had to be set up, and all software needed to be downloaded to develop android applications. This week also consisted of un- derstanding the basics of android applications, which was done by reading the book "Android programming, the big nerd ranch guide" from Hardy Brian Philips [1]. However this already started during the research phase, it still took some time in this week to finish. In this week also a beginning of the app itself was made. This included the start screen, a screen to fill in the name of the user, a main menu and a menu where a set can be selected. Screenshots of these screens were send to the client, so the client could decide whether everything turned out as expected. The client was satisfied with the progress. These screenshots can be found in figure 4.1 to 4.4.

16 4.2.I MPLEMENTATIONS PER WEEK 17

Figure 4.1: Startscreen Figure 4.2: Screen to fill in name

Figure 4.3: Menu Figure 4.4: Menu to choose a set 4.2.I MPLEMENTATIONS PER WEEK 18

4.2.2. WEEK 2 In the second week the start of the instructions of the clear process has been made. From www.brickset.com the amount of bricks of each color were counted. With this knowledge instructions were generated to disas- semble a LEGO set: from each color instructions of a random amount but with a maximum of 10 bricks were generated and randomized until all bricks were included. Bricks with not a specific color were placed in the color "Other" and were all together placed in the last instruction. An example will help to make this method clear: Suppose a set has 22 red bricks, 7 yellow bricks, 9 green bricks 31 blue bricks. This could return the following instructions: 9 green bricks, 7 blue bricks, 5 blue bricks, 7 yellow bricks, 10 red bricks, 3 red bricks, 8 blue bricks, 7 red bricks, 4 blue bricks, 7 blue bricks, 2 red bricks, 4 blue bricks, 11 other bricks. The user could press next to go to the next instruction, and after the last instruction the set will be disassembled. A LEGO avatar was added, and this avatar told the user what to do. An example can be seen in figure 4.5. After the last instruction the client got a screen with the question to take a photo of the bag with all bricks in it(figure 4.7). Of course, by this picture it is impossible to see if all bricks were included. This photo is mailed to Share2Pley, so that Share2Pley could see that the clearing process was finished. To know from who this photo was, the user had to fill in his/her name at the beginning of the app. This name was saved into a local database and loaded again if the app was restarted, so that the user had to fill in his/her name only once. After the photo was taken, a screen was displayed with the duration of the disassemble process (figure 4.6). At this point nothing is done yet with this time, because it was not decided yet what the client wanted to do with this. At the end of this week, a conversation with the client took place. The client was happy with the progress, but some things had to change. At this moment, the screen to choose a set only consisted of buttons with a number of the set. Since a child often does not know this number, it would be better to use a visualization of the set. Because the screen of a phone is not big enough to display the images of sixteen sets, the decision to make a different screen for each set has been made, where the user can swipe between the different set. Also, the client wanted the image of the brick to change corresponding to the brick that had to be cleared out. This means that the solution from the first week to give instructions for each color would disappear. Finally, the client wanted the app to be working without internet connection, because not every owner of a smartphone has the ability to make use of the mobile network, and WiFi at holiday parks is often terrible. Because of this, the mailing functionality would disappear. These changes would be the main tasks to do in week 3.

Figure 4.6: Timescreen Figure 4.5: Example of instruction screen 4.2.I MPLEMENTATIONS PER WEEK 19

Figure 4.7: Screen were is asked to take a photo

4.2.3. WEEK 3 In week 3 the changes discussed with the client at the end of week 2 were applied. The result of a different page for the action to choose a set can be seen in figure 4.8. To use the images of the bricks each image had to be downloaded separately by hand which costed a lot of time, but seemed to be the only solution at this point of the project. This took more time as expected, so this task could not be finished in this week. Looking back, we should have done this differently, but this will be discussed in the discussion. In this week the animation as described above was implemented as well. Also, for each set a corresponding LEGO avatar is implemented. 4.2.I MPLEMENTATIONS PER WEEK 20

Figure 4.8: New screen to choose a set

4.2.4. WEEK 4 In this week the unfinished task of last week, adding all the different bricks for each set into the app was finished. After this all the must haves as described in the chapter "Problem Analysis" have been finished. Because the app did not look very professional yet, especially the screens with the clear instructions were bad, there was some time spend to improve this. Also a progress bar was added, so that the user knows how far he / she is in the progress. An image of the set was added, and after each step in the instructions a part of the image disappeared. The result of this can be seen in figure 4.9. Since there is a different instruction for each brick now, the client decided that it would be useful to implement a function where the user could note that a brick was missing. Share2Pley would exactly know which bricks were missing in each set, so it would be easy for them to complete the sets again (figure 4.10). A report would be a good alternative for the mail that disappeared: after a set is cleared a report shows up with the photo taken of the set, and all missing pieces. This report could be shown at the desk where the set should be returned. An employer of the holiday park could see how many bricks were missing, and based on this decide if the deposit payed when the set was hired would be returned. An example can be seen in figure 4.11. To reduce the risk of abuse, each set should be able to be runned only once. Otherwise if the user would get to know that he / she would not get his deposit back the user could rerun the process and say that no bricks are missing. The solution to this problem would be to remove the page of this set from the pages where a set can be chosen. This was more difficult than planned, so this task could not be completed this week. The client also wanted to add references to some other LEGO related apps, so this was implemented as well. If the corresponding app was already downloaded the app would be opened, otherwise a link to the Google Play Store would be opened. 4.2.I MPLEMENTATIONS PER WEEK 21

Figure 4.9: Screen of clear instructions improved Figure 4.10: Screen where amount of missing bricks can be selected

Figure 4.11: Screen of the report 4.2.I MPLEMENTATIONS PER WEEK 22

4.2.5. WEEK 5 After showing the results of the first four weeks the client was not totally satisfied. Putting each brick in a new step would take too much time for the user to clear up the whole set, and it would get very boring. As a result, the client made a list of each set with the most valuable bricks that had to stay in the app. All the other bricks had to be removed. It costed a lot of time to look up all the bricks that had to be removed, about 5 hours per set. Because this kind of work is not a goal of our project, this was only done for a few sets to show the client how it would look like. This explains why this task is not finished for all the sets. In this week also the task that was not finished yet in week 4, the task to remove a set if it was runned, is finished. Also an "About Us" was added, so the user could get to know background information about Share2Pley. As an extra functionality PDF files of the instruction books are added, so the paper books do not have to be added anymore. On top of that, the timer function was extended: The client wanted to give the user five seconds per brick to clear. At the end of the process a message would appear, corresponding if the set was cleared within the time or not.

4.2.6. WEEK 6 At the end of week 5, the app was almost finished in the eyes of the client. This week consisted of a lot of testing, if everything worked and working on details like the layout. Because the app was technically not very complicated, a conversation with the TU coach took place to discuss this. From this conversation it became clear that still some technically functionalities needed to be added. The choice has been made to integrate an API so that the client can add new sets by themselves, and choose the bricks that they want. Also image processing will be added, so that a photo of one brick can be classified as the correct brick or not, as an extra check. Of course, these decisions have been presented to the client as well. The client thought this were good ideas as well. In week 7 these functionalities will be implemented.

4.2.7. WEEK 7 In this week the API was integrated. The client can now add new sets itself through www.brickset.com. This means that the app no longer works without an internet connection, but now is dependent of the Internet because all data will be downloaded only if needed. This means that the data from a set will be downloaded when the user clicks on "choose this set". This reduces the amount of Internet data that needs to be used. Also the PDF files with the build instructions will be downloaded from the Internet. This saves a lot of space in the app itself. It had been a good idea to integrate the API in the beginning of the project, so that we did not had to add all the bricks manually by our self. The disadvantage is that it was not possible to select the bricks to be added in the app, so in consultation with the client it has been decided to add 30 random bricks for each set.

API’s Until now, the sets and bricks were stored locally. This needs to change, if Share2Pley wants to adjust the sets and bricks dynamically. Share2Pley needs a platform to change sets and bricks. This can be done locally or online. As described ealier when sets and bricks are stored local, the local storage will be very high. This can be solved by fetching the sets and bricks from servers. Share2Pley was acquainted with Brickset.com [10]. Brickset is a website which contains all types of sets available. It contains the bricks from the set, a list of minifigures and other information about all the sets. The website has an API available, which can be used for de development of mobile applications. The API was not considered in an earlier phase of the project, due to the strict demand of creating an app which does not require any type of network to function. When Share2Pley was informed about the high local storage, they decided to go accept the proposal of the developers. The proposal was to fetch the data of bricks and sets from servers online. Every time a user needs information about sets or bricks, this will be fetched from the server. The proposal to use the platform Brickset.com was positive. This is because they are acquianted with it. The idea is that Share2Pley can make an account or multiple accounts in which they create lists of owned sets. The brickset API can acquire the sets owned by a user and puts this in an XML format. This would imply that only one API is needed to acquire all the sets and bricks. Though, this is not the case. LEGO is a company which does not share any data open- source. Brickset.com is not allowed to share the data of bricks and minifigures from LEGO. Herefore, we have to find a solution to get a list of bricks too. Luckily, there is a solution. Another website named Rebrickle.com [15] has an API available which can fetch all the possible bricks. The combination of these API’s is used to fetch all the data necessary. When Android developers try to make use of the internet, they are supposed to work on threads. These threads in Android environments are called: AsyncTasks. AsyncTasks are used to fetch data in the background. This makes sure that the app keeps running, when an AsyncTask is fetching data. So from now on when data is fetched from online sources, AsyncTasks will be used. 4.2.I MPLEMENTATIONS PER WEEK 23

The data is stored in the servers in the XML format. XML stands for Extensible Markup Language and stores data in any form possible. For example, Java classes can be converted to xml classes. A class then opens with a start tag combined with an end tag after all the attributes have been defined. This is one of the many ways to use XML. The XML data from Brickset.com and Rebrickable.com are used in the form as described above. The XML from Brickset.com contains a list of sets. This set is acquired from the user owned list. The list has been filled on the site itself. The Brickset API uses an HTTP post request to fetch data. HTTP post requests require the parameters to be stored inside the body of the request. After the data is requested, the result is a XML form. The XML contains the list of sets owned by the user. This XML data cannot be used directly in the application, herefore the XML needs to be converted to instances of Set classes. The constructor of a set class is empty, so that each attribute can be assigned using the respective set method. After all the sets have been assigned, they are added to the SetLab, which contains all the sets of the application. Now all the sets are available as instances of the set class. The only values which are not assigned yet are the list of bricks per set, and the list of instructions. After the fetching of the sets is done, the bricks will be fetched as well. The fetching of the bricks is done using the Rebrickable API. The Rebrickable API was somewhat harder to use, because the API was not very defined. The only method one this API is to get all the bricks corresponding to the given set id. This means that the bricks will be static. Although, all the bricks from the set to achieve the highest accuracy are needed. In the end the user only has to check 30 bricks, but these bricks has to be random to achieve even higher accuracy. All the bricks will be fetched, but in the end only thirty bricks are randomly selected per set. The API uses a HTTP GET request type. This means that the request itself is done by filling in the parameters in the URL. To fetch the bricks from a set, the parameter for the set id has to be passed. The result of the request is also a XML file covering all the bricks. Now this XML file can be fetched to instances of brick, using the XML fetcher class. When a brick from a set is fetched, it is added to the corresponding set. The Brick classes do have Bitmap instances for the image of the brick. This instance is not instantiated when fetching the bricks. The URL is instantiated, which can be used in a later phase to fetch the images of the bricks. The images of the bricks are not loaded directly, because this will overflow the random access memory of the mobile phone. Instead, when the desired set is selected, the brick images of the respective set will be fetched. When the clearing process of the application is finished, the images are removed from the memory. This keeps the memory low during runtime. The last type of data fetched from the servers are instructions. Instructions are available inside the Brick- set API. They come in the form of URL lists, because sets can have multiple instructions. The API method for getInstructions is executed here. It has the set ID as parameter. When the user decides to read an instruction, they can select the right instruction from the list which has shown up. After they click their desired instruc- tion booklet, the PDF will be downloaded from the URL specified in the Instructions list. The PDF will be downloaded. After the PDF is downloaded, the user can select its favorite PDF reader to read the instructions. If the user does not have enough space on it’s phone’s local storage or on the SD card, a message will be shown that the user does not have enough storage to download the PDF. Also, when the user does not have a PDF reader installed on it’s phone, a message will be shown as well now specifying that the user does not have a PDF reader installed. Now the sets can easily be adjusted by Share2Pley and the instructions per set are now available as well.

Image Processing Also the start with image processing has been made but this task was too big to finish in one week, so this will be continued in the next week. For image processing openCV is used. openCV has an option to put an image over the camera. Using this, it is possible to put an image of the brick where a picture has to be made of in front of the camera. The user can exactly fit the brick into this image, so that it is easier to compare the photo and the original image. The implementations of the image processing took some problems with it. Especially setting up the camera well took long. The normal android camera application could not be used, because it is not possible to an image over the camera. The openCV camera class is not optimal because there is not a simple function to take a picture and save it. Saving the picture was an asynchronous function, so the rest of the application had to wait for the picture to be taken, otherwise the picture was not saved yet. Also, the format of taken picture was not usable for image processing, so this format had to be converted.

4.2.8. WEEK 8 In this final week of implementation, only the image processing task had to be finished. At the moment of writing, image processing is not finished yet. The class written by Pat Cullen is currently being integrated as described in chapter 2. This class cuts up the image into multiple parts and compares the brightness. If big 4.2.I MPLEMENTATIONS PER WEEK 24 parts in a part are vastly different than the images will be labeled as not the same. If this will not work, another method needs to be implemented. This will method will compare each pixel for similarity. For each pixel a threshold for the value of the color is set. If the color of the two pixels is close enough the pixels are similar enough. If there are enough similar pixels the photo will be approved. For the amount of similar pixels also a threshold is set. To take the background in account, instructions to take a photo of the brick on a white background are given. Since the background of the original image is white as well, this can be compared well. The rest of the week the most time was spend on writing the final report. 5 CODE QUALITY

This chapter describes the code quality of the project. Twice during the project, the code of the application is sent to SIG. SIG stands for Software Improvement Group [7]. The results will be described in this chapter. Also the testing done by the developers will be discussed.

5.1. MODEL VIEW CONTROLLER To keep the quality of the code high, the Model View Controller (MVC) design pattern is used. This pattern keeps the model, the view and the controller separated. This is good for the maintainability of the code. Not it is easy to change for example only the view, without needing to replace the code of the model as well.

5.2. SIG SIG measures the quality and the maintainability of the code. The code was submitted in week 5 and in week 9. The feedback from SIG can be found in Appendix A.

5.2.1. FIRSTSUBMISSION The code of the first submission scored 4 out of 5 stars, which is not bad. The last star was missing because of Unit Size and Unit Interfacing. Some methods were too long, and also some methods had too many parame- ters. On top of that, some methods had confusing names. Based on this feedback the code was changed. The names of confusing methods have been changed and methods with many parameters have been adapted. Most methods with a lot ofparameters were in the class set, because at first a set had a parameter for each different color, including the amount of that color in the set. In a later phase, the instructions for bricks with a specific color were removed. This meant that the parameters were removed as well.

5.2.2. SECONDSUBMISSION The code of the second submission scored 4 stars as well. The recommendations from the first feedback have been applied partly. As explained in the previous section, the methods with a large amount of parameters have been removed. However, some long methods are still present. These are some onCreate() methods in activities. In some activities a lot of things have to happen when an activity was created. Splitting these methods in multiple smaller methods would take a lot of time to apply, so we decided not to do this. There was no improvement on the amount of tests, but these have been added later.

5.3. TESTING Testing is a very important part of software development. In this project unit testing and system testing is used. Because there were are different components integrated and there are no subsystems, integration testing and component interface testing has not been used.

5.3.1. UNIT TESTING Unit testing is applied to test if implemented functions do what they should do. A small amount of unit tests are written, because the model of the project is not very large. A larger section of the app is the view, which

25 5.3.T ESTING 26 can not be tested using unit testing.

5.3.2. SYSTEM TESTING System testing is done a lot. An emulator was used to run the app on the computer. Each new implementation is tested by running the app and check if everything works as it should work. All possible scenarios have been tested. System testing costed a lot of time, because for each small change that needed to be tested the app had to be downloaded and installed again on the emulator. After a view weeks we used another type of emulator which had a shorter installation time. Also, this newer emulator started faster than the old one. Because an emulator is not a real phone, on some moments during the project the app is also tested on different Android phones. 6 PROCESS

This chapter describes the process of the project. The collaboration between the team members is discussed, even as the collaboration between the team and the client.

6.1. COLLABORATIONBETWEENTHETEAMMEMBERS The collaboration between both team members went well. Both team members already knew each other well before the project started, so this was an advantage. There were no problems at all during the process. Each team member helped where needed, and to decisions were made in good consideration.

6.2. COLLABORATIONBETWEENTHEDEVELOPERSANDTHECLIENT During the project, the collaboration between the team and the client was good. Because the location of Share2Pley is in Venlo, it was not possible to meet up every week. Personal meetings have taken place four times. These were all good meetings with brainstorming, good ideas on how to develop the app and on how to improve every aspect. Most contact found place by email, this happened at least once a week. The team kept the client up to date about the progress. Email was also used to ask questions about decisions that had to be made, however for important decisions a phone call was made to make sure that the client understood what all the advantages and disadvantages were. However, looking back, this contact could have been better. As explained in the next section, quite some changes have appeared in the requirements. This was because the client changed its mind about different aspects. Some of these changes were applied because the result of an implementation turned out to be dif- ferent than expected. But also some changes occurred because a solution to a problem was not what the client wanted, despite the fact that in consultation with the client this decision was made. For example the mail that would be send was not required anymore. Because the client is not very technical, probably the client did not understand the different possibilities to a problem well enough. Some unnecessary work could have been avoided by explaining the different solutions and the effects of a solution better.

6.2.1. CHANGESOFTHEREQUIREMENTS However the communication was good between the team and the client, opinions about requirements change during the project. This was also the case for this project.

Choose a set The first idea of the screen to choose a set was to make one screen with all sixteen LEGO sets in one glance. At first a screen was made with only the number of the sets. Only this already filled a big part of the screen so it was impossible to add the images belonging to the set as well (see figure 4.4). Because a child does not know without the flyer which number belongs to the set that he/she has it would be better to choose for a different solution. The decision was made to make a seperate screen for each set so an image of the set can be added, just as the name of the set. The user can now swipe between the different sets and choose the correct set.

27 6.2.C OLLABORATIONBETWEENTHEDEVELOPERSANDTHECLIENT 28

Clear process The screen of the clear process has been changed multiple times. At first the instructions were to clear bricks of a certain color. Because some bricks do not have a specific color this could be confusing for the child. Therefore the client thought that this was actually not the optimal solution. The decision was made to change this to a different step for each brick, and to add an image of the corresponding brick. Now it is very clear for the child which brick is meant, and it is easy to detect if a brick is missing. However, for the large sets this process would take too long, so the client decided that only a few bricks had to remain and the rest had to be deleted. After the decision that the API would be integrated, the bricks could not be selected anymore. Only all bricks from a set could be loaded. The only possibility was to remove bricks at random after loading the set.

Mailing After the task to send an email to Share2Pley was finished, Share2Pley decided that it would take too much work for them to check all these mails. Therefore something that could be shown at the information desk from the holiday park had to be implemented. Share2Pley decided to make a report, so the results of the process could be seen in one glance. An example of this report can be seen in Figure 4.11

Taking a photo The first idea was to take a photo of the total cleared set. Later the client decided that it would be better to take a photo of just one brick. With this photo nothing would be done, but was used so that the child might think that he / she is checked by this photo. Later the decision was made to apply image processing to check if a photo was made of the correct brick. 7 CONCLUSION

7.1. CONCLUSION Share2Pley wanted an application which helps simplify the disassembling process of the ones who loand their LEGO sets. The application had to be made for mobile phones. The desired application has been realized. The important requirements are implemented. Not all the requirements have been implemented because of the mistakes made during the project. The developers worked on some tasks which became useless in a later phase of the project. Thanks to this, the work was not done efficiently. However, the application has been realized within the demanded ten weeks. The client did not know all the possibilities out there. They saw this project as an opportunity to see what could be possible solutions for this problem. Research was done very thoroughly to find that a lot of possibilities were not possible. This was because of variety of reasons: too less time, it cost too much storage, android phones were not capable of all the desired requirements and LEGO does not provide any kind of open source data sharing. This made the application realized within the ten weeks the most to be expected.

7.2. EVALUATION In the chapter problem definition and problem analysis a list of requirements was made. In this section the results of these requirements are explained.

MUST HAVES All the must have requirements have been implemented, however some small changes have taken place. This was of course in consideration with the client. The user can now select the set that has been loaned and follow the described steps. The instructions were to disassemble bricks by color. Now, disassembling must by done brick by brick. A specific brick is displayed which the user has to find and put in the bag. A total of thirty random bricks are selected, so that the application became a random sample. The decision to implement only thirty bricks came from Share2Pley. They did not want to check all the bricks, because this took a large amount of time, which had a negative effect on the playful aspect. The disadvantage of this solution is that not every brick is checked. However, if thirty random bricks are handed in complete, the chance is quite big that all bricks are present. From the statistics of the client it became clear that until now no set was returned incomplete. The playful aspect is present as well. The time of disassembling a set is measured. The child has the goal to disassemble the set within a specific time limit. It is up to Share2Pley to decide if a child would get a reward if the set is disassembled within the time given. At a random position during the clearing process the user is asked to take a photo of the last brick that has been put into the bag. This means that this requirement has changed a little because the original requirement was to make a photo of the cleared set. However, a photo of multiple bricks could not have any kind of image processing. As a result the decision to take a picture of just one brick has been made. The app is not totally language free. The menu contains some language, but this is impossible to remove. Logically, the “about us” page contains language as well. Also, the screen where the time is displayed and the report screen contains some language. This is impossible to remove as well. A solution to this problem would be to add multiple languages. During the project this was not done, because at the end of the project we wanted to focus on technical aspects.

29 7.3.P ROBLEM DEFINITION 30

SHOULD HAVES Most should have requirements have been completed as well. The instructions to build the set have been added in the form of PDF files. The image processing moments take place only once, because the client thought it would be boring for the child if multiple photos had to be made. The function to send an email is not used anymore, but instead a report is made. It is still possible to fill in the name of the user. This name is not used at the moment, but could still be used in the report. Since photos are not uploaded anymore the database does not have to be erased any more. An extra requirement was made during the process. If a user completes a set, this set should not be able to choose again. The database is used to store the sets which have been disassembled. When the app is reloaded, it fetches all the sets from the online server. After the fetching has been done, the sets with the same set ID as in the database will be removed from the set list. This makes sure that only the sets can be chosen which not yet have been completed.

COULD HAVES Both could have requirements are implemented. A screen with references to six related LEGO apps has been made. Also, image processing to check if a photo is made of the correct brick has been implemented.

WON’T HAVES Since the definition of a won’t have is a requirement that can be interesting in further development after this project, the requirement to develop a certificate is not implemented.

7.3. PROBLEM DEFINITION Not all parts from the problem definition have been fulfilled. Part A has been fulfilled by the requirements of taking a photo and giving instructions to clear the set. part B is completed by the playful aspect. part C is not done because it was not realizable to complete this, as described in the problem analysis.

7.4. DISCUSSIONAND RECOMMENDATIONS This section discusses the results of the project, especially all issues that did not go as well as they should have gone. It also gives recommendations about how to improve this in the future.

7.4.1. CONTACT WITH CLIENT The developers have learned a lot by working for a real client. Communication is a very important aspect and as described in chapter 6 this went quite well. It is important that possible solutions are well described, including many details and results. Sometimes these descriptions were not detailed well enough, so some functions have been implemented that were not used in the final app.

7.4.2. TIMESPENDONNON-TECHNICALASPECTS Looking back, too much time has been spent on non-technical aspects. One of them was downloading all the images of the bricks and sets that were used in the app. After the decision to implement this function, some earlier done tasks became useless. These tasks were the local storage of bricks and sets and displaying the most valuable bricks only. Both tasks took lots of time as well. Therefore thanks to earlier mistakes, work could have been done more efficient. However, if the developers knew they could use network support from the beginning, they would have implemented the application more efficient too. The mistake here was that the communication between the customer and the developers was not in full detail. The developers learned that all the solutions have to be discussed in full detail to the customer.

7.4.3. FINAL RESULT The developers are partially satisfied with the final result of the app. The technical aspects are of less quality than expected in comparison with demands given at the start of this project. Sadly, a lot of possible solutions were not applicable, as described in chapter 2. The client is happy with the final result. Though, the app does not guarantee that the set is one hundred per cent complete, a large section of the total bricks is checked for completeness. Also the playful aspect is implemented, as required by the client.

7.4.4. FUTUREDEVELOPMENT Now only an app for android is developed. For the potential users using iOS or Windows Mobile it would be good to develop an app for these operating systems as well. Also, there are no instructions yet how to use the 7.4.D ISCUSSIONAND RECOMMENDATIONS 31 app. The app is evident by itself, but smart instruction on how to use the app are not yet implemented. This decision is made because this is a non-technical aspect. Scanning a stack of LEGO bricks is not possible on a mobile phone because of the lack of storage. However, it is possible to develop a new hardware device with more storage, so scanning will be possible. The certificate has also not been implemented. This can be done in the future as well. Because the infor- mation about all the LEGO sets and the bricks are available, a certificate application can be created. Instead of just 30 pieces, the user can check if all bricks are present within the set. If the user completes all the steps, it means that the user has every brick of the set. This completeness can be converted to a certificate so that when the user decides to sell its LEGO set, the user can prove its completeness. A SIG ANALYSIS

A.1. WEEK 1 [Analyse] De code van het systeem scoort net 4 sterren op ons onderhoudbaarheidsmodel, wat betekent dat de code bovengemiddeld onderhoudbaar is. De hoogste score is niet behaald door een lagere score voor Unit Size en Unit Interfacing. Voor Unit Size wordt er gekeken naar het percentage code dat bovengemiddeld lang is. Het opsplitsen van dit soort methodes in kleinere stukken zorgt ervoor dat elk onderdeel makkelijker te begrijpen, te testen en daardoor eenvoudiger te onderhouden wordt. Binnen de langere methodes in dit systeem, zoals bijvoorbeeld de verschillende ’onCreate’-methoden, zijn aparte stukken functionaliteit te vinden welke ge-refactored kun- nen worden naar aparte methodes. Commentaarregels zoals bijvoorbeeld ’//next button pressed for new instruction’ en ’//find previous instruction’ of de verschillende ’OnClickListener’s zijn een goede indicatie dat er een autonoom stuk functionaliteit te ontdekken is. Het is aan te raden kritisch te kijken naar de langere methodes binnen dit systeem en deze waar mogelijk op te splitsen. Voor Unit Interfacing wordt er gekeken naar het percentage code in units met een bovengemiddeld aantal parameters. Doorgaans duidt een bovengemiddeld aantal parameters op een gebrek aan abstractie. Daar- naast leidt een groot aantal parameters nogal eens tot verwarring in het aanroepen van de methode en in de meeste gevallen ook tot langere en complexere methoden. Wat binnen de Java code opvalt is dat er op verschillende plekken gesproken wordt over een ’id’, ’firstname’ en ’lastname’, drie velden die bij elkaar het concept ’Person’ lijken te vormen. Om bij toekomstige aanpassingen duidelijker te maken wat er precies gebeurd is het aan te raden een specifiek type te introduceren voor deze concepten. Wat verder nog opvalt is dat de model-class ’Set’ een ’hasNext’- en een ’hasPrevious’-methode bevat. Deze concepten hebben een bepaalde semantiek in de Java wereld, maar de manier waarop deze termen gebruikt worden binnen dit project wijkt daar van af. Om verwarrijng te voorkomen is het wellicht goed om een andere naamgeving voor deze concepten te gebruiken. Over het algemeen scoort de code bovengemiddeld, hopelijk lukt het om dit niveau te behouden tijdens de rest van de ontwikkelfase. De aanwezigheid van test-code is in ieder geval veelbelovend, hopelijk zal het volume van de test-code ook groeien op het moment dat er nieuwe functionaliteit toegevoegd wordt.

A.2. WEEK 2 [Hermeting] In de tweede upload zien we dat het codevolume sterk is gegroeid, terwijl de score voor onderhoud- baarheid ongeveer gelijk is gebleven. Bij Unit Size zien we dat de lange methodes die tijdens de evaluatie van de eerste upload werden genoemd nauwelijks zijn aangepost. De onCreate methodes, die eerder als voorbeeld werden genoemd, zijn nog steeds erg groot. Daarnaast zijn in de nieuwe code nog een paar grote methodes toegevoegd, zoals bijvoorbeeld ResultActivity.onCreate (wederom een onCreate). Bij Unit Interfacing zien we wel een duidelijke verbetering. Jullie hebben de methodes met lange param- eterlijsten aangepakt, zoals de constructor van Set, en daarnaast zijn geen nieuwe gevallen meer toegevoegd.

32 A.2.W EEK 2 33

Sinds de eerste upload is er geen nieuwe testcode meer toegevoegd, en de reeds bestaande tests zijn in commentaar gezet. Dit is vermoedelijk vanwege de tijdsdruk gedaan, maar op lange termijn heeft het gebrek aan tests een negatieve invloed op de onderhoudbaarheid en stabiliteit. Uit deze observaties kunnen we concluderen de aanbevelingen van de vorige evaluatie deels zijn meegenomen in het ontwikkeltraject. B SCRUM

This appendix describes the SCRUM planning for each week. Based on user stories tasks are made and di- vided. At the end of each sprint the decision whether a task is finished is taken.

34 35

Week 1

User Story Tasks Assigned To Time reserved Finished Spend Time (hours) As a team Getting the basics Richard & Marijn 20 Yes 30 member, I want of Android to understand development. how to develop Android apps. As a team Setting up Git. Richard & Marijn 3 Yes 2 member, I want to make use of Git. As a client, I Developing the Richard 25 Yes 27 want to basics of the GUI understand how (Start screen, the app will look screen to fill in like. name, menu, menu to choose set). As a Contact the client. Richard & Marijn 2 Yes 1 development team we want to have contact with our client.

36

Week 2

User Story Tasks Assigned To Time reserved Finished Spend Time (hours) (hours) As a user, I want Couting how Marijn 35 Yes 34 to get many bricks of a instructions on certain color a set how to break contains. down the LEGO Develop set. instructions for the user to put x bricks of color y in a bag, until all bricks are cleared. As a client, I Let the user take a Richard 3 Yes 3 want a check if picture during the the set is clear up process. complete.

As a client, I Send the picture Richard 6 Yes 7 want a check if taken by the user the set is to the client. complete. As a client, I Develop a screen Richard 20 Yes 17 want to know where the user the name of the can fill in his/her user. name. After restarting the app, the name needs to be remembers. (Setting up database that remembers the name). As a client, I Implement a Richard 5 Yes 4 want the user to LEGO avatar who have fun in the tells the user the clearing up instructions. process. As a client, I Implement a Marijn 3 Yes 1 want the user to timer function have fun in the that displays the clearing up time at the end of process. the process. As a developer, I Contact with Richard & Marijn 6 Yes 10 want to have client contact with the client.

37

Week 3

User Story Tasks Assigned To Time reserved Finished Spend Time (hours) (hours) As a client, I Create a screen Richard 20 Yes 26 want the user to for each set, see an image where the user instead of the can swipe to the setnumber to next or previous choose a set in set, and select the the set menu, so correct set. that the user better knows which set to use.

As a client, I Develop an Marijn 8 Yes 8 want an animation. animation that shows a brick to go in a bag.

As a client, I Change the avatar Richard 4 Yes 6 want the LEGO for each LEGO set. avatar to be corresponding to the LEGO set. As a client, I Change the image Marijn 32 No 25 want to the brick of the brick after in the animation each step to the to be corresponding corresponding to brick. the brick that has to be cleared out. Each brick should be in a different step, until all bricks are cleared. As a developer, I Contact with Richard & Marijn 6 Yes 4 want to have client contact with the client.

38

Week 4

User Story Tasks Assigned To Time reserved Finished Spend Time (hours) (hours) As a client, I Change the image Richard 20 Yes 8 want to the brick of the brick after in the animation each step to the to be corresponding corresponding to brick. the brick that has to be cleared out. Each brick should be in a different step, until all bricks are cleared. As a client, I Work on the Richard & Marijn 15 Yes 21 want the layout layout: improve to be nice. animation, everything in correct place as the client wants it. As a user, I want Develop a Marijn 6 Yes 7 to know how far progressbar, and I am in the an image of the progress. set that breaks down after each step. As a user, I want Implement a Marijn 5 Yes 5 to tell if I miss a function so the brick. user can declare the amount of missing bricks. As a client, I Create a report at Marijn 4 Yes 3 want to be able the end of the to easily see the clear up process result of the which shows the clearing process. picture taken and the missing pieces. As a client, I Make sure that Richard 20 No 25 want the user the set cannot be not be able to chosen anymore run the clearing after the set is process for a set finished. Save in that is completed local database so already. that this remains when app restarts. As a client, I Add a page with Richard 3 Yes 4 want references references to 39

Week 5

User Story Tasks Assigned To Time reserved Finished Spend Time (hours) (hours) As a user, I don’t Remove bricks Marijn 40 No 25 want the clear up from each set so process to take that only the most to long. valuable bricks remain. As a client, I Make sure that Richard 20 Yes 23 want the user the set cannot be not be able to chosen anymore run the clearing after the set is process for a set finished. Save in that is completed local database so already. that this remains when app restarts. As a client, I Add “about us” Richard 3 Yes 2 want the user to know background information about the company

As a client, I Add instruction Richard 10 Yes 12 want to get rid of books in PDF the paper format to the app instruction books As a client, I Develop message Marijn 2 Yes 2 want the user to in report if faster have 5 seconds than 5 * amount to clear each of bricks and if brick. slower than 5 * amount of bricks As a developer, I Contact with Richard & Marijn 6 Yes 2 want to have client contact with the client.

40

Week 6

User Story Tasks Assigned To Time reserved Finished Spend Time (hours) (hours) As a developer, I Testing Marijn & Richard 80 Yes 65 want the app to everything, and be good looking optimalization. and error prone As a developer, I Contact with Richard & Marijn 6 Yes 4 want to have client contact with the client.

41

Week 7

User Story Tasks Assigned To Time reserved Finished Spend Time (hours) (hours) As a client, I Implement API of Richard 40 Yes 52 want to be able brickset.com and to add new sets rebrickable.com by myself so that the client can add new sets itself. As a client, I Implement image Marijn 40 No 45 want the photo processing to be checked if a photo is made of the correct brick.

42

Week 8

User Story Tasks Assigned To Time reserved Finished Spend Time (hours) (hours) As a client, I Implement image Marijn 15 Yes 22 want the photo processing. to be checked if a photo is made of the correct brick.

C PROJECT DESCRIPTION

43 D INFOSHEET

Name: Share2PleyApp Company: Share2Pley Presentation: 07/07/2015 Final Report: http://repository.tudelft.nl

Description Share2Pley is a company that loans LEGO sets on holiday parks to people who are on a holiday. After these sets are returned, the completeness of these sets needs to be checked. Currently, this is done by weighting the returned set. This is not error-prone because each balance scale has a deviation of a few grams. A LEGO brick only weights a few grams, so if only one or two bricks are missing this will not be notified. On top of that, this method is labor-intensive. Share2Pley wants checking if a set is complete to be automated using a software application (app) for mobile phones. The goal was to develop an app that would guide the user, most of the time a child, to clear the LEGO set. The challenge is to make sure the set will be returned complete, and the user has fun in clearing the set. After some research and some changes through the process this has resulted in an app that guides the user to clear the set. For 30 bricks an instructions will be given to clear that brick, and for one brick is asked to take a photo. To check if a photo of the correct brick is made, image processing is used. For each instruction the child can notify if a brick is missing. As playful aspect a timer is implemented. A time limit is set, and if the child disassembles the set within the time, a complimentary message is given to the child. A report is made including the photo that is made and an overview of the missing bricks. This report needs to be shown at the information desk, so the deposit can be returned. The API of www.brickset.com is implemented. If the client decides to purchase more sets, they can be added easily through www.brickset.com.

Roles Name: Marijn Otte Interests: Algorithms Roles: Development & Testing

Name: Richard Vink Interests: Security Roles: Development & Testing

Olav Bongarts Client [email protected] Client & Coach Jan Hendrikx Client [email protected] Felienne Hermans TU Coach [email protected]

Marijn Otte [email protected] Contacts Richard Vink [email protected]

44 E FLYER

Figure E.1: Outside of the flyer from Share2Pley

45 46

Figure E.2: Inside of the flyer from Share2Pley BIBLIOGRAPHY

[1] Bill Phillips Brian Hardy. Android programming, the big nerd ranch guide, 1989.

[2] Travis Cobbs. LDView, 2009. URL http://ldview.sourceforge.net/.

[3] Pat Cullen. Java Image Comparison / Motion Detection, 2014. URL http://mindmeat.blogspot.nl/ 2008/07/java-image-comparison.html.

[4] url = ldd.lego.com De LEGO Groep title = LEGO Digital Designer, year = 2004.

[5] Flare3D. Flare3d, 2013. URL http://www.flare3d.com/.

[6] Khronos Group. OpenGL, 1992. URL www.opengl.org/registry/api/glext.h.

[7] Software Improvement Group. Sig, 2000. URL www.sig.eu.

[8] D. Richard Hipp. SQLite, 2000.

[9] Dan Malec. BricksViewer, 2003. URL http://sourceforge.net/projects/bricksviewer/.

[10] Huw Millington. Brickset limited, 1997. URL http://brickset.com/.

[11] Linda Sui Neil Mawston. Strategy analytics: Android shipped 1 billion smart- phones worldwide in 2014, 2015. URL http://www.prnewswire.com/news-releases/ strategy-analytics-android-shipped-1-billion-smartphones-worldwide-in-2014-300027707. html.

[12] LDraw Organization. LDraw, 1997. URL http://www.ldraw.org/.

[13] Fabrice Closier Peter Kapelyan Greg Caldwell Andreas Engstrom Stephen White David Lenaerts Richard Olsson Cauê Waneck Rob Bateman, Alexander Zadorozhny. Away3d, 2007. URL http://www.away3d. com.

[14] Yo˘gurt Technologies. Yoghurt3d, 1997. URL http://www.yogurt3d.com/.

[15] Nathan Thom. Rebrickable, 2011. URL http://rebrickable.com/.

[16] Ivan Repin Mikhail Sukhoterin Vladimir Babushkin, Andrey Kopysov. Alternativa3d, 2007. URL http: //old.alternativaplatform.com/en/technologies/alternativa3d/.

47