Flutter: Web Services
It's pretty usual for apps to have some type of web service; a way for the the user to pull and push data outside of local contents. If you're putting in a web service, I hope you're lucky enough to have a well documented and functioning api. In many cases you'll face apis that are poorly documented or just flat broken. The US has a federal spending api, none of its endpoints have been reachable for a few years. Yet there is still a place for developers to browse the stale documentation.
In Flutter there is a way for your mobile apps to connect with functioning apis. I found a Bart api that might be cool to show off that connection. To get started we have to create our flutter project from the command line.
The library we are going to use doesn't currently exists in the project. To remedy that, you'll need to add https as a dependency to pubspec.yaml. Below, at the very bottom, you'll find the explicitly declared https version number as recommended.
Just before we start, Dart builds UI elements using setState({}). Because Dart apps execute all processes on a single thread, we have to be extra cautious of dependent processes. It is possible your feature may require a network call from inside the update scope. But it is very likely to create a poor experience for users. If you kick off a network process during a UI update, there's a risk of having unpopulated values confuse the user. In my flutter app, I made the network call the responsibility of my stateless widget. This ensures we do not try fetching more Bart stations when we wish to update some other smaller part of the UI.
Before our app is able to continue, we fetch Bart stations. These values are special however, we are able to continue making UI underneath while value-operations take place. Using this wrapper we are able to declare things for our app to do when some value changes.
Futures are closely coupled to some await operation or worker. We'll have some operation like fetching data from an api that requires signaling the execution thread that we're off the UI clock during execution.
Here's the implementation of fetchStation, notice the async keyword that is in the declaration. Our signal allows us to do things later, in this case we are able to parse the JSON returned from the Bart api. Often enough we have bloated apis with way too much information; so we have to create objects that sift through the garbage.
After viewing the returned values of the api in Postman. I was able to find the information I wanted to display the user only nested twice down in the JSON.
The final part was letting my UI know what to do with the in-between values returned by some future. We can do that by using a FutureBuilder<T>, this wrapper gives us the ability to create widgets based off T. In my app T is the information about Bart stations returned by the api.
Based on the data existing in our snapshot of the future, we are able to return widgets to use as the current child. My builder creates containers for each of the stations inside our snapshot then adds them to a ListView.
If an error has occurred in our future, we are also able to handle that with some other widget as the child.
The last thing that was helpful was adding some widget for cases where the snapshot hasn't return data or an error... yet.
