While I figured out early on that narrowing my focus by using a project-based learning approach (as opposed to the topic-by-topic laundry list approach) was important, finding the best tools for the job was a different matter.

If you happen to be searching for some of those things, then this article is for you. After over a decade of programming products, building client applications, answering thousands of questions from junior and intermediate developers, and wrestling with these questions myself, I will do my best to explain how to find the best things.

This article is intended for junior to intermediate level developers looking to get some practical answers to difficult problems. You will not need extensive programming experience to get through it and you may skip over any technical discussions specifics. Those are meant to be helpful pieces of information, but the core of this article is about how to make these decisions in general using what I call: The Law of Suitability.

The topics I will cover are:

• How to Find the Best Anything

  • How to Find the Best Water Bottle

• How to Find the Best Programming Language

  • Navigating Public and Expert Opinions

  • Low Level vs High Level

  • Tightly Structured (Static) vs Loosely Structured (Dynamic)

  • Popularity Is Only One Factor

  • Popularity Is Not A Guarantee Of Employment

  • Hardware & Working With What You Have

  • What if I Want the AI to Code For Me?

  • Avoid the Sunk-Cost Fallacy

• How to Find the Best Libraries and Frameworks

  • What Are Libraries and Frameworks?

  • How to Choose Libraries and Frameworks

• How to Find the Best Programming Principles and Practices

  • D.R.Y – Don’t Repeat Yourself

  • What About Other Programming Principles?

• A Note About Patterns and Architectures

  • How to Find the Best Software Architecture

  • The Design Pattern Trap

• Summary

How to Find the Best Anything

I invite you to follow along with some basic non-technical examples which lay the groundwork for the rest of this article. The examples may sound silly to some, but I have layered in some conceptual patterns which you can apply to programming languages, tools, and concepts – as well as just about anything where terms like good, bad, best, or worst can apply.

How to Find the Best Water Bottle

Suppose that you are looking to solve the problem of staying hydrated and wish to purchase a water bottle.

You consider that figuring out the best water bottle might involve looking into:

• Public opinions and reviews

• Expert opinions and reviews

• The manufacturer’s descriptions and reputation

• Buying and testing water bottles (though preferably not all of them, as that costs too much time and money, generally)

All of those things are fair for consideration. Something which is not well-tested in public presents uncertainty. Expert reviews can help inform your decision, but you have to consider the biases and motivations of such experts. You also should consider if the manufacturer has a history of quality, design, and customer support, or whether they’re simply maximizing profit.

After doing some research, you come up with these options:

• A plastic bottle of water from a vending machine

• A high-tech metal bottle which you can even boil stuff in!

• A simple but ethically sourced, refillable, BPA-free plastic water bottle

However, you noticed that nobody seemed to universally agree about which option was the best. There were usually some common opinions, but it was never the case that every expert had the same evaluation or recommendation.

After reflecting on this, it became obvious that you need to consider how, when, and where you will be using this water bottle. In other words, you need to consider the context or situation of its usage.

Suppose three different contexts within which you have to make this decision:

• You are standing in a rest stop in Death Valley California (often thought to be the hottest place on Earth in summer) and there is a vending machine full of micro-plastic filled, old, generic, and cheap plastic bottles of water in front of you. But you have no other options and are very thirsty

• You are in a camping store preparing for a camping trip to New Zealand with lots of hiking and not too much access to filtered water

• You are looking on your favorite shopping website for something you can bring to work each day to avoid those dehydration headaches from not drinking enough water

In summary, you shouldn’t ignore second-hand knowledge, expert opinions, popularity, ratings, reviews, testimonials, and even first-hand experience. But you will never find the best water bottle for every situation you find yourself in. The best “anything” depends on the problem you are trying to solve and the context (words like requirements or situation also apply here) of that problem.

In other words, none of these things have an absolute or fixed value – their value is always relative. I call that the Law of Suitability.

Let’s now discuss some examples which are directly related to software design and development.

How to Find the Best Programming Language

The Law of Suitability applies just as much to programming languages as it does to water bottles – even though the details and contexts are different. There is no such thing as the best programming language for every person, team, problem, or feature.

But I do have some specific details and contexts to offer which may help you answer that question for yourself. This section will cover concrete details and some general ideas on how to choose a programming language. These patterns also apply to frameworks, libraries, and most other aspects of programming.

If you are not interested in the topic of finding a programming language, feel free to skip to the next sections on topics like libraries, principles, and patterns.

Navigating Public and Expert Opinions

Firstly, you need to be skeptical of popularity and the opinions of experts and “influencers” here.

My general tip here is to be extremely cautious about anyone who makes one of these claims:

• “X” language is the best (though saying “X” language is my favourite is perfectly acceptable)

• “X” language is the worst, is terrible, is dead, is garbage, is useless, and so on.

There are three groups of people who generally make these sorts of statements:

• Actual experts who are voicing their personal preferences but presenting them as immutable facts (how I wish this was not so common in this industry)

• Non-experts parroting opinions of the above group or who have not yet understood the Law of Suitability

• Engagement farmers

It’s also worth noting that people can be experts in a subset of problems but that doesn’t guarantee their opinions about all problems are expert level.

This doesn’t mean you should reflexively dismiss expert opinions in general. Consider both the track records of the person and the degree to which they pay attention to the context of their statement.

Let us look at two examples:

• Expert A says: “Python has the best tooling, support, and ecosystem for ML development”

• Expert B says: “Python is the best programming language”

While Expert B is obviously displaying a lack of precision (either deliberately or not) if you have followed me so far, Expert A is a different case. Whether or not the statements made by Expert A are true (for the record, I have written a bit of Python but no ML code), you can tell that they are considering details and context. Look for people like Expert A!

Low Level vs High Level

In simple terms, low level programming languages are difficult for humans to read and write. Also, they tend to be faster and have a lower memory footprint than high level languages. Conversely, high level languages are closer to human language which generally makes them easier for humans to work with.

I must confess, though, that I have seen plenty of examples of people writing unintelligible code in high level languages – please don’t do that.

Someone working on an embedded system might want to do so in a language like C or C++ to optimize performance or work around the limitations of memory and processing power.

But in enterprise systems, which need to run on a variety of platforms and which closely intermingle with business requirements, rules, and real world objects (thing products, users, and so on), lower level languages are not so popular. After all, upper and middle management generally tends to care about low level optimizations only to the extent it affects the user experience.

I love optimization in general, but never forget that everything is fast with small datasets (that is, when n is small) or high processing power. In simpler terms, sometimes human concerns like legibility are significantly more important than insignificant optimizations on efficiency.

Tightly Structured (Static) vs Loosely Structured (Dynamic)

Ironically, the main downsides and benefits of a language like Java (which is very structured and verbose) versus a language like JavaScript (quite the opposite, depending on how you use it) are the same depending on the context.

Speaking of enterprise systems, using structures, types, interfaces, classes, threading, concurrency primitives, and similar programming constructs can have a variety of benefits. It can insulate you from safety while providing some flexibility via type hierarchies, interfaces, protocols, abstractions and so on.

Further, studying design patterns can teach you repeatable solutions to problems which have been encountered since the dawn of the general purpose computer – or shortly thereafter.

But the Law of Suitability still applies here. Maybe you just need to write a quick script to migrate some data from one SQL database to another. Maybe you know how to approach problems using a more functional approach that doesn’t require or discourages the use of objects, classes, or structs. Maybe you realize one day that trying to apply design patterns, architectures, hierarchies and similar constructs in every situation has actually created as many problems as they were solving. More on that later.

It’s also worth mentioning that most modern language designers and maintainers have understood that we developers like flexibility. Many of us want to avoid premature optimization and unnecessary structure but also don’t want our code to blow up because we accidentally told the program to add together 1.23356 + “Rhinoceros”.

The main point is that structure or a lack of structure is both a blessing and a curse, depending on where it is used.

Popularity Is Only One Factor

I’m not going to say that popularity is irrelevant and that you should start with the least popular hipster programming language you can find. No shade intended to hipster programming languages, but unpopularity is not generally a good thing in isolation, either.

The key point is that many people weighing in on programming languages (probably most) don’t have abundant experience working on a variety of platforms, languages, and settings. If someone has only ever written Python and enjoys doing so, they will naturally tend to regard it above others.

We humans have a tendency to find the first thing that works for us and then die on a hill defending it. But to take a more anecdotal approach here, I know a couple dozen intermediate to senior level developers who have extensive experience in Java and other programming languages. Despite Java still being ranked as one of the most popular languages globally, only one of those developers I know actually prefers to write in Java if they have the choice.

Don’t make the mistake of assuming that the first thing that works for many people will be the last thing you need to try out. I have from time to time experimented with languages such as Haskell, which taught me many valuable lessons about the benefits of making my code more functional (and functionally pure) in nature.

But I have zero intention of using Haskell as my go to solution for building GUI applications.

Popularity Is Not A Guarantee Of Employment

One of the most common things you ought to consider is whether or not the language you pick will help you get a job – assuming that’s a concern. Influencers absolutely love to tell people to choose one particular language because it has the most public commits on GitHub, or another because it has the largest number of programmers using it (which is in practice something that’s impossible to say for sure).

Let me flip that on its head: suppose that the most common programming language and platform combination is JavaScript and web. Let’s further suppose that we have pretty concrete data on the number of job postings on the web which confirms that the largest volume of jobs available is for that combination. Let’s finally suppose that for whatever reason, you strongly dislike JavaScript and enjoyed building a website using PHP.

You will find voices who will tell you that PHP is a dead language and a dead end for job searching.

But if you go looking, you may notice that there is a good supply of job postings out there looking for PHP developers who can expand and maintain existing codebases. You might also have a much better chance of getting an interview because the ratio of job postings to applications is significantly better for PHP developers than JavaScript developers. In fact, my team recently hired a PHP developer!

Hardware & Working With What You Have

This section is largely irrelevant to web developers, but may be extremely important for those looking to target specific hardware or operating systems. Simply put, if you don’t have a computer with Mac OS and XCode, you will have a very hard time developing an iOS app, for example. In my case, back in 2014, I chose Android development partly because I had studied a bit of Java – though a big consideration was that I had an Android phone.

There are some ways around this by paying to use a remote device (such as a remote Mac via an online service), but my experience with such services years ago is that they weren’t great.

Think about what resources you have and how that fits into what you want to build or whom you want to work for. If you have not much other than a cheap computer with a web browser, and you still want to build GUI applications, web development can be a great choice.

What if I Want the AI to Code For Me?

While this topic is worthy of a separate article, I don’t believe this is an unreasonable question to ask. A year ago, I would have told you that at best, the AI can write some basic code and help you learn some things which may or may not be wrong.

How things have changed! Though I would be bad at my job if I copy pasted code I didn’t understand or didn’t test, AI has absolutely become a force multiplier for me as a developer.

Back to the topic in question, how does this relate to choosing a programming language? Well, after telling you that popularity is not always a big deal, by the nature of how LLMs work, popularity is a factor. In terms of general use, languages like Python, JavaScript, and Java are likely to have the largest amount of training data. My experience has been that the languages I typically use, such as Kotlin, TypeScript, and Swift also do fine.

But there is a curious side effect of developing Android or iOS applications that I don’t experience so much in web development. The nature of these constantly changing platforms and SDKs, with tens of thousands of third party libraries, dozens of architectures, and endless opinions about best practices and anti-patterns, means that LLMs can have serious troubles with complexity or specificity.

I expect this issue to be fixed as LLM services improve correctness checking or other methods to reduce hallucinations.

Avoid the Sunk-Cost Fallacy

Perhaps the most important point I can make in choosing a programming language is to avoid the sunk-cost fallacy. For the first several years of my part-time studies, I didn’t imagine learning a second language based on how difficult it was for me to learn Java.

Roughly 12 years later, I have written non-trivial code in Java, Kotlin, Swift, C++, TypeScript, and SQL. Further, I have dabbled with code in C, Python, JavaScript, Racket, Haskell, Objective C, Visual Basic, and C#.

It was not the case that I sought out to learn all of these things artificially – I don’t tend to learn things outside of the problems in front of me. It’s that these learning opportunities naturally unfolded along with my personal and professional interests.

Learning the fundamentals or approaching mastery of any general purpose programming language will have carry over to others. It’s true that someone learning Python or JavaScript without CS fundamentals is not going to have much of a clue how things work at the OS level or lower.

It’s also true that I have met several people who could probably code circles around me in C/C++/Assembly but never made it past building toy programs in University or College.

Just keep learning and try to find a balance between personal interest and professional goals.

How to Find the Best Libraries and Frameworks

The next few topics revolve around a question which we’ll revisit a couple of times before the end of this article: “Does it solve more problems than it creates?”

What Are Libraries and Frameworks?

Before we proceed, here’s a useful but not definitive definition about the relationship between libraries and frameworks. You’ll find other definitions, but there’s remarkably little consensus on topics like this in this industry.

For me, a library is code which you can take from somewhere and use it to build things. It could be anything from a single line to a large and complex sub-system – usually something in between. I could give you a long and pedantic definition, but that’s not appropriate for this context (suitability!).

One example could be Java’s Math (java.lang.Math) library, which provides you with the following: “The class Math contains methods for performing basic numeric operations such as the elementary exponential, logarithm, square root, and trigonometric functions.”

Some people use the term framework interchangeably with library, and I don’t have any problems with that. When I think of a framework, I’m thinking about something which you build stuff around and is not necessarily to do with solving a specific problem domain (such as mathematics).

An example of this would be RxJava, which is a rather complex framework you can use to bind together and manage data flows across an entire application. I’ve used this framework in almost a dozen applications which did very different things in principle.

I do consider a framework to be a library, fundamentally – they just have a different set of goals and often a larger footprint.

