The ProProductScanner is an application where the users can track their items in their fridge. The aim is to help the users with shopping and at the same time keep track of their items in their fridge. When the users are shopping they will be able to scan the barcodes on the items that are in a store, when they do so, they can see information about the product they have scanned and at the same time they can add the product to their virtual shopping basket. When they are done shopping, the user will be able to checkout with their scanned basket and pay for the items. This reduce the time the user must wait for a clerk to scan their products for them. The scanned items will automatically be added to the user’s fridge also the expiry date on each item will begin to be tracked, this means that the user can check the app to see a list of items that is close to expiring this would help the user waste less food.
Methods and materials
In the process of making the app there has been used different methods to design the UI and the structure of the code. Some of the methods is described in this chapter.
To find the application that the team wants to work with, there was made a brainstorm where the team members listed all the ideas that they had for an IOS application. For each of the ideas the team listed all opportunities each idea had. Afterwards, all the ideas was discussed in the group and which idea that was most appealing to the group.
Use Case Diagram
This type of diagram helps with showing in a graphical way how the user will interact with the system. The diagram shows the developers how the different functions connects, and in the same time how the different functions trigger each other.
Before making the actual UI design for the application, there has been made some mockups using Balsamiq mockup. The mockup program contains all the basic UI design elements for iOS which makes it fast and easy to work with. By doing so there was opportunity to receive user feedback on the final design, which increase the user experience because we can filter out bad designs early in the design phase.
From the brainstorming we came up with several ideas, one of the things that was high rated by the team members was that the project should include various kinds of technologies. The project that we choose included a backend with authentication and a database, the use of the camera, and possibility for integrating a api. The benefit of the project included various kinds of technologies was that we got to work with more different things compared to focus and specialize a lot on one thing.
Use case diagram
The use case diagram was made with an actor that was the user and the store. The user actor is the one using the application, he will be able to interact with different functions such as scan products, view fridge, view shopping cart and view expired products. Each of these functions may trigger other functions such as from scan product to add to shopping list. By making these relations we were able to see how the application was fitting together.
The creation of the mockup designs was helping us with choosing the best design from the start. We made some different designs of the UI using the tool Balsamiq mockup and showed our applications to fellow students. The feedback helped us sort some of the less desired design out early in the process.
Some of the feedback gotten, were to keep the GUI as simple as possible. The users preferred icons over text and being able to see all features on the initial menu screen. The icons should be big and easily recognizable to avoid any confusion on where each button press took you. The users liked the concept of having a list that showed the items in the fridge and the opportunity to add products to a shopping list while shopping. But pointed out some flaws in the design that would simply be too much work for the scope of this project. The cut features were mainly cut because of possible security risk, and it would require more backend development time to make user friendly.
With the feedback were we quickly able to define the gui and avoided having to program redesigns once the application had been created. The feedback also helped us determine a more realistic scope for the project, to avoid being stuck on features that might not have been viable in the time we had to implement them.
The code is structured after a pattern called the MVC design pattern, it consists of a model, a view and a controller. The Model is where the data is stored, in this application it is information regarding the user and information about the products. The View is the UI that the user interacts with also known as the frontend of the application. The Controller is the logic code that operates between the view and the model.
The MVC pattern ensure that the calls between the code follows a structure. The view is only allowed to call code in the controller and the controller can update the view, the controller can update the model layer and the model layer can notify the controller. Furthermore, the view is not allowed to call the model directly it must go through the controller.
By using the MVC design pattern we ensure that the code is separated up in smaller pieces, instead of having a huge controller. This increase the possibility to reuse the code, test the MVC independently from the other code and makes the code easier to understand.
The Application uses the camera on the host device to recognize barcodes, that are located on the products that are scanned. When the user first time use the barcode scanner for the first time, they will be asked for permission for the application to access the camera. If the user does not allow camera access there will be shown a warning box which tells the user to allow it before they can scan barcodes.
The barcode scanner uses the build in AVFoundation framework which allows to scan common types of barcodes such as EAN-8 and EAN-13. When the camera detects a barcode, it calls a function “metadataOutput” which forward a string with the barcode that was detected. When a barcode is detected, and the barcode is not found in the database then the user will have an option to create the product. If the product is found in the database, the user will be able to view information about the product.
There is used a backend for the application called Google Firebase, this backend supports a wide range of features such as user login and a database to store data. The benefit of using Firebase it’s free to use and easy to setup, which was some of the main reasons of using it in this project.
Each user has some personal data that we want to store, this is for example the items that they have in their fridge. When the user signup in the application with their email and password a unique uuid is created for the specific user, this helps identify each user’s data in the database.
There is also public data in the database, this is for example each product that can be scanned by the users, these data make sense to share between the users because if one user created a new product another user will able to scan it afterwards and receive the data from the first user. By making the products shared between the users, this helps with letting the product database grow quickly.
The first time a product barcode is scanned, the application will make a http request to https://world.openfoodfacts.org/ (Open api for food information based on barcode). This open api then returns json data that is relevant to the specific product. The initial implementation allows for name, company, size and nutrition facts, however more information is available if the product demands it in the future. The data is also stored in the database, this way you only need to depend on the api the first time and thereby limiting the risk by not depending on this unknown factor. If no data is found standard values are stored instead that a user can change manually.
Right now, the only option the user have is to add items to the fridge or shopping cart. The cart can add all it’s items to the fridge on check out. But the option for removing a single item is still missing. There were not enough time to make everything work, so the team prioritized the most important features, and thereby scrapping removal of products from list. This would most likely be the first extra feature to be added after release.
Right now, there isn’t a possibility to look at all the expired products in your fridge, the problem is that we cannot read the expire date from the barcode. The possibility was one we were planning on implementing but couldn’t find an intuitive solution. The best case would be taking a picture of the date and with image recognition it could bind the date to the product. This would take too long to implement. A second option is to have the user manually type in the date. But this couldn’t be made in a user-friendly way, that made sense in the early development. Future development would allow for the feature to be implemented as intended.
The app could work as a payment option. This way you can prescan all the products when shopping, and then just check out and pay through the app. This idea had a lot of loose ends. There were too many security risks to make it viable in the time we had for the product. If there were the time for it, and if we could get collaborate with the stores, then it would be a possibility.
The app is only made for iPhone. This means that if the app is used on an iPad, the current constraints might not sufficient to keep the app user friendly. The application was made with iPhone use only in mind. Future development could be to migrate it to iPad’s.
The biggest issue during the development were mainly not always having a proper testing platform available. Only being able to test some features of the application in certain time intervals, meant that there had to be made certain workarounds. This took some development time away from new or improving features.
There is error handling throughout the code. But with the limited testing, and some features barely being ready, does it mean that proper testing were not conducted to determine every possible flaw. There is some trouble with the app when there is no network connection. There is no way at the moment to notify that the there is no connection to the database or api used. This is easily fixed but will take some time to properly test out.
Constraints and GUI programming were a challenge for both members of the team, since none of us had a lot of experience with front-end development. The application is made with a horizontal iPhone in mind, since it made the most sense for this type of application. This means that not all constraints are tested properly in different type of scenarios (e.g. vertical phone, iPad’s, larger or smaller phones than iPhone 6-8) this means that user experience might be lacking if the development for iPad or vertical mode is planned.
Callback method is often used in swift programming, especially with network connections. This is not a standard feature in java that are the team’s language of choice. This means that some of the callbacks made might not be best practice. That being said, most of the callbacks are handled to the best of the team’s skill set.
If the team look back at the whole process of development, there is features we could have had more focus on, like the missing features, or making the frontend more appealing. If the team used more time in the beginning to make a better plan of the code and how to handle the issue with testing, maybe we could have saved some development hours. There was code that were duplicated at times because the team members wasn’t good enough to inform each other on who was doing what exactly. With proper testing equipment for both members, and a better initial plan, could the team properly have met most goals. However, even though there was some drawbacks in the project, the overall outcome was satisfying for both members. We was able to learn new things in Swift and the mobile development platform. We was able to work with backend and frontend of a language that none of us had experience with, and were able to develop a product that met most of the requirements that the team have established from the start. The experiences gained have definitely given a good foundation for a iOS projects and help improve future applications.
Jesper Kragh Jørgensen
Marc Grønhøj Nielsen