2023 3-2 Mobile Programming Team Project
Kim Siheon | Park Hyunseo | Lee Jeonghyeon |
---|---|---|
Siheon Kim | Hyunseo Park (Sean) | jeonghyeonee |
- Fork this repository to your own account.
- Clone the repository from your account to your local machine.
git clone <forked repository address>
- Add the original repository where the project was initially created as an upstream source.
git remote add upstream <original repo address> git remote add upstream https://github.com/jeonghyeonee/Memoriary.git
- Check the list of remote repositories to ensure that your repository is set as 'origin' and the project's repository is set as 'upstream.'
git remote -v
- Work on your changes in a new branch on your local machine.
- Follow the branch naming convention:
ID/Name/IssueNumber
.# Example: jeonghyeonee/updateReadme/8
- Add your changes using the following command:
git add . or <specific file>
- Commit your changes with a meaningful commit message using either
-m
or-s
(signed-off) option.- If you use
-s
, please provide a summary of your commit message.
- If you use
- Push your changes to your repository on the branch you created.
git push origin <branchName>
- Go to your repository on GitHub and click the "Compare & Pull Request" button.
- Assign a reviewer if necessary.
- The reviewer will perform a code review and decide whether to merge the pull request if there are no issues.
- After the merge is completed in the original repository, it's important to synchronize your local
main
branch with the code in the original repository (jeonghyeonee/Memoriary). - To do this, go to your own GitHub repository, confirm that the active branch is
main
, and click theSync fork
button, then press theUpdate branch
button. - To synchronize your local
main
branch with the changes, you can execute the following commands to delete the working local branch:
# Synchronize the code
git checkout main
git pull origin main
# Forcefully delete the local branch
git branch -D <branch>
# Delete the remote branch
git push origin --delete <branch>
In certain scenarios, using LiveData in DAO (Data Access Object) might result in errors due to the requirement of non-blocking database operations. To address this limitation, an alternative approach using Observers was implemented.
The decision to move away from LiveData was made to avoid potential issues related to accessing the database on the main thread, which could lead to UI freezes. While the Observer-based implementation resolves the LiveData-related errors, it introduces a delay in synchronous operations.
To mitigate the synchronous delay introduced by the Observer pattern, consider implementing background threads or coroutines for non-blocking database operations. This ensures that the UI remains responsive while database transactions are being performed.
For a visual representation of the Observer-based implementation, please refer to the following video: