EE308FZ Team EmoGenius Crew Assignment 6:

[EmoGenius Grew]

EE308FZ Team EmoGenius Crew Assignment 6:
Extreme Programming-- Back-end separation calculator programming with login module

The Link Your Class	2301-MUSE Community
The Link of Requirement of This Assignment	Back-end separation calculator programming with login module
Team name	EmoGenius Crew
The goal of this assignment	Extreme programming in limited time
Other references	No reference

Links of documents

Repository Address in Github	EmoGenius Crew's Extreme Programming
Access Address to Server	EmoGenius URL

Catalogue

• Ⅰ. Team Labor Division of Assignment 6 (Extreme Programming)
• Ⅱ. Organization method in Assignment 6 (Extreme Programming)
• Division of Labor in Ditails:
• Team organization method
• Ⅲ. Description of functional implementation ideas
• Front-end functional implementation ideas
• Logo
• Register
• RegisterActivity
• RegisterAsyncTask
• RegisterHTTPUtil
• Login
• MainActivity
• LoginAsyncTask
• LoginHTTPUtil
• PersonalInfo
• PersonalinfoActivity:
• PersonalinfoMessage:
• PersonalInfoAsyncTask:
• PersonalInfoHttpUtil:
• ScientificCalculator
• CalculatorAsyncTask:
• CalculatorHttpUtil:
• CalculatorAsyncGetHistory:
• CalculatorHistoryHttpUtil:
• CalculatorHistoryActivity:
• Interest rate calculator
• Front-end functional implementation ideas
• Ⅳ. Program outcome display and screenshot
• Opening page
• Screenshot Display
• Video Display
• Login Function
• Screenshot Display
• Video Display
• Register Function
• Screenshot Display
• Video Display
• Home Function
• Screenshot Display
• Scientific Calculator Function
• Screenshot Display
• Video Display
• Deposit and Lone Calculator Function
• Screenshot Display
• Video Display
• Personal Info Function
• Screenshot Display
• Video Display
• Ⅴ. Difficulties encountered in cooperation and solutions
• Yifan Wang
• Guohua Wu
• Tianjun Shi
• Yuhao Lu
• Xindan Zhang
• Binyue Zheng
• Yanbo Wang
• Haoyuan Zheng
• Zhaoyou Wang
• Guandong Li
• Ⅵ. PSP table of each member
• Yifan Wang
• Guohua Wu
• Tianjun Shi
• Yuhao Lu
• Jingzhen Fan
• Xindan Zhang
• Haoyuan Zheng
• Binyue Zheng
• Yanbo Wang
• Zhaoyou Wang
• Guandong Li
• Ⅶ Take a screenshot of Github's submission log

Ⅰ. Team Labor Division of Assignment 6 (Extreme Programming)

This table demonstrates the Team Division of Labor of Assignment 5(Not the overall project, just Assignment 5).

Student ID	Work distribution	Contribution
Wang Yifan	UI Graphics deployment, Front-end development, Front and Back end communication docking, Blog essay, Project Management	35%
Wu Guohua	Back-end development, Front and Back end communication docking	25%
Shi TianJun	Front-end development, Front and Back end communication docking	14%
Lu Yuhao	Back-end development	10%
Zhang Xindan	UI Graphics Deployment & Design	3%
Fan Jinzheng	Front-end development	3%
Zheng Haoyuan	UI Graphics Design	2%
Zheng Binyue	UI Graphics Design	2%
Wang Yanbo	UI Graphics Design	2%
Wang zhaoyou	UI Graphics Design	2%
Li Guandong	Front-end development	2%

Ⅱ. Organization method in Assignment 6 (Extreme Programming)

For this Extreme Programming (XP) session, our team is divided into three main groups: UI Design Team, Frontend Programming Team, and Backend Team.
After a thorough understanding of the task requirements, the project leader, leveraging existing resources, conducted preliminary ideation and code writing for the project. Tasks were cleverly assigned to team members, allowing each member to focus on their respective expertise.
Once the basic framework, activity classes, and main components of the Android app were determined, the project leader provided detailed instructions for UI prototype design. Additionally, the leader defined the methods and content for communication between the frontend and backend, setting clear deadlines. This process helps ensure a consistent understanding of the project goals across the entire team and provides clear direction for each group's work.
During the task allocation phase of the project, the team has made significant progress, laying a solid foundation for subsequent work.

Division of Labor in Ditails:

