An overwhelming majority of Flutter code tutorials show phone screens in portrait mode. But what about tablets and landscape mode? Android comes with a system to specify layouts per orientation – can you do this with Flutter?
When I created my first Flutter app Crosswords to learn French, I locked it to portrait mode. This was fine for v1.0, but for v1.1, I wanted to add tablet support. This meant allowing landscape mode. To my surprise, it took only about 30 minutes. You read that right, 30 minutes! As I had already put each UI section into its own widget, it was easy to recombine them based on orientation. And retrieving orientation turned out to be easily done, once I knew where to look ( MediaQuery and MediaQueryData).
Note: I chose to maximise crossword size, so I decided not to show the custom keyboard view across the full width of the screen, but, technically, I could have done it just as easily.
Many Android apps require what Android deems a dangerous permission. For example using the camera, adding an event to the user calendar, or reading the user contacts. Previously, Android used to ask for those permissions at install time, but since Marshmallow, it does it at runtime. So, how do you implement the Android runtime permission flow in Flutter?
A search of Flutter plugins currently shows no results, so I had to figure it out myself for my app Preset SMSs.
In this code tutorial, we will create an app that shows a list of all contacts with a mobile phone number. The app displays a loading screen while it obtains the contacts and an error Snackbar when the app has no permission. The Android code itself is based on the official Requesting Permissions at Run Time guide. For communicating between Flutter and Android, we will use Method Channels.
Love them or hate them, ads are a common way for indie app developers to make money from their apps. So, how can you display a banner ad in your Flutter app?
If you search Flutter packages for “ad”, there are currently two relevant results, both for AdMob. One is admob and the other is firebase_admob. As of writing this, the former only supports interstitial ads and hasn’t been updated for 7 months; as for the latter, it supports interstitial, banner and rewarded video ads as of version 0.3.0, and was updated last week.
This code tutorial will show you how to display a banner ad using firebase_admob plugin. It includes a trick to make sure the ad doesn’t hide the bottom of your screen content, so, for example, your Snackbars aren’t hidden behind the banner ad.
Material Design’s Snackbars are a great way to give feedback to users, and even allow them to undo or retry an action. So, how do you display a Snackbar in Flutter?
If you create a Material App in Flutter, you will use a Scaffold. In the Scaffold.of documentation, there are examples to show a Snackbar. While very useful, in all those examples, the Snackbar is shown when the user presses a button. But often, you need to show a Snackbar following an async operation, such as a server call.
In this code tutorial, we will demonstrate how to show a snackbar outside the build method of your widget, and will call this after an async operation.
A common Android UI pattern for edit screens is to ask the user to confirm that they want to discard their changes when they tap the back button or back navigation arrow. So, how do you catch this user event in Flutter?
Well, after a fair amount of trial and error, the solution turned out to be quite simple, using a WillPopScope.
A fairly common UI action for lists in native apps is “swipe to dismiss”. That is, the user can swipe left, or right, and a leave-behind UI element indicates what will happen if the user continues on with swiping. Typically, the leave-behind element is a delete icon.
Flutter comes with a UI widget called Dismissible – as the name suggests, it enables us to implement this pattern. This code tutorial will show you how.
Learning a new UI engine is always tricky. Thankfully, the Flutter team has highlighted the basic widgets. For this code tutorial, we will focus on Row and Column, which lay out a list of child widgets in the horizontal and vertical direction respectively.
First off, my favourite thing about them is that, even though you may mistake them for Android SDK’s LinearLayout at first, they are actually far more flexible, yet easy to understand.
To figure out how Row and Column work, we will start from 3 different mock-ups and lay them out using them. We will do this as part of an app with 3 screens (one screen per example).
For each example, we will have a rough sketch of what we want, with notes to describe how each part of the layout behaves. Why rough hand drawn sketches and not fancy mock ups done in Photoshop? Because I want to show you a simple process that you can apply to your own mock ups. Oh, and also because pen and paper is a very useful tool (see Tip 3 of 4 tips to boost your software development career).
We all know that no app is maintainable without tests. Indeed, strength of a framework is a function of how easy integration tests are to write and maintain. And I don’t say this lightly – I wrote Android integration tests for a 4.3 rated app with more than one million downloads before Espresso came along!