Category: Coding & Scripting

Flutter: add drag handle to ReorderableListView

By default, ReorderableListView only shows drag handles on desktop (GitHub). To enable a drag handle inside a ReorderableListView, it is possible to add the following code into the child’s subtree:

ReorderableDragStartListener(
  index: index,
  child: const Icon(Icons.drag_handle),
),

A full example usage with a very simple list:

var moviesTitles = ['Inception', 'Heat', 'Spider Man'];
ReorderableListView(
  onReorder: (oldIndex, newIndex) {
    // Handle reorder
  },
  children: moviesTitles.map((movie) {
    var index = moviesTitles.indexOf(movie);
    return ListTile(
      key: Key('${index}'),
      tileColor: Colors.white,
      title: Text(movie),
      trailing: ReorderableDragStartListener(
        index: index,
        child: const Icon(Icons.drag_handle),
      ),
      onTap: () {
        // Handle tap
      },
    );
  }).toList(),
);

This will result in the following output:

Adjust text color to be readable on light and dark backgrounds of user interfaces

Most modern user interfaces are supporting different color schemes for day and night: the so called light and dark modes. Selecting a text color for each of those modes is not a big deal and it’s the way to go when designing the user interface.

In some cases, the text color is driven by the displayed contents. In the example below, the tint color is matched to the color of the drink. The global tint color of this app is totally different, but this color adjustment gives a very nice effect. But as you might already see, there is a small problem when it comes to very light or very dark colors: each color either has a good readability on light or dark backgrounds. Some colors might fit to both, but that’s not always the case. In the example below, the light yellow is still visible, but when it comes to small icons or small text, the details are lost.

To overcome this issue, a simple solution is to select two colors for each recipe so that each mode has a different one. That’s fine, but it might totally change the effect of this colored pages.

Can we calculate a suitable color?

Some time ago, there was an article about Black or white text on a colour background? In this one, I described different algorithms to calculate the best text color (black or white) for a colored background. But now, we need the opposite: a colored text that has a good readability on white (light) or black (dark) backgrounds.

When we look at HSL and HSV/HSB color models, we already have a value for ‘lightness’ or ‘brightness’. The idea is to find a color that matches a given hue and saturation and that has a brightness which is readable on light and dark background. For this, we can use different algorithms. Very good results could be achieved with a ‘Weighted W3C Formula‘. This formula take into consideration that the human eye perceives some of the primary colors darker than others.

f'(x) = r ? 0.299 + g ? 0.587 + b ? 0.11

Each color that is located at the border between the black and white overlay is suitable for light and dark backgrounds.

Step 1: convert the given color to HSV/HSB

Step 2: keep hue and saturation constant and adjust the brightness (make the color lighter or darker)

Step 3: convert the HSV/HSB value back to the required color format

Implementation in PHP

A simple calculation for a given RGB color is shown below. The classes used in this snippet are available on GitHub. The code checks the initial brightness of the color and lightens or darkens the values until the ‘border’ calculated by the ‘Weighted W3C Formula’ is reached. This is the case for the value 127, the total range of the brightness is 0 to 255.

$hsv = Convert::rgb2hsv($rgb);

$step = 0.01;
$brightness = Calculate::weightedW3C($rgb);
if ($brightness < 127) {
    while ($brightness < 127 && $hsv[2] >= 0 && $hsv[2] <= 1) {
        $hsv[2] += $step;
        $brightness = Calculate::weightedW3C(Convert::hsv2rgb($hsv));
    }
} else {
    while ($brightness > 127 && $hsv[2] >= 0 && $hsv[2] <= 1) {
        $hsv[2] -= $step;
        $brightness = Calculate::weightedW3C(Convert::hsv2rgb($hsv));
    }
}

return Convert::hsv2rgb($hsv);

Some examples

But how does this result look for different colors? Let’s start with some dark colors. Those are fine for a light background, but they become unreadable on a dark one. The top colors show the input color (before) and the color below shows the output of the calculation above (after).

Color #632300 adjusted to be readable on light and dark background
Color #454545 adjusted to be readable on light and dark background

And now let’s look at some light colors which are fine for dark backgrounds, but they are totally unreadable on light backgrounds.

Color #73FEFF adjusted to be readable on light and dark background
Color #F0C&96 adjusted to be readable on light and dark background

The last color is similar to the example at the beginning and as you can see, the optimized color has a much better readability. This could be achieved for both light and dark colors. The code example shown above is written in PHP. An adoption should be easily possible for any other coding or scripting language