Yifan Wang: UI Graphics deployment, Front-end development, Front and Back end communication docking, Blog essay, Project Management (35%)
Guohua Li: Back-end development, Front and Back end communication docking (25%)
Tianjun Shi: Front-end development, Front and Back end communication docking (18%)
Yuhao Lu: Back-end development (7%)
Xindan Zhang: UI Graphics Deployment & Design(5%)
Jingzhen Fan: Front-end development(3%)
Haoyuan Zheng: UI Graphics Design (2%)
Yanbo Wang: UI Graphics Design (2%)
Binyue Zheng: UI Graphics Design (2%)
Zhaoyou Wang: UI Graphics Design (2%)
Guandong Li: Front-end development (2%)

Team organization method

1. Regularly assess team performance: Evaluate team performance periodically, identify problems, and take timely measures for improvement. Regular performance assessments help the team identify issues and make adjustments and improvements promptly
2. Team meetings: In order to better coordinate the work among all members, we will hold a meeting every day, in which we will explain their progress and give the next schedule.
3. Communication: Our group communicates and collaborates through offline communication and online voice communication. All members are serious and responsible for their work and can complete the task in a short time.
4. Feedback: We will give feedback and improvement regularly, each member will put forward their own views on the work, and finally we will jointly decide on a best improvement plan.
5. Mutual Support and Encouragement: We place a high value on mutual support and encouragement among team members. When a team member encounters challenges, we make every effort to assist and motivate them.

   Ⅲ. Description of functional implementation ideas

   This project adopts a front-end and back-end separation approach for Android development. The front-end primarily utilizes Android Studio for activity navigation, user interaction, data processing and communication, as well as implementing business logic. On the other hand, the back-end is responsible for data storage and interaction with the database. The front-end and back-end were collaboratively developed by two teams comprising four students, actively coordinating data integration, and ultimately achieving successful implementation. In this section, we describe the functional implementation ideas for the frontend and backend separately.

   Front-end functional implementation ideas

   The project can achieve the following functionalities:
6. User Authentication and Registration: Ensure secure user authentication and data safety through login and registration processes.
7. Scientific Calculator: Support various scientific calculations and allow users to query their calculation history.
8. Interest Calculation: Assist users in understanding the interest rates and returns on their deposits, supporting queries and modifications of interest rate records.
9. Personal Information: Record user account information such as username and nickname, allowing users to modify their details.
   

   

   
   This class diagram shows the transition of the various active classes in the frontend.
   Upon running the project, the Logo interface (Logo Activity) is displayed first. Afterward, the user enters the login interface (Login Activity), where they can input their account credentials or proceed to register. During login, the user's entered information is transmitted to the server using the HTTP protocol to verify the account's existence and the correctness of the password. In case of registration, the server stores the user-entered information for future logins. Upon successful login, the user enters the main interface (Home Activity), where they can choose their desired operations.
   The Home Activity class interacts with the Scientific Calculator Activity class, which handles scientific calculations. It also interacts with the Scientific Calculator History Activity class, responsible for displaying the user's calculation history.
   Home Activity communicates with the Interest Rate Calculator Activity class, which calculates interest rates/interest and supports user modifications. It also displays the user's history of queries and modifications.
   Finally, Home Activity interacts with the Personal Info Activity class, responsible for recording user account information. Users can modify their information within this interface.

   Logo

   

   
   LogoActivity is the launch activity (LogoActivity) in an Android application. Its primary function is to display a logo page with the application's logo when the app is launched. After a 5-second delay, it automatically transitions to another activity (MainActivity). To prevent users from seeing the Logo page again when pressing the back key, the finish() method is called.

Register

RegisterActivity

RegisterActivity implements the logic for the registration page. When the user clicks the registration button, it retrieves the entered username, password, and email information. It then uses the RegisterAsyncTask asynchronous task to send a registration request to the server. During registration, it checks if the entered passwords match and displays a corresponding prompt if they don't. After sending the registration request, the registration result is handled through a callback mechanism. If registration is successful, it navigates to the main page (MainActivity); otherwise, it displays a registration failure message.

RegisterAsyncTask

RegisterAsyncTask uses the RegisterHTTPUtil class's sendPost method to send a registration request to the server. The onPostExecute method handles the result of the request. When processing the result, it parses the returned JSON data, determines the success of the registration, and notifies the caller through a callback interface (OnRegisterResultListener). If registration is successful, the onRegisterResult method in the callback passes true; otherwise, it passes false.

RegisterHTTPUtil

