Challenges & Solutions

Problem: Users needed a seamless way to share and access specific bets, groups, or actions (like joining a group or starting a new bet) directly—whether the app was already running or freshly launched.
Solution: Implemented a custom deep linking system using a dedicated `DeepLinkManager` and URL parser. Incoming links are decoded into actionable routes and buffered if the user isn't authenticated. Once the user signs in, the app flushes any buffered links and routes them appropriately. This supports both universal links and custom schemes, enabling dynamic navigation like `/group/:id`, `/bet/:id`, or `/join/:code`.

Problem: There was no structured way for users to resolve bets, propose winners, or handle disputes after a bet was completed.
Solution: Designed a resolution request system using `BetMessage` models and Firestore subcollections. Users can propose a winner with a justification, which notifies the opponent and prompts them to accept or reject. Resolved bets are automatically archived after a cooldown period, keeping active views clean and historical data accessible. This workflow supports accountability and preserves bet integrity across groups.

Problem: Old bets that have already been resolved were still visible in the Group.
Solution: Implemented archiving of older bets into a new subcolletion, to reduce the data traffic when opening a Group.

Challenges & Solutions

Problem: The AVCaptureVideoPreviewLayer wasn’t rendering correctly inside SwiftUI due to improper layer handling.
Solution: Replaced the default UIView with a custom UIView subclass (PreviewContainerView) that directly uses AVCaptureVideoPreviewLayer as its backing layer. This ensured the camera preview appeared fullscreen and consistently across devices.

Problem: The initial Firebase Firestore security rules didn’t restrict access based on user authentication. This meant that any authenticated user could potentially read or write to any document in the racquets collection.
Solution: Firestore security rules were updated to strictly scope access to each user's own data.

Challenges & Solutions

Problem: Spring Boot standard custom error handling returns html format. For the REST API there is no json response (just responded with a json of the html error page).
Solution: Implemented a handler, that checks if the api endpoint is pinged before returning the error html file.

Problem: Insights on articles were increasing upon refresh of the page.
Solution: Introduced a new Model ArticleView that will be created using the javascript of the view Article Button. This way when the article is refreshed there is no counter that is increased, and we can track the views back with a timestamp, for the insights.