How to Choose Libraries and Frameworks

When I think about choosing libraries and frameworks, I ask myself these questions:

• Does it solve more problems than it creates compared to writing my own solution?

• Is it well-maintained (regularly worked on, responsive authors, backed by tech companies)?

• Does it have good documentation (less of a problem now that we can leverage AI for this purpose)?

• What kind of footprint does it have?

Let’s take two examples. I won’t refer to the specific platform or name of these libraries to avoid offending anyone. But they were/are both used in mobile development (though they are solving common GUI problems on any platform).

Firstly, one of my favorite libraries had one job: It loads images into the UI.

Although devices are more powerful than they used to be, it can still be a problem to load large images on smart phones for display. Mobile operating systems can be aggressive about killing programs (that is, processes) which use up too much of the system’s resources.

This library handles all aspects of loading images that I’m concerned about:

• Loading the image into a particular widget

• Displaying an appropriate loading indicator

• Displaying an optional error or fallback state that tells the user something went wrong

• Handling the complexities of asynchronously loading in (via URL/URI), processing, and compressing potentially large streams of bits (that is, image data)

• Doesn’t inflate the packaged application’s size unnecessarily

• Doesn’t change its public API frequently (think changing function names which cause people’s implementations to break when updating versions)

• It solves problems that I’m not interested in solving

Secondly, one of my least favorite libraries also had one job: Pagination. Pagination, or paging, in this case refers to loading data in chunks into an application. This is an extremely common pattern in shopping cart or social media applications.

The library I am thinking of approaches that problem like so:

• Tightly couples every layer of your client application (from front end to back end) to its dependencies

• This tight coupling makes testing difficult without jumping through some hoops

• Handles the core problem of pagination well unless you need customization or specialized cases

• Frequently changed its public facing API

• Solved (in general) a problem which I am quite happy to write my own solution for

• Did not play well with other frameworks due to a restrictive set of types and lack of flexibility

• Was constantly updated for a couple of years then ditched and marked deprecated

• Did not inflate the packaged applications size too much but certainly more than my own solution would

As you can see, even something which solves a core problem reasonably well, can still fail this simple test of: Does it solve more problems than it creates? Having written pagination code by myself on a couple of occasions now, I would have to be pretty strongly convinced not to.

How to Find the Best Programming Principles and Practices

There are more best practices and principles than I care to describe in detail. What I will do is explain why I treat programming principles as being distinct from immutable/unbreakable laws. Similarly to my goal of finding the best programming language, I wanted to find the best principles in order to write the best code.

The problem is that any programming principle I’ve come across has also been subject to the Law of Suitability. I’ll discuss one example from personal experience and point out that the question we asked above, “does it solve more problems than creates,” also applies here.

D.R.Y – Don’t Repeat Yourself

This principle can be summarized with the idea that if you find duplicated code, you should pull it into a separate module (file, function, class, library, and so on). Without getting into the weeds, the act of pulling the duplicated code into a separate module can be thought of as a process of abstraction.

To be fair to the creators and proponents of this idea, it’s more nuanced than that. But many developers never bother to dig that deep into nuances – nor should they have to. I ran into the nuances simply by applying this idea more than I should have.

There a couple of cases where code duplication is sometimes preferable:

• You have a set of similar modules (say similar widgets or business rules) but they get used in different places for different reasons

• You have a set of similar modules which might change for different reasons (for example, rapidly changing demands from product teams and clients with different priorities)

• You’re deliberately grouping certain modules that work together in distinct packages, files, or directories to insulate modules/groupings from affecting each other

• You find that you need to add details about one particular implementation into your abstraction, but those details don’t apply to other implementations (that is, it’s a bad abstraction)

All of the things I listed above are summaries of things I have run into in the past. The key take away is that I broadly agree with avoiding code duplication. I also know of some cases where I prefer it. Suitability!

What About Other Programming Principles?

In general, you can think of all programming principles like YAGNI, DRY, SRP (and other aspects of SOLID), and even software development methodologies like AGILE and Waterfall in the same way. Contextually, you can use them as guidelines to help avoid some common problems. But a person of sufficient creativity and experience can come up with a situation where following any of these principles creates more problems than it solves.

In many cases, you need to apply these things too much in order to understand what too much means in practical terms. Just be careful not to swing too far in the other direction when one of these principles really breaks down in front of you. I’ve also made that mistake and had to re-adjust.

To date, I haven’t come across a programming principle which is universally true. There are some which come close to that, but I can always imagine a situation where they’re not the best approach. Take a good one like: Always write the simplest code you can write. In other words, don’t add extra complexity without a reason.

Well, suppose you have a not great value system or incentive structure which encourages inflating your work artificially. Need I say more?

A Note About Patterns and Architectures

I’ll now discuss the topic of patterns and architectures in software systems with respect to the Law of Suitability. Software architecture is the only thing I consider myself an expert in, and I have read multiple books on design patterns. I always try to provide some useful info on these topics when I get the chance.

How to Find the Best Software Architecture

To summarize entire articles, courses, and public talks I have given on this topic: The best software architecture depends on project and personal requirements.

One way to grasp the main idea is to ask yourself whether the best architecture for a hospital is also a good fit for a 2-bedroom apartment. The obvious answer is that we might expect a few commonalities (doors, windows, bathrooms of some kind, and so on) among these different sets of requirements. But the ideal, or even just a good architecture for a 2 bedroom apartment cannot possibly be the same for a hospital.

In short, you will never find an architecture which works well for all projects and requirements.

Here is a list of architectures I have some familiarity with:

• Model-View-Controller

• Model-View-Presenter

• Model-View-ViewModel

• VIPER

• Clean Architecture (Robert C. Martin style)

• Model-View-Intent

To make matters more confusing, there are multiple different ways to implement these architectures – almost as many ways as developers implementing them! M-V-VM is one of the more common architectures in mobile development, and I can think of at least five different variations on how to achieve what some people think of as a single architecture.

Here are my general suggestions for working with these architectures:

• Be wary of adding unnecessary complexity with the more complex architectures (particularly Clean Architecture, as many people get this horribly wrong)

• Don’t try to make the project requirements fit the architecture – work the other way around (the best indicator for this is noticing that something you’re trying to implement is made unnecessarily difficult because of the architecture you’re using)

• Don’t be afraid of applying different approaches in different features of the same application instead of blindly applying the same pattern just for consistency’s sake

The Design Pattern Trap

One of the most common engagement farming tactics I see on social media is to post lists of design patterns “that you must know” in order to get a job or to scare junior programmers into buying your low-quality, copy-pasted content of each pattern.

Don’t get me wrong, I loved studying design patterns and I use a couple key patterns in most GUI applications I build. The Observer (a.k.a. Publisher-Subscriber or Pub-Sub) Pattern really shines when you need to glue together a bunch of asynchronous data sources. I love seeing library developers give me a nice Builder Pattern to work with their APIs. I think understanding the basics of patterns like the Bridge or Facade can teach you how to hide details behind abstractions, which is actually simpler than the big scary words describing these things make it sound.

But I spend very little time in my day to day work thinking about or in design patterns. Instead, I’m always thinking about the kinds of attitudes and principles that give rise to these patterns:

• Promoting loosely coupled code (separating the creation and usage of dependencies and parameters, reasonable usage of abstraction)

• Writing classes, interfaces, protocols, and functions which do one thing (though this “one thing” might be a macroscopic goal instead of a microscopic operation)

• Avoiding complexity wherever possible (a common source of this complexity is over-use of abstractions)

• Not pretending that every complex problem has a simple solution (that is, as simple as it can be but no simpler)

• Avoiding pre-mature optimization

Again, I will only apply these principles and attitudes to the extent that I find they solve more problems than they create. Design patterns, when applied too rigorously, can break many of those principles – particularly when it comes to avoiding complexity and pre-mature optimization.

Don’t try to make your project requirements fit your patterns. Instead, think about which patterns might suit your project requirements and deviate as necessary.

Summary

My goal with this piece was to provide three things:

• A practical overview of choosing a programming language and avoiding the traps the people can fall into when navigating these sorts of topics

• A philosophical but pragmatic framework which you can use to evaluate the suitability of anything – with emphasis on learning and developing software

• A breakdown of how I approach other topics like tools, architectures, and patterns

While it can be important to consider things like job opportunities and your current hardware, don’t discount personal interest as a driving factor. From what little I remember about studying cognition (learning how to learn), interest is tightly coupled to motivation and memory. We can’t always exclusively do what interests us, but I suggest you look for intersections between personal and practical concerns as often as you can.

In closing, I encourage you to think about other areas where you might be able to explore the principles of suitability and the problems of tribalistic thinking. Change is constant and value is relative.

I will explain what they are in simple terms, but my main goal is to change how you think about abstractions in general. All of this is in service of helping you develop the art of programming.

These are the topics I will cover:

• What is an abstraction?

• How to use abstractions in your programs
  – How to use interfaces and protocols
  – How to use function types and lambda expressions

• Is abstraction the most important idea in programming?

• How much abstraction do I need?

The code samples will be in Kotlin, but I have written the article assuming you only have basic programming knowledge in any industry standard language.

I also use a variety of approaches to cover both object-oriented and functional styles of code.

What Is An Abstraction?

To begin with, we will discuss what this term means in the most general sense. Here is a simplified definition I have come up with for an abstraction:

“A less detailed representation of an object or concept in nature.”

I know my definition sounds very vague, but we will discuss some clear examples shortly. First, we must understand what detail is.

What Is Detail?

Detail refers to the quantity, or density perhaps, of information. Here are two examples of data models which are more and less detailed:

User {
  name,
  id
}

User {
  name: String,
  id: Integer,
  phone: Integer,
  email: String
}

There is no need to overthink this point! More details is another way of saying more information or more complexity.

The only other key point is to understand what a representation is.

How to Represent Something

Suppose you are going to travel somewhere which has a particularly deadly kind of venomous snake. In order to gain information about this snake, you have a few different options:

• Read a verbal description of the snake and its behaviour

• Look at a drawing or picture of the snake

• Listen to audio of what it sounds like when behaving aggressively

All of the above points are examples of different kinds of representations, or abstractions, of the venomous snake.

In each case, some pieces of information, which accurately represent properties of the real snake, are conveyed. However, neither a verbal description, nor an image, nor a recording can bite you!

Here we see the main utility of abstractions: Conveying important information (also known as details or properties) of an object or concept, while leaving out the unnecessary information.

How to Use Abstractions In Your Programs

Before we discuss some specifics, it is worth mentioning that everything in a computer program is technically an abstraction.

In fact, programming languages, as well as all forms of mathematics, are systems of abstractions.

However, programmers tend to think of abstractions as a narrow band of software entities usually referred to as:

• Interfaces or Protocols

• Abstract Classes

• Function Types/References/Signatures

• Super/Parent-Classes

Unfortunately, the names and mechanics of the above software entities can vary substantially in different programming languages.

For this reason, I will take two examples which may be more or less appropriate to your preferred languages:

1. An interface or protocol (which will also cover abstract classes)

2. A function type or method reference

In any case, don't worry so much about the names or any minor differences in how these things work across languages. Instead, I invite you to focus on the general ideas.

How to Use Interfaces and Protocols

I will use the term interface from here on, but this term is synonymous with protocol. I will also use the term function synonymously with method.

Interfaces allow you to define behaviour of functions, classes, or objects, without defining their implementation.

Don't worry, I am not like some teachers who throw out some jargon and pretend like I am teaching you something.

Let's look at exactly what I mean by behaviour and implementation.

Behaviour literally means a function declaration:

interface UserDataSource {
//this line below has a function declaration but no function "body"
  fun getUserById(id: String): User?
}

data class User(
  val id: String,
  val someData: Any
)

You can see the footnotes below regarding my usage of the term “function declaration.”

To translate this into English, this function declaration says the we are defining a function which:

• Is named “getUserById”

• Accepts a String type called “id” as an argument when called

• Returns a “User” or a null value if no user exists (this is because we have a “?” after the “User” type)

Implementation refers to the function body:

//Note that ":" is short for extends/implements in Kotlin for the class
//declaration
class UserDatabase(): UserDataSource {
//the curly braces, and everything between them, is the implementation
  override fun getUserById(id: String): User? {
    var user: User? = null
    //… not important for this example
    return user
  }
}

Another name for the function inside of the interface is an abstract function. Hopefully, our discussion on abstract meaning “less detail” is starting to make more sense here!

Some notes for accuracy:

1. Some languages have features to define properties, variables, and even implementations (that is, function declarations + function bodies) within interfaces. This does not change the primary purpose of interfaces, though.

2. The term function declaration will be defined differently depending on the language. Instead of worrying about verbal definitions, please consider my code examples to follow what I mean.

What About Abstract Classes?

Apart from in Python (and perhaps other languages I am not aware of), abstract classes are very similar to interfaces except for one key difference: a class may only inherit from a single abstract class.

In my opinion, before languages started to include ways for interfaces to define their own implementations, the use of abstract classes versus interfaces was clear:

• If you only want to share behaviour across a set of software entities, use an interface

• If you want to share implementation and behaviour, use an abstract class instead

Unfortunately, this distinction is very blurry since many languages now have features to add implementation to interfaces (like Java’s Default Methods).

The only general recommendation I can make which does not account for the specific details of any particular programming language is this: Use the simplest construct to get the job done.

How to Use Function Types and Lambda Expressions

There are different ways to achieve abstraction without defining interfaces or classes. But the amount of structure these language features require is still subject to language specifics.

Kotlin provides enough of these features that you will hopefully be able to make some connections with your preferred languages.

How to Use Function Types Instead Of An Interface

We will start with a practical example and then explain the finer details part by part.

Suppose we want to set up an abstract function (recall that this means a function with no implementation) to handle a click event.

