Flutter and Android Development

So after some install minor trouble in IntelliJ due to minor bugs in the Flutter Dart plugin, the system works quite nice. Hot reloads are the best. There are however some issues. Like the following.

  1. The produced files are multi-megabyte resource hogs. This may just be the debug version, but even with building production APK, not having JDK 8 options in pro-guard, a simple 1 page GUI hits 6 MB. (Be careful of libraries).
  2. There is little configure-ability in the default demo project. Things like default used SD card for install and other sensible options, mean trips into the Android base code and XML more often than should be necessary. (I can’t edit my MainActivity.java with source highlights and error locations).
  3. The state-container split is weird, especially as all the sub-containers are in the state. I do like the templating though in IntelliJ. (The documentation on preserving state is scarce).
  4. Generic functions are nice, and so is some of the library support. There are still a few inconsistencies, but these should iron out over time.
  5. I’m about to discover the GC of PaintRecorder panic on my graphical reserves. I assume this is making GL shaders in the background.
//looks different now, ... The package dart:ui has issues!!<br />//and a duplicate Image, Rect, ... classes
  void atlasUsing(SmartCanvas sc) {
    sc.drawRawAtlas(hi, _transforms,
        _getCharacterRect(),
        Int32List colors,
        BlendMode.srcOver,//should check for mixing foreground and background
        CanvasManager.unit,
        sc.normalPaint);
  }

A bit of work later, and the dart analyser does not crash as often. I think it really is important to not go too low level without some knowledge. The classes collide, and it is best to import dart:ui as an as (I picked ‘Hood’ for under the hood), so as to avoid many of the issues. This does mean that I will have to abstract many of the functions of the low level to be easy functions working with high level (non Hood) Paint, Rect and others. But it was a fun journey!

The channel interface to native is quite an interesting journey as well. It has all the memories of Java and switching back from dart, some things are missed. I’m using the Android platform to generate some sound in the current project. There is not too much in the way of basics to play sound files in the Flutter libraries. Custom AudioTrack stuff is a definite return to Java and a MethodChannel.

The next thing is some code to put the sound together, and some code to add in some convenience methods for putting animation on the CanvasWidget I’ve put together. The IntelliJ dart analyser keeps failing but is restartable after a bit of editing. The code is quite simple for many tasks. There is some complexity when dealing with Future<X>, which infects its way up the stack, needing some setState() for eventually filling in the data on the future resolution. You’d have thought that a¬†return¬†await would have resolved and made the async wait for a resolved future. Because, the documentation is unclear on many things.

It’s not a perfect language isn’t dart, but it is quite nice to use. Flutter is actually very good. I’d suggest ScopedModel and quite a few of the better packages to be included in most projects you’d make.

Author: Jacko

Technical. Well is mass information conservation the reason for dark energy via uncertain geometry and photon exchange? Is dark matter conservation of acceleration with a gradient field heavy graviton? Does the KODEK work yet?