A Better Flutter App #2
--
Save your Flutter App’s system and user preferences with ease
One of a series of articles detailing a comprehensive starter app. This app is generated by a template offered by the package, app_template, which uses the underlying framework, mvc_application, based on the MVC design pattern.
I Like Screenshots. Tap Caption For Gists.
As always, I prefer using screenshots in my articles over gists to show concepts rather than just show code. I find them easier to work with frankly. However, you can click or tap on their captions to see the code in a gist or in Github. Tap or click on the screenshots themselves to zoom in on them for a closer look.
No Moving Pictures, No Social Media
There will be gif files in this article demonstrating aspects of the topic at hand. However, it’s said viewing such gif files is not possible when reading this article on platforms like Instagram, Facebook, etc. They may come out as static pictures or simply blank placeholder boxes. Please, be aware of this and maybe read this article on medium.com.
Let’s begin.
Three In One For Starters
The starter app produced by this custom template has three separate apps. Two of which you’ll likely recognize while the third demonstrates the use of an SQLite database. The user can switch between the three with a tap of a menu option. Note, the last app displayed will be the first app presented the next time the app starts up. The starter app uses the mobile phone’s platform-specific stored-preferences mechanism to do this. This article will demonstrate how this is done. The gif files below depict the starter app starting up the last app used. As you see, on three separate occasions, three different apps were last used.
What’s Your Preference?
So let’s see how this is done. In the left screenshot below, you see the code involved when determining which of the three apps to display at startup. Note, the static function called, getInt(), from the Prefs package is returning an integer to the property field, _appCount. This counter is used as an index on the List, appNames, to determine which particular Flutter app gets displayed. With every tap of a menu option, that counter is incremented and the index value loops through that List variable. Pretty straightforward. You’d be right if you suspect the default integer value would a zero if the device’s stored preferences don’t yet contain the key, ‘appRun.’
The right-hand screenshot above displays the ‘App Controller’ that contains that code. Hence, this is the controller responsible for handling this particular preference. And so, in the onSelection() function in the app’s popup menu, that controller is again accessed so as to ‘switch out’ the current app. See below. This time, it’s the controller’s changeApp() function that’s called. It’s in this function where the ‘app counter’ is incremented and its value stored in preferences. See how this all works? Pretty straightforward, right?
The underlying framework supplies the Prefs package which itself works with the device’s platform-specific preferences mechanism — with the ‘start-up app’ being only one of many preferences that are recorded and retrieved in this starter app.
Saving Face
For example, in this starter app, even the last interface used is again brought up the next time the app starts up. As you know, Flutter has been acclaimed to be Google’s answer for cross-platform apps: One codebase with more than one platform-specific interface. For mobile apps, in particular, there is either the Android-style interface (using the Material interface design) or the iOS-style interface (using the Cupertino interface design) depending on which platform the mobile app is running on.
Therefore, not surprisingly, the framework itself can ‘sense’ which interface design to use depending on the platform it’s running on. Since the starter app is to showcase how to do things in Flutter, you should also not be surprised, that with yet another tap of a menu option, you can switch between the Material and Cupertino ‘look and feel’ as easily as you can switch between apps. See below. And again, the last interface design is recorded and retrieved the next time the app starts up. Kinda neat, no?
Below is a screenshot of the app’s State object, TemplateView. Highlighted is the parameter, switchUI, used by the framework to switch to the ‘opposite’ interface design depending on the platform it’s running on — when the boolean value is true. That boolean value, in this case, also comes from the device’s stored preferences and defaults to false if the key ‘switchUI’ is not yet recorded.
You’ll find the use of a device's stored preferences is an invaluable means to adapt the app's functions and features to a user’s own personal preferences. It’s a functionality required of most production-worthy apps and is readily available to you using this framework.
Cheers.
A Better Flutter App #3