This code is a utility class (RegisterHTTPUtil) for sending user registration requests to the server. It uses the HTTP POST method to encapsulate the provided username and password in JSON format. It then sends this data via a URL connection to the designated registration server for storing user account and password information.

Login

MainActivity

This is the implementation of the main activity (MainActivity) in an Android application. Its main functionalities include user login, remembering account credentials, and facial recognition for photo uploads. In the user login section, it retrieves the username and password, utilizes the LoginAsyncTask for an HTTP request. If the request returns true, it navigates to the HomeActivity; if false, a "Login failed" message dialog is displayed, indicating incorrect password input or the non-existence of the user. This achieves user login functionality. Additionally, it provides the feature to remember account credentials by saving user input data using SharedPreferences, enabling automatic filling on the next app opening.

LoginAsyncTask

To prevent user interface lag and provide a smoother experience, as well as to avoid executing time-consuming tasks on the main thread, an asynchronous thread is used to handle user login. The doInBackground method executes network operations. It uses the LoginHTTPUtil class to send a POST request for user login validation. After the login request's result is returned, it parses the JSON-formatted response data to determine the success of the login. If successful, it notifies the caller through a callback interface, extracts user information, and saves it to SharedPreferences, including username, age, gender, and a personalized signature.

LoginHTTPUtil

This is an HTTP utility class (LoginHTTPUtil) for handling user login. Its main function is to send a POST request to a specified URL, transmitting the provided username and password information. Before sending the request, it constructs JSON-formatted data containing the username and password using JSONObject and sends it as the request body. It establishes a connection using HttpURLConnection, sets the request method to POST, configures request header information, writes the JSON data to the output stream, and then retrieves the server's response. If the response code is 200, indicating a successful request, it converts the server's returned input stream into a string and returns it as the result; otherwise, it returns null.

PersonalInfo

PersonalinfoActivity:

In this activity, users can fill in and save personal information, including username, signature, gender, age, etc. Additionally, users can choose an avatar from the system gallery, and the avatar is uploaded to the server in Base64-encoded form. The activity also includes a button to navigate to a camera page for capturing portraits. The user-entered personal information is sent to the server for storage through the PersonalInfoAsyncTask asynchronous task class. Saved personal information and avatars are retrieved from SharedPreferences upon activity startup and displayed in the corresponding EditText and ImageView.

PersonalinfoMessage:

It contains static variables for username (user) and password (psw), along with corresponding methods for retrieval and setting. This allows other classes to directly access and set user login information through the PersonalinfoMessage class, achieving information sharing and access.

PersonalInfoAsyncTask:

Executes background network requests related to personal information. This class includes an interface, OnPersonalInfoResultListener, for handling callbacks on personal information request results. The setCallback method is used to set the callback interface, notifying the caller to process the result after the network request is completed. In the doInBackground method, the PersonalInfoHTTPUtil class's sendPost method is called to execute the network request, passing the appropriate parameters.

PersonalInfoHttpUtil:

Used for sending POST requests for personal information to the server. Specific functionalities include constructing JSON-formatted personal information data, sending the data via an HTTP PUT request to a specified URL, and handling the server's response. This class allows packaging user information such as username, password, nickname, age, gender, and signature into JSON format, then sending it to the server via an HTTP connection. When sending the request, it sets the Content-Type of the request header to "application/json," indicating that the data in the request body is transmitted in JSON format. When retrieving the server response, it reads the response's input stream and returns the result as a string.

ScientificCalculator

### ScientificCalculatorActivity:
This code represents the primary logic implementation of a scientific calculator, including the initialization of interface buttons, handling button click events, converting infix expressions to postfix expressions, performing postfix expression calculations, and error checking. During the initialization phase, it sets up click and touch event listeners for buttons on the interface, with touch event handling managed by the ScaleTouchListener class. Button click event handling involves appending the button text to the current editing box and constructing the corresponding mathematical expression string. In the equals button click event, it converts the infix expression to postfix and performs the calculation, finally displaying the result in the editing box. Additionally, it uses the CalculatorAsyncTask asynchronous task to send the calculation expression and result to the server. Upon receiving the server's returned history records, it displays them in the calculator history interface.

CalculatorAsyncTask:

Primarily responsible for sending calculator expressions and user information to the server via an HTTP POST request. It uses the sendPost method of the CalculatorHTTPUtil class to send the request, executing in the background thread without blocking the main thread. This AsyncTask does not handle specific return results upon completion but rather passes the result to the caller through the callback interface OnCalculatorResultListener.

