C64 Tribute Watch Face updated

A couple of years ago I bought an Android Wear device. Naturally, I wanted to see how to write apps for this smartwatch. That app is part of my book about Android programming. When I finalized the version for Android 7 a few months ago, Android Wear 2.0 was still in beta. This has changed recently, so I updated the app accordingly. You can find the source on GitHub. The app itself can be downloaded from the Play Store. Here’s how it looks like:
The watchface
The settings
Watchface chooser
Of course you need an Android Wear smartwatch to give it a try.

Quick tip regarding Android Wear watch faces: PROVIDE_BACKGROUND apparently not needed

Stumbled upon this one by chance. Turns out com.google.android.permission.PROVIDE_BACKGROUND is not needed.


Quick tip: Call a rest service with curl

curl \
--header "Content-type: application/json" \
--request POST \
--data '{"id": 42, "active": true}' \


Dart for Java developers: Mobile apps with Flutter

In a previous installment of my series of posts about Dart for Java developers we took a brief look at how to write a simple web application using Dart. This time, I would like to introduce you to the Dart way of going mobile. It's called Flutter. Flutter had its first public appearance in 2015. At that time it was called Sky. Since then Flutter has evolved quite a bit. Although still being a technical preview it is possible to write real world applications. As with all prerelease solutions, some things will likely change. On the other hand, being an early adopter also means building up skills early.

The underlying idea of Flutter is to build Material Design mobile apps for Android and iOS with one code base using Dart as the programming language. On both platforms the user interface is not made of native components. Flutter handles all painting by itself. Nonetheless Flutter tries to provide expected behavior, for example by using appropriate gestures, animations and transitions. This approach has both pros and cons. I am not going to discuss them here, but leave pondering up to you.

At this point, you are probably asking yourslef how a Flutter application looks both in source code and up and running. I have created a Flutter version of the temperature conversion app. You can find it on GitHub. Here is a screenshot of the app running in the iOS Simulator:

Screenshot of the temperature conversion app

Before taking a look at the code, I would like to talk about system requirements. Currently you need a macOS or Linux machine. Support for Windows appears to be work in progress. Setting things up currently requires quite a few steps, but these are well documented. Finally, let’s take a look at the code. The basic structure of a Flutter app looks like this:

import 'package:flutter/material.dart';
import ...


void main() {
  runApp(new MyApp());

class MyApp extends StatelessWidget {
  Widget build(BuildContext context) {
    return new MaterialApp(
      title: _appName,
      home: new MyHomePage(title: _appName),

class MyHomePage extends StatefulWidget {
  MyHomePage({Key key, this.title}) : super(key: key);
final String title;
  _MyHomePageState createState() => new _MyHomePageState();

class _MyHomePageState extends State<MyHomePage> {

  Widget build(BuildContext context) {
    return new Scaffold(
      appBar: new AppBar(
        title: new Text(config.title),
      body: new Block(

The top-level function main() is the entry point of the application. We instantiate a class that extends StatelessWidget. As the name implies, such widgets have no mutable state. Its build()-method returns yet another widget: MaterialApp. It has a title and a home. The latter one is a StatefulWidget. It overrides createState(), which to no surprise returns a freshly created State. Its build()-method returns a Widget that represents the current state. This may look complicated at first sight, but in fact its super simple. Changes to the state result in build() being called. As you can see in my sample app at GitHub, there is a corresponding setSate() to set this chain in motion.


Dart for Java developers: a visibilty primer

In the previous installments of my small series about Dart for Java developers we saw quite a few lines of code. ...that is, if you looked at the .dart files I linked to. ;-) You may have wondered why some identifiers start with an underscore. I briefly mentioned libraries and packages, but did not say much about visibility or scope. The underlying questions are
  • Where can I see a variable, function or method?
  • Where and when can I access them?
Consider the following source file named a.dart:

var answer = 42;
main() {
  var a = answer;
    var b = a;

It will print 42 once, but then fail with a NoSuchMethodError. That happens because there is no top-level getter b. To a Java developer it will not be surprising that print(b); outside the nested block fails, as b is not visible here. But why do we see NoSuchMethodError? Didn't I just access an identifier?

In Dart access to variables occurs via getters and setters, and if these have not been defined by the developer, they will be there automatically. If we remove the second print(), the program will run just fine (assume a version named a_correct.dart). Now take a look at the following lines of code:

import "a_correct.dart";
main() {

If we run it, 42 is printed once. In a_correct.dart answer has been declared at the top-level, so the identifier can be seen by the library that imports a_correct.dart. But what if we don't want a variable or function be visible? Just prefix the identifier with an underscore. Imagine a file b.dart:

var _answer = 42;
_hello() {

And c.dart:

import "b.dart";
main() {

Not to much surprise, it will fail. Neither _hello() nor _answer are visible. There is more control about what packages export to the outside world, but this is an advanced topic I might cover later. So, for now dear Java devs, just forget about publicprivate and protected. And stick to this simple rule:

If it's local, prefix the identifier with an underscore.

Clear. Precise.


Dart for Java developers: a simple web app

In the previous installment of my small series of posts about Dart for Java developers we have put together the pieces we crafted so far. We saw a small console application which used both model and converter libraries. As a next step we will be building a small web application. The following screenshot shows the running program.

a temperature converter web app

The corresponding html file is fairly simple. If you take a look at the body you find three tags: h1, form and p. The latter one will receive the computed temperature. The headline is merely decorative. The form comprises a text input field for the input temperature, two fieldsets which contain radio buttons for the input and output temperature units, and a button. There is no css to make the ui a little more fancy. Relating pull requests would be greatly appreciated.

So far, so easy. But how do we connect the html file to a Dart program, and how does this look like? The head contains two script references:

<script defer type="application/dart" src="main3.dart"></script>
<script defer src="packages/browser/dart.js"></script>

The latter one bootstraps the Dart runtime, whereas main3.dart (yes, that name is not extraordinarily desriptive ;-)) refers to the program. Let's take a look at it. There is a toplevel main() function, which connects the code to ui elements through querySelector(). To be able to use this function, we must import the dart:html package. Have you spotted the two calls to listen()? One is used to receive button clicks, while the other one will give us events when a key icharacter is entered. We use this to disable the button if the input field is empty. The remaining code is straight forward. We instantiate a model class, set it up, and have it calculate the output temperature.

Isn’t that easy?