The algorithm mentioned in this post is also available on GitHub https://github.com/mixable/color-utils. This package is usable with composer:

composer require mixable/color-utils

The optimized color can be calculated with:

use Mixable\Color\Calculate;
// ...

$hex = '#ffcc00';
$optimizedColor = Calculate::readableColorForLightAndDarkBackground($hex);

Flutter: expand TextField height to match parent widget

To expand the height of TextField to match the parents widgets height, the following code can be used:

Container(
  height: 500.0,
  child: TextField(
    expands: true,
    minLines: null,
    maxLines: null,
    ...
  ),
),

The important thing is, that both minLines and maxLines need to be set to null.

To set the height of the Container to match it’s parent or even the complete screen, height can be set to double.infinity.

Enable debugging output in PHPUnit

When running PHPunit there are only dots and letters for each test by default:

To enable debug output and get some more details about the tests running, simply add the logging section to phpunit.xml.dist:

    <logging>
        <log type="testdox-text" target="php://stdout"/>
    </logging>

This will create a debug output and helps to track the tests:

In my case, this helped when my code reached an infinite loop due to an error. This results in a RuntimeException without any outputs or log messages. The process just ended with:

[Symfony\Component\Process\Exception\RuntimeException]  
The process has been signaled with signal "11". 

Xcode: how to disable an extension during app build

Sometimes the development version of an app includes multiple code e.g. an extension that should not be released yet. In this case, it’s possible to exclude the extension when building an app. This keeps all your code, but does not include the extension during the build phase.

To achieve this, simply open the Build Phases of your main app and remove the extension(s) from Dependencies and Embed App Extensions. You can add the extension later when required.

Below is a screenshot of the setting in Xcode.

Photo by Clément Hélardot on Unsplash

Create certificate for localhost domains on macOS

Step 1: create a self-signed root certificate

First, let’s create a self-signed root certificate:

openssl req -x509 -nodes -new -sha256 -days 390 -newkey rsa:2048 -keyout "RootCA.key" -out "RootCA.pem" -subj "/C=de/CN=localhost.local"
openssl x509 -outform pem -in "RootCA.pem" -out "RootCA.crt"

The parameter -days 390 sets the number of days, this certificate is valid. Starting on September 1st (2020), SSL/TLS certificates cannot be issued for longer than 13 months (397 days), see https://stackoverflow.com/a/65239775.

If this time is too long, you will receive an NET::ERR_CERT_VALIDITY_TOO_LONG error. In the command above, this value was set to 390 days, which works for me.

Step 2: define domains and subdomains that should be included in the certificate

For this, just create a text file named vhosts_domains.ext and insert the following contents:

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost
DNS.2 = *.mixable.blog.local
DNS.3 = mixable.blog.local

This example includes subdomains for a local development environment for the domain mixable.blog.local and all subdomains like www.mixable.blog.local or apps.mixable.blog.local.

If you plan to use a more general certificate e.g. to include all subdomains under *.*.blog.local, this will not work. The definition only supports ‘first level’ subdomains. It would be great, because this saves a lot of additional setup, but unfortunately this is note supported.

Step 3: create the certificate

Now let’s create the certificate:

openssl req -new -nodes -newkey rsa:2048 -keyout localhost.key -out localhost.csr -subj "/C=de/ST=State/L=City/O=Organization/CN=localhost.local"
openssl x509 -req -sha256 -days 1024 -in localhost.csr -CA RootCA.pem -CAkey RootCA.key -CAcreateserial -extfile vhosts_domains.ext -out localhost.crt

Calling the two commands above will create the localhost certificate that includes all the provided domains and subdomains. Your file listing should look like this:

Step 4: make the certificate available for Apache

Depending on your system, copy all those files into the the configuration folder of the Apache installation. In my case, the installation was done with the help of brew, so the local path is:

/usr/local/etc/httpd/cert/

At the end, it’s not important where those files are located, because we no add this path to the vhost definitions. For this, open your vhosts file and link the crt and the key file as follows:

# mixable.blog.local
<VirtualHost *:80>
    ServerAdmin webmaster@example.com
    DocumentRoot "/Users/mathias/Sites/mixable.blog.local"
    ServerName mixable.blog.local
    ServerAlias mixable.blog.local
    ErrorLog "/usr/local/var/log/httpd/localhost-error.log"
    CustomLog "/usr/local/var/log/httpd/localhost-access.log" common
