AppDevCon 2023

9:50: Voyage to planet X – The lesser-known libraries of kotlinx

Severn Everett (Backend Developer)

Some interesting libraries that I wasn’t familiar with yet:

Already known libs:

10:55 SOLID principles in 5 nightmares

Simon Painter (Senior Developer)

Fun talk about the SOLID principles, with the help of some slightly imaginative examples taken from a popular SF franchise. Simon explained what are they, what nightmare scenarios can occur if they aren’t followed, and how they can subsequently be applied.
You can find this talk on the Developer Days Youtube channel as well.

11:50 Using Compose runtime to create a client library

Fatih Giri? (Android Lead)

How to (ab)use (Android Jetpack) Compose to generate PowerPoint slides. In the mean time he explained how Compose works.
The ComposePPT project is also available on Github.
A video of his talk (at another conference) is available on the Droidcon website.

13:15 Observation-based product development using Flutter

Mangirdas Kazlauskas (GDE for Flutter & Dart)

How to use app monitoring, product metrics and UX feedback to improve your app.
Check out the full presentation on the Droidcon website.

14:10: Common mistakes in UI testing

Alex Zhukovich (Senior Android developer)

Some tips on how to write and maintain UI tests, without getting too frustrated.

15:15 Imperative, declarative, object oriented, functional: four of a Kotlin kind

Maia Grotepass (Android principal)

A comparative view of four interrelated programming paradigms: imperative, declarative, object oriented and functional – from a Kotlin perspective.
We use all four kinds while working on an Android app.
The complete presentation is available on the I Code Java SA Youtube channel.

16:10 Decision-making for developers

Rick Kuipers (CTO)

Tips to help developers to make decisions.

There’s a recap available at the Youtube channel.

16:45 Keynote/Being human in times of exponential technology

Rens van der Vorst (Technophilosopher)

Funny and inspirational talk about the downside(s) of technology.


I hope to see all videos from the talks on the AppDevCon website soon.

The Abstraction Ladder

In this post I hope to help you come to a better understanding of levels of abstraction in software design. I’ll use the clean architecture concept and the abstraction ladder to illustrate it. Let’s start with the ladder.

The Ladder

The abstraction ladder is a way to organize things from concrete to abstract. At the bottom of the ladder are all concrete things. At the top are abstract concepts. In the middle are things that are not very concrete, but also not very abstract. This idea was coined by S. I. Hayakawa in his book Language in Thought and Action” published in 1939. He gave the following example of an abstraction ladder:

8. Wealth
7. Asset
6. Farm assets
5. Livestock
4. Cow
3. Bessie
(2. Object of experience, how we perceive the “process-cow”)
(1. “Process-level”-cow, the atoms, electrons, etc. that Bessie consists of)

Lots of other examples can easily be found in biological taxonomy, e.g.

7. Animalia (Kingdom)
6. Chordata (Phylum)
5. Mammalia (Class)
4. Primates (Order)
3. Hominidae (Family)
2. Homo (Genus)
1. Homo sapiens (Species)

Of course the ladder can be applied to a very wide range. I’ll include one more example to illustrate:

7. Information
6. Publications
5. Books
4. Novels
3. Science-fiction novels
2. Dirk Gently’s Holistic Detective Agency
1. My copy of Dirk Gently’s Holistic Detective Agency

As you may notice, when you move up the ladder, the description related to the rung you are on has fewer characteristics than the rung below it.

Code Example

The Dagger (2) documentation contain a good example of how the ladder can be applied to code as well. They’re describing how to abstract and construct a coffee maker. The ladder that we can build from this example looks like this:

4. Coffee maker
3. Drip coffee maker
2. Drip coffee maker with thermosiphon and electric heater
(1. A particular instance of a drip coffee maker with thermosiphon and electric heater)

Clean Architecture

In his article “The clean Architecture” Uncle Bob illustrates software architecture as a set of concentric circles. Each layer represents an area of responsibility within the software. Working from the inner to the outer circle, the following responsibilities are listed:

  • Entities
  • Use Cases
  • Controllers / Presenters / Gateways
  • Web / UI / External interfaces / DB / Devices

Relation to the abstraction ladder

So how does clean architecture relate to the abstraction ladder? I’m sure you’ve already spotted it. If you look at the layers listed above, the most concrete concept is at the bottom and the most abstract is at the top.

Uncle Bob already made the connection between writing code and writing an article in his book “Clean Code”. The abstraction ladder is another tool that authors can use while writing texts.

It can be a tremendous help for you as software developer when you are able to order your software design concepts on the abstraction ladder. It’ll help you put code on the right level of abstraction. After that you can also make sure that calls you make from one class to another are not jumping across multiple levels of abstraction (or in the example of the ladder, multiple rungs).
Further, it might also make communication with peers easier if you simply draw up a ladder of all the concepts you’re talking about.

Further reading

Characterization Testing

A nice way to help you refactor legacy code is to use “Characterization Testing” or “Golden Master testing”. These approach provide a quick way to get cover legacy code with _some_ tests. There is a big catch though:

Unlike regression tests, to which they are very similar, characterization tests do not verify the correct behavior of the code, which can be impossible to determine. Instead they verify the behavior that was observed when they were written.

You can use a tool like “Approval tests” to quickly set up “Characterization Testing”. Emily Bache has a nice introduction video about working with “Approval tests”.

After you’ve covered the legacy code using “Characterization Testing”, you can start refactoring the legacy code. At this point, don’t forget to add unit tests for the new code you’re writing.

For more info have a look at:

Fuzz testing

Last year at Droidcon Online Xavier Gouchet gave a talk titled: “It’s time to up your test game“. Here he talked about testing and more specifically fuzz testing.

Wikipedia describes fuzz testing as follows:

Fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. The program is then monitored for exceptions such as crashes, failing built-in code assertions, or potential memory leaks.


In his talk he introduced Elmyr:

A Kotlin library providing tools to generate “random” values.

Elmyr github page

Seeing how easy it was to use Elmyr, it got me inspired to start using it in my own projects as well. About a month ago I found some time to get started and I’m loving it!

Adding and using Elmyr turned out to be super easy. It took very little time to get up and running.

What surprised me most is that almost immediately I found a bug in my code due to the random test data that Elmyr produces!

Another thing I really like is that I no longer need to think about what test data to use with my subject under test. All I need to do is ask Elmyr to give me some random data.

If you need Elmyr to support some of your own classes for fuzzing, simply create a new ForgeryFactory, add it to the Forge in your test and you’re done.

Now I wish that I learned about fuzz testing ages ago!

If Elmyr doesn’t do the trick for you, Github hosts tons of other fuzzing libraries.