Using something like an interface, we could do the following:

//assume this is an platform/OS component that tells you when
//a user clicks something on screen
class PlatformComponent(
  var clickListener: ClickListener? = null
) {
  fun userClickedScreen() {
    //Note: the "?" means handleClick() is only
    //called when clickListener is NOT NULL
    clickListener?.handleClick()
  }
}
//This interfaces hides (abstracts) the concrete class/type
//which handles the click
interface ClickListener {
  fun handleClick()
}
//This concrete class/type handles the click
//by extending the interface
class ScreenController() : ClickListener {
  override fun handleClick() {
    println("Click handled.")
  }
}

fun main() {
  PlatformComponent(
    ScreenController()
  ).userClickedScreen()
}

An alternative approach is to use a function type instead of an interface:

fun main() {
  val controller = ScreenController()
  val component = PlatformComponent(
    //The double colon tells the compiler that we are referring to
    //the function handleClick defined in ScreenController
    controller::handleClick
  )
  component.userClickedScreen()
}

//assume this is an platform/OS component that tells
//you when a user clicks something on screen
class PlatformComponent(
  var clickListener: () -> Unit
) {
  fun userClickedScreen() {
    //This is equivalent to calling ScreenController.handleClick(),
    //but PlatformComponent does not know that. Abstraction!
    clickListener()
  }
}
//This concrete class/type handles the click
class ScreenController() {
  fun handleClick() {
    println("Click handled.")
  }
}

In this example, we can see how there is even less structure required to achieve the same result. But keep in mind that having less structure does not immediately imply better code. Really, it depends.

In any case, with a practical example in mind, we can break down how this code actually works in more detail.

How to Use Function References

If you are unfamiliar with how function types, method references (or whatever else they are called) work, this section explains them in Kotlin. Feel free to jump to the next section if you are already familiar.

Similar to most modern programming languages, we can create a reference variable to a particular function in Kotlin:

var clickListener: () -> Unit

In Kotlin, function types have the following syntax:

(optional list of parameter types) -> return type

For example:

• (Int, Int) -> Int means that the associated function must take in two Int parameters, and return a single Int

• () -> Unit means that a function has no parameters and executes without returning a meaningful value

Unit is roughly equivalent to Java’s void return type or Python’s None type – at least in principle.

When it comes time to call (invoke) a function reference, we have two options:

• clickListener() for short

• clickListener.invoke() is the full syntax, which is necessary when making null-safe calls like clickListener?.invoke(), for example

How to Use Lambda Expressions

In the previous example, it is worth noting that ScreenController does not care what the actual function it is invoking happens to be named.

We can take this level of abstraction even further, by not even defining a ScreenController:

fun main() {
  //note that the outer parenthesis are optional in Kotlin,
  //but may make this easier to understand
  val component = PlatformComponent(
    { println("Click handled.") }
  )
  component.userClickedScreen()
}
//assume this is an platform/OS component that tells
//you when a user clicks something on screen
class PlatformComponent(
  var clickListener: () -> Unit
) {
  fun userClickedScreen() {
    clickListener()
  }
}

Unlike the previous examples, this one is not intended to resemble a practical scenario – just to demonstrate a lambda expression.

The actual lambda expression is this:

{ println(“Click handled.”) }

As you can see, it does not get much more abstract than a lambda expression.

On the surface, it's almost like defining only the implementation but not the behaviour. But at least in Kotlin, the lambda expression must conform to the type we are assigning it to.

In this case, { println(“Click handled.”) } has no parameters and does not return a meaningful value. So it conforms to () -> Unit.

Which Approach Should I Use?

You may wonder which approach you should be using – assuming your language allows for multiple approaches.

The most accurate answer I can give you is that there is no general rule.

Plenty of teachers these days will say “x is worse than y” or simply “x is bad,” because it works great for clickbait and search engine optimization.

But a language, platform, code construct, architecture, and just about anything else can only be judged good, bad, better, or worse relative to your requirements.

In fact, different requirements are the reason we have languages as different as Python and Java which are both extremely popular.

So instead, try different approaches and be skeptical of anyone who makes absolute statements without discussing requirements.

Is Abstraction the Most Important Idea in Programming?

The point of this article was never to say: “Using interfaces and abstract classes everywhere will make you a better programmer.”

In fairness, as many developers do, I went through a phase around 2016–2018 where I did actually think that statement was pretty accurate.

Instead, the point of this article is to explain two things:

• Abstraction in programming, in my opinion, should not specifically mean abstract classes, or any particular code construct

• Abstraction in programming is a process by which we design our software entities according to how much detail they internally (privately) contain and externally (publicly) provide

In a sense, every decision we make about the structure of our code, regardless of the language, comes down to this process of abstraction.

With that being said, how do we know when making some aspect of our program more abstract is beneficial, useless, or detrimental?

How Much Abstraction Do I Need?

I can only think of one kind of situation where you should strongly consider using something like an interface or function type.

Recall that these software entities provide variability of implementation but consistent behaviour. Further, that implementation typically refers to the body of a function.

Two things follow from that observation:

• If no variability of implementation is required, there is not likely to be a benefit of using a more abstract software entity.

• If variability of implementation is required, using a more abstract software entity is likely beneficial.

We will now discuss two situations I have encountered where variability is a requirement.

How to Make Your Code Easier to Test

Suppose that we have some kind of software entity, which must request some user data from a database or network adapter:

class PresentationLogic(
 val datasource: Datasource
) {
    fun start() {
        val someData = datasource.getData()
        presentData(someData)
    }

    //...
}

class Datasource() {
    fun getData(): Data {
        var someData = getLocalOrRemoteData()
        //... error handling and so on

        return someData
    }
}

Also suppose that we want to test PresentationLogic without needing a real datasource to supply the data.

There are a few different ways to solve this problem (see the note below), but a simple solution is to make the datasource more abstract:

class PresentationLogic(
 val datasource: DatasourceInterface
) {
    fun start() {
        val someData = datasource.getData()
        presentData(someData)
    }

    //...
}

interface DatasourceInterface {
    fun getData(): Data
}

From there, we can create a fake implementation of the datasource in a test environment:

class FakeDatasource(): DatasourceInterface {
        override fun getData(): Data {
            return Data()
        }
}

@Test
fun testLogic() {
    val logic = PresentationLogic(
       //here we provide the fake version
       FakeDatasource()
    )
}

Using abstraction, PresentationLogic does not know or care whether it is talking to a fake or real datasource. By extension, it does not need to change to work with either of them. Variability of implementation!

Note that there are other way to achieve this variability apart from using an interface. You could use a mocking library, or configure a build tool to swap out implementations.

There is no clear answer to which approach is better outside of discussing specific requirements.

Also, note that this approach would not actually work unless the details of how the datasource is created are kept separate from PresentationLogic.

This is commonly referred to as Dependency Injection, which I will discuss in a separate article.

How to Work With Different Versions and Vendors of a Service

Suppose that for some reason, you must work with different versions or vendors of the same service depending on different requirements.

An example could be supporting both AWS and Firebase to store the same data. Another example could be supporting a legacy version of a service along with a newer version of that same service.

In any case, it is another situation where variability of implementation is expected.

The code examples we will discuss have the following requirements:

• A client program must use three services, all from different vendors, to perform the same behaviour

• The decision to choose a particular service is determined at runtime based on the environment (platform, OS, hardware, and so on) of the client program

For those wondering, “client” in this context is a generic word for some program or software entity which uses other programs or software entities.

For example, YouTube’s website and mobile apps are “client apps” of YouTube’s backend servers.

Without applying any abstraction, our client program will need to know about every possible service and be told which service to choose:

fun clientProgram(
    request: Request, 
    awsService: AwsService,
    firebaseService: FirebaseService,
    parseService: ParseService
): Result {
    val use: USE_SERVICE = determineBestService()

    val result = when (use) {
        USE_SERVICE.AWS -> awsService.executeRequest(request)
        USE_SERVICE.FIREBASE -> firebaseService.executeRequest(request)
        USE_SERVICE.PARSE -> parseService.executeRequest(request)
    }

    //assume additional work is done before returning the result
    return result
}

enum class USE_SERVICE {
    AWS,
    FIREBASE,
    PARSE
}

Notice that clientProgram has a parameter which refers to specific vendors of the service:

• Amazon Web Services (AWS)

• Firebase

• The now defunct Parse service from Facebook

It follows that any changes to our services will require clientProgram to be refactored (rewritten) appropriately.

The reason I chose Parse as one of the example services is specifically because it was shut down, despite being widely used. There are various reasons why a particular service may no longer fit requirements, but not working any more is a good one.

An alternative approach would be to hide all the details about the service being used from clientProgram. You could use an interface, but for variety’s sake I have used a function type instead:

fun main() {
    //Creating the services
    val awsService = AwsService()
    val firebaseService = FirebaseService()

    //determining which service to use must 
    //not be included in clientProgram
    val use: USE_SERVICE = determineBestService()

    //Assign serviceToUse to the appropriate function
    val serviceToUse: (Request) -> Result = when (use) {
        USE_SERVICE.AWS -> awsService::executeRequest
        USE_SERVICE.FIREBASE -> firebaseService::executeRequest
    }

    val request = getRequest()

    clientProgram(
       request,
       serviceToUse
    )
}


fun clientProgram(
    request: Request, 
    service: (Request) -> Result
): Result {

    val result = service.invoke(request)

    //assume additional work is done before returning the result

    return result
}

enum class USE_SERVICE {
    AWS,
    FIREBASE
}

class AwsService() {
    fun executeRequest(request: Request): Result = Result()
}
class FirebaseService() {
    fun executeRequest(request: Request): Result = Result()
}

The end result of this abstraction is that we can change services without needing to change clientProgram – assuming our behaviour does not change.

I want to point out that I am not advocating that you hide every service behind some kind of abstraction. If no variability is required or expected, there may not be any benefit to extra abstraction.

Closing Thoughts

I hope it is clear when reading this article that my intention is not to push dogmatic opinions about how abstract your code should be.

As a junior and intermediate developer, it took me a few years to realize that it really does depend on project requirements.

I also hope that this article gave you some new ideas and perspectives about what abstraction is and how it can be applied in your code. Good luck and happy coding!

Before you go...

If you liked this article and want more information on these principles and code constructs, check out my free, full length programming fundamentals course. It includes professionally written English, Burmese, and Arabic subtitles.

First, we will discuss why you may want to write more legible code as opposed to short, concise code. Afterwards, we will look at the following strategies on how to do that with:

• Variable, value, reference, class, object, and function naming

• Helper functions

• Code comments

• Enums/dictionaries/sealed classes/etc.

• Package organization and naming

Basic code literacy is recommended to get the most out of this article. However, I have tried to make it accessible to beginners where possible.

