Programming Exercise II:
My Native Mobile App for a Bookstore
(Detailed, Second-to-None Comprehensive Specifications)
According to a study, students in computer courses learn much more by building large-scale exercises instead of many small-scale test programs like these, which give fragmented knowledge contrary to solid understanding of the system.
Development Requirements
When start developing this exercise, follow the two requirements below:
- Have to use Android Studio and SQLite embedded database to create a native mobile app, instead of a mobile website.
- The exercise should be located at
C:\513\Ex2\ .
Due Date and Submission Methods
On or before Thursday, December 04, 2025 and upload the source code (no documentation needed) to the section “COVID-19 Exams & Programming Exercises” of
Blackboard.
Send an email to the instructor at
wenchen@cs.und.edu including
- The SQL
create commands used, and
- Setting up an appointment to demonstrate your exercise to the instructor individually, so misunderstanding would be minimized.
The mail lists the times you will be available.
The instructor will prepare a set of test data to be used by all students.
Objectives
Companies nowadays require not only web sites but also mobile apps using databases.
This exercise has students design and implement a simple database-driven mobile bookstore from the ground up.
Students learn how to program for the embedded database SQLite by using an Android platform.
Java or Kotlin
Use either Java or Kotlin, but the exams will only cover Java.
In addition, Java is still more popular than Kotlin according to the Slide
1.6.
Requirements
The app includes the following requirements:
- The data of a book includes
- a unique ISBN (10 characters),
- a unique title, and
- a price.
- The data of a customer includes
- a unique ID assigned by the system automatically after signing up,
- a name,
- the information of all purchased books (no duplicate books and no quantities), and
- the total amount spent on the purchased books (one amount per customer).
- (System reset: 10%)
The system can be reset, which is to clear all data stored in the database and files, so the instructor can test the system by using only his own test data.
That is the system has to include a button such as “Clear system” at the system entry page.
- (Input: 10%)
Enter books one by one for the one (and only one) system administrator.
- (Output: 30% total)
For both administrator and customers:
- (Listing all data: 10%)
Both can display all hyperlinked book titles and only administrator can display all hyperlinked customer names.
- (Listing book data: 10%)
List all data of a specific book (including an ISBN, a title, and a price) by clicking its hyperlinked title.
- (Listing customer’s data: 10%)
List all data of a specific customer (including an ID, a name, the books purchased, and the total amount paid) by clicking her/his hyperlinked name.
A customer can only list her/his own data.
- (Customers: 45% total)
For each customer:
- (User-friendliness: 05%)
User-friendliness will be heavily considered when grading.
In the past, some exercises were awkward, which made the grading or browsing difficult.
Evaluations
The following features will be considered when grading:
- Specifications:
- The instructor (or your assumed client) has given the exercise specifications as detailedly as possible.
If you are confused about the specifications, you should ask in advance.
Study the specifications very carefully.
No excuses for misunderstanding or missing parts of the specifications after grading.
- The specifications are not possible to cover every detail.
You are free to implement the issues not mentioned in the specifications, but the implementations should make sense.
Implemented functions lacking of common sense may cause the instructor to grade your exercise mistakenly, and thus lower your grade.
- The exercise must meet the specifications.
However, exercises with functions exceeding the specifications will not receive extra credits.
- Grading:
- This exercise will not be graded if the submission methods are not met.
Students take full responsibility if the app is not working.
- A set of test data will be used by all students. The grades are primarily based on the results of testing.
Other factors such as performance, programming styles, algorithms, and data structures will be only considered minimally.
For example, finding the largest saving could be an NP-hard problem.
Instead of finding an optimizing algorithm, an exhaustive search could be used to find the answer.
- Before submitting the exercise, test it comprehensively.
Absolutely no extra points will be given after grading.
- To make sure the data is saved to and retrieved from permanent storage like a database, the app may be shut down a couple of times during demonstrations.
- The total weight of exercises is 40% of final grade, 20% for Exercise I (ORDB) and 20% for this exercise (EDB or embedded DB).
- Feel free to design your own interfaces; user-friendliness will be heavily considered; each function/button will be tested extensively; and from the source code submitted, the programs will be examined.
- If not specified, NO error checking is required; i.e., you may assume the input is always correct for that case.
- The exercises will be kept until the end of this semester.
They will be used to check against others’ exercises.
The instructor will inform you the exercise evaluations by emails after grading.
- Android platform:
- Android platform has to be used.
- Since no advanced Android features need to be used, the following SDK (Software Development Kit) and IDE (Integrated Development Environment) will be used to grade exercises:
- Android SDK 15.0, API 35,
- Android Studio Koala, and
- Android Virtual Device (AVD) (3.2” QVGA and Marshmallow API level 23).
Make sure that your app works for the SDK and AVD.
- Android emulator (AVD) will be used to grade the exercises.
- No mobile browser will be used to check your app.
- SQLite database:
- The embedded database, SQLite, has to be used to save and retrieve book and user data.
- An embedded database can only store a limited amount of data.
To store more data, Android connecting to a server-side database is covered in the CSCI 457 Electronic and Mobile Commerce Systems.
- The SQL DDL commands such as “
create table” have to be submitted, where SQL is Structured Query Language and DDL is Data Definition Language.
- From the source code submitted, the database design and programs will be examined.
Poor database design or uses will result in a lower grade.
- (-05%) if the database design is NOT optimal.
- (-05%) if the SQL
create commands of database implementation are NOT submitted.
- Try to perform the tasks by using SQL (Structured Query Language) as much as possible because SQL, a non-procedural language, can save you a great deal of programming effort.
- Comments:
- Make the exercise work first.
Do not include extra features, such as passwords, in the beginning.
By the way, you will not receive credits for the extra features.
- Time management is critical for software development. If you are not able to complete the exercise, display whatever you have accomplished, so the instructor can give partial credit to your exercise.
- Many times, simplicity is the same as user-friendliness.
- One way to build a mobile-commerce system from scratch is to design the user interfaces first and then implement the system button by button.
By doing this way, it could simplify the construction.
The recommended construction steps are
- Studying the specifications very carefully,
- Designing the databases (E-R modeling or normalization),
- Implementing the databases (SQL),
- Building the interfaces (XML),
- Implementing the system button by button (Java), and
- Testing the exercise thoroughly.