Programming Exercise II: A Native Mobile App for a Bookstore
(Industry-Level and Second-to-None Comprehensive Specifications)

---

Absolutely no copying others’ works
Development Requirements
When start developing the exercise, follow the requirements below:

• Superuser (managing the bookstore through desktop web browsers):
  
  
  • The book and customer data should be saved to and retrieved from the server-side/cloud-based MySQL database.
  
  
  • The system entry page must be located at http://undcemcs02.und.edu/~user.id/457/2/ and all pages must be hosted by http://undcemcs02.und.edu/~user.id/ .


• Customers (interacting with the bookstore through emulators/smartphones):
  
  
  • Have to use Android Studio to create a native mobile app, instead of a mobile website.
  
  
  • The exercise should be located at C:\457\Bookstore\ .

---

Due Date and Submission Methods
On or before Wednesday, May 01, 2024. Send an email to the instructor at wenchen@cs.und.edu including

• the password for displaying the source code (including one interface for all Android code) online (only one password for all exercises and interfaces),
• the SQL create commands used, and
• an appointment to demonstrate your exercise to the instructor individually, so misunderstanding would be minimized. The instructor will prepare a set of test data to be used by all students. The instructor’s Zoom ID is https://und.zoom.us/j/2489867333 .

---

Objectives
This exercise is to design and implement a native mobile app on Android devices. Students learn how to build a mobile app connecting to the servers.

---

Requirements
This exercise is to build an app for a local bookstore by using Android Studio. It includes the following requirements:

• The data of a book includes
  
  
  • a unique ISBN (10 characters),
  • a title, and
  • a price.


• The data of a customer includes
  
  
  • a unique ID (assigned by the system automatically after signing up),
  • a name,
  • an account including
    
    
    • a list of purchased, unique books (no duplicate books and no quantities) and
    • a total amount spent on the purchased books (one amount per customer).


• [Superuser (managing the bookstore through desktop web browsers): 25% total]
  For the one and only one superuser:
  
  
  • (System reset: 05%) 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.
  
  
  • (Entering books: 05%) Enter books one by one.
  
  
  • (Listing all books: 05%) List all books each including (i) an ISBN, (ii) a title, and (iii) a price.
  
  
  • (Listing all customers: 05%) List all customers each including (i) an ID, (ii) a name, and (iii) a hyperlinked total amount.
  
  
  • (Listing all purchased books: 05%) After clicking on the hyperlinked amount, list the titles of all books purchased by the customer.


• [Customers (interacting with the bookstore via emulators/smartphones): 65% total]
  For each customer:
  
  
  • (Signing up, in, and out: 15%) Customer can sign up, in, and out.
  
  
  • (Searching for books: 15%) List the book if its title includes any case-insensitive keywords in a query entered by users. The query is a list of keywords separated by spaces. If the query is empty, list all books. Each result includes (i) a checkbox (for purchasing) and (ii) a hyperlinked title.
  
  
  • (Purchasing books: 15%) After searching, purchase several books (but not all the listed books) at the same time. If the books have been purchased before, ignore the books.
  
  
  • (Checking her/his own account: 10%) List the customer’s (i) ID, (ii) name, (iii) hyperlinked titles of all purchased books, and (iv) total amount.
  
  
  • (Showing the details of a book: 10%) List the book’s (i) ISBN, (ii) title, and (iii) price by clicking on its hyperlinked title.


• (Instructor’s requirements: 10% total)
  Other than the above system requirements, the instructor has the following requirements:
  
  
  • (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.
  
  
  • (Plagiarism-proof: 05%) It is for the instructor to find any plagiarism. Each web interface includes a button “Display source,” which is to list ALL the source code for implementing the functions of this interface. In addition, there should have more than one button on a web page listing all source code of Android. Only one password is for all exercises and interfaces. The system will be highly suspected if fail to implement this button.

---

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 for 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.
  • 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 the final grade, 13% for this exercise (e-commerce system), 14% for Exercise II (m-commerce system), and 13% for Exercise III (AJAX).
  • If not specified, no error checking is required; i.e., you may assume the input is always correct for that case.
  • 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 database design and programs will be examined.
  • The systems have to be active until the end of this semester. They will be used to check against others’ exercises for any plagiarism. The instructor will inform you the exercise evaluations by emails after grading.


• Desktop web browsers:
  
  • Desktop web browser will be used by the superuser to manage the bookstore.
  • The newest Firefox browser will be used to grade exercises. Note that Internet Explorer, Chrome, and Firefox are not compatible. That is your exercises may work on the IE or Chrome but not Firefox.


• 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) was used by the instructor:
    
    
    • Android SDK 6.0, API 23,
    • Android Studio 1.3, and
    • Android Virtual Device (AVD) (3.2” QVGA and Lollipop API level 21).
    
    
  • Android emulator (AVD) will be used by the customers to interact with the bookstore.
  • No mobile browser will be used to check your app.


• MySQL database:
  
  • MySQL database hosted by the NDUS has to be used to save and retrieve book and customer data.
  • 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. The same is applied to the server-side PHP programming because client-side Java programming is more difficult.
  • There are many advantages of using databases. If database is not used, the problems caused by not-using-transaction must be considered. For example, if two customers are enrolled at the same time, an ID may be assigned to different customers if databases are not used.


• 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.
  • 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
    
    
    1. Studying the specifications very carefully,
    2. Designing the databases (E-R modeling or normalization),
    3. Implementing the databases (SQL),
    4. Building the interfaces (XML),
    5. Implementing the system button by button (Java), and
    6. Testing the exercise thoroughly.
    
    
  • Many times, simplicity is the same as user-friendliness.