Flutter is Dart’s Killer App

This past week we started using Google Flutter to build a new mobile app for Invoice Ninja, I thought it may be helpful to share some of the things we’ve learned early on.

What is Flutter?

At a high level it enables building high quality mobile apps for iOS and Android using a single codebase. While this has been possible for a while now with frameworks like React Native the catch is they use a JavaScript bridge which can impact performance. Flutter compiles to native ARM code, in theory it could be considered ‘more native‘ than a native Android app which compiles to JVM bytecode.

For the record, this isn’t the first time I’ve fallen hard for a new Google technology (anyone remember GWT). That said Flutter is receiving glowing praise from the developer community, myself included.

Here are some key points to be aware of:

  • It’s completely open source, you can drill down into the libraries to understand how they work and debug problems.
  • Everything is a widget, the architectural patterns are very similar to Adobe Flex.
  • It’s becoming very popular very fast.
  • It supports hot reloading which applies code changes in real time while retaining the application state.
  • It provides a comprehensive widget library.

Some of the drawbacks:

  • It’s very new, although Google claims it’s ready for production.
  • It requires learning Dart.
  • The app size will typically be larger than a native app.

Finally some of the reasons I believe Flutter will succeed:

  • ARM is the future of mobile/mobile is the future of computing.
  • JavaScript isn’t very good, or more accurately it wasn’t initially designed for how it’s being used.
  • Probably most importantly… it’s fun to use.

Setting up a Development Environment

The setup guides are good but I ran into a few problems. I initially started on Ubuntu Linux but in the end wasn’t able to get my test app to build, the details are here in case you have any ideas.

I then switched to my MacBook. After dealing with a Homebrew issue I was able to get it running. The last OS I tried was Windows which worked out of the box.

You can choose between two code editors: Android Studio (which is built on IntelliJ) or Microsoft’s VS Code. I’ve found VS Code runs faster however Android Studio provides a more seamless experience with better debugging tools.

A few points worth mentioning:

  • On first launch I had trouble with the Android virtual machine. By default it uses x86, I needed to download a 64bit version for it to run.
  • I initially started on the beta Flutter channel but after a short while I ran into an issue which forced me to change to the dev channel.

Learning Flutter/Dart

When I learn a new technology I’m a fan of reading a book cover to cover, sadly I wasn’t able to find any Flutter books on Amazon (yet). That said their docs are excellent and there are a fair number of tutorials online.

Here are some standout references.

I’d also strongly recommend installing the gallery app on your phone, it’s a great way to discover all of the available widgets.

Finally, it’s worth mentioning that Flutter recently switched from Dart to Dart 2. A new feature in Dart 2 is the ability to remove the ‘new’ keyword when creating objects, you’ll notice a lot of older examples still include it while newer examples don’t.

Deciding on an Architecture

Probably the biggest decisions you make when developing an app (once the technology stack has been chosen) is deciding on the architecture. It seems the main choice right now comes down to whether or not to use Redux.

While many developers love it there is definitely pushback from others who feel it requires too much boilerplate code. This article by the co-author of Redux does a great job detailing the pros/cons.

The latest advice from Google seems to be to use Streams and BLoCs (business logic components) to create reactive apps, that said it doesn’t preclude also using Redux. I think the co-author of the flutter_redux package explains it well on this Reddit post.

Redux is basically a StreamController sitting in an InheritedWidget at the root of your app. StoreConnector is just a wrapper for StreamBuilder with some helper functionality.

Note: the comment will probably make more sense once you’ve learned what any of those words mean.

Starting to Code

At this point I’ve only been writing Dart/Flutter for a few days but I think I have a reasonable sense for the possibilities it enables.

Live reload is amazing but I should point out it doesn’t always work, it’s useful when fine tuning the style of a screen but can fail when making large changes to the codebase.

And finally, back to Dart. I remember first hearing about it and thinking it looked cool but at the time I had no reason to use it, with Flutter that’s no longer the case.

Using multiple databases in Laravel for all queries

As we continue to grow our hosted Invoice Ninja platform we’ve been been looking into both vertical scaling [bigger servers] and horizontal scaling [more servers].

Initially we added more web servers using a load balancer. This was relatively easy to setup and as an added bonus provided higher availability. Over time however we’ve started to see our single database server experience increased memory usage, particularly after releasing our mobile apps.

Our plan was to simply divide our users across multiple databases. One database would function as the lookup server, the other databases would store the actual data.

Searching Google for ‘multiple databases in Laravel’ mainly returns examples of either specifying the connection for the particular query:

DB::connection(...)->select(...)

Or defining it in the model by setting:

protected $connection = ...;

However, if you’d like to use a different connection for all queries you can use:

config(['database.default' => ...]);

For our implementation we created a middleware class to find the database server with the provided credentials. The server is stored in the cache so the lookup is only required once every two hours, this is particularly helpful for the API where there’s no session.

To keep the lookup tables up to date we’re using Eloquent creating and deleted model events. Finally, to ensure our queued jobs use the right database we’re using Queue::before(...) to set it.

Developing a bot for the Microsoft Bot Framework using PHP

We recently released our first version of our Skype bot, I thought it might be helpful to share some of our implementation details.

Our bot enables users of Invoice Ninja to easily create, update and email invoices as well as list their products. The code for the bot is available on GitHub.

Here’s an example:

