Android service binding fix for API 30

Android 11 (API 30) changes the way of using external app services. Using `compileSdk 30` and above, without additional Manifest entry the `bindService()` method will always return `False`, even if with `compileSdk 29` the app will work perfectly. I want to share solution of this problem after WAY TOO LONG time I spent on searching it...

Command Pattern in Kotlin

The Command pattern wraps the request into a specific object that has all the information necessary to perform its task. You can think of it as the next stage of refactoring, where at first we extract the code to a separate method, and then to a separate object, taking the arguments needed to execute the request in the constructor.

Remote Logger

While working on a project, I couldn't use Android's 'Development Options' - I couldn't access the logs. If only you could send Logcat logs, e.g. via WebSocket, and then catch them on your computer... I did not find such a tool, so I wrote one and described the process in this post.

Mediator in Kotlin

The Mediator's job is to organize communication between close classes. The `Mediator` pattern cuts out dependencies between components. It takes over the interaction between them, becoming the main communication hub for a group of classes. There is a reverse of the controls because components are now just telling 'what happened' instead of telling others to 'do something'. It can be found e.g. in the form of `ViewModel` in Android, where it separates UI interactions from data model changes.

Decorator Pattern in Kotlin

The `Decorator` pattern is used where creating separate classes which are a combination of all possibilities would result in their explosion. This pattern focuses on creating object layers to transparently and dynamically complement objects with new tasks. The decorator provides an object with the same interface as the decorated object.

Adapter Pattern in Kotlin

The Adapter or Wrapper Pattern allows you to `translate` one interface into another, expected by the client class. It is especially useful when the adapted object comes from 3rd party library, and you do not want to make your system depending on that interface, creating the so-called `anticorruption layer`. Adaptee interface changes will only affect the `Adapter` and not the rest of the code.

IntelliJ IDEA as a LaTeX editor

IntelliJ IDEA is pretty good at handling LaTeX. I dare say that it is an even better experience than TexStudio or Texmaker, which are dedicated to this type of project. However, the strength of IntelliJ is not in its out-of-the-box capabilities, but plugins and manual configuration of the build process.

Facade Pattern in Kotlin

The facade allows you to hide the details of the module from clients. It ensures compliance with `Law Demeter`. Using the generic interface and various implementations greatly simplifies testing. It blends well with other patterns like `Strategy`,` Template Method`, or construction patterns, allowing configuration of the object available for the clients. The facade is a good entry point for libraries, giving customers access to high-level functionality and hiding all internal logic and classes.

Strategy Pattern in Kotlin

The `Strategy` pattern creates a family of algorithms, enclosing the differing logic in separate classes while hiding it from clients behind the interface. It enables the interchangeable use of implementations. The use of the strategy simplifies the customer code, avoids code duplication and conditional statements. Significantly simplifies testing - by separating client testing from strategy algorithms.

Kotlin Template Method

The template method is a very simple design pattern, that separates shared class parts from changing ones. The core idea is to have an abstract parent class containing the algorithm steps and allowing inheriting classes to overwrite individual steps, but not the algorithm that uses those steps itself.