Merge branch 'main' of https://github.com/timothydillan/300cem-androi…

…d-app into main

README.md

@@ -48,6 +48,9 @@ To begin, the APIs used are listed as follows:
 *The auth api won't be elaborated here, so a short explanation for it is that it is used to ease the authentication process by allowing users to create an account, or sign in with an account, and all the "back-end" stuff is mainly handled by Firebase.*
 
 # Videos
+### Phone + Wearable
+https://youtu.be/Kjf-d7_s1gQ
+
 ### Phone
 https://streamable.com/q9v6y4
 
@@ -67,16 +70,16 @@ https://streamable.com/qwk7ay
 # Location Sharing
 To conduct location sharing, the application uses the Database API to update the user's latitude and longitude in real-time. To be able to accomplish this, a fused location provider with a custom location callback listener was used. Once the location of the user is changed, the callback triggers the `onLocationResult` event, which then updates the user's location in the database. A code-by-code explanation can be seen [here](https://github.com/timothydillan/300cem-android-app/blob/main/app/src/main/java/com/timothydillan/circles/Services/LocationService.java).
 
-When the location of the user is updated, the onUsersChange event will be triggered for every listener that is registered/listening to the events provided by the UserUtil class. The event, when triggered, provides us with a DataSnapshot (basically new data from the DB), which we will then use to get new information about the user, as seen [here](https://github.com/timothydillan/300cem-android-app/blob/main/app/src/main/java/com/timothydillan/circles/MapsFragment.java#L227).
+When the location of the user is updated, the `onUsersChange` event will be triggered for every listener that is registered/listening to the events provided by the UserUtil class. The event, when triggered, provides us with a DataSnapshot (basically new data from the DB), which we will then use to get new information about the user, as seen [here](https://github.com/timothydillan/300cem-android-app/blob/main/app/src/main/java/com/timothydillan/circles/MapsFragment.java#L227).
 
-Now, to get information that the user cares about (only their circle information), the MapsFragment overrides the default onUsersChange behavior and calls the getUpdatedInformation function from the Location utility class to provide the users with new information. All processing of data filtering will not be explained, however, the full explanation for the data filtering can be seen [here](https://github.com/timothydillan/300cem-android-app/blob/d9889e950b1cc7b4ff0be97defd35ac60d019423/app/src/main/java/com/timothydillan/circles/Utils/LocationUtil.java#L184).
+Now, to get information that the user cares about (only their circle information), the MapsFragment overrides the default `onUsersChange` behavior and calls the getUpdatedInformation function from the Location utility class to provide the users with new information. All processing of data filtering will not be explained, however, the full explanation for the data filtering can be seen [here](https://github.com/timothydillan/300cem-android-app/blob/d9889e950b1cc7b4ff0be97defd35ac60d019423/app/src/main/java/com/timothydillan/circles/Utils/LocationUtil.java#L184).
 
 ### Extra
 
 A custom bottom sheet layout, combined with a custom recycler view, was used to display detailed information about each user, such as the address of their current location ([reverse geocoding of their latitude and longitude was done to do this](https://github.com/timothydillan/300cem-android-app/blob/d9889e950b1cc7b4ff0be97defd35ac60d019423/app/src/main/java/com/timothydillan/circles/Utils/LocationUtil.java#L301)). Also, each user's username, as well as their profile picture is shown in the custom recycler view. A custom recycler view adapter was also used to allow users to immediately redirect ([move their map camera position to a user's marker](https://github.com/timothydillan/300cem-android-app/blob/d9889e950b1cc7b4ff0be97defd35ac60d019423/app/src/main/java/com/timothydillan/circles/MapsFragment.java#L137)). Also, when each user's marker is clicked, an info window will be shown, and when a user clicks on a specific marker, they would be able to get directions to the person clicked ([this uses a google map intent that passes in the latitude and longitude of the user](https://github.com/timothydillan/300cem-android-app/blob/d9889e950b1cc7b4ff0be97defd35ac60d019423/app/src/main/java/com/timothydillan/circles/MapsFragment.java#L186)).
 
 # Moods
-The Moods fragment, similar to the Maps fragment, also uses the Database API, combined with the Wearable API to update and retrieve information. The Moods fragment, when launched, first checks whether user has a wearable paired with their handheld device. The application does this by checking whether the user has the WearOS app (this is a really "ghetto" way to check whether the user has a wearable paired, but due to time constraints this is what I have to settled with). If the user has a wearable paired, the Moods fragment will trigger the WearableService, which inherits the WearableListenerService, that uses the Data Layer API (https://developer.android.com/training/wearables/data-layer/events) to receive data from the wearable, to the app. When data is retrieved from the wearable, the onDataChange event will be triggered in the service, and the data from the wearable (heart rate) will be retrieved, and the Database API will be used to update the user's heart rate data. Once the heart rate data is updated, the MoodUtil class will receive the new information, and assign the user's mood according to their heartbeat. Details about the calculation for each mood is elaborated in the report, and can be seen [here](https://github.com/timothydillan/300cem-android-app/blob/d9889e950b1cc7b4ff0be97defd35ac60d019423/app/src/main/java/com/timothydillan/circles/Utils/MoodUtil.java#L41).
+The Moods fragment, similar to the Maps fragment, also uses the Database API, combined with the Wearable API to update and retrieve information. The Moods fragment, when launched, first checks whether user has a wearable paired with their handheld device. The application does this by checking whether the user has the WearOS app (this is a really "ghetto" way to check whether the user has a wearable paired, but due to time constraints this is what I settled for). If the user has a wearable paired, the Moods fragment will trigger the WearableService, which inherits the WearableListenerService, that uses the Data Layer API (https://developer.android.com/training/wearables/data-layer/events) to receive data from the wearable, to the app. When data is retrieved from the wearable, the onDataChange event will be triggered in the service, and the data from the wearable (heart rate) will be retrieved, and the Database API will be used to update the user's heart rate data. Once the heart rate data is updated, the MoodUtil class will receive the new information, and assign the user's mood according to their heartbeat. Details about the calculation for each mood is elaborated in the report, and can be seen [here](https://github.com/timothydillan/300cem-android-app/blob/d9889e950b1cc7b4ff0be97defd35ac60d019423/app/src/main/java/com/timothydillan/circles/Utils/MoodUtil.java#L41).
 
 ### Extra