6 Commits (b00ce6c7b390550ac8a54177b63b28b13e99bdbe)

Author	SHA1	Message	Date
Miguel Beltran	b00ce6c7b3	[Compass App] User name and profile picture (#2435) ... This PR completes the home screen, adding the username and the profile picture.   This feature follows the basic structure: - Added repository, both local and remote. - Added API call + API model. - Added Domain model (reduced version only containing name and profile picture). - Modified the ViewModel to obtain the user and expose it to the Widget. - Updated Widget to display the username and profile picture. - Added `/user` endpoint to server project. - Updated widget tests, as well as integration tests. The Compass App is basically completed with it. Maybe the next step is to merge it to the `main` branch? And then we can do a full review, remove TODOs and setup CI jobs. ## Pre-launch Checklist - [x] I read the [Flutter Style Guide] _recently_, and have followed its advice. - [x] I signed the [CLA]. - [x] I read the [Contributors Guide]. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-devrel channel on [Discord]. <!-- Links --> [Flutter Style Guide]: https://github.com/flutter/flutter/blob/master/docs/contributing/Style-guide-for-Flutter-repo.md [CLA]: https://cla.developers.google.com/ [Discord]: https://github.com/flutter/flutter/blob/master/docs/contributing/Chat.md [Contributors Guide]: https://github.com/flutter/samples/blob/main/CONTRIBUTING.md	2 months ago
Miguel Beltran	93b86b86f3	[Compass App] Refactor model (#2431) ... This PR removes the `compass_model` subproject and moves each data model class to the respective `app` or `server` project. Although this leads to code duplication, this is a more realistic implementation where clients and servers have their own respective data model class implementations. The model classes for the server are located in `server/lib/model`. Model classes for the app are located in two places: - API-only model: `app/lib/data/services/api/model`. - Domain model: `app/lib/domain/model`. In general, models located under the domain are used across the app, while the API-only models are only used for interacting with the API client. Tests have been updated. ## Pre-launch Checklist - [x] I read the [Flutter Style Guide] _recently_, and have followed its advice. - [x] I signed the [CLA]. - [x] I read the [Contributors Guide]. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-devrel channel on [Discord]. <!-- Links --> [Flutter Style Guide]: https://github.com/flutter/flutter/blob/master/docs/contributing/Style-guide-for-Flutter-repo.md [CLA]: https://cla.developers.google.com/ [Discord]: https://github.com/flutter/flutter/blob/master/docs/contributing/Chat.md [Contributors Guide]: https://github.com/flutter/samples/blob/main/CONTRIBUTING.md	2 months ago
Miguel Beltran	fb869e729e	[Compass App] Home screen with booking list (#2428) ... This PR introduces the storage and retrieval of bookings. ### Server implementation - New booking routes: - GET `/booking`: Obtain the list ofer user bookings - GET `/booking/{id}`: Obtain the specific booking object - POST `/booking`: Creates a new booking - The `BookingApiModel` objects are incomplete, the `Destination` is a reference, not the full object, and the `Activity` list are also listed as references only. - Server booking always has an existing booking created (Alaska, North America) for demo purposes. - Storage is "in memory", stopping the server deletes all stored bookings. ### New `BookingRepository` - New repository class. - Both local and remote implementations. - Converts the `BookingApiModel` into a complete `Booking` that the app can use, or a `BookingSummary` that only contains the necessary information for the home screen. ### New `LocalDataService` - Service that loads hard-coded data or from assets. ### New `HomeScreen` - Route path: `/` - Loads and displays the list of created bookings from the `BookingRepository`. - Tap on a booking title opens the `BookingScreen`. - Floating Action Button to create a new booking. ### Changes in `BookingScreen` - Can be accessed at the end of creating a booking or from the home screen when tapping a booking title. - Two commands: - `createBooking`: Takes the stored `ItineraryConfig` and creates a booking, the booking is stored to the `BookingRepository` (locally or on the server). - `loadBooking`: Takes a booking ID and loads that existing booking from the `BookingRepository`. - Simplified navigation: Once at `BookingScreen`, user can only navigate back to `HomeScreen`. - Share button converted to `FloatingActionButton` ### Integration Tests - Updated to use new home screen. - Updated to cover opening an existing booking in tests. ### TODO Next - Refactor the `compass_model` project and move data model classes to `server` and `app`, then delete project. - Implement some user information for the home screen (e.g. retrieve user name and profile picture url) ### Screencast [Screencast from 2024-09-02 16-25-25.webm](https://github.com/user-attachments/assets/8aba4a61-def6-4752-a4e5-70cbed362524) ## Pre-launch Checklist - [x] I read the [Flutter Style Guide] _recently_, and have followed its advice. - [x] I signed the [CLA]. - [x] I read the [Contributors Guide]. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-devrel channel on [Discord]. <!-- Links --> [Flutter Style Guide]: https://github.com/flutter/flutter/blob/master/docs/contributing/Style-guide-for-Flutter-repo.md [CLA]: https://cla.developers.google.com/ [Discord]: https://github.com/flutter/flutter/blob/master/docs/contributing/Chat.md [Contributors Guide]: https://github.com/flutter/samples/blob/main/CONTRIBUTING.md	3 months ago
Miguel Beltran	3be6873210	Compass App: WIP Auth logic refactor (#2394) ... This PR follows up with the conversation we had via email and cleans up the auth implementation. **New `AuthRepository`** The `AuthTokenRepository`, `AuthLoginComponent` and `AuthLogoutComponent` have been refactored into a single `AuthRepository`. This `AuthRepository` exposes the `isAuthenticated` boolean, which is used by `go_router` to handle redirects. Also, has two methods, `login(email, pass)` and `logout()`, similar to what we had in the components. The implementation uses the new `SharedPreferencesService`, which is a service to access the `shared_preferences` plugin to store the `String` token. **New `AuthApiClient`** The `ApiClient` has been split in two. The `/login` REST call is moved to the `AuthApiClient`, while the other calls that require an auth token remain in the `ApiClient`. **`ApiClient` credentials** The main open question is, what is the best way to pass the auth token to the api client? I've found several alternatives: 1. `ApiClient` has a `token` setter which the `AuthRepository` calls to set the token - Implemented in this PR. - Follows our architecture design. - `AuthRepository` should be the source of truth, but the `ApiClient.token` could be set externally by mistake, so the single source of truth principle gets blurry. 2. `ApiClient` calls to the `AuthRepository` to obtain the token. - This is what the code was doing before. - `AuthRepository` is the source of truth. - But the dependency "Service to Repository" breaks our architecture design principle. 3. `ApiClient` calls to the `SharedPreferencesService` to obtain the token ( - `SharedPreferencesService` is the source of truth, as the `ApiClient` doesn't need the `AuthRepository`. - We see a "Service calling a Service" which maybe breaks our architecture design principle? 4. The `ApiClient` doesn't hold the token at all, intead, each call requires us to pass a token. - Tried to implement it but becomes very complex. - Makes other repositories depend on the `AuthRepository` or the `SharedPreferencesService`. Personal take: I have implemented 1 in this PR because it is the one that follows best the architecture recommendations. However I see some pitfalls, e.g. the `AuthRepository` needs to fetch the token from the `SharedPreferencesService` at least once on app start and pass it to the `ApiClient`. While on the solution 2 that's never a problem, since the `AuthRepository` is being called from the `ApiClient` and so it is always the source of truth for authentication. I am looking forward for your thoughts @ericwindmill ## Pre-launch Checklist - [x] I read the [Flutter Style Guide] _recently_, and have followed its advice. - [x] I signed the [CLA]. - [x] I read the [Contributors Guide]. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-devrel channel on [Discord]. <!-- Links --> [Flutter Style Guide]: https://github.com/flutter/flutter/blob/master/docs/contributing/Style-guide-for-Flutter-repo.md [CLA]: https://cla.developers.google.com/ [Discord]: https://github.com/flutter/flutter/blob/master/docs/contributing/Chat.md [Contributors Guide]: https://github.com/flutter/samples/blob/main/CONTRIBUTING.md	3 months ago
Miguel Beltran	e0f25da42b	Compass App: Basic auth (#2385) ... This PR introduces basic auth implementation between the app and the server as part of the architectural example. This PR is a big bigger than the previous ones so I hope this explanation helps: ### Server implementation The server introduces a new endpoint `/login` to perform login requests, which accepts login requests defined in the `LoginRequest` data class, with an email and password. The login process "simulates" checking on the email and password and responds with a "token" and user ID, defined by the `LoginResponse` data class. This is a simple hard-coded check and in any way a guide on how to implement authentication, just a way to demonstrate an architectural example. The server also implements a middleware in `server/lib/middleware/auth.dart`. This checks that the requests between the app and the server carry a valid authorization token in the headers, responding with an unauthorized error otherwise. ### App implementation The app introduces the following new parts: - `AuthTokenRepository`: In charge of storing the auth token. - `AuthLoginComponent`: In charge of performing login. - `AuthLogoutComponent`: In charge of performing logout. - `LoginScreen` with `LoginViewModel`: Displays the login screen. - `LogoutButton` with `LogoutViewModel`: Displays a logout button. The `AuthTokenRepository` acts as the source of truth to decide if the user is logged in or not. If the repository contains a token, it means the user is logged in, otherwise if the token is null, it means that the user is logged out. This repository is also a `ChangeNotifier`, which allows listening to change in it. The `GoRouter` has been modified so it listens to changes in the `AuthTokenRepository` using the `refreshListenable` property. It also implements a `redirect`, so if the token is set to `null` in the repository, the router will redirect users automatically to the login screen. This follows the example found in https://github.com/flutter/packages/blob/main/packages/go_router/example/lib/redirection.dart On app start, `GoRouter` checks the `AuthTokenRepository`, if a token exists the user stays in `/`, if not, the user is redirected to `/login`. The `ApiClient` has also been modified, so it reads the stored token from the repository when performing network calls, and adds it to the auth headers. The two new components implement basic login and logout functionality. The `AuthLoginComponent` will send the request using the `ApiClient`, and then store the token from the response. The `AuthLogoutComponent` clears the stored token from the repository, and as well clears any existing itinerary configuration, effectively cleaning the app state. Performing logout redirects the user to the login screen, as explained. The `LoginScreen` uses the `AuthLoginComponent` internally, it displays two text fields and a login button, plus the application logo on top. A successful login redirects the user to `/`. The `LogoutButton` replaces the home button at the `/`, and on tap it will perform logout using the `AuthLogoutComponent`. **Development target app** The development target app works slightly different compared to the staging build. In this case, the `AuthTokenRepository` always contains a fake token, so the app believes it is always logged in. Auth is only used in the staging build when the server is involved. ## Screenshots <details> <summary>Screenshots</summary> The logout button in the top right corner:  The login screen:  </details> ## Pre-launch Checklist - [x] I read the [Flutter Style Guide] _recently_, and have followed its advice. - [x] I signed the [CLA]. - [x] I read the [Contributors Guide]. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-devrel channel on [Discord]. <!-- Links --> [Flutter Style Guide]: https://github.com/flutter/flutter/blob/master/docs/contributing/Style-guide-for-Flutter-repo.md [CLA]: https://cla.developers.google.com/ [Discord]: https://github.com/flutter/flutter/blob/master/docs/contributing/Chat.md [Contributors Guide]: https://github.com/flutter/samples/blob/main/CONTRIBUTING.md	3 months ago
Miguel Beltran	0c88289339	[Compass App] Booking screen (#2380) ... This PR adds the Booking screen at the end of the main app flow. After the user selects `Activity`s, these get stored in the `ItineraryConfig` and then the user navigates to the `BookingScreen`. In the `BookingScreen`, a `Booking` is generated with the `BookingCreateComponent`. This component communicates with multiple repositories, and it is a bit more complex than the average view model, something that we want to show as discussed in the previous PRs. <details> <summary>Screenshots</summary>   </details> In the `BookingScreen`, the user can tap on "share trip" which displays the OS share sheet functionality. This uses the plugin `share_plus`, but the functionality is also wrapped in the `BookingShareComponent`, which takes a `Booking` object and creates a shareable string, then calls to the `Share.share()` method from `share_plus`. But the `share_plus` dependency is also injected into the `BookingShareComponent`, allowing us to unit test without plugin dependencies. This is an example of a shared booking to instant messaging:  **TODO** - I want to take a look at the whole experience on mobile, as I noticed some inconsistent UI and navigation issues that I couldn't see on Desktop. I will submit those in a new PR. - We also talked about user authentication in the design document. I will work on that once we are happy with the main app flow. ## Pre-launch Checklist - [x] I read the [Flutter Style Guide] _recently_, and have followed its advice. - [x] I signed the [CLA]. - [x] I read the [Contributors Guide]. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-devrel channel on [Discord]. <!-- Links --> [Flutter Style Guide]: https://github.com/flutter/flutter/blob/master/docs/contributing/Style-guide-for-Flutter-repo.md [CLA]: https://cla.developers.google.com/ [Discord]: https://github.com/flutter/flutter/blob/master/docs/contributing/Chat.md [Contributors Guide]: https://github.com/flutter/samples/blob/main/CONTRIBUTING.md	3 months ago