</VirtualHost>
<VirtualHost *:443>
    DocumentRoot "/Users/mathias/Sites/mixable.blog.local"
    ServerName mixable.blog.local
    SSLEngine on
    SSLCertificateFile "/usr/local/etc/httpd/cert/localhost.crt"
    SSLCertificateKeyFile "/usr/local/etc/httpd/cert/localhost.key"
</VirtualHost>

If you have additional vhost definitions, you can add the <VirtualHost *:443> part to every server name entry and use the correct paths to SSLCertificateFile and SSLCertificateKeyFile.

After changing the vhost settings, it is required to restart your Apache server!

Step 5: add the certificates to macOS

When opening a local website, the certificate should be used but you might see a NET::ERR_CERT_INVALID error. This is the case, because modern browsers/systems do not trust self-signed certificates by default. to overcome this issue, we have to add the created certificates to the macOS Keychain Access. For this, open the *.crt files in Keychain Access:

So that they are know by macOS:

And finally, update the trust settings of each certificate to “Always trust”:

You should now be able to use a secure connection between your browser and your local server:

Step 6: additional fixes

The steps above might already work for Chrome and Safari. If you have problems with Firefox, just open settings and go to Privacy & Security. Then you have to import the root certificate file RootCA.crt, so that Firefox knows about your certificate.

UX improvements: `enterkeyhint` to define action label for the keyboard of mobile devices

Usability

The enterkeyhint is a html attribute described in the HTML standard, which can be used to improve the context of action buttons of keyboards on mobile device.

The enterkeyhint content attribute is an enumerated attribute that specifies what action label (or icon) to present for the enter key on virtual keyboards. This allows authors to customize the presentation of the enter key in order to make it more helpful for users.

It allows the following fixed values: enter, done, go, next, previous, search and send. Let’s have a look at those values and the resulting keyboard style on iOS:

<input>

The default behavior without any value.

<input enterkeyhint=”enter”>

The user agent should present a cue for the operation ‘enter’, typically inserting a new line.

<input enterkeyhint=”done”>

The user agent should present a cue for the operation ‘done’, typically meaning there is nothing more to input and the input method editor (IME) will be closed.

<input enterkeyhint=”go”>

The user agent should present a cue for the operation ‘go’, typically meaning to take the user to the target of the text they typed.

<input enterkeyhint=”next”>

The user agent should present a cue for the operation ‘next’, typically taking the user to the next field that will accept text.

<input enterkeyhint=”previous”>

The user agent should present a cue for the operation ‘previous’, typically taking the user to the previous field that will accept text.

<input enterkeyhint=”search”>

The user agent should present a cue for the operation ‘search’, typically taking the user to the results of searching for the text they have typed.

<input enterkeyhint=”send”>

The user agent should present a cue for the operation ‘send’, typically delivering the text to its target.

Photo by Melisa Hildt on Unsplash

Flutter on iOS: themeMode does not change to dark mode if `ThemeMode.system` is used

In my case, a simple app should automatically use the theme (light or dark) of the system to style the user interface. By default, this should work when using ThemeMode.system (see flutter documentation). But it didn’t.

The themes have been defined as follows:

    return MaterialApp(
      themeMode: ThemeMode.system,
      theme: ThemeData( ... ),
      darkTheme: ThemeData( ...),
      ...
    );

In addition, the WidgetsBindingObserver callback didChangePlatformBrightness() was never called. It was defined as follows:

class MyHomePageState extends State<MyHomePage> with WidgetsBindingObserver
{
  @override
  void initState() {
    super.initState();
    WidgetsBinding.instance.addObserver(this);
  }

  @override
  void dispose() {
    WidgetsBinding.instance.removeObserver(this);
    super.dispose();
  }

  @override
  void didChangePlatformBrightness() {
    print(WidgetsBinding.instance.window.platformBrightness);
    // > should print Brightness.light / Brightness.dark when you switch
    super.didChangePlatformBrightness();
  }
}

After hours and days of searching, it turned out, that the following definition was set in info.plist of iOS:

<key>UIUserInterfaceStyle</key>
<string>Light</string>

Removing this line solved the issue. This setting sets the apps theme to Light, which results in a constant value even if the user changed the brightness to dark. Without this line, UIUserInterfaceStyle depends on the global setting.

Source: https://stackoverflow.com/questions/61620332/platform-brightness-is-still-light-on-ios-even-when-dark-mode-is-on-flutter