Vadym Yaroshchuk’s Post

🫡

Hello everyone! Just wanted to share that I am currently fully engaged on my TimeMates project: from rewriting FSM logic, to refactoring to the hexagon architecture (at least try my best 😄). There haven't been any posts for the past 3 days for this reason. 😋 P.S: Finally, I wrote good tests using kotlinx-coroutines-test (previously was too lazy). Additionally, I plan to try #Konsist on the backend.

Listen to other people's opinions, other people's opinions:

In some of my articles, I discussed the importance of effective project build configuration. Security, Simplicity and Maintainability – for me, at the moment, it's a combination of Version Catalogs and Build Conventions. But, how does it simplify my build configuration?  In brief, Version Catalogs simplify the process of updating dependencies (using Dependabot or builtin auto-update feature in IDE), while Build Conventions eliminate duplicate configurations in different modules, making life much simpler. But setting up a project, environment, dependencies and just the structure every time takes a long time, doesn’t it? That's why, I have been using my own template for my projects for over two years, and it has significantly reduced the time required to create and configure projects effectively. If anyone is interested, I am sharing it at https://lnkd.in/duBCWSJb. #Kotlin #Gradle 

The number one mistake I see in the #Android development is overburdened ViewModels. ViewModel is and should be just a holder of your state, nothing more. It is important to avoid including any logic that is unrelated to the state, such as navigation or IO tasks. ❓ Why no navigation? Imagine having a mobile-only app that you have developed exclusively for mobile screens. Let's assume that we overlook the fact that navigation logic violates the Single Responsibility Principle (SRP) and focus on the scenario where we want to adapt our application for tablets or desktops in a multi-platform context. How would you go about solving this? Before this, you simply passed the navigator and pushed the screen onto the stack. Now you need a screen to be displayed somewhere on the side of the main screen. And cut, that's a wrap! ❓ Why no IO operations? I don't think it's even reasonable to explain that the testability and maintainability of the ViewModel handling low-level operations (that usually should be offloaded to the data layer) are not reachable, at all. If we need to include tests, we must ensure that not only the UI-related logic is tested, but also the data-related and business logic. At times, we probably will encounter an @VisibleForTesting annotation, or worse, a reflection check of private variables. Well, or simply the lack of tests as such. Your UI should be responsible for navigation and how to react to it, the ViewModel should only provide state and operate on it. That's it.