This is a text version of my presentation at DartUP 2020.
Our main product is a large and complex Property Management System. Also, we have a set of smaller products, one of which is a mobile application intended mainly for housekeepers and other hotel staff. Initially, it was written as a native application for iOS and Android, but about 1.5 years ago we decided to migrate it to Flutter.
In this article, I would like to share some problems we’ve encountered so far, describe the architecture we’ve eventually come to, what libraries we’ve found useful, and eventually, I’ll answer the…
As you probably know from my previous articles and talks, I love Flutter. I really think that this is one of the best options to develop a high-quality multi-platform app. It’s so easy to create custom views with complex animations — especially, comparing with the native Android View layer. The way it promotes composition over inheritance and immutable widgets, or encourages you to make the view a pure function of a state makes me happy.
Unfortunately, I cannot say the same about Dart, the language that Flutter is written in, and that you’re supposed to use to develop Flutter apps…
Continuous integration (CI) is the practice of merging all developers’ working copies to shared mainline several times a day.
One of the most important aspects of CI is keeping the mainline healthy. That’s why it’s crucial to have proper tests, both unit and UI, that can run against any PR and/or commit to the mainline. At the same time, these tests should also be fast. It’s usually not a problem with unit tests, but UI tests, especially if you want to run them on multiple devices, can take a rather long time.
As a balance between speed and reliability, for…
Today I would like to share with you our experience with running our Flutter application in production for about 6 months. We will talk about how to organize your code, which libraries to use, and other tips and tricks we’ve learned so far.
This is actually a text version of my online presentation — for those who (like me) prefer reading to watching and listening.
First of all, let’s talk about cross-platform development in general. …
During one of our recent discussions about Flutter and Flutter for Web (and I do like talking about Flutter a lot), I was asked a question, whether the final goal of our Application Development department is to fire all the front-end developers and replace them with Flutter developers. It was a joke, of course, but I think it’s a good question to think about and to discuss: what role Flutter is going to play in Web development.
Let’s think about types of Web applications we usually develop.
However good Flutter may be, using it for a static page is a…
As I wrote in a previous article, we’re experimenting with Flutter while developing our side project for step challenges with colleagues. This side project should also be considered as a playground, where we can check if we can use Flutter in more serious projects. That’s why we want to use some approaches there that can look like an over-engineering for such a small project.
The weekend was rather rainy, so I was playing with Flutter. Last time I’ve tried it, it was still in beta (or even alpha?), so I was interested if it finally became useful for building multi-platform apps.
I’ve decided to re-make our MileFarClub app (it’s our internal side project for tracking steps and competing with colleagues). Here’s what I was able to achieve while investing into it several hours for 2 days:
The common use-case is like this: you need to get an image from some server, resize and cache it (you’re using Picasso for this, aren’t you?), make corners rounded (ok, this is not the most popular use-case, but it’s what this article is about) and load it into view. So, how can we make rounded corners?
As usual, we have several ways to achieve this in Android.
Some desperate person can offer you to place your image view inside
FrameLayout, add another image above it with a transparent body and solid corners and… you’re done. …
Suppose you have a multi-flavored project. Each flavor is a separate app, so you have to use separate google-services.json file for each flavor.
The problem is that google-services.json file must be placed in the app/ directory (update: as of version 2.0.0-alpha3 of the plugin support was added for build types), so we have to copy this file to app/ directory on every flavor build process.
If we want to automate this process, we can add flavor-specific tasks to our build.gradle file and make them run depending on what flavor we are building.
Here is my way of achieving this.
Head of Applications @ Mews