Flutter: Handling your network API calls like a boss!

If there is one technology that’s literally giving me goosebumps, it’s Flutter. One language for all platforms: desktop, web, iOS and Android. Google has really done something incredible creating this. I strongly believe this tech will take over and really soon if it hasn’t already since its inception around two years ago.

OMG, Flutter!!

I wanted to cover a few things in this article so anyone getting started with Flutter can get going quickly and easily with their API network calls on your projects.

We’ll be creating a small fun Chuck Norris facts app in Flutter using this endpoint. I will be covering these items below in the tutorial:

• BLOC Architecture and Project setup
• API calls setup
• Repos and BLOCS
• UI

Ok — let’s dive straight into it.

BLOC Architecture and Project setup:
So the basic architecture pattern that is replacing MVVM for Flutter is BLOC. They are almost identical except what the BLOC pattern gives you is a data stream that can be updated by adding new data through streams instead of the ViewModel — data flows from the BLOC to the UI or vice-versa in the form of these streams. There is an awesome introduction to streams here.

BLOC Architecture

Let’s hope you’ve already done a few Flutter projects and have a bit of a handle on it. Using your favourite IDE, either Visual Studio or Android Studio, start your new project (you can also do this via the terminal flutter create apiCallsBoss).

My personal preference is Android Studio. So just go ahead and create a new Flutter project in Android Studio and name it whatever your heart desires. I’ll call it “apicallsboss”.

After you’ve created your project we’ll need to setup our packages:
Name them “blocs”, “models”, “networking”, “repository” and “view” as shown below. All of them are pretty self-explanatory about what classes they’ll be holding and it’ll become more clearer as we get deeper into it. I suggest using this architecture for all your new Flutter projects as you’ll be able to separate and manage all your business logic properly and easily.

Package Structure

Next let’s add our dependencies. For this project all we are going to need is our http library for our network calls. Open the pubspec.yaml file and plugin
http: ^0.12.0+1 like so:

Finally run flutter packages get or do a “packages get” in Android Studio.

Networking Setup:
Now for the really fun part ladies and gents.
We’ll be connecting to this api https://api.chucknorris.io/ which churns out random Chuck Norris jokes based on certain categories.

Generating your models from JSON:
Generate your dart models easily and quickly from this online tool or use this plugin for Android Studio here or here (Preferences — Plugins). I love this tool because literally within seconds you can create all your models from large chunks of JSON from your endpoints without writing a single line of code.

There are only two endpoints we’ll be hitting.

https://api.chucknorris.io/jokes/categories
and
https://api.chucknorris.io/jokes/random?category={category}

The first one only returns a simple list of strings so only a model will be required holding a list of strings.

Chuck category model

Ok, let’s hit up our second end-point. Go to https://api.chucknorris.io/jokes/random?category={category}and pop in sport for the category variable. You should see something like this.

Here’s where a little magic happens. Go into either the online converter or simply right click on your ‘models’ package.

This is what you’ll end up with. If you get a ‘package models’ inserted at the top of your class, just remove it and it’ll be fine.

chuckResponsemodel

Ok, the juicy networking bit now.
To get our data flow of communication between our app and the API we’ll need three API classes to assist us with this. Go into your networking package.
Right click and create a new Dart class and call it ‘ApiProvider’.

This is our main API provider class that currently has a GET and some exception handling. Add additional methods like Post, Delete or Put if you need to add those on for your own application.

Now lets go and create our ‘CustomException’ class:

To handle all our API responses on the UI thread we’ll need an API response class (not model).

…and there we have it! All our networking layer classes done. Sit back and take a breather and admire what you’ve done so far. Phew! Incredible, you’re a legend. :)

Now let’s go and finish the rest of our app.

Let’s go and add our repository and bloc classes. Our repository classes act as the ‘middle-men’ or “gateways” to our data source and basically serve as an abstraction between the UI and the data provider (API).

We’ll only need 2 repository classes and 2 blocs as there are only 2 endpoints we’ll be hitting as previously mentioned.

The first repository class will be for our category list:

Chuck Category Repository

Our second one will be for our main chuck response.

Chuck Repository

BLoC (Business Logic Components). BLoC represent a stream of events talking to the widgets (UI). The bloc loading the data will notify the UI widgets whether the data being loaded, completed or if there is an error.

Our Blocs:

Chuck Categories Bloc

Chuck bloc

Cool, time for the UI!!

I like to keep all my views together so pop main.dart into your view package but that is entirely up to you.

We’ll initiate our app in our main.dart call to our Chuck categories UI screen as seen below.

chuck_categories_view.dart

Once all this is implemented, our categories will call our ‘ShowChuckyJoke’ screen.

You should end with something like this once everything is finished up.

Completed project.

The completed project can be found here:

rgodlontonshaw/apicallsboss

Wishing all of you happy coding and happy Fluttering. :) I hope this helped you a bit with your API calls.

Credit: Thanks to Sahil Kumar for the original concept here.

Ryan Godlonton-Shaw is a full-time mobile engineer @Platform45.