Photo by [Unsplash](https://unsplash.com/@jamie452?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Jamie Street / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit)

Does Efficiency Come From Fewer Keystrokes?

I recall as a junior developer, thinking that short or abbreviated names for identifiers – basically any code construct us developers are allowed to name – were more efficient.

My logic was simple: If it takes me less time to write it, then I can get the job done faster.

This logic would make sense if the following things were true:

• I, or someone else, would never have to read or fix what I wrote in the past

• I did not often forget what a variable, or several variables were, as I was reading through a function

• I did not occasionally have to write some code which was truly complex and obscure

• I could rename ridiculous or obscure external library functions, classes, or properties to something more sensible

The point is that, for me, I find few situations where being concise actually saves time. Further, modern IDEs have this useful feature called code completion which saves most of the keystrokes anyways.

You may not feel the same way, and that is perfectly okay! Take whatever works for you in this article and throw away the rest.

How To Name Classes, Variables, and Functions

I will now share what I do to make my code easier for myself and others to read. The code examples I use will be in Kotlin, but the points I make should be applicable to most platforms and languages.

There are two important things to know when learning about how to name software entities. Before getting to that, this term software entities refers to any of the following:

• Classes, structs, objects

• Variables, values, references, pointers

• Functions, methods, algorithms, commands

• Interfaces, protocols, abstractions

Essentially, anything which a programmer has to name when writing a program.

How Descriptive Names Should Be

My goal for naming software entities is this: The name should reduce any confusion about what a software entity does, or is.

The details of how it does something are not usually necessary.

The context, or everything around, of a software entity is important when deciding on a name. Something may require more or less details depending on its context.

Let us consider three examples:

1. getFormattedDate(date: String) : String

2. getYYYYMMDDFormattedDate(date: String) : String

3. getYYYYMMDDFormattedDateFromIso8601Format(date: String) : String

The production application I am currently working on frequently requires transforming dates to and from different formats.

In that context, I absolutely use names like example 3, which is much clearer than example 1.

Another option might be to change the parameter name in example 2 to something like iso8601Date.

While I do suggest you be consistent in your approach in a given codebase, feel free to experiment with what works for you. The point is to add as much information as is necessary to clear up any ambiguity.

If I was writing a one-off program that only ever converts one format to another, then example 1 is fine. Adding more information than necessary is not what I am advocating here.

The More Something Does, the Harder It Is to Name

If you find yourself having trouble naming something, it is most often (though not always) because it does too many things that are not conceptually related.

The degree to which software entities are conceptually related is known as cohesion.

By looking at what parts of a program are cohesive or not,** you can begin to understand what should be separated or grouped together.**

This process can be done from various perspectives, which I will try to explain by example.

Suppose you have four software entities:

1. StoreUserInCloud

2. StoreUserOnDisk

3. StoreMessage

4. EditUserUI

The first perspective we can consider is the real-world information which these entities are concerned with. From that perspective, we can see that StoreUserInCloud,StoreUserOnDisk, and EditUserUIuse the same model of information: A User.

However, there is another perspective that we must keep in mind, particularly when designing graphical user interface (GUI) programs.

Every GUI program can be broken down into three principal layers:

• User Interface (commonly called “View”)

• Logic (commonly refers to things like Controllers and Presenters)

• Model (data storage and access, or the state itself depending on your definition)

This does not mean that you should only ever look at a program as having these three layers! The three layer approach is a generalization which is frequently insufficient.

In any case, from that perspective, StoreMessage has more in common with the other storage entities than does EditUserUI.

Being able to look at your programs from multiple perspectives is something that will come as you build more complex programs.

The key takeaway is that separating your codebase into cohesive, related parts will generally make software entities easier to name.

How to Use Helper Functions

Helper functions, particularly when combined with good function naming practices, can greatly improve the readability of your code.

Helper functions are also an opportunity to apply a core principle of software architecture: Separation of concerns.

How to Create Sudoku Puzzles with Helper Functions

We will now look at a practical example to demonstrate extensive usage of helper functions. Please try to imagine how much harder this code would be to follow if everything was just in a single, giant function!

In the past, I worked on a large but cohesive part of a program: A Sudoku builder which uses graph data structures and algorithms. Even if you are not familiar with Sudoku or graph DSA, I believe you will still be able to follow the main point.

You can find the full source code here.

We can break the process of generating a playable Sudoku puzzle into five steps:

• Creating the nodes of the puzzle (representing the tiles)

• Creating the edges of the puzzle (edges in this case is another word for relationships/references between the tiles: Either row, column, or subgrid)

• Seeding (adding) some values to the data structure to make solving it faster

• Solving the puzzle

• Unsolving a certain number of tiles so that the game is actually playable by a user

I used something similar to the builder pattern to represent these steps in the function I call to create the puzzle:

internal fun buildNewSudoku(
    boundary: Int,
    difficulty: Difficulty
): SudokuPuzzle = buildNodes(boundary, difficulty)
        .buildEdges()
        .seedColors()
        .solve()
        .unsolve()

Although the idea of “nodes” and “edges” are technical definitions within graph theory, this code clearly reflects the five steps I had decided on.

We will not look at the entire codebase, but I want to highlight how the helper functions continue to break down the logic and promote readability:

internal fun SudokuPuzzle.buildEdges(): SudokuPuzzle {
    this.graph.forEach {
        val x = it.value.first.x
        val y = it.value.first.y

        it.value.mergeWithoutRepeats(
                getNodesByColumn(this.graph, x)
        )

        it.value.mergeWithoutRepeats(
                getNodesByRow(this.graph, y)
        )

        it.value.mergeWithoutRepeats(
                getNodesBySubgrid(this.graph, x, y, boundary)
        )

    }
    return this
}

internal fun LinkedList<SudokuNode>.mergeWithoutRepeats(new: List<SudokuNode>) {
    val hashes: MutableList<Int> = this.map { it.hashCode() }.toMutableList()
    new.forEach {
        if (!hashes.contains(it.hashCode())) {
            this.add(it)
            hashes.add(it.hashCode())
        }
    }
}

internal fun getNodesByColumn(graph: LinkedHashMap<Int,
        LinkedList<SudokuNode>>, x: Int): List<SudokuNode> {
    val edgeList = mutableListOf<SudokuNode>()
    graph.values.filter {
        it.first.x == x
    }.forEach {
        edgeList.add(it.first)
    }
    return edgeList
}
//...

To summarize this process, the helper functions provide two benefits:

• They are a stand in for a blob of code which does something

• That blob of code can be given a descriptive name

Both of those benefits can lead to greater legibility as the code becomes less cluttered and more descriptive.

If you are wondering what should and should not be a helper function, I suggest you practice different approaches to see what works for you.

How to Use Code Comments

My personal preference on code comments is that they have two primary usages: First, comments help describe complex functions in detail.

Second, to clear up any confusion about a line or block of code.

How To Use Comments to Design New Functions

When I come across functions which I expect to be difficult to write, I will describe what the function does using either plain language or pseudocode.

How I do this has changed over the years, so I encourage you to try different approaches.

In the examples from the previous section, I had omitted the code comments:

/**
 * 1. Generate a Map which contains n*n nodes.
 * 2. for each adjacent node (as per rules of Sudoku), add an Edge to the hashset
 *  - By column
 *  - By row
 *  - By n sized subgrid
 *
 *  LinkedHashMap: I chose to use a LinkedHashMap because it preserves the ordering of
 *  the elements placed within the Map, but also allows lookups by hash code, which are
 *  generated by x and y values.
 *
 *  As for the LinkedList in each bucket (element) of the map, assume that the first element
 *  is the node at hashCode(x, y), and subsequent elements are edges of that element.
 *  Apart from the ordering the first element as the Head of the LinkedList, the rest of
 *  the elements need not be ordering in any particular fashion.
 *
 *
 *  */
internal fun buildNodes(n: Int, difficulty: Difficulty): SudokuPuzzle {
    val newMap = LinkedHashMap<Int, LinkedList<SudokuNode>>()

    (1..n).forEach { xIndex ->
        (1..n).forEach { yIndex ->
            val newNode = SudokuNode(
                    xIndex,
                    yIndex,
                    0
            )

            val newList = LinkedList<SudokuNode>()
            newList.add(newNode)
            newMap.put(
                    newNode.hashCode(),
                    newList
            )
        }
    }
    return SudokuPuzzle(n, difficulty, newMap)
}

The amount of detail I add to these comments depends on the context. If I am working in a team, I will usually try to keep this much shorter than what you see above, and only include information that I feel is necessary.

The example above was a personal learning project that I expected to share with others. This is why I even included my decision making process on the types used to represent a Sudoku puzzle.

For fans of test driven development, you might try writing out the pseudocode steps of an algorithm before writing the test:

/**
     * On bind process, called by view in onCreate. Check current user state, write that result to
     * vModel, show loading graphic, perform some initialization
     *
     * a. User is Anonymous
     * b. User is Registered
     *
     * a:
     * 1. Display Loading View
     * 2. Check for a logged in user from auth: null
     * 3. write null to vModel user state
     * 4. call On start process
     */
    @Test
    fun `On bind User anonymous`() = runBlocking {

        //...
    }

This allows you to design the unit at a higher level of abstraction before writing the implementation. The time you spend designing at higher levels of abstraction can save you time in the long run.

How to Use Inline Code Comments Effectively

There are two primary situations where I will write an inline code comment:

• When I feel that the purpose of a line or block of code will not be clear to myself or anyone else reading it later

• When I have to call some poorly named library function which has a confusing or misleading name

By far, the most complex Sudoku algorithm in my program is the solver algorithm. In fact, it's so long that I will only post a snippet of it here:

internal fun SudokuPuzzle.solve()
        : SudokuPuzzle {
    //nodes that have been assigned (not including nodes seeded from seedColors()
    val assignments = LinkedList<SudokuNode>()

    //keep track of failed assignment attempts to watch for infinite loops
    var assignmentAttempts = 0
    //Two stages of backtracking, partial is half the dataset, full is a complete restart
    var partialBacktrack = false

    var fullbacktrackCounter = 0

    //from 0 - boundary, represents how "picky" the algorithm is about assigning new values
    var niceValue: Int = (boundary / 2)

    //to avoid being too nice too soon
    var niceCounter = 0

    //work with a copy
    var newGraph = LinkedHashMap(this.graph)
    //all nodes which are of 0 value (uncolored)
    val uncoloredNodes = LinkedList<SudokuNode>()
    newGraph.values.filter { it.first.color == 0 }.forEach { uncoloredNodes.add(it.first) }

    while (uncoloredNodes.size > 0) {
    //...
    }
//...
}

In this case, inline comments were necessary as I would frequently forget what some of these variables were while reading through this giant algorithm.

Another case where I will add an inline comment is when I have to explain or remind myself about code which I do not have control over.

For example, the infamous Java Calendar API uses zero-based indexing for months. This is arguably really stupid, as I am not aware of any standard that represents January with 0, nor do I care if one exists!

I cannot share the code with you as it is proprietary, but suffice it to say that I have comments in my current team’s codebase that explains random - 1 statements to conform to the Calendar API.

How To Use Enums and Dictionaries

There are other names for these kinds of code constructs, but these are the two I am familiar with. Suppose you have a restricted, or limited, set of values which you use to represent something.

For example, I needed a way to limit the number of tiles that are included in a new Sudoku puzzle, based on:

• The size of the puzzle (4, 9, or 16 tiles per column/row/subgrid)

• The difficulty of the puzzle (easy, medium, or hard)

Through extensive testing, I arrived at the following values as modifiers:

enum class Difficulty(val modifier:Double) {
    EASY(0.50),
    MEDIUM(0.44),
    HARD(0.38)
}

data class SudokuPuzzle(
        val boundary: Int,
        val difficulty: Difficulty,
        val graph: LinkedHashMap<Int, LinkedList<SudokuNode>>
        = buildNewSudoku(boundary, difficulty).graph,
        var elapsedTime: Long = 0L
)//...

These values are used in various places where the logic must change based on the difficulty.

Sometimes, you do not even need to have values associated with human-readable names. I used a different enum to represent different solving strategies to ensure a puzzle is playable relative to the selected difficulty:

enum class SolvingStrategy {
    BASIC,
    ADVANCED,
    UNSOLVABLE
}

internal fun determineDifficulty(
    puzzle: SudokuPuzzle
): SolvingStrategy {
    val basicSolve = isBasic(
        puzzle
    )
    val advancedSolve = isAdvanced(
        puzzle
    )

    //if puzzle is no longer solvable, we return the current strategy
    if (basicSolve) return SolvingStrategy.BASIC
    else if (advancedSolve) return SolvingStrategy.ADVANCED
    else {
        puzzle.print()
        return SolvingStrategy.UNSOLVABLE
    }
}

A good principle in designing any system is this: Fewer moving parts generally have fewer things that can go wrong.

Placing restrictions on values and types, and giving them good names, not only makes your code easier to read, it can protect it from errors as well.

How to Organize and Name Packages, Folders, and Directories

No guide on code legibility would be complete without some discussion on packages. If the platform and language of your preference does not use this term, assume I mean folder or directory instead.

This is something which I have changed my opinions on several times, and that is reflected in my older projects.

Two common approaches to package organization are:

• Package by architectural layer

• Package by feature

How to Do Package By Layer

Package by layer is the first and worst system I have ever used. The idea is usually to build your package structure around some architectural pattern like MVC, MVP, MVVM, and so on.

To take MVC as an example, your top level package structure would look like this:

• model

• view

• controller

The first problem with this approach is that it assumes that every class or function fits comfortably in one of these layers. This is rarely the case in practice.

I also find this approach to be the least legible, as the top level tells you only the most general details about what to expect inside each package.

This approach can usually be improved upon by adding more “layers” to be more specific:

• ui

• model

• api

• buildlogic/di

• repository

• domain

• common

This can work reasonably well in smaller codebases where all developers are familiar with the general pattern and style used.

How To Do Package By Feature

Package by feature has its own flaws, but is generally easier to read and navigate. This is assuming that you give the packages good names.

The term feature is tough to describe, but I would generally define it as this: A screen/page, or set of screens/pages that define a primary piece of functionality for users or customers.

For a social media app, we might see a structure such as:

• timeline

• friends

• userprofile

• messages

• messagedetail

The core problem with package by feature is the opposite of package by layer: There will almost always be software entities which are used in multiple features.

There are two solutions to this problem. The first would be to have duplicate code in each feature.

Believe it or not, duplicating software entities can be incredibly useful in enterprise settings in specific situations.

However, it is not something I would recommend as a general rule.

How to Do a Hybrid Package Structure

The solution I generally recommend to developers is what I like to call the hybrid approach. It is very simple, flexible, and should cover most of your requirements:

• timeline

• friends

• messages

• allmessages

• conversation

• messagedetail

• api

• timeline

• user

• message

• uicomponents

Please do not take this example too seriously; I am trying to convey the general idea: Anything which is feature specific goes into that feature package. Anything which is shared across features goes into a separate package nested at the same level or a higher level.

Again, what defines a layer was a vague concept to begin with, so do not just follow a convention blindly. Think critically about what is clear, particularly to someone who is not familiar with the project.

Closing Thoughts

Most of my preferences on code legibility and style have come from a great deal of trying different approaches. Sometimes these were approaches I saw others use and some of them came about naturally.

If you are able to put yourself in the position of someone less familiar with the code or program you are looking at, you will have an easier time making your code read like a book.

Before you go...

If you liked this article and want more information on these principles and code constructs, check out my free, full length programming fundamentals course. It includes professionally written English, Burmese, and Arabic subtitles.

Compose is a new UI framework for Android (though Desktop and Web support is being developed), which replaces the old XML-based View system.

While still in beta release as of writing this article, I do not expect this particular part of the library to change drastically for the stable release.

Topics include:

• A brief recap of the XML approach

• How to migrate from the XML-based colors, themes, and typography (font) system

• How to set up light and dark themes for your apps in only a few lines of code

• How to use your new Kotlin-based style information in your composables

• How to style Text Composables specifically

Before proceeding, it is important that you understand what a composable is. I will not be stopping to explain that concept here, as I already have in this article.

How We Used to Style Android Apps Using XML Resources

As usual, I like to share with you the motivations behind, and a bit of history on, these topics. In case you do not care, feel free to skip to the next section where we get into the practical stuff.

Android Resources

The Android app resources system is something which the Android team deserves a high five for, at least in my opinion. But like every design decision, a feature in one situation becomes a flaw in another situation.

To be specific, one of the greatest challenges for both platform and application developers alike is to create what I will call localized resources. I am referring to the challenge of building apps which:

• Display text and graphics in a variety of different languages and alphabets

• Look and feel proportionate to a wide variety of form factors (dimensions, densities, and so on.)

Those are just two common examples – there are plenty more. The resource system gives us a place where app developers can provide localized resources which the platform can select for at compile time. This saves us having to write that boilerplate code ourselves.

Feature or Flaw?

While I would never want to manage the boilerplate code necessary for localized string resources myself, that does not mean I enjoy writing XML.

In fact, there are very few things I would prefer to do in XML over a modern, idiomatic, and elegant language such as Kotlin or Swift. Personal preference aside, there is a more technical reason why XML resources are not always ideal.

Please note that this is not meant as a criticism of the platform developers/engineers. It is merely an observation of how design decisions always have benefits and costs.

In order to integrate our XML-based resources into our JVM-based application code, we must necessarily have layers of translation (compilation) and platform bridges (APIs). This can present difficulties for both platform and application developers.

Two common problems I ran into were:

• I want access to a resource in a place where I do not want tight coupling to the platform APIs which provide the resource

• I have to write some ridiculous boilerplate code just to change the look of a View (that is, override something defined within resource styles and themes)

The root problem for everyone involved is tight coupling to the View system and the Android resource system (which are themselves tightly coupled together).

For the platform developers, this means they have to build on top of, or work around gigantic and old codebases. Add that they must also try to have new features work on older Android OS versions, and that becomes a very thankless job.

The result for us application developers is most often a lot of boilerplate code, some hacky workarounds for things which intuitively seem like they should be one-liners. Not to mention the main API for getting these resources is Context, which is a class you really do not want to leak in memory.

Enter Jetpack Compose.

How to Set Up Themes, Colors, and Fonts with Jetpack Compose

With our review of the old system out of the way, let's explore a much prettier and simpler way to style and theme an Android application. I said I would keep this practical, but allow one point.

Since we will be doing that work in Kotlin, it means one very important thing: Both we and the platform developers are much less bound by translation (compilation) and API bridges (Android's R class and Context) between XML and the JVM.

In simple terms, this means much less boilerplate code, and much more control at runtime.

For the practical part of this article, my suggestion to you is to follow this process in the order I explain it. I have structured it in the order I follow when writing this code in a new App.

How to Replace Colors.xml Resources with Kotlin Compose

If you have not already decided upon a color scheme for your application, I suggest that you use the various resources available on the official Material Design website. Try out:

• The color palettes

• The color tool

If you plan to support light and dark app themes (explained shortly), try to select a color scheme which supports white text and a color scheme which supports black text.

Example of light and dark color schemes.

Create a file called something like Color.kt (the name does not matter) and fill it with immutable values:

import androidx.compose.ui.graphics.Color

val primaryGreen = Color(0XFF00bc00)
val primaryCharcoal = Color(0xFF2b2b2b)
val accentAmber = Color(0xFFffe400)

val textColorLight = Color(0xDCFFFFFF)
val textColorDark = Color(0xFFf3f3f3)
val gridLineColorLight = Color.Black
//...

You can either use a predefined value like Color.Black or supply your own ARGB Hex value.

Since ARGB Hex is just a bunch of jargon to describe what the heck "0XFF00bc00" means, let me translate:

• First two characters 0x tell the compiler that this is a hexadecimal number

• Second two characters , "FF" or "DC", represent Transparency/Opaqueness/Alpha in Hex

• The remaining six character pairs represent Red, Green, and Blue

How to Add Fonts and Replace the fontFamily Attribute

Typography (fonts) is also very easy to manage. This is the kind of thing where Kotlin's default arguments are very useful.

Create a file called something like Type.kt (the name still does not matter) and create Typography class...:

val typography = Typography(
    body1 = TextStyle(
        fontFamily = FontFamily.Default,
        fontWeight = FontWeight.Normal,
        fontSize = 16.sp
    ),

    button = TextStyle(
        fontFamily = FontFamily.Default,
        fontWeight = FontWeight.Bold,
        fontSize = 32.sp
    ),

    caption = TextStyle(
        fontFamily = FontFamily.Default,
        fontWeight = FontWeight.Normal,
        fontSize = 12.sp
    )
)
//...

...and some TextStyle classes:

//...
val mainTitle = TextStyle(
    fontFamily = FontFamily.Default,
    fontWeight = FontWeight.Light,
    fontSize = 48.sp,
    textAlign = TextAlign.Center
)

fun dropdownText(color: Color) = TextStyle(
    fontFamily = FontFamily.Default,
    fontWeight = FontWeight.Normal,
    fontSize = 32.sp,
    textAlign = TextAlign.Center,
    color = color
)
//...

Whether you provide public functions or values (I advise against using **var** here) is up to your individual preference and current requirements.

How to Create an App Theme in Jetpack Compose

The last thing you need to configure before using your theme in your composables is a MaterialTheme @Composable. I have mine, and along with my light and dark color palettes in a file called GraphSudokuTheme:

import androidx.compose.foundation.isSystemInDarkTheme
import androidx.compose.material.MaterialTheme
import androidx.compose.material.darkColors
import androidx.compose.material.lightColors
import androidx.compose.runtime.Composable
import androidx.compose.ui.graphics.Color

private val LightColorPalette = lightColors(
    primary = primaryGreen,
    secondary = textColorLight,
    surface = lightGrey,
    primaryVariant = gridLineColorLight,
    onPrimary = accentAmber,
    onSurface = accentAmber
)

private val DarkColorPalette = darkColors(
    //main background color
    primary = primaryCharcoal,
    //used for text color
    secondary = textColorDark,
    //background of sudoku board
    surface = lightGreyAlpha,
    //grid lines of sudoku board
    primaryVariant = gridLineColorLight,
    onPrimary = accentAmber,

    onSurface = accentAmber

)

@Composable
fun GraphSudokuTheme(
    darkTheme: Boolean = isSystemInDarkTheme(),
    content: @Composable () -> Unit
) {

    MaterialTheme(
        colors = if (darkTheme) DarkColorPalette else LightColorPalette,
        typography = typography,
        shapes = shapes,
        content = content
    )
}

Since you should already be familiar with what a composable is (I gave you fair warning), the only new thing here is darkTheme: Boolean = isSystemInDarkTheme().

To give a simplified explanation, isSystemInDarkTheme() is a call which asks any compatible Android device for the user's preference of a light or dark theme.

It returns a boolean value which we can use in a Ternary (Conditional) Assignment expression such as colors = if (darkTheme) DarkColorPalette else LightColorPalette.

That is actually it. Colors, Fonts, and two Themes defined in a few minutes.

How to Use a Theme in Compose

It is now time to use this Theme in your app. In this app, which only has two primary screens, I just use an Activity as a container for my composables:

class NewGameActivity : AppCompatActivity(), NewGameContainer {
    //...
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        //...

        setContent {
            GraphSudokuTheme {
                NewGameScreen(
                    onEventHandler = logic::onEvent,
                    viewModel
                )
            }
        }
        //...
    }

Wherever you find yourself calling setContent {}, my suggestion for beginners is to immediately place your Theme composable inside of it. Doing so will cause the style information to cascade/inherit to each nested composable.

You are done! Almost.

How to Override Styles and Themes

If you can help it, try to include any colors you will want in your light and dark palettes. This way, when you call MaterialTheme.colors.<Color>, the system will handle the conditional logic necessary to pick the appropriate palette:

@Composable
fun NewGameContent(
    onEventHandler: (NewGameEvent) -> Unit,
    viewModel: NewGameViewModel
) {
    Surface(
        Modifier
            .wrapContentHeight()
            .fillMaxWidth()
    ) {
        ConstraintLayout(Modifier.background(MaterialTheme.colors.primary)) { 
            //...
        }
        //...
      }
}

However, sometimes it is more suitable to write your own conditional logic...or I just got lazy. Fortunately Compose makes many such configurations available as properties:

@Composable
fun DoneIcon(onEventHandler: (NewGameEvent) -> Unit) {
    Icon(
        imageVector = Icons.Filled.Done,
        tint = if (MaterialTheme.colors.isLight) textColorLight 
        else textColorDark,
        contentDescription = null,
        modifier = Modifier
            .clickable(
            //...
            )
    )
}

MaterialTheme.Colors.isLight returns a boolean indicating what mode they are in, then we can use another Ternary Assignment from there.

How to Style a Text Composable

Just set the style argument equal to one of your text styles (whether it comes from MaterialTheme or one of the styles within Type.kt):

Text(
    text = stat.toTime(),
    style = statsLabel.copy(
        color = if (isZero) Color.White
        else MaterialTheme.colors.onPrimary,
    fontWeight = FontWeight.Normal
    ),
    modifier = Modifier
        .wrapContentSize()
        .padding(end = 2.dp, bottom = 4.dp),
        textAlign = TextAlign.End
)

TextStyle has its own copy function ready to go should you need to overwrite anything.

And that's it! You now know how to style and theme an application using Jetpack Compose. Thanks for reading :)

Social

You can find me on Instagram here and on Twitter here.

Here are some of my tutorials & courses

https://youtube.com/wiseass https://www.freecodecamp.org/news/author/ryan-michael-kay/ https://skl.sh/35IdKsj (introduction to Android with Android Studio)

In the old system, we used OnClickListeners and other interfaces. In Compose, we can take full advantage of Kotlin’s Sealed Classes, Function Types and Lambda Expressions.

If you do not know what a composable is, consider reading this article which explains the fundamentals.

How to Model UI Events with a Sealed Class

First, we must learn what is meant by UI Events and how to model them with Sealed Classes.

I have described this same process for Java and Kotlin (with the old view system) before, so I will keep this brief.

The Process

For each screen or sub-screen of your UI, ask yourself this question: What are all the different ways which the user can interact with it?

Let's take an example from my first app built fully in compose, Graph Sudoku:

Screenshot of a Sudoku Android App

The sealed class I use to represent the UI interactions of this screen looks like this:

sealed class ActiveGameEvent {
    data class OnInput(val input: Int) : ActiveGameEvent()
    data class OnTileFocused(val x: Int, 
    val y: Int) : ActiveGameEvent()
    object OnNewGameClicked : ActiveGameEvent()
    object OnStart : ActiveGameEvent()
    object OnStop : ActiveGameEvent()
}

To explain briefly:

• OnInput represents a user touching an input button (like 0, 1, 2, 3, 4)

• OnTileFocused represents a user selecting a tile (like the amber highlighted one)

• OnNewGameClicked is self-explanatory

• OnStart and OnStop are lifecycle events which my composables do not care about, but they are used in the Activity which acts as a Container for the composables

Once you have your sealed class set up, you can now handle a wide variety of events using a single event handler function. Sometimes it might make more sense to have multiple event handler functions, so keep in mind that this approach must be adapted to your project's specific requirements.

How to Connect Your Software Architecture

What you have handling these events is totally up to you. Some people think that MVVM is the golden standard of software architectures, but it seems like more and more people are realizing that there is no single architecture which works best for every situation.

For Android with Compose, my current approach is to use a very 3rd party minimalist approach which typically has these things in each feature (screen):

• A (Presentation) Logic class as an event handler

• A ViewModel to store the data necessary to render the View (as the name implies)

• An Activity which acts as a Container (not a god object)

• Composables to form the View

Model-View-Whatever

I do not care what you use as long as you are applying separation of concerns. This is how I arrived at this architecture, by simply asking what should and should not be put together in the same class.

Whether you want your ViewModel, a Fragment, or an Activity to be your event handler, all of them can be set up the same way: Function Types!

Within your class of choice, set up an event handler function which accepts your sealed class as its argument:

class ActiveGameLogic(
    private val container: ActiveGameContainer?,
    private val viewModel: ActiveGameViewModel,
    private val gameRepo: IGameRepository,
    private val statsRepo: IStatisticsRepository,
    dispatcher: DispatcherProvider
) : BaseLogic<ActiveGameEvent>(dispatcher),
    CoroutineScope {
    //...
    override fun onEvent(event: ActiveGameEvent) {
        when (event) {
            is ActiveGameEvent.OnInput -> onInput(
                event.input,
                viewModel.timerState
            )
            ActiveGameEvent.OnNewGameClicked -> onNewGameClicked()
            ActiveGameEvent.OnStart -> onStart()
            ActiveGameEvent.OnStop -> onStop()
            is ActiveGameEvent.OnTileFocused -> onTileFocused(event.x, event.y)
        }
    }
    //...
}

This approach is very organized and makes it easy to test every Unit in this 3rd party library free class through a single entry point.

However, we are not done yet. Naturally, we need a way to get a reference to this event handler function, onEvent, to our Composables. We can do this using a function reference:

class ActiveGameActivity : AppCompatActivity(), ActiveGameContainer {
    private lateinit var logic: ActiveGameLogic

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val viewModel = ActiveGameViewModel()

        setContent {
            ActiveGameScreen(
                onEventHandler = logic::onEvent,
                viewModel
            )
        }

        logic = buildActiveGameLogic(this, viewModel, applicationContext)
    }

      //...
}

I am sure some of you are wondering why I am using an Activity. You can ask me during a livestream Q&A sometime for a detailed answer.

In short, Fragments appear to be a bit pointless with Compose with my approach to architecture (I do not use Jetpack Navigation), and there is nothing wrong with using Activities as a feature specific container. Just avoid writing god activities, basically.

To be specific, the way you make a reference to a function in Kotlin, is by providing the class/interface name (or skip that if it is a Top-Level function), followed by two colons, and the name of the function without any arguments or brackets:

onEventHandler = logic::onEvent

How to Replace onClickListener With Jetpack Compose onClick Modifier

With that stuff ready, we can look at how this works within the composable. Naturally, your root composable will need the event handler function as a parameter:

@Composable
fun ActiveGameScreen(
    onEventHandler: (ActiveGameEvent) -> Unit,
    viewModel: ActiveGameViewModel
) {
//...
}

It can be a bit tricky to get function type syntax correctly, but understand that this really is a reference to a function, which is not so different from a reference to a class.

Just as you should not build god objects, you should not build giant composables:

1. Break your UI down into the smallest reasonable parts

2. Wrap them in a composable function

3. For each composable which has a UI interaction associated with it, it must be given a reference to your event handler function

Here is a composable which represents the input buttons of the Sudoku app, which is given the event handler by reference:

@Composable
fun SudokuInputButton(
    onEventHandler: (ActiveGameEvent) -> Unit,
    number: Int
) {
    Button(
        onClick = { onEventHandler.invoke(ActiveGameEvent.OnInput(number)) },
        modifier = Modifier
            .requiredSize(56.dp)
            .padding(2.dp)
    ) {
        Text(
            text = number.toString(),
            style = inputButton.copy(color = MaterialTheme.colors.onPrimary),
            modifier = Modifier.fillMaxSize()
        )
    }
}

To actually pass the event to the logic class, we must use the invoke function, which will accept arguments as per the function type definition (which accepts an ActiveGameEvent in this case).

At this point, you are ready to handle UI interaction events in Kotlin (compose or not) by taking full advantage of this beautiful and modern programming language.

If you liked this article, share it on social media and consider checking out the resources below to support an independent programmer and content creator.

Social

You can find me on Instagram here and on Twitter here.

Here are some of my tutorials & courses

https://youtube.com/wiseass https://www.freecodecamp.org/news/author/ryan-michael-kay/ https://skl.sh/35IdKsj (introduction to Android with Android Studio)

While this is a beginner's guide to Compose, it will not be a beginner's guide to Android – so you should have built at least an application or two (though not in Compose, necessarily).

Before we begin, I was initially planning to write a follow up article directed towards more senior developers until I came across Leland Richardson’s two part article series. Leland is not only a Software Engineer working on the Jetpack Compose team, but I see that he is a great writer as well.

While I feel my article will stand on its own as an introduction to the basics of Jetpack Compose, I strongly suggest you read his articles once you have gained some practical experience with Compose (or right away if you prefer to learn that way).

Key Terms/Concepts Explained in this article:

• A brief review of the old View System and Hierarchy

• Composables and how they stand in relation to Views

• Recomposition and how to avoid doing it very poorly!

What Is A Composable?

In this section, we will discuss the most fundamental part of the Jetpack Compose library. If you are a seasoned Android developer, you may wish to skip to the sub-section titled “Are Composables Views?”

If you are not already familiar with the View system, you should read the next section as it is necessary to motivate and understand what a Composable is.

View Hierarchy

In the context of the Android SDK (the libraries we use to make user interfaces on this platform), a View is what we use to give structure and style to our applications.

It is the most fundamental kind of building block or element of a given user interface (UI), and each of these building blocks will contain the following kinds of information (among other things):

• X and Y start and end positions which tell the computer where to draw the view on the device screen

• Color and alpha (transparency) values

• Font information, text, symbols, and images

• Behaviour based on events such as user interaction (clicks) or changes in the application’s data (more on that later)

It is important to understand that a View can be something like a button (commonly referred to as a “widget”), but it can also be a container of the whole screen, part of the screen, or for other child Views.

Such containers are commonly referred to as Layouts or Viewgroups depending on the context. And, while sharing most of the same kinds of information as a widget, they also contain information about how to arrange and display other Views which are nested within them.

With that in mind, we get to the important part of this review of the View system: The View Hierarchy. For Web Developers, the View Hierarchy is essentially Android’s version of the Document Object Model (DOM).

For Android Developers, you can think of the View Hierarchy as a virtual representation of all the Views which you defined either in XML files or programmatically in Java or Kotlin.

To illustrate this, let's look at such an XML file (there’s no need to study it closely, just note the names). Then, using a debugger/stepper tool, we will look at what it looks like in the memory space of the Fragment which inflates this file:

fragment_hour_view.xml:

<?xml version=”1.0" encoding=”utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android=”http://schemas.android.com/apk/res/android"
android:layout_width=”match_parent”
android:layout_height=”match_parent”
android:id=”@+id/root_hour_view_fragment”
xmlns:app=”http://schemas.android.com/apk/res-auto"
>
<androidx.compose.ui.platform.ComposeView
android:id=”@+id/tlb_hour_view”
//...
 />
<com.wiseassblog.samsaradayplanner.ui.managehourview.HourToggleView
android:id=”@+id/vqht_one”
//...
/>
<com.wiseassblog.samsaradayplanner.ui.managehourview.HourToggleView
android:id=”@+id/vqht_two”
//...
/>
<com.wiseassblog.samsaradayplanner.ui.managehourview.HourToggleView
android:id=”@+id/vqht_three”
//...
/>
<com.wiseassblog.samsaradayplanner.ui.managehourview.HourToggleView
android:id=”@+id/vqht_four”
//...
/>
</androidx.constraintlayout.widget.ConstraintLayout>

Memory Space of (Fragment)HourView.kt:

Image of a View Hierarchy

The debugger and stepper tools are some of my favourite ways to learn about what is going on under the hood of the code that I use from various libraries. Give it a try some time!

The purpose of showing you this XML file and what it turns into in a process (a process is simply a program that is running on a device), is to demonstrate how nested Views in an XML file translate into a nested View Hierarchy at runtime.

Hopefully, with a simple but concrete model of how the old system works, we can compare it with the new one.

Are Composables Views?

This was one of the first questions I asked when I started working with Compose, and the answer I have arrived at is both yes and no.

Yes, in the sense that a Composable fulfills the same conceptual role as a View in the old system. A Composable can be a widget like a button, or a container such as a ConstraintLayout (it is worth noting that there is a Composable implementation of ConstraintLayout available).

No, in the sense that the UI is no longer represented virtually in a View Hierarchy (apart from situations involving interoperability). With that being said, compose does not use magic to virtually represent and keep track of the UI. This means that it must have its own thing which is conceptually similar to a View Hierarchy.

Let us take a very brief look at this thing. Here, we have an Activity which uses the setContent {…} function to bind a Composable to itself:

ActiveGameActivity.kt:

class ActiveGameActivity : AppCompatActivity(), ActiveGameContainer {
private lateinit var logic: ActiveGameLogic
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    val viewModel = ActiveGameViewModel()
    setContent {
        ActiveGameScreen(
            onEventHandler = {
                logic.onEvent(it)
            },
            viewModel
        )
    }
    logic = buildActiveGameLogic(this, viewModel, applicationContext)
}
//…
}

