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
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>
![image](https://github.com/user-attachments/assets/6a9d8d5b-0d2c-4724-8aca-d750186651b7)
![image](https://github.com/user-attachments/assets/0ef4d00e-e67b-4ec6-9ea3-28511ed4c2b8)
</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:
![image](https://github.com/user-attachments/assets/5a559080-4f9a-45e6-a736-ab849a7adc39)
**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