DEV Community: Sven Hennessen

A first look at Flutter

Sven Hennessen — Fri, 17 Apr 2020 06:35:28 +0000

This article was originally published on hennessen.net on December 22nd, 2019

Cross-platform app development (read "iOS and Android from the same code-base") is the wet dream of many teams and companies for a long time. I've spent quite some time with projects based on HTML5 + Cordova or Xamarin.iOS / .Android (not Forms), so I have a bit of experience in the area and try to keep up with the trends.

Flutter is in everybody's mouth these days when talking cross-platform app development. Basically, Flutter is Google's approach to the cross-platform topic, based on their own programming language, Dart with a declarative UI SDK. I won't repeat the details of the language or SDK here or its features here. Head over to flutter.dev if you're interested in more.

Apple introduced their own, declarative UI development framework, called SwiftUI, when releasing iOS 13. Thinking declarative UI code often is superior to other approaches (see XAML for WPF, XAML for Xamarin.Forms or Google's argument for the approach in the Flutter docs, ), I gave it quick shot, but became frustrated quickly for all the bugs in the first releases. Hence, it was time to give Flutter a shot for my next iOS side project.

This post shows the key aspects of that app and how I implemented them.

The App - Spiramentum 2

The app is a very simple meditation app. The main features I wanted to have are:

The ability to configure a timeframe for how much time I want to spend
A timer display, for checking the time that has past
A push notification at the end of the time
Store the time spend in Apple's HealthKit as mindful time spent

Besides playing around with another SDK, this app addresses a particular problem for me: All existing mindfulness or meditations apps in the app store, which I've checked, require a registration/login or event subscription.

One question you might have is: Why is the app called "Spiramentum 2"? Have a look at the app project README for the answer.

Widgets

To follow the description in this blog, it is important to understand an important thing in Flutter: Everything is a "widget". With that I mean your screens/pages, controls, layouts, spaces between controls, paddings, etc. Everything inherits from the Widget base class and shares the same life cycle. Flutter provides a variety of widgets as part of the SDK.

The main screen

The single screen of the app is implemented as a stateful flutter widget called MyHomePage and the corresponding MyHomePageState. We need state to maintain stuff, like the selected time to run the timer for or its start timestamp. In addition, other technically required components like a controller for animations are maintained here as well.

Everything is setup in the void initState() method and cleaned up, if necessary in the void dispose() method, which are both inherited from State<MyHomePage>. Another inherited method is Widget build(BuildContext context), which controls what is rendered to the UI. Here is the structure for our UI:

@override
  Widget build(BuildContext context) {
    final titleText = Padding(
        child: Text(
            // A title label to tell the user what to do
        )
    );

    final durationPicker = CupertinoPicker(
        // A picker to the allow selection for different timeframees
    );

    final pickerTransition = SizeTransition(
        // A transition wrapper for the picker
    );

    final timerTextTransition = SizeTransition(
        child: Text(
          // A label for the timer, wrapped in a transition
        ),
    );

    final startStopButton = CupertinoButton(
      // Button to start/stop the timer
    );

    // Finally the page scaffold putting everything together
    return CupertinoPageScaffold(
        child: Column(
          children: <Widget>[
            Spacer(),
            titleText,
            Spacer(),
            pickerTransition,
            timerTextTransition,
            Spacer(),
            startStopButton,
            Spacer()
          ],
        ),
    );
  }

Since the app is targeted for iOS only, only Flutter's Cuptertino* controls (see the flutter docs) are being used.

The two SizeTransitions are used to switch between the timer and the picker, depending on the state of the timer. I will come back to that later.

Interaction and State

Interaction with the UI, background processing, what is executed on the UI thread and what is not have been problematic areas in past SDKs and led to errors in projects. Hence I was curious to see how Flutter solves this and luckily the answer is "very simplistic".

Explicit actions like our button to start and stop the timer, simply have a callback action.

Button(
    onPressed(): {
        // do stuff
    }
)

Updates to the UI are automatically triggered, each time state on a stateful Widget. State updates are triggered through the void setState(VoidCallback fn) method on the widget, which might sound familiar if you've worked with React before.

_myAction() {
    // Update UI
    setState(() {
      myStateProperty = newValue;
    });
}

By the way, the underscore before the method declaration marks the method as private in Dart as you would know it from other languages like C# or Java.

So far so good, but what about long running tasks which should not block my UI? Well, Dart supports async/await like other languages/frameworks do today. Async methods return their value wrapped into the Future type, which corresponds to the Task in .NET or a Promise in JavaScript.

I think, this is basically everything you need without having to worry too much about threading issues or similar. Oh and for our app's timer, there is the Timer class from the dart:async library, which does the heavy lifting (scheduling and threading) for us.

Animation

One thing Flutter surprised me with, was the simple animation API and diverse standard widgets which already allow all sorts of animations. Our simple app uses the SizeTransformation widget, which can be easily animated using a AnimationController.


// do this in initState
var _animationController = AnimationController(
        duration: const Duration(milliseconds: 400), vsync: this);
var _pickerAnimation = 
        Tween<double>(begin: 1, end: 0).animate(_animationController);
var _counterLabelAnimation =
        Tween<double>(begin: 0, end: 1).animate(_animationController);

// and this in build
final pickerTransition = SizeTransition(
    sizeFactor: _pickerAnimation,
    child: ...
);

final timerTextTransition = SizeTransition(
    sizeFactor: _counterLabelAnimation,
    child: ...
);

Having the two transitions rendered right above each other, it is easy to hide one and show the other with _animationController.forward() and _animationController.reverse(). This is how the picker is replaced by the label while the timer is running and vice versa.

Native Plugin

To achieve the functionality I described in the beginning, we need direct access to the HealthKit and UNUserNotification APIs of iOS. Well, there is no native API in Dart/Flutter, hence the answer was to provide a native iOS plugin.

The API is straight-forward and string-based similar to native plugin APIs, e.g. in Cordova.

These are the two classes provided on the Flutter side to wrap the API calls:

import 'package:flutter/services.dart';
import 'dart:async';

class NotificationService {

  static const platform = const MethodChannel('de.sventropy/notification-service');

  Future<void> showNotification(String title, String message) async {
    await platform.invokeMethod('showNotification', [title, message]);
    print("Triggered notification with text $message");
  }
}

class MindfulStore {

  static const platform = const MethodChannel('de.sventropy/mindfulness-minutes');

  Future<void> storeMindfulMinutes(int minutes) async {
      await platform.invokeMethod('storeMindfulMinutes',minutes);
      print("$minutes stored");
  }
}

In the iOS Runner project, this is the code provided to receive the plugin call and call the native API

override func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {

    let flutterViewController = self.window.rootViewController as! FlutterViewController // provided via FlutterAppDelegate base class
    let storeMindfulMinutesChannel = FlutterMethodChannel(name: "de.sventropy/mindfulness-minutes", 
        binaryMessengerflutterViewController.binaryMessenger)
    let showNotificationChannel = FlutterMethodChannel(name: "de.sventropy/notification-service", 
        binaryMessengerflutterViewController.binaryMessenger)

    // ensure permissions for notifications and HealthKit

    storeMindfulMinutesChannel.setMethodCallHandler { (call: FlutterMethodCall, result: @escaping FlutterResult) in
        guard call.method == "storeMindfulMinutes" else {
            result(FlutterMethodNotImplemented)
            return
        }
        let minutes = call.arguments as! Int32
        self.storeMindfulMinutes(minutes: minutes, result: result)
    }

    showNotificationChannel.setMethodCallHandler {
        (call: FlutterMethodCall, result: @escaping FlutterResult) in
        guard call.method == "showNotification" else {
            result(FlutterMethodNotImplemented)
            return
        }
        let args = call.arguments as! Array<Any>
        let title = args[0] as! String
        let message = args[1] as! String
        self.sendNotification(title: title, message: message, result: result)
    }

    // register plugins with platform

    func storeMindfulMinutes(minutes: Int32, result: @escaping FlutterResult) {

        let endDate = Date()
        let startDate = Calendar.current.date(byAdding: .minute, value: Int(minutes * -1), to: endDate)!
        let mindfulSessionTime = HKCategorySample(type: HKObjectType.categoryType(forIdentifier: .mindfulSession)! , 
            value: HKCategoryValue.notApplicable.rawValue, start: startDate , end: endDate)

        self.healthStore!.save(mindfulSessionTime, withCompletion: { (success, error) in
            if !success {
                result(FlutterError(code: "UNAVAILABLE",
                                    message: "Error storing mindfulness time",
                                    details: "\(String(describing: error?.localizedDescription))"))
            } else {
                result(true)
            }
        })
    }

    func sendNotification(title: String, message: String, result: @escaping FlutterResult) {
        let content = UNMutableNotificationContent()
        content.title = title
        content.body = message
        content.badge = 1
        content.sound = UNNotificationSound.default()

        let trigger = UNTimeIntervalNotificationTrigger(timeInterval: 0.1,
                                                        repeats: false)

        let requestIdentifier = "de.sventropy.spiramentum2.notification"
        let request = UNNotificationRequest(identifier: requestIdentifier, content: content, trigger: trigger)

        UNUserNotificationCenter.current().add(
            request,
            withCompletionHandler: { (error) in
                if error != nil {
                    result(FlutterError(...))
                } else {
                    result(true)
                }
        })
    }
}

One thing to point out: Both plugins are "write-only" since only data is sent to the native platform but none is returned. However, it is important to call the result(...) method anyway, otherwise the asynchronous plugin call will not return.

So basically, this concept is nothing new, works as intended, but will never have the flexibility of a native app with all these APIs at hand without a plugin wrapper.

Community

What I liked looking around for resources on Flutter was the community work around the SDK. I'd like to point out three examples:

The "Widget of the Week" videos on the Flutter YouTube channel, where Google presents an existing or new Widget per week, by example
The Awesome Flutter community project on GitHub with a collection of other projects, concepts and patterns
The Flutter i18n plugin for VSCode built by a friend of mine

My gut feeling is, that there is simply more going on around after a short live of Flutter of ~2.5 years compared to other SDKs/Frameworks. I've witnessed the rise and life of Xamarin from the first line, which at least felt a little less noisy than the Flutter hype.

Conclusion

I like Flutter. Most of all for its accessible declarative API, simple concepts and its easy to learn language, Dart. If you've worked with Swift, you'll know that that not all languages are like that.

Update 2019-12-23: This conclusion would not be complete without stating that Flutter, similar to other cross-platform approaches with their own runtime and API can never be as performing and up-to-date (in terms of new features) as the native SDK is. It still is fun and easy to use ¯\(ツ)/¯.

That's it. The entire project is available on GitHub, so feel happy to browse the code.

Feedback? I am happy to hear it @svenhennessen on Twitter.

On working remotely

Sven Hennessen — Fri, 17 Apr 2020 06:31:54 +0000

This article was originally published on hennessen.net on November 15th, 2019

A topic I keep coming back to, is remote collaboration in software development. Why?
Well, I had the opportunity to work in multiple project setups with different setups with regards to the team members locations. Basically it spanned from single location office, over multiple locations in one time zone up to offices and remote colleagues across three time zones. The main reason is, that I myself like working from home quite a lot and will be doing so more in the future. Hence, I started looking around for material on the topic and best-practices for remote teams quite a while back.

This blog sums up, what I've experienced and found in several sources.

ℹ️ For those of you understanding German and being more interested in listening than reading, I've discussed this topic with my friend Michael in the first episode our Podcast Entropisches Duett. However, there might be more in here, since @mi_schm recommended some more material on the topic after the show. Thanks for that!

Which Re-Mode?

Collaboration in software project can have many flavors, spanning from all in one office (not remote) to all somewhere, no shared location (full remote). The usual model I've seen so far in the corporate area, was a larger part of the team being on the same location (obviously). This gets more complex from a team setup perspective when one or more locations are added, which I will keep referring to as a mixed setup.

Looking around for software companies actively, publicly talking about their remote collaboration models, I found multiple examples, like Zapier, InnoQ, Doist, and more which all add their personal experience to the topic. One finding up-front: Atlassian was the only example I found, actively talking about their mixed setup with feature teams on one location.

For me, the topic breaks down in these areas:

Working Mode

Besides the setup of teams from a geographical perspective, the working mode in which the team operates plays a role to the success of a remote team as well. Basically, in this area many of the articles emphasized the importance of the agile best practices many know for years, but probably not so many teams execute.

Examples are Ship things once they are done, not when a deadline tells you or Everybody does support on a rotation basis to keep workload and knowledge distributed across the team.

While doing so, the organizational structure in the teams can have different formats peculiarities: Developers working on features by them selves with reviews by others, compared to pair programming are mentioned.

A while back, I came across an approach entirely new to me: Remote Mob Programming, which is based on a team of four members and non-stop rotation of one member typing and the other three discussing what is to type. The company behind it InnoQ also as a podcast with an episode dedicated to this topic which I can highly recommend, while unfortunately having no experience in this area.

Team Member Profile

Zapier talks extensively about the profile people should fulfill to work in a remote environment. They should be of time management and self-organizing of course. But they also have to be what they call tech-savvy and good writers, as their only direct interaction partner throughout their workday will be a computer, where they communicate in written form. Potential team members need to be ok with working in a non-social workplace, like their home office most of the time.

Manager's should judge employee's on the outcome of their work and not the hours they are online; they should hire trustworthy people and then (and I like that) also trust them.

Communication

Communication is the area, where in my experience things can get complicated easily and hence I deem it to be the most important area.

In remote teams, most commination will happen in text form, usually in a collaboration tool. This requires all participants to change their behavior compared to an office environment:

Such communication is happening asynchronously (and it should). This can be difficult, as GrooveHQ, X-Team and Doist point out, but it is the basis for team members being able to plan their day in advance and be focused when working on a task without interrupts. The planning is getting more important and hence a necessity. Immediate answers to questions just raised, can no longer be the expectation. Synchronous communication can (and as well should) happen in certain rare occasions, for instance for emergencies or team-alignment (like your daily standup). However, async should be the default.

For asynchronous communication, multiple tools are already available and frequently used out there, the most famous example probably being Slack. And yes, email can be used asynchronously, however the usual expectation in projects is synchronous feedback and email has a major other flaw: No transparency to whom is not on the recipients list. Hence whatever the tool, it has to ensure, that all communication is visible to all others and can be found again later. The last point is something that I haven't read consciously in any of the posts I am linking. Thinking of new team members boarding on once a project is one year down the road, tells me that this is highly important.

Synchronous communication can be easily achieved face-to-face, using Zoom, Google Hangout or other video conferencing solutions.

Besides the planning part for your day or the project becoming more important, asynchronous communication adds other aspects of pro-activeness required by all team members. Without transparency across the team, misunderstandings can happen and hence work even not done, or done twice. Transparency means, that all team members communicate transparently on the status of their work, problems, future plans, etc. Some examples I'd like to point out, are:

Meeting Notes, per default, visible to any-one (including management meetings)
Clear, joint priorities for the entire team
Developers stating their plan for the day each morning in Slack
Developers sharing their most important lesson for the day at the end of it ("Today I learned")
All team members following up on the information (i.e. "reading") relevant for their work

Social Interaction

Apart from communication on work itself, the social aspect cannot be disregarded, even in full-remote teams. This starts with everyone's attitude towards communicating with others in text form. Sometimes, chat messages, questions or even decisions might catch us on the wrong foot. There is a known phenomenon, where people would assume other’s unexpected behavior as an display of bad or at least confrontational attitude instead of simply not being up to date or not knowing: Hanlon’s Razor.

Synchronous communication, as mentioned before, still has its place in even entirely remote working teams. There are work-driven reasons, like the daily standup, which simply works better as a direct discussion. Bonding between team-members, building team spirit and getting to know each other beyond work are important goals, which direct conversation and face-to-face meetings help to achieve. Formats like regular 1-on-1's between manager and employee, monthly team-meetings (in person or via video conference) or yearly gatherings in-person are only some of the formats used. Zapier for instance creates pairs of employees randomly every couple of weeks and encourages them to have a discussion and get to know each other.

I've briefly touched the social impact, a completely remote working environment can have on people. At Doist, they are aware of the potential issues, which can arise in an isolated space like your own four walls and hence promote actively awareness and measures against it, to counter these effects on their employees.

Side effects

Random work has its challenges (as seen above), however there are certain advantages mentioned by almost all articles I've read. Less commuting means more time throughout the day and being home earlier. Seeing remote work as the default compared to onsite workshops spares everybody airplane flights. For company owners, remote teams mean no cost for office space and furniture.

In 2019, I cannot finish on the topic without mentioning, that the time and resources reduced, directly result in a reduction of the the carbon footprint and hence helps our planet.

Conclusion

I like working remotely and I like it more than working in an office. I am writing this, while never working longer remotely than two or three weeks in a row. However, reading on the matter makes me think that I will enjoy it much longer, while knowing that frustration can arise when stuff like proactive communication is not lived throughout the team or company.

In case you have any feedback, I would be happy to hear it @svenhennessen on Twitter.

Have fun working remotely, cheers!

DEV Community: Sven Hennessen

A first look at Flutter

The App - Spiramentum 2

Widgets

The main screen

Interaction and State

Animation

Native Plugin

Community

Conclusion

On working remotely

Which Re-Mode?

Working Mode

Team Member Profile

Communication

Social Interaction

Side effects

Conclusion

Sources