ActiveGameScreen.kt:

@Composable
fun ActiveGameScreen(
    onEventHandler: ((ActiveGameEvent) -> Unit),
    viewModel: ActiveGameViewModel
) {
    //...

    GraphSudokuTheme {
        Column(
            Modifier
                .background(MaterialTheme.colors.primary)
                .fillMaxHeight()
        ) {
            ActiveGameToolbar(
                clickHandler = {
                    onEventHandler.invoke(
                        ActiveGameEvent.OnNewGameClicked
                    )
                }
            )

            Box {
              //content
            }
        }
    }
}

In Compose, the View Hierarchy is replaced with something that we can locate if we dig really deeply into the mWindow field of this Activity. Within that field is the conceptual replacement of the View Hierarchy: The **Composer** and its **slotTable**.

At this point, if you want a detailed overview of the Composer and its slotTable, I must again suggest that you read Leland’s article (he goes into detail in part 2). There is more to the Compose Hierarchy than the Composer and its slotTable, but that should be sufficient to get us started.

In general terms, Jetpack Compose uses what we might call its Compose Hierarchy (which is made of, and managed by things like the Composer and its slotTable).

Again, this is the same conceptual idea as the View hierarchy, a bunch of objects in memory space which collectively represent the UI, but it is implemented very differently.

