Flutter: Assorted Notes

Just a few useful notes about Flutter I want to remember:

Update NPM on Windows:

1. Open PowerShell as Administrator
2. Run: Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force
3. Run: npm install -g npm-windows-upgrade
4. Run: npm-windows-upgrade

Update Android app APK version:

1. Go to android/app/build.gradle
2. Increment the versionCode found inside the defaultConfig settings
3. Update the versionName accordingly

Add Flutter to Mac Path:

1. Find where the Flutter SDK is located
2. Open your bash profile, i.e. sudo vi ~/.bash_profile
3. Add the following: export PATH=[PATH_TO_FLUTTER_GIT_DIRECTORY]/flutter/bin:$PATH
4. Save changes

Change Package Name for an Existing app:

1. Go to your AndroidManifest.xml file
2. Change the label name:
   <application
android:name="io.flutter.app.FlutterApplication"
android:label="[APP_NAME]"
3. Change the package name:
   xmlns:android="http://schemas.android.com/apk/res/android"
package="your.package.name">
4. Then go to your android/app/build.gradle file
5. Update the applicationId found inside the defaultConfig settings
6. with the package name:
   defaultConfig { applicationId "your.package.name" }
7. And finally, go to the MainActivity.java file:
   package your.package.name;

Change Package Name for a New app:

1. Run: flutter create --org com.yourdomain appname

Flutter Basics: HTTP Post Requests

Myself and the rest of Team Tiger (from the Flutter dev internship program we’ve recently joined) have just been handed a challenge to work with a simple API, to send HTTP requests and receive responses which a mobile app should understand. I’ve always been fond of reading and understanding web network requests, and knew the challenge would be fun.

If we want to work with HTTP requests, we need to import several dependencies:

The dart packages are built into Flutter, but we also need an external http package, which we have to include in our pubspec.yaml file, like so:

And now we can try sending post requests through our mobile app! Here’s an example code of asynchronously deleting something through an API:

The code is straightforward, sending a .post() method containing the URL of where we want to perform an activity and a  body field which tells us what information we need to send to said URL, all inside an asynchronous Future. We specify that we want to close the HTTP client after the POST request gets completed by sending a client.close command inside the .whenComplete() method.

We can change the app state by running desired commands inside the setState() method. In the example code above, we’re just printing the response received from the POST request. What you want to do about that response is up to you. You can also return the response to someplace in the app if you want.

The if (!mounted) clause is there just to guard us from situations where the user suddenly moves to another part of the application while the POST request is still running. In that case, the request immediately stops and sends a desired return.

One Month with Flutter: Some Notes

Wait, what, it’s already been a month? 😮

It apparently took me an exciting month to build a moderately intricate multi-page mobile app, powered by Flutter, with custom calendar and credit card views. The designs for the pages already existed, which was good because I did not want to worry about designing an app for my first try with Google’s SDK and the Dart language. I only wanted to test-drive writing the code for the user interface and find out what tools and structure I could use for managing state and data, given a relatively short span of time. A month isn’t enough to understand everything about the framework but I did learn a lot from the experience. A realization: I can totally write mobile apps now if I want to.

Some notes I’d like to remember from the exercise:

• Flutter’s built-in widgets really make it easy to build native-like mobile app user interfaces quickly. Baking in default behavior and validations to the widgets is straightforward too. UI with custom behavior will take a bit longer to write but is still relatively comfortable and rewarding to build using composition, given enough time.
• The Flutter tutorials from the Tensor Programming YouTube channel particularly helped me understand how specific widgets and concepts work, including databases and state management.
• I’m currently fond of the scoped_model library for managing state within an app, and the cloud_firestore library for accessing and manipulating a Google Cloud Firestore database. The Scoped Model is especially powerful in sharing state between widgets that are not directly linked together, while Cloud Firestore is a real-time database which can easily be integrated into a mobile app and is free within a certain limit of usage per month.
• At present, there’s an open issue in Flutter about reducing the sizes of the app release APK and IPA files, which are the actual app installers for android and iOS. They’ve recently made progress in the problem, and hopefully they’ll go further forward. If they do, complex Flutter apps can be made compatible with the Google Play Instant service.
• A challenge in building mobile apps is building them in a way that they look pleasing to the eyes in various font size settings. I believe that content overflow is a common problem developers encounter. The Flutter team suggests we test our apps often on small screen devices with a large font size setting.

First Two Weeks with Flutter

I’ve been messing around with Flutter, Google’s SDK for building native apps for both Android and iOS, recently. It’s been two weeks actually, and I’ve found myself captivated by how they’ve made it quite easy to build native and reactive UIs fast, which includes the usual validation and interactivity. That’s really awesome, especially for someone like me who’s never written any native mobile app before.

There’s still many things to learn though before I can confidently call myself a mobile app programmer – state management, databases, animation, APIs, to name a few. After feeling productive with the user interface, I’ll most probably try to tackle all of those in the coming months. For now I’ll keep practicing with our current project at work, will eventually share it with the team, then let them decide what they want to do with it.

In the immediate future I’ll likely write some tools on the mobile platform, for my own use or for others to try.