Reference no: EM132764063

Route

You are to develop an app that provides nutrition facts and information to users. The app should:

1. Contain a list of products (minimum 20 products) so it can be tested. Each product must include at least its name and its nutrition grade (i.e. A, B, C, D, E). You will be able to add more products using screen #2.

2. A screen for adding new products. The user should be able to type a product's barcode or scan a barcode to add it. The data must be automatically loaded using the openfoodfacts API. If the product is found, enable the user to ‘save' it to the list of products (i.e. screen #1).

3. A screen where you can view individual products. For a selected product you should be able to see a description (name), ingredients, and nutrients. Also, you should be able to add (or remove) products from custom lists (see screen #4 below).

4. A screen for managing custom lists (like ‘favorites' or ‘avoid' or ‘healthy'). This screen should enable you to add more lists or delete existing ones. Clicking on a list should show the list of products in that list.

You may hard-code data into the app but to achieve the highest marks in this part, your application should connect to a public, web-based service (see Assessment Criteria below) e.g. to retrieve live information such as the ingredients and nutrients for a selected product.

As part of the app you will need to maintain a small database to store the products and their mapping into lists.

For this you will use an SQLite database. An example database is provided for you and you are free to build from scratch or extend it as you wish. This is a simplistic database with just three tables named ‘lists', ‘products' and ‘products_to_lists'. The first table holds the details of each list (id, name, description, perhaps colour). The second holds details for each product (id, name, ingredients, nutrients etc.). You can use the openfoodfacts API to see the available data. The latter table uses foreign keys to match products to lists. This is illustrated in the figure below:

Figure 1: Schema of the ‘products', 'lists' and ‘products_to_lists' tables

In the "products" table the ‘code' is the primary key (it can take values such as ‘20503550', ‘3052X22A', etc.) The ‘name' is the product's name (e.g. "Kellogs Corn Flakes"), ‘grade' is a text-based rating of the nutritional value of the product (usually ‘A', ‘B', ‘C', ‘D', and ‘E'). Similarly, the nova group is a numerical rating of the nutritional value of the product. The ingredients and the nutrients can be text-based descriptions of the contents of the product (like "sugar 50%, salt 5%", etc.) Note this is only one way to (simplistically) hold the information. You could also hold the structured data you receive from the openfoodfacts API in separate tables, or perhaps as a JSON-formatted string which continues to hold the information. Additional data you could include are ‘vegan', ‘vegetarian', etc. (SQLite does not directly support Booleans. Instead, you could use integers where 0 is false and 1 is true).
The "lists" table holds data about the lists you use to organize the products. At the very least they include an ID, name and description, but you could further customize with colour, icons, etc.

Finally, the ‘products_to_lists' table is used to provide mappings from products to lists. The two fields together form the primary key, and individually are foreign keys to the corresponding products and lists tables. Adding an entry introduces the mapping of the product to a list. Removing it eliminates the mapping. This way you can have multiple mappings of the same products in multiple lists, and multiple products in the same list. SQLite has a simplified set of data types compared to other database engines such as MySQL.

THE BRIEF/INSTRUCTIONS
Your coursework assignment is to design then develop a mobile application. The following pack outlines the basic components and advanced features your application needs for assessment. The second route is pre-defined - this is the route for you, if you would prefer to be told exactly what to create. Both the routes are assessed in the same way, there is no one route better than the other. It is personal choice for each individual student.

Attachment:- SQL_work.rar