There's an important difference, though, which is tricky to understand technically, but easy to understand in principle. This is the way in which Compose handles updates to the Compose Hierarchy: Recomposition.

Recomposition: How To Update Compose UI

For my ESL friends, the word Compose comes from the latin componere, which roughly means “to put together.” Someone who writes music is often called a “Composer,” which can be thought of as the one who puts together the notes coming from one or more instruments into a composition (song).

Putting together implies that there are individual pieces. It's important to understand that almost any good software developer makes at least some effort to break their code down into the smallest reasonable parts.

I mention reasonable, because I think principles like DRY (Don’t Repeat Yourself) should be followed only to the extent that they solve more problems than they create.

There are many benefits to applying this concept, which is often called modularity, (or as I prefer, Separation of Concerns, or SOC). I am aware that some of you reading this might think I am just copying what Leland said in his article, but I have been talking about SOC as the Golden Principle Of Software Architecture for many years already.

Where this plays into Compose, is the same principle which we see in the popular Javascript library React. When done properly, Compose will only “recompose” (redraw, re-render, update, whatever) the Composables (parts/elements of the UI) which need to be recomposed.

This is ENORMOUSLY important when it comes to the performance of an application. This is because redrawing the UI, whether in the old View system or in Compose, is costly for system resources.

In case you were not aware, the entire purpose of the old RecyclerView (which was the first thing I ever made a tutorial on back in 2016!) was to employ the ViewHolder pattern to a list of data. This avoided the need to constantly inflate (make) new Views for each list item.

My goal in this article was to focus mostly on the theory, as I will be writing plenty of practical content over the next few months. However, I will finish the article off with a story from my direct experience, which will help you to further understand how recomposition works, and how to avoid doing it very poorly!

The Stopwatch Example

For my first full Compose application, I decided to build Sudoku. There are a number of reasons why, including the fact that I wanted a project which did not have an insanely complicated UI. I also wanted the chance to deep dive into Graph DS and Algos, which are quite suitable for Sudoku puzzles.

One thing I wanted was a Stopwatch which would keep track of how long it took the user to complete a puzzle:

Graph Sudoku puzzle

As is often the case in my profession, I expected this timer to be much easier to add than it really was. I messed around with Android’s Chronometer class as well as the Java Timer class, and both of them presented different but still application-breaking problems.

Eventually I took a step back and realized that I was writing in Kotlin. So I set up a Coroutine based timer in my presentation logic class (it ended up making the most sense to put it there), which would update my viewmodel each second:

Class ActiveGameLogic(…):…{
//…
inline fun startCoroutineTimer(
    delayMillis: Long = 0,
    repeatMillis: Long = 1000,
    crossinline action: () -> Unit
) = launch {
    delay(delayMillis)
    if (repeatMillis > 0) {
        while (true) {
            action()
            delay(repeatMillis)
        }
    } else {
        action()
    }
}
private fun onStart() =
launch {
    gameRepo.getCurrentGame(
    { puzzle, isComplete ->
        viewModel.initializeBoardState(
            puzzle,
            isComplete
    )
        if (!isComplete) timerTracker = startCoroutineTimer {
            viewModel.updateTimerState()
        }
    },{
        container?.onNewGameClick()
    })
}
//…
}

The ViewModel (not from AAC – I write my own VMs. But Compose already has good interoperability with AAC VMs from what I can see.) exposed references to callback functions, which is what I would use to update my Composables:

class ActiveGameViewModel {
    //…
    internal var subTimerState: ((Long) -> Unit)? = null
    internal var timerState: Long = 0L
    //…
    internal fun updateTimerState(){
        timerState++
        subTimerState?.invoke(timerState)
    }
//…
}

Now comes the important part! We can trigger recomposition of the Compose Hierarchy by using certain features of compose, such as the remember function:

var timerState by remember {
    mutableStateOf(“”)
}

If you must know, these features store the state of whatever you are remembering in the slotTable. In short, the word state here means the current “state” of the data, which starts out being just an empty String.

Here is where I screwed things up. I had pulled my simple timer composable into its own function (applied SOC), and I was passing in timerState as a parameter to that composable.

However, the above snippets were sitting in the parent composable of the timer, which was a container for the most complicated portion of the UI (a 9x9 Sudoku requires a large number of widgets):

@Composable
fun GameContent(
    onEventHandler: (ActiveGameEvent) -> Unit,
    viewModel: ActiveGameViewModel
) {
    Surface(
        Modifier
            .wrapContentHeight()
            .fillMaxWidth()
    ) {
        BoxWithConstraints(Modifier.background(MaterialTheme.colors.primary)) {
            //…
            ConstraintLayout {
                val (board, timer, diff, inputs) = createRefs()
                var isComplete by remember {
                    mutableStateOf(false)
                }
                var timerState by remember {
                    mutableStateOf("")
                }
                viewModel.subTimerState = {
                    timerState = it.toTime()
                }
                viewModel.subIsCompleteState = { isComplete = it }
            //…Sudoku board
            //Timer
                Box(Modifier
                    .wrapContentSize()
                    .constrainAs(timer) {
                        top.linkTo(board.bottom)
                        start.linkTo(parent.start)
                    }
                    .padding(start = 16.dp))
                {
                    TimerText(timerState)
                }
            //…difficulty display
            //…Input buttons
            }
        }
    }
}
@Composable
fun TimerText(timerState: String) {
    Text(
        text = timerState,
        style = activeGameSubtitle.copy(color = MaterialTheme.colors.secondary)
    )
}

This was causing some considerable lag and unresponsiveness. By making heavy usage of the debugger, I was able to find out why. Because my timerState variable was created and updated inside the parent Composable, it was triggering a recomposition of that entire portion of the UI. Every. Single. Tick.

After moving the appropriate code into the TimerText composable, things worked very smoothly:

@Composable
fun TimerText(viewModel: ActiveGameViewModel) {
    var timerState by remember {
        mutableStateOf("")
    }

    viewModel.subTimerState = {
        timerState = it.toTime()
    }

    Text(
        text = timerState,
        style = activeGameSubtitle.copy(color = MaterialTheme.colors.secondary)
    )
}

