Flutter: to make a virtue of necessity
Here at Iakta we are a small team of developers. When I joined the team there were just one Android developer and only one iOS developer. Customers are always around the corner and deadlines are looming and so productivity is a thing that really matters. One of our last projects was about maintaining and build a new release of an app called Rotor, previously developed by another team.
In short Rotor is just a Uber style service, but involving artisans such as plumbers and electricians.
You all know that when developers read bad code written by other developers it’s a real mess, and that was really bad code. Both Android and iOS apps had a strange logic and the code was one of the spaghettiest I’ve ever seen.
Now, I like spaghetti, but I don’t like mixing work and food.
I am a big fan of cutting edge technologies and I admit that I like Google stuff pretty much. I had heard about Flutter some months before and that was definitely the right moment to give it a chance.
It took me a weekend to write a scaffold of the new version of Rotor and at Iakta we were really excited about the productivity of the framework, considering that the same app was good both on Android and iOS. Of course the framework was still in Alpha (now it’s beta), but overall it provided a good developer experience
But you can’t deliver a scaffold, so we began to write the rest of application. Two mobile developers working at the same project, sharing ideas and dividing and conquering the commission.
Things we use a lot when developing apps are Android build types and iOS targets. We like to give different icons and colors to different builds (staging, development, release..) in a way we can be sure we’re deploying the right stuff.
In Flutter you can do that in a pretty fast way on android, you just build using the flavor option:
flutter build apk --flavor staging
In iOS things were not so smooth, the same method doesn’t work and we discovered that Flutter seems to have some problem with projects naming and folder path, but writing issues (#14652, #14648) and chatting on the gitter of flutter we managed to accomplish what we wanted. It’s not so immediate and it does not allow to debug the application, but we can always do that on Android.
It took us two weeks to release a new version of Rotor. It was practically a copy of the old version, but you could feel the changes under the hood.
Next releases were straight forward. We added some features such as firebase data notifications using platform-channels (no good plugin is available at this time) and we’re adding a map (planning to fork the current experimental implementation).
Overall Flutter has proven itself as a good framework, productive and maybe a game changer in a field where the messy React Native and the bad Xamarin (just my opinions) were taking over.
And you know what? It’s funny and the community is great!
Bye, a presto!