CalculatorHttpUtil:

This code is a utility class for sending calculator results and user information to the server via HTTP POST requests. It includes the processes of establishing an HTTP connection, setting request headers, sending data to the server in JSON format, and retrieving the server's response results. Specifically, this utility class is used to send calculation results and usernames to a specified URL and return the server's response.

CalculatorAsyncGetHistory:

A utility class for retrieving calculator history records from the server via HTTP GET requests. It includes processes such as establishing an HTTP connection, setting request parameters, receiving server response results, and passing the results to CalculatorHistoryActivity through a callback.

CalculatorHistoryHttpUtil:

A utility class for sending POST requests to the server. It uses an HTTP POST request to upload user calculator history records to a specified URL, including processes such as establishing an HTTP connection, setting request parameters, sending JSON-formatted data, and receiving server response results.

CalculatorHistoryActivity:

This code represents an Android application activity for displaying calculator history records. It uses the CalculatorAsyncGetHistory class to execute an asynchronous task to retrieve the user's calculator history records and displays the results on the interface.

Interest rate calculator

The interest rate calculator is designed to present relevant information based on the user's selected operation. Users first choose between a deposit or a loan, and then select the deposit term/loan period to inquire about the deposit interest rate/loan interest. In addition, the calculator offers functionality for modifying interest rates/interests and querying historical records, adding greater practicality to the software.

In the implementation of the interest rate calculator, the Spinner control is utilized to create a dropdown list, allowing users to easily choose between deposit or loan options and select the term for deposit or loan. Textbox controls are employed to display information, such as whether the user has chosen a deposit or loan and what the loan interest rate is. For data transmission, the InterestAsyncTask asynchronous task is employed to send queries or modifications to the server. The InterestRateHttpUtil is used to send POST requests to upload information to a specified URL, involving the establishment of an HTTP connection, setting request parameters, sending data in JSON format, and receiving server response results.

Furthermore, users can also click the "History" button to view past modification or inquiry records. When users enter the History activity class, the InterestRateAsyncGetHistory asynchronous task is used to send requests to the server. The InterestRateHistoryHttpUtil is employed to send POST requests to upload information to a specified URL, including establishing an HTTP connection, setting request parameters, sending data in JSON format, and receiving server response results. Ultimately, InterestRateAsyncGetHistory uses a callback interface to pass information to the History activity class, realizing the functionality of querying historical records

Front-end functional implementation ideas

The CalculatorController class is responsible for receiving requests from the client and invoking corresponding service and DAO methods to handle and manipulate calculator history record information in the database. The ExpressionRequest class functions as a simple data structure used to store and pass expression strings.
The CalculatorController class is tasked with handling HTTP requests related to calculator history records. The InterestController class manages HTTP requests for the addition, update, and retrieval operations of deposit and loan interest rates. The UserController class handles HTTP requests for user registration, login, information updates, and logout operations. It receives objects from the request body, then calls the appropriate service class methods to handle business logic and returns the results.

Specifically:
register: Handles the POST request for "/register," used for user registration. It receives a User object as the request body, performs validation, calls the userService's register method for registration, and returns a Result object.
login: Handles the POST request for "/login," used for user login. It receives a User object as the request body, performs validation, calls the userService's login method for login, sets session information upon successful login, and returns a Result object.
update: Handles the PUT request for "/PersonalInfo," used for updating user information. It receives a User object as the request body, performs validation, calls the userService's update method to update user information, updates session information, and returns a Result object.
logout: Handles the GET request for "/logout," used for user logout. Sets the user information in the session to null, indicating the user has logged out, and returns a successful Result object.
Four DAO interfaces define database operations related to calculator history records, including adding new records, querying history records based on user accounts, and deleting history records for specific users. They also include operations related to deposit and loan interest rate information, such as adding new deposit and loan rate information, querying rates based on periods, and updating rate information. Additionally, they cover operations related to the user table, including adding user information, querying user information based on accounts, and updating user information.

Five objects are defined: CalculationHistory, depositInterest, loanInterest, Result, and User.
The CalculatorServiceImpl class provides methods to save, read, and delete calculator history records. It executes database-related operations through the injected calculatorHistoryDAO object. The InterestRateServiceImpl class provides methods to save, update, and read deposit and loan interest rates. It executes database-related operations through the injected depositDAO and loanIntDAO objects. The UserServiceImpl class provides methods for user registration, login, and updating user information. It interacts with the database through the injected userDAO object.