invoice acme for 2 tickets, set the due date to next thursday, the deposit to 5 dollars and the discount to 10 percent

LUIS is able to parse the command into its distinct parts.

LUIS

Our app can then process the intent and return the invoice.

Skype

Two core benefits to natural language input can be seen in the example:

  • Dates can be easier to select as text. I’d much rather input ‘next thursday’ than have to find it in a cramped data picker.
  • We’re able to expose fields through multiple terms. In our standard interfaces each field needs a single label however with speech we can assign multiple labels, in this case ‘partial’ and ‘deposit’.

Microsoft provide helper libraries for C# and Node but the core features are available through a REST API. When getting started I found this article to be extremely helpful, it covers authenticating with OAuth and sending messages using PHP.

LUIS can handle matching intents but the client and product names need to be matched in our app, to accomplish this we’re using a combination of similar_text and metaphone to select the best match.

When we deployed the bot to production we found that getallheaders() wasn’t available, this solution enabled us to access the authorization token.

If you have any questions comment below.

Using a foot pedal for ctrl and alt modifiers on Ubuntu

I’m a big fan of my DataHand (or one of these) but overtime I’ve found the Ctrl and Alt modifiers a bit uncomfortable.

One of my favorite hotkeys is to use the ctrl key with left or right to move between words but that has me regularly holding down the key.

The solution I’ve found is to use a USB foot pedal, here are the steps to set it up on Ubuntu.

First use evtest to determine the /dev/input/event number and the button codes

evtest
/dev/input/event16: OLYMPUS CORPORATION HID FootSwitch RS Series
Select the device event number [0-16]:
Event: time 1456855230.136267, -------------- SYN_REPORT ------------
Event: time 1456855230.528267, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90011
Event: time 1456855230.528267, type 1 (EV_KEY), code 272 (BTN_LEFT), value 0
Event: time 1456855230.528267, -------------- SYN_REPORT ------------
Event: time 1456855230.872269, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90012
Event: time 1456855230.872269, type 1 (EV_KEY), code 273 (BTN_RIGHT), value 1

Then use evrouter to map the buttons by creating a file called ~/.evrouterrc with the following contents (you’d likely need to update the values).

"" "" any key/272 "XKey/Control_L"
"" "" any key/273 "XKey/Alt_L"

And then run evrouter

evrouter /dev/input/event16

Sites to help predict future trends

One of the challenges working as a programmer is keeping up with new technologies. Although many appear promising if you decide to spend the time to learn something new it needs to pay off in the long run.

There are two sites I primarily use to help decide, I consider both to be good leading indicators of the future success of a language/framework/library/etc.

All technologies will eventually go out of date, the challenge is picking ones that will hang around for a while.

Laravel: TokenMismatchException error

A common cause for this error (assuming you’re correctly passing along the form token) is the form session expiring. This chunk of code will warn the user when the session is about to expire and enable them to extend it by making a simple get request.

Note: you’ll need to add a /keep_alive route which return ‘success’ (or any other value).


<div class="alert alert-warning" id="keepAliveDiv" style="display:none">
    This page will expire soon, <a href="#" onclick="keepAlive()">click here</a> to keep working
</div>


<script type="text/javascript">
    var redirectTimer = null;
    function startWarnSessionTimeout() {
        var oneMinute = 1000 * 60;
        var twoMinutes = oneMinute * 2;
        var twoHours = oneMinute * 120;
        setTimeout(function() {
            warnSessionExpring();
        }, (twoHours - twoMinutes));
    }

    function warnSessionExpring() {
        $("#keepAliveDiv").fadeIn();
        redirectTimer = setTimeout(function() {
            window.location = '{{ URL::to('/dashboard') }}';
        }, 1000 * 60);
    }

    function keepAlive() {
        clearTimeout(redirectTimer);
        $('#keepAliveDiv').fadeOut();
        $.get('{{ URL::to('/keep_alive') }}');
        startWarnSessionTimeout();
    }

    $(function() {
        startWarnSessionTimeout();
    });

Lessons Learned – Part 1

When I think back to when I just started working as a programmer I distinctly remember thinking I knew what I was doing. Almost 15 years later I now have the experience to know how wrong I was. We learn from failure and over the years I’ve had the chance to learn a lot.

I can never forget (still trying…) my first major screw up. I was just a couple of days at my new job working on a mailing list solution for a custom CRM. I had temporarily added a line of code to force the test emails to just be sent to my address. A few hours later my boss asked me to make an adjustment. While working on it he asked me about an email he’d received. Of course I’d forgotten to put back the line of code and had sent my test email to all 200,000 users.

Part of this was likely hubris, how could I possibly forget to set this insanely important line of code. Of course everything that can go wrong will go wrong. I had been testing with some pretty stupid emails, messages to myself and that sort of thing. Luckily the email the went out was just the word ‘test’. Mistakes will always happen, we need to create environments which prevent them.

Looking back this clearly should have been an environment setting. Laravel has an extremely useful ‘pretend’ setting in the email config file which prevents any emails from being sent, writing them to the log instead.

I’m a strong believer in the value of mistakes. Fool me once shame on you, fool me twice shame on me. The scars we get when bad things happen never fully heal which thankfully serve as reminders in the future. I’ve probably become a bit too paranoid now (especially when working with emails) but I’m sure it’s for the better.

Sign up below to be notified of future posts in the series or follow me on twitter @hillelcoren.