When looking at Carriage’s Flutter repos, you may see two files main.dart and main_common.dart and wonder why they both exist (after all, apps only have one entry point!). Both of these files are needed because our repos are compatible with Flutter Flavors (fancy name for build variants).
main_common.dart contains the code that all build variants would share. Now you will begin to see that our main.dart file is simply a build variant. It allows you to define an AppConfig widget (which we can redefine to contain any data we want to vary between different flavors of the app). This is extremely powerful! You can create as many flavors of your app as you need, testing slight variations, simply by creating a new entry point file and defining an AppConfig. To run a new flavor in Android Studio, simply add your new entry point file to a new Run Configuration!
Read more about Flutter Flavors here.
“flutter clean” then “flutter create --project-name <name> --org cornelldti .” are a very useful set of commands when things just aren’t working correctly.
If you get an error that says something like “CocoaPods could not find compatible versions for pod …”:
https://stackoverflow.com/questions/67283211/flutter-cocoapods-could-not-find-compatible-versions-for-pod-fbsdkcorekit
If you are having a null somewhere and are not sure where it came from, it might be useful to check the database to make sure that nothing is missing. But if everything is in order and you are still getting a null, you might want to check the code that is serializing backend information. It may very well be that someone has updated a model in the backend and the frontend devs have not adjusted accordingly. See this PR where the Driver app’s Profile page was not loading due to a misalignment between the backend model’s structure and the structure of the app’s internal representation (which was then passed down to a provider).
When getting the repos working on iOS, some issues and their solutions can be found in this PR: https://github.com/cornell-dti/carriage-driver/pull/56
At the time of writing, our Apple Developer account is an Individual account. If this is still the case, ask the dev leads if they can share the account credentials with the developers. If we have an Organization account, then they can be added as a developer to the team instead.
As Carriage is alongside the Cornell administration, cost, particularly as it relates to the efficiency of backend calls, is incredibly important. Therefore, on both web and mobile, we try to lift state up and pass our data around the app using providers (or contexts and hooks in React). This limits the number of requests we need to make and also makes our code cleaner by eliminating the need to pass data around the app manually as props (this gets very messy!).
Note: If you end up passing around ride information this way, make sure you can guarantee that the information you have stored in your provider is up to date! Definitely want to avoid a scenario where someone misses a ride or a driver comes at the wrong time because a Provider did not contain the most updated ride information.