Specifically:
Result register(User user): Implements the UserService interface's register method. Checks if the username already exists in the database using userDAO.getByAccount(user.getAccount()). If it exists, returns a registration failure message; otherwise, calls userDAO.add(user) to store user information in the database and returns a registration success message.
Result login(User user): Implements the UserService interface's login method. Checks if the user exists in the database using userDAO.getByAccount(user.getAccount()). If the user doesn't exist, returns the corresponding failure message. If the user exists, it verifies whether the password matches. If the password doesn't match, returns the corresponding failure message. If both the username and password match, returns a login success message.
Result update(User user): Implements the UserService interface's update method. Checks if the user exists in the database using userDAO.getByAccount(user.getAccount()). If the user doesn't exist, returns the corresponding failure message. Checks if the fields in the incoming user object are empty; if empty, retains the values of the corresponding fields in the database. Finally, calls userDAO.update(user) to update user information and returns an update success message.

Ⅳ. Program outcome display and screenshot

Opening page

When the user opens the APP, our project LOGO is automatically displayed for five seconds. After that, it will automatically jump to the login screen.

Screenshot Display

Video Display

Because we want to show the log printing of communication, we want to prove the excellent interaction ability of the front and back end, so we recorded the full screen, which may be a little hard to see, please forgive me!
Because we want to show the log printing of communication, we want to prove the excellent interaction ability of the front and back end, so we recorded the full screen, which may be a little hard to see, please forgive me!
Because we want to show the log printing of communication, we want to prove the excellent interaction ability of the front and back end, so we recorded the full screen, which may be a little hard to see, please forgive me!

Login Function

When the user clicks the login button, the front-end converts the account and password into JSON and sends it to the back-end server. The backend server checks if the login was successful. If the account does not exist or the password is wrong, the login will not be successful. Otherwise, the login will succeed.
In addition, we will provide a portrait recognition login function. If the user has entered personal portrait information, he can log in through portrait recognition.

Screenshot Display

Video Display

Because we want to show the log printing of communication, we want to prove the excellent interaction ability of the front and back end, so we recorded the full screen, which may be a little hard to see, please forgive me!**

Register Function

In the registration function, the user can apply for an account through the unique account number, personal password and email. If the application is successful, the relevant data will be automatically submitted to the backend server for storage.
If the account has been registered, or the password is not the same, the registration cannot be completed.

Screenshot Display

Video Display

Because we want to show the log printing of communication, we want to prove the excellent interaction ability of the front and back end, so we recorded the full screen, which may be a little hard to see, please forgive me!

Home Function

In the app's HOME interface, users can choose within three different functions: using a scientific calculator, using an interest rate calculator, or editing personal information.

Screenshot Display

Scientific Calculator Function

In the scientific calculator function, users can perform basic addition, subtraction, multiplication, and division, or more advanced bracket calculations, logarithmic calculations, log calculations, third-order functions, factorizations, and more.
In addition, we implemented three additional features:

1. With the "COPY" case, the user can automatically copy the calculation results to the clipboard
2. The user can set the exact number of decimal points for the calculation.
3. The user can click the "HIST" button to view the history by reading the formula and the result stored in the backend database. The history is stored as "Formula= Result=. "
   (In the video display, part of the storage form before modification is retained because of the storage form of subsequent modification.)
   In addition, the history of different login accounts is different, because the backend server explicitly stores the history of different users

   Screenshot Display

   

   
   

   

Video Display

Because we want to show the log printing of communication, we want to prove the excellent interaction ability of the front and back end, so we recorded the full screen, which may be a little hard to see, please forgive me!

Deposit and Lone Calculator Function

In the Deposit and Lone Calculator, we provide two drop-down boxes to help users query or modify information. In the first drop-down box, the user can choose deposit or loan, and in the second drop-down box, the user can choose different query time. We do this because it's more user-friendly and because selection is easier than typing.After that, we also provide a text input field for the users to input data.
When the user clicks on the query, the rate value stored in the back-end database is automatically obtained and displayed on the screen, and recorded in the history record. Similarly, when the user clicks Modify, the backend database will modify the value that the user wants to modify.
Users can click "History" to view their modifying/query history.

Screenshot Display

Video Display

Because we want to show the log printing of communication, we want to prove the excellent interaction ability of the front and back end, so we recorded the full screen, which may be a little hard to see, please forgive me!

Personal Info Function