Hopefully I have given you a working understanding of recomposition and one of the biggest ways to do it incorrectly.

Avoiding unnecessary recompositions is incredibly important for performance. And so far it seems that applying SOC rigorously, even to the point of keeping remember state in separate composables, should become standard practice.

Resources & Support

If you liked this article, please share it on social media and check out my other articles on freeCodeCamp here. I also have a YouTube channel with hundreds of tutorials, and am an active writer on various platforms.

Connect with me on social media

You can find me on Instagram here and on Twitter here.

Also, I want to point out the single resource I used to get started with Jetpack Compose: Working code samples from good developers.

For my first few years as a software developer, primarily working with the Android SDK, I had no idea of what the Android Debug Bridge (ADB/adb) was, what it did, or when to use it.

Amusingly, it was not some professional goal which motivated me to learn about it initially. Rather it was my boot looping Nexus 6 which I desperately wanted to resurrect. For a problem like that, Android Studio and Gradle are about as useful as a waterproof tea bag.

I would also like to mention that this article has been written with two kinds of individuals in mind:

• Those who are familiar with CLI, Shell, Processes, and the Client-Server Model

• Those who are not familiar with CLI, Shell, Processes, and the Client-Server Model

For those in the first category, you may wish to skip the section titled: "How to Work With The ADB."

For those in the second category, I will assume you were like me as a Junior developer and know very little about CLIs, Shells, and the ADB. The first section is a soft introduction and glossary for some basic terms and ideas, explained in the simplest way I can manage.

Preliminaries

Here, we will learn about some topics which are important if you want to understand how the ADB works and is used.

Some of you may have been scared away from learning command line tools in the past by sneering Vim enthusiasts or judgmental Unix System Administrators. As you will see, I freely admit that CLI is not ideal for how my brain works, so I think you might enjoy my take on the subject.

Command Line

Simply put, a command line is an interface (way of sending/receiving information) to a computer which only uses lines of text.

It is important to understand that a command line interface (CLI) is not itself a program, but rather some programs will provide a CLI (and perhaps other interfaces such as a GUI as well).

At some point, you may have typed something into Windows Command Prompt (or MS-DOS if you are a 90s kid like me), Mac Terminal, or something like GNOME Terminal common on many Linux distributions. All of these are primarily used via a CLI.

The benefits and deficits of using a CLI depend largely on the individual using it, and what kind of problem they are trying to solve. I personally do not like using a CLI unless it is for something that I do almost every day.

My brain is simply not suited for memorizing obscure shorthand text commands (I had trouble learning to read as a kid for the same reason), so I must rely on a great deal of repetition-based implicit memory (muscle memory) and cheat sheets.

For those who are willing to put the time in even if it is a struggle (like I do), or those who are really quite good at remembering such things, you will likely learn to appreciate how much more efficient you can be within a CLI versus a GUI.

Many operations can be carried out in a fraction of the time it takes to point and click your way through various menus and screens. It is also possible to write scripts, which are files containing a series of text commands, that can increase your efficiency even further.

How to use the ABD Shell

I will have to assume that you are familiar with the term Operating System (OS), which includes Android, iOS, Windows, Mac, Linux, and any other Unix-like system.

Why is this term relevant to the ADB? To give an explanation which prioritizes clarity over precision, the Android OS is based on Linux, and Linux is based on Unix.

As a result of this, we can use the ADB to get a hold of the Unix Shell for the device or emulator we are working with. This allows us a great deal of flexibility, capabilities, and control over the device or emulator by directly interacting with its shell.

A shell is a general term for the program which you use to interact with an OS. Just as a turtle shell provides protection and access to a turtle (and is the outermost layer), the shell of an OS both protects and provides access to the inner workings of the OS. Personally, I was quite surprised to learn that "Shell" was not some esoteric acronym.

Do not feel the need to overthink this term. If you are reading this on a computer of some kind, you used a shell to help you get here.

A shell can provide either or both a CLI or GUI. In either case you will use it to create/update/delete/move files, start other programs, and access the various services of the OS which are made available through the shell.

How to use the ABD Client and ABD Server

Again, let us start with a slightly imprecise explanation which is hopefully easier to understand. I will correct this definition shortly, though.

Clients and Servers are both computers. The reason why we differentiate them in this way is based on their role. For example, your computer (whether it is a desktop, laptop, phone, or whatever else) is a Client of a freeCodeCamp Server, which serves you this HTML page.

In general, a client is something which uses something else, whereas a server is that which is being used. Do not overthink this term, as a Client-Server Model can describe a very large number of things both inside and outside of computing.

Now, when I said that Clients and Servers are both “computers”, that is not really true in the context that we will use these terms later on.

As programmers and engineers, we typically ought to think of Clients and Servers as being processes (a process is simply a running program).

This means that while a Client process and a Server process often do run on separate computers, it is also fine if they run on the same computer.

They will occupy distinct locations in the memory space of said computer, so effectively the only difference is that they will communicate using IPC (inter-process communication) as opposed to sending messages to each other through a network connection.

As we will see shortly, the ADB makes use of a Server process, which allows multiple developers (multiple clients) to manage multiple Android devices and/or emulators.

In an enterprise setting, this Server process would likely sit on a remote (communicated to through a network connection) computer, but we will set up a Server which is local to our Client. Doing that will be much simpler than you probably think it will be.

What is an ABD Daemon?

In case you skipped ahead, I already explained that a process is simply a running program. A Daemon is a process which runs in the background, which is to say that the user does not directly interact with it.

For example, if you open a web browser, then chances are that the actual work of managing the network connections required to connect to the Internet will be carried out by something like a NetworkManager Daemon (as opposed to the browser process itself).

Each Android device (physical or emulated), assuming it is configured properly, will have an ADB Daemon (adbd) which executes commands given to it by a Server process.

In short, when our Client issues a command to the Server, the Server will forward that command to the ADBD, which will execute it on the device.

How to Use ADB for Android Development

For the remainder of this article, we will explore the following topics:

• Drivers and configuration necessary to use the ADB on your system

• Using the ADB with physical devices and emulators

• Basic commands using the ADB’s CLI

• A glance at more complicated usage using an Android device’s Shell via the ADB

Before proceeding, you will want to establish what CLI tool you will be using to interact with the ADB. On Windows, I prefer using PowerShell, but Command Prompt would work too. For Linux and Mac, the default Terminal should work.

Feel free to use whatever gets the job done.

This article contains a very detailed explanation of the whole process, but I have prepared a video tutorial which covers it succintly here:

How To Understand The CLI Examples

This article contains many commands to be inputted to your preferred CLI tool. Any part of a given command which changes situationally will be written within angle brackets.

Do not include the angle brackets in the CLI command you write.

For example, if I wrote...:

adb pair <ip-address>:<port>

...you would substitute the angle brackets and name for the actual value, such as:

adb pair 192.168.0.1:5554

ABD Drivers & Configuration

Firstly, ensure that you have the latest (or at least a recent) version of the Android SDK Platform-Tools. If for some reason you do not use Android Studio (AS), click that link and download the standalone package for your respective OS.

If you have Android Studio, you can download or update this package using the SDK Manager.

There is typically a toolbar icon in AS to open the SDK Manager, but they like to change what it looks like practically every hotfix.

If you do not have luck finding it, go to File -> Settings and in the search bar, type “SDK”, and search for the “Android SDK” menu item.

Systems setting showing that Android SDK Platform Tools are installed

The next step changes depending on a number of variables. As discussed in the Preliminaries section, the ADB uses a Client-Server Model which allows a lot of flexibility in how you use the tool.

To be more specific, you may have:

• Multiple Clients interacting with a remote Server

• A Server which is local (same computer) to one Client

• A variety of physical devices and emulators hooked up to the same server

Advanced configuration with multiple Clients and an exceedingly large number of devices is possible with the ADB, but outside of the scope of this article.

One Server can manage up to 16 emulators and as many physical devices as you would like (within reason), without requiring advanced configuration.

For the remainder of this article, the most we will work with is one physical device and one emulator for a single ADB server process.

How to Configure An ABD Emulator

Most likely you do not need to make any further configurations, but it is possible you may need to enable Developer Options on your emulator. You will know very shortly if it is working properly when we get to our first few ADB commands.

If you do wish to enable this feature on your emulator, you will need to research how to do that for your particular version of Android.

USB Debugging – How to Configure a Physical Device

If you are not planning to use a physical Android device, you can skip this section. However, it is worth noting that you may still need to enable Developer Options

In order to proceed, you will need to configure either USB Debugging or WiFi Debugging on your Android device and development machine.

In either case, start by enabling Developer Options on your device. You will need to research how to do that for your particular version of Android.

USB Debugging

Ensure that you have enabled USB Debugging on the Android device via Developer Options. The link I shared above will describe that process, which tends to change somewhat across different versions of the Android OS.

Before proceeding, Windows users will need to download a USB Driver. Ubuntu users also require some extra steps. For Mac and Chrome OS, you should be good to go.

Once USB Debugging is enabled via Developer Options, connect your Android device via a USB cable.

WiFi Debugging

If you happen to have multiple physical devices or a shortage of USB cables, then you may want to opt for WiFi Debugging.

Again, visit Developer Options on your Android device and enable Wireless debugging. It should prompt you about Allowing debugging on the network which the device is currently connected to, which you should allow (assuming that is the appropriate network).

Time to start working with your CLI. First, you will need to locate the platform-tools directory (or folder – same thing) within your Android SDK installation directory.

Assuming you have Android Studio installed, a quick way to locate it via the app is to again go to File -> Settings, then type “SDK” in the search bar. The “Android SDK” menu will show you where your SDK is installed, which will be the directory that should contain platform-tools.

In the example below, I copied the path to my Android SDK directory, and then opened an instance of Windows PowerShell. I then typed the following commands:

Change Directory:

cd <path-to-SDK-directory>

List Files and Directories:

ls

Next, I typed cd platform-tools to navigate to that directory. Note that the following steps assume you are using a device which is running Android OS 11 or higher.

If you are working with a device running Android 10 or lower, detailed instructions for that situation can be found here.

Once you are within the platform-tools directory, you are ready to pair an Android device to a development machine using the following steps:

1. Within the Wireless debugging submenu in Settings -> System -> Developer options, select Pair device with pairing code.

2. Within your CLI tool which should be set to the platform-tools directory, enter the following command:

adb pair <IP address>:<Port>

where both the IP address and the Port come from the dialogue on your Android device which popped up after selecting Pair device with pairing code (do not include the angle brackets).

Note: You may need to prepend your call to adb with some other symbols or commands depending on which CLI tool you are using, your OS, and your access controls. For example, I had to type .\adb pair : using PowerShell on Windows.

3. Assuming things went well with your CLI, you will be prompted to enter the pairing code which was made visible in the same dialog on the Android device which gave you the IP address and Port number.

4. After entering the pairing code, you will know this operation was successful if you receive a message stating:

Successfully paired to <IP Address>:<Port> [guid=<Some GUID>]

5. If you are using Windows or Linux, you will also need to run the following command using the IP Address & Port which is visible from within the Wireless debugging preferences menu (not the dialogue which pops up after selecting Pair device with pairing code):

adb connect <IP Address>:<Port>

after which you should receive a notification on the phone to indicate that you are connected.

How to Use The ADB: Commands

Assuming you managed to properly configure your Android device and your development machine, you can now use the ADB tool.

Before proceeding, navigate to the directory which contains adb using a CLI tool (unless you just followed the steps in the previous section for setting up WiFi debugging).

Otherwise do so now, or check out that section for instructions on how to locate that folder.

How to See Which Devices Are Currently Connected To The Server

You can now start up an adb server by calling just about any command on the ADB except adb kill-server. Whether or not your server process is running, type in the following command:

adb devices

In the above screenshot, I first called adb devices when my Android phone was connected to the server. After killing the server via the adb kill-server command, I once again called devices which restarted the server.

Again, if an ADB server is not currently running, calling more or less any ADB command will start the server back up (except adb kill-server, of course). There is an explicit adb start-server command, but in practice I have never needed to use it.

Since the server was reset, devices did not return any items. Therefore, before moving to the next example I had to once again use the adb pair and adb connect (if on Windows or Linux) commands described in the previous section.

I have now fired up an emulator using PowerShell and the emulator program which is also located in a subdirectory of platform-tools called "emulator."

You may of course use the AVD Manager or Android Studio to start up an emulator to follow along with the example if you would like to.

If you have many connected devices, a useful option for the adb devices command is -l, which gives you more information about the devices.

Below you will see several entries which refer to my physical Android device, as well as an emulator which has been attached to a specific port:

How to Send Commands To A Specific Device

To avoid accidentally bricking my phone, I want to send commands to the emulator instead. To do this, I must prepend the -s option, followed by the serial number of the target device, before typing the command.

The serial number is the first set of characters which describes a connected device after using the devices command.

For example, the emulator’s serial number in this case is just the word emulator followed by the port which the emulator is currently attached to.

The other red arrow points to the serial number for my phone (blocked out for obvious reasons).

Naturally, if you only have one device connected (whatever kind it is), you do not need to use the -s option.

Install An APK (App) On A Device

I am now going to install a test APK on the running emulator using the adb install command.

This is basically equivalent to having Android Studio and Gradle install a debug APK. As you will see, test APKs require the -t option after the install command:

adb -s <device-serial-number> install -t <path-to-APK>

Note: The Android OS requires that any APK must be signed before it can be installed (even if it is just a test/debug APK).

One solution is to build and run the app to be installed in Android Studio, which will sign it with a generated debug certificate. There are several other ways to sign such an APK which you can explore by visiting this link.

