-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
added single journey in multiple groups #167
Conversation
WalkthroughThe pull request introduces changes to location tracking and journey management across multiple files. The primary modifications involve adding user preferences to location journey processing, enhancing the ability to save and update location journeys with space-specific context. The changes extend the Changes
Sequence DiagramsequenceDiagram
participant LUR as LocationUpdateReceiver
participant JR as JourneyRepository
participant AJS as ApiJourneyService
participant JG as JourneyGenerator
LUR->>JR: saveLocationJourney(location, userId, userPreferences)
JR->>JR: Iterate through space_ids
JR->>JG: getJourney(userId, location, lastKnownJourney)
JG-->>JR: Journey details
JR->>AJS: addJourney/updateJourney(userId, journey, spaceId)
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 4
🧹 Nitpick comments (8)
data/src/main/java/com/canopas/yourspace/data/service/location/ApiJourneyService.kt (1)
167-167
: Standardize logging format.The "xxx" prefix in log messages appears non-standard. Consider using consistent logging format across the codebase.
- Timber.e("xxx Failed to get group cipher for group $memberId") + Timber.e("Failed to get group cipher for group $memberId in space $spaceId") - Timber.d("xxx Added journey to group $memberId in space $spaceId") + Timber.d("Successfully added journey to group $memberId in space $spaceId")Also applies to: 184-184
data/src/main/java/com/canopas/yourspace/data/repository/JourneyRepository.kt (2)
27-28
: Add null safety check for space_ids.While we handle the null case for currentUser, we should log a warning when space_ids is empty to help with debugging.
- val spaceIds = userPreferences.currentUser?.space_ids ?: emptyList() + val spaceIds = userPreferences.currentUser?.space_ids ?: emptyList() + if (spaceIds.isEmpty()) { + Timber.w("No space_ids found for user: $userId") + }
36-43
: Consider updating cache strategy for multi-space support.The current caching strategy stores journeys by userId only, which might lead to race conditions or overwrites when handling multiple spaces. Consider updating the cache to be space-aware.
- locationCache.putLastJourney(journey, userId) + locationCache.putLastJourney(journey, "$userId:$spaceId")This would require updates to the
LocationCache
class and other related methods to support space-specific caching.Also applies to: 45-52
data/src/main/java/com/canopas/yourspace/data/repository/JourneyGenerator.kt (5)
Line range hint
15-18
: Document threshold constants with their business logic implications.The threshold constants lack documentation explaining their business logic implications and how they were determined.
Add detailed documentation for the threshold constants:
-private const val MIN_DISTANCE = 100.0 // 100 meters -private const val MIN_TIME_DIFFERENCE = 5 * 60 * 1000L // 5 minutes -private const val MIN_DISTANCE_FOR_MOVING = 10.0 // 10 meters -private const val MIN_UPDATE_INTERVAL_MINUTE = 30000L // 30 seconds +/** Minimum distance (in meters) to consider a user has changed location significantly enough to start a new journey */ +private const val MIN_DISTANCE = 100.0 + +/** Time threshold (in milliseconds) after which we consider a moving user has stopped at their destination */ +private const val MIN_TIME_DIFFERENCE = 5 * 60 * 1000L + +/** Minimum distance (in meters) required to update a moving journey's route */ +private const val MIN_DISTANCE_FOR_MOVING = 10.0 + +/** Minimum time interval (in milliseconds) between journey updates to prevent excessive updates */ +private const val MIN_UPDATE_INTERVAL_MINUTE = 30000L
Line range hint
96-107
: Consider extracting journey state transition logic into a more explicit state machine.The current implementation uses nested conditions and comments to manage state transitions. This could be made more maintainable by using an explicit state machine pattern.
Consider creating an enum class for journey states and a separate class to handle state transitions. This would make the logic more maintainable and testable. Would you like me to provide an example implementation?
Line range hint
172-183
: Improve accuracy of route calculations.The current implementation has potential accuracy issues:
- Route distance is calculated using straight-line distance between points, which might underestimate actual travel distance.
- Route duration calculation could be simplified.
Consider these improvements:
val updatedJourney = lastKnownJourney.copy( to_latitude = newLocation.latitude, to_longitude = newLocation.longitude, - // Add new distance to previous distance, if you want cumulative - route_distance = (lastKnownJourney.route_distance ?: 0.0) + distance, - route_duration = lastKnownJourney.updated_at - - lastKnownJourney.created_at, + // Calculate cumulative distance along the actual route + route_distance = calculateRouteDistance(lastKnownJourney.routes + newLocation.toRoute()), + route_duration = System.currentTimeMillis() - lastKnownJourney.created_at, routes = lastKnownJourney.routes + newLocation.toRoute(), updated_at = System.currentTimeMillis() )Would you like me to provide an implementation of the
calculateRouteDistance
function that computes the actual path distance?
Line range hint
20-189
: Consider breaking down the complex journey generation logic.The
getJourney
function is quite long and handles multiple responsibilities. This makes it harder to maintain and test. Consider breaking it down into smaller, more focused functions.Consider extracting these responsibilities into separate functions:
- Journey state determination
- Distance calculation logic
- Time threshold checking
- Journey update logic
- New journey creation logic
Would you like me to provide an example of how to break this down into smaller functions?
Line range hint
217-227
: Optimize geometric median calculation.The current implementation of geometric median calculation has O(n²) complexity and might be inefficient for large location lists.
Consider:
- Implementing a more efficient algorithm (e.g., Weiszfeld's algorithm)
- Adding a maximum limit to the number of locations processed
- Caching the result if the location list hasn't changed
Would you like me to provide an optimized implementation?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
data/src/main/java/com/canopas/yourspace/data/receiver/location/LocationUpdateReceiver.kt
(3 hunks)data/src/main/java/com/canopas/yourspace/data/repository/JourneyGenerator.kt
(6 hunks)data/src/main/java/com/canopas/yourspace/data/repository/JourneyRepository.kt
(2 hunks)data/src/main/java/com/canopas/yourspace/data/service/location/ApiJourneyService.kt
(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
🔇 Additional comments (8)
data/src/main/java/com/canopas/yourspace/data/service/location/ApiJourneyService.kt (2)
91-95
: LGTM! Clean implementation of the Triple return value.The Triple construction properly encapsulates the distribution message, group cipher, and distribution ID for secure group messaging.
147-190
: Verify data isolation between spaces.The changes to handle single-space journeys maintain encryption, but we should verify that this doesn't impact data isolation between spaces.
Run this script to check for potential cross-space data access:
Also applies to: 195-230
✅ Verification successful
Data isolation between spaces is properly maintained ✅
The changes maintain strict data isolation through space-specific storage paths, encryption keys, and proper space ID validation. No cross-space data access patterns were found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for potential cross-space data access in journey handling # Search for direct space ID references in journey methods rg -A 5 "spaceMemberJourneyRef|spaceGroupKeysRef" --type kotlin # Look for space ID validation ast-grep --pattern 'spaceId.takeIf { $_ }'Length of output: 12348
data/src/main/java/com/canopas/yourspace/data/receiver/location/LocationUpdateReceiver.kt (3)
11-11
: LGTM!The import for UserPreferences is correctly added to support the new functionality.
41-43
: LGTM!The UserPreferences dependency is properly injected using Dagger's @Inject annotation.
59-59
: Verify error handling for userPreferences.While the method call is updated correctly, we should ensure proper error handling if userPreferences is not initialized when the location update is received.
data/src/main/java/com/canopas/yourspace/data/repository/JourneyRepository.kt (2)
7-7
: LGTM!The import for UserPreferences is correctly added.
18-21
: LGTM!The method signature is properly updated to include userPreferences parameter.
data/src/main/java/com/canopas/yourspace/data/repository/JourneyGenerator.kt (1)
Line range hint
1-189
: Verify alignment with PR objectives.The PR's objective is to "allow users to have a single moving or steady journey across all spaces", but the current changes only add logging statements. The core functionality to support journeys across multiple spaces appears to be missing.
Please verify:
- How does this implementation support journeys across multiple spaces?
- Are there additional changes needed in other files to support this feature?
Run this script to check for related changes:
Changelog
Summary by CodeRabbit
Release Notes:
New Features
Improvements
Bug Fixes
The updates focus on improving location tracking accuracy and providing more robust space-specific journey management with enhanced logging capabilities.