For each user, you can set a user nickname, personal signature, gender, age, and profile picture. In the personal information function, users can select their favorite pictures from their mobile phone storage as their profile pictures through the "Person Photo" function, and they can also modify four basic information. When "Save Info" is clicked, the frontend passes the personal information to the server and makes changes.
In addition, we noticed two details:

1. When a user logs in, the application fetches the account's personal information from the backend server and stores it.
2. Users can use the "Taking Photo" button to capture the portrait information. The portrait information is passed to the database and stored, after which the user can log in through face recognition.

Screenshot Display

Video Display

Because we want to show the log printing of communication, we want to prove the excellent interaction ability of the front and back end, so we recorded the full screen, which may be a little hard to see, please forgive me!

Ⅴ. Difficulties encountered in cooperation and solutions

Yifan Wang

Challenge: Conflict of AsyncTask

Description: In android development, we encounter an error problem of doInBackground function, which conflicts with doInBackground in Android.os.asynctask. This is because the first generic parameter of AsyncTask is Params, and doInBackground returns a String, which is different from the default.

Solution: To solve this problem, we change the return type of doInBackground to Void by changing the generic parameter of AsyncTask, because in AsyncTask, Params represents the input parameter, Progress represents the progress update unit, and so on. Result represents the return type of doInBackground. In your case, the return is a String, so we use Void as a generic argument, meaning that no result is returned. This solves the problem of conflict.

Challenge: History display problem

Description: Get the history data from the background is successful, but it cannot successful shows in the CalculatorHistoryActivity front-end. Even the related content cannot be printed out through Log.

Solution: We examined CalculatorAsynGetHistory and CalculatorHistoryActivity code and found that by onPostExecute method to pass the data to CalculatorHistoryActivity, But there may be problems with the handling in the onCalculatorResult method. Finally, in onCalculatorResult, we should first process the received string appropriately to ensure that the data format is correct, and then update the UI. In addition, you can log is added in the onPostExecute method, to ensure the success of the data is passed to the CalculatorHistoryActivity.

Guohua Wu

Challenges : When creating a user system, using the method in the jakarta.servlet.http.HttpSession package, the user in the session has not been assigned, and it is impossible to determine whether the user who modified the information is a logged-in user.

Description : Found that user information cannot be correctly stored in the session. Try to use the method of HttpSession to store user information. Because the user information cannot be stored correctly in the session, it is impossible to judge whether the user who modifies the information is a logged-in user.

Solution : When sending JSON data, the user information is sent together as additional content, thus bypassing the assignment problem in the session and successfully solving the problem of unable to judge the login user.

Tianjun Shi

Challenge: AsyncTask's onPostExecute Method Not Executed

Description: In CalculatorAsyncGetHistory, it was observed that certain logs within the onPostExecute method were not printed, while other logs were functioning as expected.

Solution: Firstly, confirm whether the doInBackground method is executing properly and returning the result. If doInBackground has no exceptions, and onPostExecute is not being executed, it might be due to issues with the AsyncTask lifecycle or threads. Ensure that onPostExecute is executed on the UI thread. Use Log statements within onPostExecute to print some debugging information and make sure the method is being called. If not, consider using runOnUiThread to ensure execution on the UI thread.

Yuhao Lu

Challenges encountered : When writing the interest rate library, the request from the front end cannot be accepted normally.

Description : No matter what kind of request the front-end sends, the back-end cannot give the correct response.

Solution : In the process of debugging, it is found that the data type of sending request and receiving request does not match, and it is solved by unifying the data type as string.
There is a problem when confirming the receipt of the request, and the root cause of the data type mismatch is located. Through debugging, tracking the sending and receiving process of the request, the location where the data type does not match is found. Subsequently, the type difference between sending and receiving data was clarified, and it was decided to unify the data types of both as strings. After the modification and unification of the code, the front-end request can be received and processed normally.

Xindan Zhang

Challenge: Achieving Consistent UI Layout Across Different Mobile Phones

Description: When developing a mobile application, differences in screen sizes and models of various smartphones pose a challenge to UI layout. Due to varying screen sizes and resolutions among different phones, using a fixed layout may result in display issues on certain devices, such as elements appearing too small or too large, or layout distortion.

Solution: To achieve consistent UI layout across different phone models, we employ the following strategies:

Use Relative Layout: Relative layout positions UI elements relative to the parent or other elements, rather than using absolute pixel values. This ensures that the relative positions of elements remain consistent across devices with different screen sizes.
Test and Debug: Conduct testing and debugging on different devices to ensure the UI displays correctly under various circumstances. Utilize emulators and real devices to examine the UI effects on different screen sizes.