What Else Can ADB Do?

Before we take a look at some more advanced usage of the ADB, I strongly encourage you to try the adb --help command. As is customary for most CLI based programs, the help command will print out documentation which describes the various commands and options of the tool.

I am happy to say that the documentation for the ADB is quite legible and useful, which is not always the case in CLI programs.

Advanced ADB Usage Tips

It would be a waste of time for both of us to cover every usage and command of the ADB in this article.

In case there is any confusion, using the ADB to install APKs and do many of the things which Android Studio and Gradle do for you is not something that I would recommend (unless you have a good reason to do so).

With that being said, there are plenty of things that the ADB can do which are either difficult or impossible to do without it.

In the preliminaries section, I mentioned that the ADB can be used to get a hook to the shell of the device. To finish this article off, we will look at how to use shell commands and where to find more information about them.

If you do not know what a shell is, you probably skipped the section above where I explained that.

How to Use the ABD Shell

Sending a command to the device’s shell using the ADB is fairly simple. Remember that if you have multiple devices connected, follow it with -s <device-serial-number> to direct the command to a specific device.

To make a single shell command, we must use the adb shell command (big surprise, eh?), followed by the actual command we want to make on the device's shell:

adb shell ls

Output:

As mentioned previously, the ls command displays a list of files and directories at the CLI's current directory. This happens to be the Android device's root directory until we move to a different one.

If you plan to be making many commands via the Shell, you can also start an interactive Shell session. This can be done via the simple command:

adb shell

While in an interactive Shell session, you can type Shell commands directly without further use of adb shell <command>.

Note that when you want to quit the interactive Shell session, you can do so by typing exit or hitting Ctrl + D.

There are a variety of different commands and utilities you can work with via the Shell. The ActivityManager (am) of an Android device can be particularly useful for testing different components (Activities, Services, BroadcastReceivers, to name a few) of an Android app under different circumstances.

Suppose we want to launch straight into a particular Activity, but this Activity is not designated as the launcher Activity in the manifest.

You will still need to add the android:exported=”true” attribute to each <activity/> entry in the manifest which you want to launch (assuming it is not already the launcher Activity).

After that you can use the following command to go straight to it:

am start -n <app-package-id>/<activity-name>

Note that the <activity-name> must include whichever packages, relative to the package-id, within which it is located. See the output below for an example of launching an Activity which sits within several packages.

Further Reading

My goal in this article was to do my best to introduce, explain, and guide you through the usage of the ABD in my own words (insofar as that is possible).

At this point I would need to start making some very contrived examples or to simply carbon copy the documentation, neither of which are things that I am interested in doing.

Instead, I would like to encourage you to visit the documentation, and to have a brief look at some of the cool things you can do using tools like the Activity Manager, Package Manager, Policy Manager, and others.

You can get in touch with me on social media here:

https://www.instagram.com/rkay301/
https://www.facebook.com/wiseassblog/
https://twitter.com/wiseass301
http://wiseassblog.com/

We will explore two variants of MVVM (there is not just one way to do it), and the reasons why you may prefer one variant over another, based on project requirements.

MVVM vs MVP/MVC?

It is quite likely that the most common question I am asked during my live Sunday Q&A sessions, is something like:

MVVM vs MVP/MVC?

Whenever I am asked this question, I am quick emphasize the idea that no single GUI architecture works great in all situations.

Why, you may ask? The best architecture (or at least a good choice) for a given application depends strongly on the requirements at hand.

Let us briefly think about what this word requirements actually means:

• How complex is your UI? A simple UI does not generally require complex logic to coordinate it, whereas a complex UI may require extensive logic and fine-grained control to work smoothly.

• How much do you care about testing? Generally speaking, classes which are tightly coupled to frameworks and the OS (especially the user interface) require extra work to test.

• How much re-usability and abstraction do you wish to promote? What if you want to share the back end, domain, and even presentation logic of your application across different platforms?

• Are you by nature pragmatic, perfectionist, lazy, or all of the above at different times, in different situations?

I would love to write an article where I discuss in fine detail how MVVM works with respect to the requirements and concerns listed above. Unfortunately, some of you have likely been mislead into thinking that there is only one way to do MVVM.

Instead, I will discuss two different approaches to the general idea of MVVM which present very distinct benefits and disadvantages. But first, let us start with the general idea.

Thou Shalt Not Reference Thy View Classes

For my friends who cannot read old English: “You may not reference view classes."

Apart from using the name ViewModel (which itself is confusing if the class is full of logic), the one iron-clad rule of MVVM architecture is that you may never reference a View, from ViewModel.

Now, the first area of confusion can arise from this word “reference,” which I will restate using several different levels of jargon:

• Your ViewModels may not possess any references (member variables, properties, mutable/immutable fields) to any Views

• Your ViewModels may not depend on any Views

• Your ViewModels may not talk directly to your Views

Now, on the Android platform, the reason for this rule is not simply that breaking it is bad because someone who seems to know about software architecture told you it is bad.

When using the ViewModel class from Architecture Components (which is designed to have its instance persist longer than the Fragment/Activity lifecycle when appropriate), referencing a View is asking for SERIOUS MEMORY LEAKS.

As for why MVVM in general does not allow such references, the goal is hypothetically to make both the View and the ViewModel easier to test and write.

Others may also point out that it promotes reusability of ViewModels, but this is exactly where things break down with this pattern.

Before we look at the code, please note that I personally do not use LiveData in my own production code. I prefer to write my own Publisher-Subscriber Pattern these days, but what I say below applies to any library which allows for the PubSub/Observer Pattern link from the ViewModel to the View.

This article is accompanied by a video tutorial covering many of the same ideas here:

ViewLogic + ViewModel or View + ViewModelController?

When I said “break down” in the previous section, I do not mean to say that the pattern literally breaks. I mean that it breaks down into (at least) two different approaches which have very distinct appearances, benefits, and consequences.

Let us consider these two approaches, and when you may wish to prefer one over the other.

Boromir explains that MVVM is not a magic wand that makes your application's presentation logic disappear.

First Approach: Prioritize Reusable ViewModels

As far as I can tell, most people who implement MVVM make it a goal to promote re-usability of ViewModels, so that they may be reused for n number of different Views (many-to-one ratio).

In simple terms, there are two ways you can achieve this re-usability:

• By not referencing a specific View. Hopefully this is not news to you at this point.

• By knowing as little as possible about the details of the UI in general

The second point may sound vague or counter-intuitive (how can it know anything about something which it does not reference?), so I think it is time to look at some code:

class NoteViewModel(val repo: NoteRepo): ViewModel(){
    //Note: you may also publish data to the View via Databinding, RxJava Observables, and other approaches. Although I do not like to use LiveData in back end classes, it works great with Android front end with AAC
    val noteState: MutableLiveData<Note>()
    //...
    fun handleEvent(event: NoteEvent) {
        when (event) {
            is NoteEvent.OnStart -> getNote(event.noteId)
            //...
        }
    }
    private fun getNote(noteId: String){
        noteState.value = repo.getNote(noteId)
    }
}

While this is a very simplified example, the point is that the only thing which this particular ViewModel exposes publicly (other than the handleEvent function), is a simple Note object:

data class Note(val creationDate:String,
                val contents:String,
                val imageUrl: String,
                val creator: User?)

With this particular approach, the ViewModel is well and truly decoupled from not just a particular View, but also the details, and by extension, presentation logic of any particular View.

If what I am saying still seems vague, I promise it will be clear once I describe the other approach.

Although my earlier heading, “ViewLogic + ViewModel…” is not meant to be used or taken seriously, I mean that by having very decoupled and re-usable ViewModels, we are now depending on the View itself to do the work of figuring out how to render/bind this Note object on screen.

Some of us do not like filling View classes with Logic.

This is where things get very muddy and dependent on project requirements. I am not saying that filling View classes with logic such as…:

private fun observeViewModel() {
    viewModel.notes.observe(
        viewLifecycleOwner,
        Observer { notes: List<Note> ->
            if (notes.isEmpty()) showEmptyState()
            else showNoteList(notes)
        }
    )
   //..
}

…is always a bad thing, but classes which are tightly coupled to the platform (like Fragments) are difficult to test, and classes with logic in them are the most important classes to test!

In a word, it is a failure to apply what I consider to be the golden principle of any good architecture: Separation of concerns**.**

My personal opinion is that it is worth it to apply separation of concerns to a very high degree. But make no mistake that plenty of cash cow applications have been written by people who do not have the faintest clue about what that means.

In any case, the approach we will discuss next, while having its own side effects, once again removes the presentation logic from the View.

Well, most of it anyways.

Second Approach: Humble View, Control-Freak ViewModel

Sometimes not having fine-grained control over your Views (which is a consequence of prioritizing re-usability of ViewModels), actually kind of sucks.

To make me even less enthusiastic about applying the previous approach indiscriminately, I find that I often do not need to reuse a ViewModel.

Ironically, “too much abstraction” is a common critique of MVP over MVVM.

With that being said, one cannot simply add a reference back in to the ViewModel in order to regain this fine-grained control over the View. That would basically just be MVP + memory leaks (assuming you are still using ViewModel from AAC).

The alternative then, is to build your ViewModels such that they contain almost all of the behaviour, state, and presentation logic of a given View. The View must still bind to the ViewModel of course, but enough details about the View are present in the ViewModel that the View’s functions are reduced to one liners (with small exceptions).

In Martin Fowler’s naming conventions, this is known as Passive View/Screen. A more generally applicable name for this approach is the Humble Object Pattern.

In order to achieve this, you must essentially have your ViewModel possess an observable field (however you achieve that – data binding, Rx, LiveData, whatever) for every control or widget present in the View:

class UserViewModel(
    val repo: IUserRepository,
){

    //The actual data model is kept private to avoid unwanted tampering
    private val userState = MutableLiveData<User>()

    //Control Logic
    internal val authAttemptState = MutableLiveData<Unit>()
    internal val startAnimation = MutableLiveData<Unit>()

    //UI Binding
    internal val signInStatusText = MutableLiveData<String>()
    internal val authButtonText = MutableLiveData<String>()
    internal val satelliteDrawable = MutableLiveData<String>()

    private fun showErrorState() {
        signInStatusText.value = LOGIN_ERROR
        authButtonText.value = SIGN_IN
        satelliteDrawable.value = ANTENNA_EMPTY
    }
    //...
}

Subsequently, the View will still need to wire itself up to the ViewModel, but the functions required to do so become trivially simple to write:

class LoginView : Fragment() {

    private lateinit var viewModel: UserViewModel
    //...

    //Create and bind to ViewModel
    override fun onStart() {
        super.onStart()
        viewModel = ViewModelProviders.of(
        //...   
        ).get(UserViewModel::class.java)

        //start background anim
        (root_fragment_login.background as AnimationDrawable).startWithFade()

        setUpClickListeners()
        observeViewModel()

        viewModel.handleEvent(LoginEvent.OnStart)
    }

    private fun setUpClickListeners() {
      //...
    }

    private fun observeViewModel() {
        viewModel.signInStatusText.observe(
            viewLifecycleOwner,
            Observer {
                //"it" is the value of the MutableLiveData object, which is inferred to be a String automatically
                lbl_login_status_display.text = it
            }
        )

        viewModel.authButtonText.observe(
            viewLifecycleOwner,
            Observer {
                btn_auth_attempt.text = it
            }
        )

        viewModel.startAnimation.observe(
            viewLifecycleOwner,
            Observer {
                imv_antenna_animation.setImageResource(
                    resources.getIdentifier(ANTENNA_LOOP, "drawable", activity?.packageName)
                )
                (imv_antenna_animation.drawable as AnimationDrawable).start()
            }
        )

        viewModel.authAttemptState.observe(
            viewLifecycleOwner,
            Observer { startSignInFlow() }
        )

        viewModel.satelliteDrawable.observe(
            viewLifecycleOwner,
            Observer {
                imv_antenna_animation.setImageResource(
                    resources.getIdentifier(it, "drawable", activity?.packageName)
                )
            }
        )
    }

You can find the full code for this example here.

As you have probably noticed, we are probably not going to be re-using this ViewModel anywhere else. Also, our View has become sufficiently humble (depending on your standards and preferences for code coverage), and very easy to write.

Sometimes you will run in to situations where you must find some kind of half-measure between the distribution of presentation logic between Views and ViewModels, which does not strictly follow either of these approaches.

I am not advocating one approach over another, but rather encouraging you to be flexible in your approach, based on the requirements at hand.

Choose Your Architecture Based on Preferences And Requirements

The point of this article was to look at two different approaches which a developer can take in terms of constructing a MVVM style GUI architecture on the Android Platform (with some carry over to other platforms).

In truth, we could get more specific about small differences even within these two approaches.

• Should the View observe a field for every individual widget/control it possesses, or should it observe one field which publishes a single model to render the entire View anew each time?

• Maybe we could avoid having to make our ViewModels one-to-one, while keeping our Views as Humble Objects, simply by adding something like a Presenter or Controller to the mix?

Talk is cheap, and I strongly advise you to try and learn these things in the code so that you do not need to rely on people like me to tell you what to do.

Ultimately, I think the two elements which make for a great architecture come down to the following considerations:

Firstly, play with several approaches until you find one which you prefer. This is best done by actually building an application (it can be simple) in each style, and seeing what feels right.

Secondly, understand that preferences aside, different styles will tend to emphasize different benefits in exchange for different deficits. Eventually, you will be able to pick good choices based on your understanding of the project requirements rather than blind faith.

Learn More About Software Architecture:

Social

https://www.instagram.com/rkay301/
https://www.facebook.com/wiseassblog/
https://twitter.com/wiseass301
http://wiseassblog.com/