Flutter is a cross-platform UI framework using the Dart language. Since 2018, it has exploded in use and navigating the eco-system gets more and more challenging (but it makes also Flutter a more useful eco-system for professionals). Using a well-built starter app can help you make the right choices from day 1 and support you in keeping in sync with recommended best practices. This post introduces first_app, a carefully designed template for new Flutter applications that is listed on Awesome Flutter and is also aligned with the official Flutter skeleton app.
Only For Beginners?! Not At All!
I think most people have used some kind of Hello World app to get started. As you build your knowledge and your first application, you also form opinions on how you want to structure the application, how to do testing, and you find packages you typically use. Next application, you start out with your previous application, clean up what you don’t want. first_app is not a beginner app, and it’s not an auto-generated code base with lots of things you don’t need (or understand). It’s a skeleton of an application with good structure, a few, carefully selected packages to show how functionality can be introduced, and it’s designed to make it easy remove the parts you don’t need. It is also kept updated with the latest dependencies, Xcode and Android upgrades, as well as with Flutter and Dart best practices.
So, if not using first_app for your project 3, 4, or 5, you can look at the change notes and git history to determine what has changed since you last started a new application. Also, a separate beta branch is kept to integrate new functionality as it is introduced in the Flutter beta channel.
What Is first_app?
The first_app application is quite simple, though it has enough functionality show-cased to be useful. Below are some snapshots from the application.
The application has also a drawer menu with localisation settings and a sample interaction with a backend API. A sample login system is included that can easily be used for your own backend services (OpenId Connect/OAuth2) or an authentication service like Firebase. There is access to the mobile’s GPS location, and a Google Map can be shown. That’s pretty much it from a functionality point of view. In fact, although there is a Google Play version available that you can install on your Android phone, Apple did not approve the app as it has no “real usefulness”, so it is only available through Testflight.
In more detail, the app supports the below. The clean separation of each makes it easy to tailor the app to your needs.
- Support for iOS, Android, and web
- Separation of business logic in models and providers, and UI in a separate folder structure
- Use of provider as an example for app state management with multiple states
- Authentication and authorisation using the https://appauth.io/ OpenID Connect and OAuth2 library
- Global state management of login and login token, app localisation, and configuration, including permanent storage for restarts
- Simple widget framework for handling logged-in, expired, and logged-out states
- Basic UI with sliding drawer menu and menu options
- Testing using unit test framework and simple mocking for log in and log out, as well as location
- Integration tests
- Localisation using i18n and the Flutter standard support to generate boilerplate code
- Use of a global UI theme
- Custom icons for both iOS and Android
- Use of Firebase Analytics for usage tracking
- Use of Firebase Crashlytics for crash reporting
- Use of Firebase Cloud Messaging for push notifications
- Use of a OS native capability (location tracking) using a published plugin (geolocator)
- Use of Google Maps API to present a map of the current location
- Use of an independently defined new widget type called AnchoredOverlay to overlay a map widget
What Is The Value of first_app?
Throughout the evolution of Flutter and Dart, many things have changed. How you should do integration testing, localisation support, and state management are just examples. In addition, Dart introduced null safety (basically static and real-time support to make sure that you don’t get unexpected null values), which caused the entire package eco-system to slowly introduce null safety. Although the transition was seamless compared to many other large language changes, there was a period with tricky dependencies on packages without null safety before first_app could support null safety fully. All these transitions were at clear display in first_app, and once you understood the basic working of the app, it was easy to keep tab of the necessary changes through the change notes and the git log.
Another source of frustration is Xcode and Android upgrades and how those can wreak havoc to the app. A recent example is how Apple introduced changes in Xcode to support their new Apple chips that broke command line builds for Flutter and causing the app to build fine in Xcode, but not from e.g. Visual Studio Code.
first_app is designed with the principle that all parts should be easy to understand and that it should be easy to replace each sub-system. One example is state management. There are many opinions about how to manage state, there are personal preferences, and there are different needs dependent on the app. first_app does not try to solve all things for all apps, and it does not embrace any of the larger frameworks that give you “batteries included”. It is easy to add other state management or frameworks if you want them, but the basic state management is sufficient for many professional apps and easy to extend.
A word of warning: it is easy to get lost in the package eco-system. Do not add a package to your app without looking at pub.dev to verify that it has a history of being maintained. Also, remember that all packages are available in source code, so for more immature packages you can choose to copy the code (remember copyright and to verify the license!) into your app and maintain it yourself. first_app only uses proven and robust packages to avoid that you get stuck in the future by an abandoned package.
To get started, it is easy to use the template code from https://github.com/gregertw/actingweb_firstapp/ and just run it. If you want to have a look at the latest changes in the beta channel, use the beta_channel branch. And if you are entirely new, go to the official Flutter Getting Started docs!
If you just want to see the app in action, you can use the above links to install the apps on your mobile, but the easiest is just to have a look at the web version.
I would love to see your contributions to first_app, suggestions and issues, as well as PRs are welcome!