Last week, we ended up with a nice looking artist details page.
While I had played around with animations in Flutter before, there wasn’t a tutorial on how to orchestrate multiple animations together. Since that tutorial now exists, I thought this would be the perfect time to test it out.
Just having a quick glance at the animation APIs, I thought having something meaningful ready would take some time. Learning an entirely new animation API would probably require some getting used to, right?
I was wrong. I was able to whip up the prototype for this tutorial in one hour.
Without further ado, let’s get to animating.
It’s been a quite long time since the last post. Since I now figured out the ultimate way to finish articles, hopefully, I’ll be able to push some more content more often. Spoiler alert: it involves beer.
Today, we’re turning the beautiful artist profile page mockup by pramod into a real Flutter UI. For the mock data, we’re using one of my all-time favorite musicians, Andy Fraser, and a couple of the most amazing live performances he did with Free.
Here’s what the result looks like:
Without further ado, let’s go straight into it.
When developing mobile apps professionally, we’ll need to have at least two different environments: a development and a production one. This way we can develop and test new features in the development backend, without accidentally breaking anything for the production users.
Currently, the official Flutter documentation doesn’t have any recommendations on how to do this. Like usual, a quick Google search is your friend. It turns out we can do some StackOverflow driven programming.
UPDATE: This article now lives as part of the official documentation.
It is hard to think of a mobile app that doesn’t need to communicate with a web
server or easily store structured data at some point. When making
network-connected apps, the chances are that we need to consume some good old
JSON, sooner or later.
In this tutorial, we look into ways of using JSON with Flutter. We go over what
JSON solution to use in different scenarios and why.
Usually, when developing apps for mobile phones, having too much screen real estate is not the problem. In fact, quite the contrary. Much thought has to be put into how to structure the app so that it does not feel cluttered.
On tablets, it is a whole different story.
Let’s see what I am talking about through an example.
Result & source code
For the impatient, here’s what the result looks like on a mobile and tablet device:
The source code is available here. If you get stuck, here is the entire git diff for what it took to convert the existing app to be adaptive.