This is part of a series about building a User Defined Type system using Kotlin. If you haven’t read the previous parts (Part 1 and Part 2), I recommend catching up before you do.

In part 1 and 2, we implemented a simple but powerful User Defined Type system. We can describe a type and create instances of that type, and the code to do so is fairly easy to use from Kotlin. Our example usage looks like this:

While we can create a type and instance, this is a User type system, we need to be able to get the types to and from a User. …


This is part of a series about building a User Defined Type system using Kotlin. If you haven’t read the previous parts (Part 1 and Part 2), I recommend catching up before you do.

The Type system we defined is powerful and flexible. Unlike some UDT systems, it allows a type to be defined in code as easily as from user data, and to be used almost like a Kotlin type, as long as all you want to do is move data around. So we’re going to add some more features.

First, it would be nice to more easily access, from code, the properties of a UDT. It’s possible with the data class we’ve defined, but you’d have to iterate the list of properties, we’ll fix that with a similar utility to the one we used in the DType for its fields. As well as a map indexing the values, we’ve added a generic get method to the class, so we can get a typed value concisely. …


This is Part 2 of a series on User Defined Types in Kotlin. If you haven’t read Part 1, I recommend catching up on it before proceeding.

In part 1, we defined a User Type System. It was simple, but flexible. However, it’s still lacking one important feature, creating instances of the Types we define. As it stands, the Type system looks like this:

(Notice that since part 1, I’ve added a method to DType. …


Eventually, most developers end up working on a project with User Defined Types. Often it’s the basis of a customisable forms system. For me, it was a school record system in which different schools tracked different pupil statistics.

When working with UDTs, it can be tempting to reach for a dynamically typed language, such as Javascript, and relying on the lack of strong typing to handle the changing type schema. However, a strongly typed UDT can be made in very few (<500) lines of kotlin, taking advantage of some of its features.

For a UDT, we need to be able to serialize not just the instances, but the type information too. For inspiration, we can look at Google’s Protobuf Struct types. Google have already worked out the hard details of how to structure a Type message — we’re going to adapt it slightly. …


Our current project relies on using ROS to interact with a drone and control station (GCS). The drone and GCS both communicate via MAVLink, so the obvious answer is to use Mavros. Mavros connects to the drone and control system and forwards messages between the two, while making a lot of status information available on ROS topics, and allowing commands to be sent to ROS topics to control the drone.

This seemed like a good idea at first, but there was a problem for our project, we actually wanted to intercept the messages and add some logic to decide if they should be forwarded. Mavros - running as a node - unfortunately, provides no way to intercept the messages. …

James

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store