Binyue Zheng

Challenge: Discrepancy Between Designed UI and Implemented UI Aesthetics

Description: While designing multiple color schemes in real-time design tools, the transition to Android Studio implementation yields less-than-ideal results. The button colors are challenging to harmonize with the background image shared across different pages. Attempts to change the background image and button colors have shown limited success. The primary reason for significant deviations in UI design results is the disparity in button layout proportions between real-time design and Android UI implementation, leading to substantial visual aesthetic differences.

Solution: Modify the layout of the scientific calculator's design page to align with the proportions of UI implementation. Subsequently, adjust button colors and background based on the revised layout. Engage in group discussions to select an appropriate design solution that addresses the visual aesthetic differences.

Yanbo Wang

Challenge: Lack of Consistency in Design Style

Description: During the UI design phase, inconsistencies may arise among team members, resulting in a lack of uniformity in the final product's UI.

Resolution: To address this issue, it is advisable to conduct a meeting before the design process begins to establish a unified design style and standards. This includes defining a shared component library, color specifications, and style guidelines to ensure that the entire team adheres to the same standards during the design phase.

Haoyuan Zheng

Challenge: Difficulty Achieving Seamless Alignment with Design Plans in UI Construction

Description: Despite careful planning in the design phase, challenges arise when translating design patterns into actual code, leading to difficulties in achieving the expected appearance.

Resolution: To overcome this challenge, I proactively consulted relevant resources, conducted thorough research, and sought advice from ChatGPT to acquire coding techniques related to UI design. Subsequently, through continuous debugging and optimization, I gradually ensured that the final interface aligns seamlessly with the design plans.

Zhaoyou Wang

Challenge: Discrepancy in the Logic of Text Box Utilization between Page Design and Android Front-End Development

Description: In the process of designing specific functionalities for text boxes, such as capturing user information like name and age, page design tools like Instant Design and Mockingbird allow for the direct input of specified functionalities within the text box to clarify the intended user input. However, implementing the same functionality programmatically in Android Studio during front-end development poses a significant challenge. Achieving a balance between text input and the preservation of text content proves intricate.

Resolution: To address this challenge, the android:maxLength attribute can be employed to set the maximum number of characters permissible in the input box. Simultaneously, the android:inputType attribute can be utilized to designate the expected input type for the text box, such as numeric, textual, or date-related inputs.

Guandong Li

Challenge: Version Compatibility Issues

Description: Different Android versions may have variations in their support for certain UI elements or styles, leading to inconsistent display effects on some devices.

Solution: Address version compatibility issues by:

Using AppCompat Library: Employ the AppCompat library and Material Design components to ensure a consistent UI appearance across different Android versions.
Dynamic UI Adjustment: Dynamically adjust the UI behavior by checking the API version, allowing for variations in UI elements or styles based on the Android version.

Ⅵ. PSP table of each member

Yifan Wang

两天睡觉时间不到十个小时 :) 团队大作业能不能减少 :)
两天睡觉时间不到十个小时 :) 团队大作业能不能减少 :)
两天睡觉时间不到十个小时 :) 团队大作业能不能减少 :)
两天睡觉时间不到十个小时 :) 团队大作业能不能减少 :)

Personal Software Process Stages	Estimated Time（minutes）	Actual Time（minutes）
Planning	200	230
• Estimate	200	230
Development	600	900
• Analysis	40	50
• Design Spec	50	70
• Design Review	20	40
• Coding Standard	30	30
• Design	60	100
• Coding	200	250
• Code Review	100	150
• Test	100	250
Reporting	50	45
• Test Repor	15	10
• Size Measurement	15	15
• Postmortem & Process Improvement Plan	20	20
Sum	1000	1170

Guohua Wu

Personal Software Process Stages	Estimated Time (minutes)	Actual Time (minutes)
Planning	60	60
• Estimate	60	60
Development	410	430
• Analysis	30	30
• Design Spec	40	45
• Design Review	15	15
• Coding Standard	10	10
• Design	60	60
• Coding	75	80
• Code Review	20	20
• Test	30	30
Reporting	60	70
• Test Report	10	10
• Size Measurement	15	15
• Postmortem & Process Improvement Plan	35	45
Total	800	840

Tianjun Shi

Personal Software Process Stages	Estimated Time (minutes)	Actual Time (minutes)
Planning	300	320
• Estimate	300	320
Development	525	435
• Analysis	30	50
• Design Spec	70	60
• Design Review	40	30
• Coding Standard	55	25
• Design	60	40
• Coding	150	110
• Code Review	30	30
• Test	90	90
Reporting	75	75
• Test Report	30	30
• Size Measurement	15	15
• Postmortem & Process Improvement Plan	30	30
Sum	900	830

Yuhao Lu

Personal Software Process Stages	Estimated Time（minutes）	Actual Time（minutes）
Planning	30	20
• Estimate	30	20
Development	500	590
• Analysis	30	60
• Design Spec	20	20
• Design Review	20	30
• Coding Standard	60	50
• Design	60	20
• Coding	60	70
• Code Review	120	100
• Test	110	240
Reporting	80	70
• Test Repor	20	10
• Size Measurement	20	10
• Postmortem & Process Improvement Plan	40	50
Sum	610	680

Jingzhen Fan

Personal Software Process Stages	Estimated Time（minutes）	Actual Time（minutes）
Planning	20	10
• Estimate	20	10
Development	50	50
• Analysis	20	30
• Design Spec	10	10
• Design Review	10	20
• Coding Standard	40	30
• Design	30	20
• Coding	100	100
• Code Review	40	30
• Test	30	30
Reporting	50	40
• Test Repor	20	10
• Size Measurement	20	10
• Postmortem & Process Improvement Plan	40	50
Sum	470	450

Xindan Zhang

Personal Software Process Stages	Estimated Time（minutes）	Actual Time（minutes）
Planning	60	60
• Estimate	60	60
Development	255	280
• Analysis	30	30
• Design Spec	30	40
• Design Review	15	15
• Coding Standard	10	10
• Design	60	60
• Coding	60	75
• Code Review	20	20
• Test	30	30
Reporting	40	45
• Test Repor	10	10
• Size Measurement	15	15
• Postmortem & Process Improvement Plan	15	20
Sum	355	385

Haoyuan Zheng

Personal Software Process Stages	Estimated Time（minutes）	Actual Time（minutes）
Planning	40	45
• Estimate	40	45
Development	205	235
• Analysis	20	30
• Design Spec	30	30
• Design Review	15	15
• Coding Standard	10	10
• Design	40	60
• Coding	60	60
• Code Review	15	15
• Test	15	15
Reporting	55	55
• Test Repor	20	20
• Size Measurement	20	15
• Postmortem & Process Improvement Plan	15	20
Sum	300	335

Binyue Zheng

Personal Software Process Stages	Estimated Time（minutes）	Actual Time（minutes）
Planning	20	60
• Estimate	20	60
Development	295	390
• Analysis	15	15
• Design Spec	60	80
• Design Review	20	20
• Coding Standard	20	20
• Design	60	75
• Coding	80	100
• Code Review	30	40
• Test	30	40
Reporting	110	120
• Test Repor	75	80
• Size Measurement	15	15
• Postmortem & Process Improvement Plan	20	25
Sum	425	570

Yanbo Wang

Personal Software Process Stages	Estimated Time（minutes）	Actual Time（minutes）
Planning	40	45
• Estimate	40	45
Development	205	320
• Analysis	20	30
• Design Spec	30	30
• Design Review	15	15
• Coding Standard	10	10
• Design	40	80
• Coding	60	120
• Code Review	15	15
• Test	15	20
Reporting	55	55
• Test Repor	20	20
• Size Measurement	20	15
• Postmortem & Process Improvement Plan	15	20
Sum	300	420

Zhaoyou Wang

Personal Software Process Stages	Estimated Time（minutes）	Actual Time（minutes）
Planning
• Estimate	20	30
Development
• Analysis	30	30
• Design Spec	20	30
• Design Review	20	20
• Coding Standard	40	60
• Design	30	20
• Coding	60	120
• Code Review	30	45
• Test	20	10
Reporting
• Test Repor	20	15
• Size Measurement	30	20
• Postmortem & Process Improvement Plan	30	40
Sum	350	440

Guandong Li

Personal Software Process Stages	Estimated Time（minutes）	Actual Time（minutes）
Planning
• Estimate	20	30
Development
• Analysis	30	20
• Design Spec	30	20
• Design Review	20	20
• Coding Standard	45	30
• Design	15	15
• Coding	110	145
• Code Review	20	30
• Test	20	20
Reporting
• Test Repor	20	20
• Size Measurement	30	30
• Postmortem & Process Improvement Plan	30	30
Sum	390	410

Ⅶ Take a screenshot of Github's submission log

The total commit number is 59. We have 11 individuals in our team~