Necessity is the mother of invention.

― Plato

Every idea comes from a need and this time was no different. During a regular day to day feature development at Whatnot I was struggling to keep up the pace of the business. I had to implement a quite huge feature in a week, making sure that everything works as expected. But how? What corners should have been cut to deliver good quality software? Let me explain it step by step.

Firstly, let’s focus on things that I perceive as a coding pace blockers.

• Shame on me! Writing unit tests along with implementation of bleeding edge feature that changes every two hours not only from the business perspective but also design point of view is quite painful.
• Testing complex user paths manually is frustrating and destroys focus.
• Application build time. Complex codebase can slow down development pace. We all live with that pain!

🏃 Let’s skip unit testing!

Skipping unit tests create a bad side effect of not having an ability to execute and test code in isolation. Building app every minute on device is time consuming and this is how we burn tons of development cycles. Another hidden gotcha is fixing bugs without introducing a new ones. It is almost impossible without a solid regression suite.

I decided that I can live without unit tests during feature development and write them after the product launch. At the same time I put an extra effort to make sure that the code I write is testable and clean. It is not a huge challange as our architecture builders are well established and robust. Guess what! Skipping Test Driven Development saved me tons of time! I was able to write code fast and adjust implementation without any hassle.

Unfortunately testing on device destroyed my focus and I knew that I had to do something with that. Let’s try!

🔗‍💥 Testing on device

Fast Android emulator, incremental compilation and build cache are definitely one of the best things that could happen to Android engineers. It is not a huge pain to run an app every couple of minutes, but what if we need to test a specific validation scenario, error states or empty paths? Those complex user paths can take some time and consume our focus. As I mentioned before, unit testing helps us with that by letting us run code in isolation, setting initial state and get fast feedback. How can we translate this approach into the world where tests simply do not exist?

To answer that question let me briefly introduce our Whatnot Android tech stack. At Whatnot we are building live shopping and marketplace where you can buy, sell and discover products you will love. Along with live streaming we have plenty of seller and buyer features with rich native UI experience. We adopted Jetpack Compose at the early stage and that decision unlocked fast development cycle along with joy and developer satisfaction.

Jetpack Compose is the modern Android UI toolkit that can speed up development massively. Not only the code produced is simpler but also more elegant and concise. We do also use Jetpack ViewModel to feed our Composable UI with correct state. TL;DR MVI onboard. ViewModel is nothing else than a container that glues couple of functions that reduces state with network results and pushes it to the view layer.

🔁⚒️ Fixing fast feedback loop

Now when you know what tools do we use I can start explaining how I came up with a solution to fix broken feedback loop.

My goal was to build an easy solution for running UI along with model layer in isolation. On the top of that I wanted something fast, reliable and predictive. A few questions came to my mind:

1. How to run Compose code in isolation?
2. How to run Model logic in isolation?
3. How to build a set of predefined states that I can use to test regression?

First things first, running @Composable function in isolation is quite easy. Jetpack Compose comes with an additional tooling artifact that allows to render it directly in Android Studio Preview.

debugImplementation("androidx.compose.ui:ui-tooling:VERSION")
implementation("androidx.compose.ui:ui-tooling-preview:VERSION")

This is super handy for creating a set of variants and test them in easy and fast way. Here is an example of using @Preview to visualise all secondary button states in Whatnot Design System.

Next puzzle is a bit harder. How can we use @Preview to run an entire screen or even an entire user flow in isolation? Regular screen written in Compose has more sophisticated function parameters than a button, but is that an issue? It is a challenge!

Let’s start from defining a public API of a screen.

As you can see we can run this as a regular Composable in @Preview by supplying function arguments.

ScreenViewModel is created by hand using fake use cases. We can do even better by using another Compose tooling candy. @PreviewParameter!

That is nice, isn’t it? By using PreviewParameterProvider and @PreviewParameter we can define as many cases as we want. All of them will render in Android Studio Preview automatically. They follow same coding approach as JUnit test params.

So what we achieved so far? We know how to render a screen in isolation along with its model logic. That is great, but is that enough to fix broken feedback loop? Not really, as we still do not know how to use @Preview to RUN and not only RENDER complex user path.

To simplify our complex path, imagine that we have a user flow that presents a list of shipping profiles and gives an ability to add, update and delete each profile. In addition to that, every screen should handle properly empty, error and data states. We also need some advanced form validation to make sure that user knows what to do. As it happens, we have such flow in our Whatnot app so let’s use it as an example.

As you can see, the video shows only a portion of the flow as it starts only from the Profile tab. In practice, testing every use case is more complex as we need to log in, go to the right screen, and make sure that all feature flags and configurations are set correctly. Do not be scared though. It is possible to RUN our flow in isolation using @Preview!

Going into the details it is worth mentioning that we use Compose Navigation which is nothing else than a Jetpack Navigation Component. It makes life way much easier and comes with some handy animations and tooling.

The entry point to the shipping profiles flow looks like this:

Ohh boy, that looks pretty scary at first, but let me explain what is happening here from the higher level point of view.

1. shippingProfileFlow is an extension function that can be easily connected to any nav graph. This makes flow reusable across the entire codebase.
2. shippingProfileFlow function defines six different navigation destinations such as list, create, edit, two types of an errors and some cost optimisation info message.
3. The most important are the last three parameters viewModelStoreOwnerProvider, shippingProfilesViewModelProvider, shippingProfileViewModelProvider. They bring an actual “magic” that allows us to inject fake model providers and run code in isolation.
4. By default shippingProfilesViewModelProvider has a real implementation that injects a correct object instance based on LocalViewModelStoreOwner.current.
5. By default shippingProfileViewModelProvider has a real implementation that injects a correct object instance based on viewModelStoreOwnerProvider which is passed as a parameter.

Such technique is nothing different than a well known Dependency Injection. Now, with all of that, we can add @Preview code and RENDER flow in isolation.

Firstly, define @PreviewParameter(s).

Then add the @Preview function.

The most noisy part of this code is the helper functions for creating modalBottomSheetLayout, but I decided not to present it as it does not bring any real value here. Same rule apply to fake substitutions.

Finally! We are able to RENDER our flows in Android Studio Preview.

It works! What about RUNNING them on emulator?

As you can see flows RUN in isolation and we can play with them just after less than a second. I was able to transform “static” @Preview into fully blown @Preview Driven Development tool. It speeds up code pace and allows faking different complex scenarios with just few lines of code in data provider. In addition to that, @Preview cases are great documentation and manual regression set.

🤓 Key takeaways

I know, that might be a lot to digest, but if you already use Compose with Jetpack ViewModel it should not be hard to apply same strategy to your codebase.

Going back to coding pace blockers.

1. Skipping writing unit tests is not something that I would recommend, but it saves time. Actually time is not saved, but borrowed from the future! After release I wrote full unit test suite to make regression faster. It took me a day as business logic and UX was already settled.
2. Running complex user paths using @Preview is a game changer to me! Super easy to maintain, reliable and fast!
3. Incremental build time takes less than two seconds and faking through @PreviewParameter is easy and concise.

To sum up, I really encourage you to start using Compose @Preview tooling if you do not. At Whatnot we are in the middle of implementing Compose Design System and I cannot imagine it without interactive @Preview(s). Stay tuned as I am planning to write about it soon!

If this was interesting to you, leave a comment, give some claps 👏 or let me know on Twitter. We are hiring at Whatnot!

@Preview Driven Development with Jetpack Compose was originally published in Whatnot Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

You can have all the tools in the world but if you don’t genuinely believe in yourself, it’s useless.

― Ken Jeong

My life has many journeys and the most inspiring are those that bring me personal joy and satisfaction. Programming is one of them, and the more I am into it the more exciting it is.

I used to be pretty shy in terms of publishing my knowledge and sharing my thoughts with a broader audience. Every single public speech that I made was a disaster and a huge drama. I knew that I have to change it to evolve and push my programming skills to the max. A couple of years ago I challenged myself by deciding to become a conference speaker. In this article, I want to share with you how I overcome stress for public speeches and especially live coding. I will show you some techniques and exercises that I use to stay calm and never get surprised. Sit comfy, get your favorite beverage and enjoy reading!

Relax, you know more than you think 🧘

Are you familiar with the most iconic Aristotle’s quote?

The more you know, the more you know you don’t know. — Aristotle

That is a definition of every single engineer’s life. We learn something new every single day. Awesome, right? It would be awesome, but there is also the other side of the moon that is extremely dark😨! A lot of engineers(including myself) that I have met during my programming career were thinking that they were not good enough. Why? Because they knew a lot. They knew that there is so much knowledge out there that it is not possible to touch it all.

How is it possible that I had such a mindset? What blocked me from sharing my solutions? The answer is simple. I was too stressed about it as I only thought about what can go wrong and what things I do not know. If you want to become a speaker and successfully write code in front of the public you need to make the first step. Relax. You are doing it every day at work. Pairing with your teammates is nothing different than coding one the stage. Breath, relax and live code!

Prepare yourself, it will reduce your stress 🤓💻

Now when you know that being stressed can kill your motivation you need to reduce your stress during live coding itself. There are many techniques like cold showers, a small amount of alcohol or laugh therapy, but nothing can help you more than a solid preparation.

Coding Script 📝

Before anything else, you have to have your coding script done, as you need a clear presentation plan. To do that you do not write every single step of your coding. You also do not need to create it before you write all your code. From my experience, the best way is to sit, think twice and write all necessary building blocks(including several refactoring). After that extracting script will be way much easier. It is easier because during programming tons of things are changed and the script can be rebuilt completely. That means that spending time before coding can be a huge waste of time.

Practice every day 👨‍💻

Writing code can be as personal as writing poems. Many young engineers are struggling with writing code in front of the other engineers. They are scared of it as they have a too strong connection with the code they write. Other problems live in the lack of fluency and speed in typing and generating code. So how you can train to become a fearless, real time code generator?

To break a fear I recommend implementing a weekly routine to pair program with your company colleagues. A really important point is to shuffle your buddy as often as you can to get out of your comfort zone. Besides that, try to pick up bigger tasks and not just bugs or quick changes. It will give you a chance to learn and see how other people work and use their tools to get a job done. Another good exercise is MOB programming. It is an approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer. So you can see it as a pairing on steroids.

Following those tips allows practicing live coding skills almost every day at work! I love pairing and I am a huge fan of extreme programming as it teaches me a lot in terms of good practices and my own weaknesses.

Use the right tools, they will save your life ⚒️

Now with no fear you can start building your ultimate fluency. Whenever I have to do a particular job I am looking for the best tool that I can get and I master it. I research productivity plugins and create my custom list of useful shortcuts. The most important thing is to build robust navigation awareness. Walking is not enough. You have to teach yourself how to run using your IDE. The best way is to forget about a mouse🖱️🤮, trackpad or any other pointing device. They just make you crippled.

A couple of years ago I got inspired by Hadi Hariri and his amazing talk “Mouseless Driven Development”. Since that time I treat mouse as an exception and I use only my keyboard to write code and navigate. It took quite some time to be proficient in it, but it was the best investment that I did in my life. This skill helps me a lot during live coding sessions not only during conference talks but also every day at work. Presenting solutions is easy when it can be done smoothly and without any breaking pauses.

I also released that during development there is no need to see any additional things than the code itself so I disabled icons, tabs, and other sugars. My IntelliJ IDEA looks pretty clean. Almost like an old good text editor 💪.

Probably you have already seen IntelliJ in this form. It is nothing else than “Presentation Mode” except its name. It is called “Distraction Free Mode” and it can be turned on in every IntelliJ Platform-based product.

Programming in “Distraction Free Mode” is an awesome way to practice IDEA navigation and shortcuts. After a few months, you will be as fast as SegaSonic.

Besides that:

• It will make you comfortable with “Presentation Mode”.
• All your coding skillset will be there for you during your live coding.
• “Distraction Free Mode” is clean, neat and it makes every code presentation more readable.

TL;DR. Tips 😴

I am so happy that you read all my thoughts but let’s have a look at tips that I gathered over a couple of years. Some of them can be implemented with minimal effort and bring instant, positive results.

1. Believe in yourself. If you think about giving a live coding presentation that means that you know more than you think.
2. Prepare a coding script. Planning is important!
3. Practice your live coding. Use QuickTime to record your screen to see your progress.
4. Go deep into the implementation of the functions that you use. It will help you answer all the Q|A questions.
5. Pick the right tools to get a job done.
6. Reduce stress by being fast and fluent with your tools.
7. Try to implement training routines. Remember that you can practice every day at work, just do it!
8. During live coding avoid context switching. Try not to leave your editor at all. Use GIT and console plugins that are built into your IDE.
9. If you switch between two tools make sure that they are in separate desktops. Do not use just one with many windows opened as it creates a distraction.
10. Make sure that your desktop is empty(no icons!) and your wallpaper is minimalistic.
11. Turn off all your email and chat clients. Disable all system notifications if possible.
12. Use your daily keyboard to make you feel comfortable with the setup.
13. If your code depends on the external library make sure that every single one is downloaded. Try using offline mode if it is available.
14. Be on time. Make sure that your IDE has the best color scheme for the screen. Same story with font size. “Dark Mode” is not always the best option.
15. Always create backup templates of your code. It will let you finish your live coding when something will go wrong.
16. Have your coding script with you while presenting. Sometimes stress can make you skipping some important parts of your code. Do not let the disaster happen.

Be patient, you will get better over time 😌

Last but not least do not get sad when your presentation will go wrong. We all make mistakes every single day and it just makes us stronger. Practice, practice, and practice more. See you on the stage!

Useful Links:

• MOB programming
• Extreme Programming
• Mouseless Driven Development
• IntelliJ IDEA

If this was interesting to you, leave a comment, give some claps 👏 or let me know on Twitter.

Successful Live Coding was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Don’t cry because it’s over, smile because it happened.
― Dr. Seuss

Unfortunately, all journeys have to end😿. This is the last — but not least — part of my three-part series about the sweetest Kotlin candies. In previous posts you had a chance to get familiar with:

• sealed classes to encapsulate different state definitions in different cases.
• when() functions to permute in a clean and elegant way.
• with() functions to omit qualifiers.
• inline functions and reified types to write your own withCorrectType() functions with.

This time I have something really special, and you can treat it as the frosting on the cake. First, I would like to introduce you to code association and how to use the delegation mechanism of the Kotlin language to make it simple and short. Then, in the second part of the article, you will become more familiar with writing your own DSL (Domain-Specific Language) structures.

Pour a cup of your favourite beverage and enjoy reading.

KProperty: make your composition great again

It is said that the wrong abstraction is worse than no abstraction. Actually, what this points out is that inheritance is a really tricky mechanism and it should be used carefully. Some books say that you should use composition over inheritance and that it is key to good design.

Kotlin has a built-in delegation pattern, and it is super easy to use it for aggregation.

As you can see, there is no magic here. The Component class implements Navigable and Searchable interfaces and then, using the language keyword by, applies behaviours from navigable and searchable constructor parameters. This language construct is super useful as it cuts tons of boilerplate code, but it is not a silver bullet for all association scenarios.

Imagine that you need to mark your interfaces as internal because you want to make them a part of your internal architecture:

How does it affect the Component class? Sadly, you broke the code and now you are getting a compilation error💔. This is because the Kotlin compiler does not permit exposure of the internal components of your module.

So, if there is no need to expose Navigable and Searchable dependencies, you can:

• Remove the constructor.
• Use composition instead of aggregation.
• Define the ComponentInterface that contains method signatures from Navigable and Searchable interfaces.

Wow! That escalated quickly. From zero boilerplate aggregation you went to nasty-looking composition. But don’t cry, because Kotlin always has some sugar to make your codebase happier. Kotlin not only supports method delegation to the specified object using the by keyword, but also has a mechanism to delegate properties. You have probably been using it by applying the lazy() delegate to properties that should be initialised in access time.

Being lazy is good, but how is it connected with your case? It means you can apply the same pattern that is used to define the lazy() function to re-factor your composition code.

Warning! This code can change your life drastically💣.

ReferencedProperty is a class that takes two functions as parameters in the constructor and defines two operators.

• The get function takes nothing and returns a generic type T. It is an accessor function.
• The set function takes a generic type T and returns Unit. It is a mutator function. Additionally, set has a default value set to empty function.
• The fun getValue() operator invokes the get() function.
• The fun setValue() operator invokes the set() function with a value parameter.

The most important thing to know is that operators are used by the property delegation mechanism. After the ReferencedProperty class declaration, you can find two generic ref() methods that return an instance of the ReferencedProperty type. Why two? The first one will be used for properties marked as var and the second one for those marked as val.

Let’s use ref() functions to clean-up your composition.

It looks much cleaner right now, doesn’t it? The ref() function allows you to delegate the property definition to another component. By using :: you can get KProperty0 for val and KMutableProperty0 for var. These are representations of your properties and you can easily access getter and setter functions from them. It may sound complicated but I really encourage you to play with this syntax. Hopefully, you will find it useful as it can save a lot of lines of your codebase. It saved mine! There is one caveat that you need to be aware of. This syntax uses reflection under the hood so make sure you are ready to take such trade-off.

It is about time to dive into the waters of DSL. Get ready.

Write DSLs to cover up ugliness

One of the coolest features of Kotlin is that it gives you the ability to write clear DSLs. A Domain-Specific Language is a computer language specialized to a particular application domain. The perfect example is a well known Anko library that was made to build the user interface of Android application programmatically. Additionally, you can use it to write statements against the SQLite database and schedule background tasks (Coroutines under the hood😎).

Not only does it simplify the code, it also makes it more readable.

You might think that building such a pleasant API needs advanced Kotlin knowledge, but you couldn’t be more wrong! Recently, I decided to build an additional layer on the top of my acceptance tests. My main goal was to separate the WHAT from the HOW. What does that mean?

• The WHAT should be the test itself that contains only the information that is to be tested.
• The HOW describes the internals of the framework that is used for testing.

In addition, I wanted my test cases to look the same for Android written in Kotlin and for iOS written in Swift. Writing DSLs for those were the perfect solution.

Let’s have a look at the syntax I wanted to achieve.

This is a really nice and clean looking piece of code, isn’t it? The setup() function contains prerequisites for the main test case. It makes an app to open ScreenOne using a navigation controller. Can you tell how this DSL is implemented under the hood? Of course, I am not asking about the framework that sends the commands to the target device. If you have no idea, let me explain it to you.

As you can see, the implementation is trivial. The navigation() function takes a block as a parameter that is nothing else but a function literal with a receiver. The body of the function invokes the block() directly on the NavController object. NavController is just an object that defines the behaviour function. This is where you implement the HOW, using any of your favourite testing frameworks.

There is one more construct living in the test case that is worth explaining.

What is so interesting in the DSL mentioned above? It is almost the same as the navigation { openScreenOne() } except that after the closing bracket, there is another chained construct. How is it possible to chain such constructions? Is it a function invocation or something totally different? To make it more clear, I will change this DSL to something more obvious.

The main difference is that before invoking the openSearch() function (the code shows the function using parentheses) you can see the dot notation. This shows in a very explicit way that openSearch() is a function called on some object that is returned from toolbar {}. Now it should be an easy task to implement such DSL and the implementation can look like this:

The toolbar() function looks similar to the previously implemented navigation() one. It takes the function literal with a receiver as a parameter and additionally returns an instance of the Toolbar object. It allows you to invoke the openSearch() function, which contains the HOW and returns an instance of the SearchToolbar object. Again the SearchToolbar is an object that defines the behaviour function type() that contains the HOW. Awesome!

The last riddle is the dot notation and how to achieve the DSL syntax that omits it. To be honest, the implementation is based more on a hack, than an elegant dedicated solution.

Marking the openSearch() function as infix allows you to call it with infix notation. The infix keyword was added to the Kotlin language to answer a need for writing arithmetical and logical statements. It should not be abused to achieve other constructs. Additionally, infix can be used only for functions with one parameter. This “limitation” can cause inconsistencies in your DSL.

I hate writing endings as I feel that I am losing a friend―you. But, as I said at the beginning of this article:

All journeys have to end😿.

I hope that this three-part series has not ended but helped to start your own journey through the Kotlin language syntax. I wish you clean code and a happy codebase.

If this was interesting to you, please give some claps 👏 or let me know on Twitter.

Try new things. I think a lot of what people call intelligence boils down to curiosity. — Aaron Swartz

We are continuing our journey through some of my favourite Kotlin constructions. In the first part, you learned how to use sealed classes and permute two or even three enums in an elegant and concise way.

In this part, I would like to show you something that I frequently use in components that have a presentation layer. There will be also something special that perfectly demonstrates how to use an inline reified function. I hope you will appreciate my sugars the same way I do.

Let’s start with the well-known with() function.

Use the with() function to scope invocations

Assuming that you have never used a with() function before let’s see what you can find in the documentation:

inline fun <T, R> with(receiver: T, block: T.() -> R): R (source)

Calls the specified function block with the given receiver as its receiver and returns its result.

😕😢😭… At first glance it looks a little complicated, but only if you have no idea what a block or receiver is. As always, an example will clarify them all for you:

The first line is a no-brainer. It shows the receiver of the type String. The receiver type is important because in line three you can see a definition of the function literal with a specified receiver object. This notation may remind you of an extension function mechanism, and that is a good thing. Inside the specified block, you can call methods on the receiver object without any qualifiers. The last interesting thing is the return Unit type of the block function.

Now, block and receiver should not have any hidden logic. Using your new knowledge, applying block and receiver to the with() function is not only an easy task but also fun.

Let’s make it a little shorter, more concise and typeless.

The block lambda is the last parameter of the with() function and because of that, you can place it outside the round brackets. That is it!

So, how can you apply a with() function to your codebase to make it happier? During the last couple of months, I often used it to omit qualifiers like view.show() and view.hide() in the Presentation layer of my UI components:

That looks nice, doesn’t it? Moreover, it is really easy to work with such code in the future. There is no need to think about the view because our function is already scoped with it.

Now, it is time to go further and write your own withCorrectType() function using the reified keyword👊!

Try inline reified to invoke withCorrectType()

I truly love code reviews. In my opinion, it is one of the best ways to learn fast and exchange knowledge in your team. The next sugar is taken from my teammate’s comment to code that I refactored lately. Have you ever had the feeling that something was wrong with the codebase but you did not know how to make it better? If so, don’t feel bad because it’s completely normal.

Let’s analyse the following.

Can you point out any weak lines in this code? It is quite obvious that MediaItemRenderer and IconItemRenderer have similar logic in the render() method. Additionally, you can use the knowledge from the previous sugar and omit view qualifiers. Easy!

Now it is time to come up with something clever. How about creating a function similar to with() and trying to move the type-checking code there?

Excellent! Now you are good to go and refactor your render() function, aren’t you? Hmmm… There is a small problem because your code does not compile.

What does it even mean that it is not possible to check for an instance of the erased type: T? This error is strictly limited to the erasure of generic types and the way generics work.

During the type erasure process, the Java compiler erases all type parameters and replaces each with its first bound if the type parameter is bounded, or Object if the type parameter is unbounded. — docs.oracle.com

So, is it possible to prevent your generic T from being erased? With Kotlin, everything is possible! ...I mean, almost everything😜. By using a combination of inline and reified keywords, you can easily fix your problem.

Refactored code.

You can go deeper and use the IntelliJ IDEA Kotlin Bytecode tool to find out what the Kotlin compiler did with your reified type and how the inline keyword helps.

That is pure magic, right? The Kotlin compiler left your type because you marked it as reified. This would not be possible without marking your function using inline, as the code from withCorrentType() had to be injected directly into the invocation places.

Summing up, the inlining function with a reified type not only makes your code more readable, it also has no negative impact in terms of performance😎.

That’s all for the second part, but if you’re still hungry, stay tuned for Part 3, or return to Part 1.

6 magic sugars that can make your Kotlin codebase happier — Part 3

If this was interesting to you, please give some claps 👏 or let me know on Twitter.

Syntactic sugar causes cancer of the semicolon. — Alan J. Perlis

We are constantly missing some things. Some of them are more important than the others, but it is never too late to catch up with those. Kotlin language brings tons of new concepts and features to your miserable programming life and it is really hard to use all of them in your daily duties. After almost two years of using Kotlin in production, the language itself can give me joy and satisfaction. How is it possible? Because of its many small sweet sugars 🍰.
In this article, I would like to share with you my favorite Kotlin candies that I discovered when I was in need of writing robust and concise components for Android applications. To make this article more friendly to read I divided it into three parts. In the first part, you will be able to see some cool features of sealed class and when() control flow function. Enjoy!

Seal your class with a kiss of “pattern matching”

Recently I had a chance to work with Swift. Not only did I have to review the code, I also had to translate some of the components into Kotlin. The more code I read, the more amazed I was, but the most attractive feature for me were enums 🚀. Unfortunately, Kotlin enums are not very versatile so I had to find a suitable replacement for them: Sealed classes.

Sealed classes are nothing new in the programming world. Actually, the sealed class is a pretty well-known language concept. Kotlin introduces the sealed keyword that can be added to a class declaration and used to represent restricted class hierarchies, where a value can have one type from a limited set, but cannot have any other type. Long story short, you can use sealed classes as a replacement for enums and much more.

Let’s examine the following lines of code.

At first glance, this code does nothing except declare a poor inheritance relationship, but after step by step deconstruction it shows astonishing potential. So, what actually does the sealed keyword add to the Response class? The best way to unmask it is to use the IntelliJ IDEA Kotlin Bytecode tool.

After this super easy transformation, you can start reading the Java representation of your Kotlin code.

As you have probably already guessed, sealed classes are made especially for inheritance, so they are abstract out of the box. But how are they similar to enums? Here is the moment when the Kotlin compiler does you a huge favour by allowing you to use the subclasses of the Response class as cases of the when() function. Additionally, Kotlin provides great flexibility where structures that inherit from a sealed class can be declared as data or even as an object.

Not only does it give fully exhaustive expression, it also provides automatic casting so you can use a Response instance without any additional transformations.

Can you imagine how ugly and complicated it could look without a sealed feature, or without Kotlin at all? If you have forgotten some of the Java language, use IntelliJ IDEA Kotlin Bytecode once again, but sit tight — it might make you faint.

Summing up, I was delighted to use the sealed keyword in such cases because it let me shape my Kotlin code in a fashion similar to the Swift version ❤️.

Use the when() function to permute like a boss

As you have already had a chance to see the power of when() in use with the sealed classes, I decided to share more of its robust capability with you. Imagine that you have to implement a function that accepts two enums and produces an immutable state.

enum class Employee describes all roles that can be found in the Company XYZ and enum class Contract contains all types of an employment contract. Based on these two enums you should return a correct SafariBookAccess. Moreover, your function has to produce the state for all permutations of the given enums. As the first step, let’s prototype the signature of the state-producing function.

Now it is time to define theSafariBooksAccess structure and because you are already aware of the sealed keyword, it is a perfect time to use it. It is not necessary to seal SafariBookAccess but it is a good way to encapsulate different state definitions in different cases of SafariBookAccess.

So what is the main idea behind of the access() function? Permutation! Let’s permute 👊.

This code is faultless, but can you make it more Kotlin-ish? What would you suggest while doing the day-by-day code review of your colleague’s PR/MR? Your comments can contain something like this:

- Too many when() functions. Use Pair to avoid nesting.

- Change the order of enums parameters. Define pair as a Pair<Contract, Employee>() object to make it more readable.

- Merge duplicated return cases.

- Change to single a expression function.

Now it looks much cleaner and more concise, but Kotlin has some additional sugar that allows you to omit the Pair definition completely 🐵. Bam!

I hope that you have found this useful, as this construct made my life easier and my Kotlin codebase happier. Unfortunately, it is not possible to use this syntax for triples.

That’s all for the first part, but if you’re still hungry, stay tuned for Part 2. It will be delivered shortly. Cheers!

6 magic sugars that can make your Kotlin codebase happier — Part 2

If this was interesting to you, please give some claps 👏 or let me know on Twitter.

It is easier to get into something than to get out of it. — Donald Rumsfeld

Living without Kotlin is like playing Warcraft III on the touchpad. Buying a mouse is simple but what can you do if your new employer does not want to let you use Kotlin in production?

There are a few options.

• Fight with your product owner to obtain the rights to use Kotlin.
• Use Kotlin and do not tell anyone about it because you know best what is best for you.
• Wipe away your tears and use Java in all its glory.

Imagine that you lost the battle with your product owner and as a professional engineer, you will not lie and use hipster technology without anyone’s permission. I know that it sounds pretty scary especially when you have already tasted Kotlin but do not lose your hope.

In further parts of this article, I want to shortly describe some Kotlin features that you can apply to your Android Java code through some well-known tools and libraries. A rudimentary understanding of Kotlin and Java is required.

Data classes

You really do love Kotlin’s data classes, don't you? It is so easy to get equals(), hashCode(), toString() and copy() generated for you. To be specific data keyword also generates componentN() functions corresponding to the properties in their order of declaration. They are used in destructuring declarations.

Do you know what will be printed? For sure it will not be the value returned from the toString() of the Person class. Here is where the destructuring declaration comes to play and assigns a value from name to riddle. Using parenthesis for (riddle) compiler knows that it has to use destructuring declaration mechanism.

As you can see data keyword is a super useful language feature so what can you do to bring it to your Java world? Use annotation processor and modify the Abstract Syntax Tree. If you want to go deeper please read the article listed at the end(Project Lombok — Trick Explained).

Using project Lombok you can achieve almost the same functionality that data keyword provides. Unfortunately, there is no way to have destructuring declarations.

@Data annotation generates equals(), hashCode() and toString(). Additionally, it creates getters for all fields, setters for all non-final fields and constructor with all required fields(finals). It is worth to be aware of that Lombok is used just for compilation so the library code will not be added to your final .apk.

Lambda expressions

Android engineers have a pretty tough life because of lack of Java 8 features and one of them are lambda expressions. Lambdas are great as they cut down tons of boilerplate for you. You can use them in your callbacks and streams. In Kotlin lambda expressions are built-in and they look way much better than they look in Java. Moreover, the bytecode of the lambda can be inserted directly into the bytecode of the calling method, so the method count does not increase. It can be done using inline functions.

Lately Google announced support for Java 8 features in Android and thanks to Jack compiler you can use lambdas in your code. It is also good to mention that they are available on API level 23 and lower.

How to enable them? Just add those several lines to your build.gradle file.

If you are not a fan of Jack compiler or for some reasons you cannot use it, there is a different solution for you. Project Retrolambda lets you run Java 8 code with lambda expressions and method references on Java 7, 6 or 5 and here is the setup.

As I mentioned before inline functions in lambdas in Kotlin do not increase method count but what about using them with Jack or Retrolambda? Obviously, they do not come for free and the hidden costs are listed below.

Data manipulations

Kotlin introduces higher-order functions as a replacement for streams. They are extremely useful when you have to transform one set of data to another or filter the collection.

Streams are also provided by Google using Jack compiler. Unfortunately, Jack does not work with Lombok because it skips generating intermediate .class files when compiling the code and Lombok depends on these files.

That is too good to be true so where is the catch? Sadly, streams are available from API 24. Good job Google but in what universe apps have minSdkVersion = 24?

Fortunately Android platform has an awesome open source community which produces a lot of great libraries. Lightweight-Stream-API is one of them and it contains streams implementation based on iterators for Java 7 and below.

The sample above combines Lombok, Retrolambda, and Lightweight-Stream-API and it looks almost as good as Kotlin, doesn’t it. Using static factory method allows you to transform any Iterable into a stream and apply lambdas on it as on Java 8 streams. It would be perfect to wrap the static invocation Stream.of(persons) into extension function of Iterable type but Java does not support it.

Extension functions

Extension mechanism provides an ability to add functionality to a class without having to inherit from it. This well-known concept fits great in the Android world and that is why Kotlin is so popular in the community.

Is there any technique or magic trick that brings extension functions to your Java toolbox? Thanks to Lombok you can use them as an experimental feature. According to what Lombok documentation says they want to move it out of experimental status with no or minor changes soon. Let’s refactor last sample and wrap Stream.of(persons) into extension function.

All methods that are public, static, and have at least one argument whose type is not primitive, are considered extension methods. @ExtensionMethod annotation allows you to specify a class that contains your extension functions. Instead of using one .class object you can also pass an array.

I am fully aware that some of my thoughts are pretty controversial especially Lombok ones and I also know that there are a lot of other libraries that can make your life easier. Please do not hesitate to share your experience in comments. Cheers!

Lombok, Lightweight-Stream-API, Retrolambda

Project Lombok - Trick Explained

If this was interesting to you, please do hit the heart button ❤ or let me know on Twitter.

“The only true wisdom is in knowing you know nothing.”
― Socrates

I have been using Kotlin for almost a two years and I started from putting it to toy project intended for my tech talks. Do you remember that time when Kotlin had traits instead of interfaces? From the very first line, I knew that this language will change my life, and you know what? I was totally right.

Knowledge makes you better and that is why world’s most successful engineers are constantly learning new things. Here is my list of five less known things about Kotlin and I hope you will find at least three worth knowing.

1. Name your imports

In Kotlin, imports are used by the compiler to let you name your classes by their unqualified name. What happens if you have naming conflict? Sad things happen!

Personally, I hate using fully qualified package names in my code as it lowers readability and clarity. In Python, you can name your imports to fix the conflicts and Kotlin supports it as well ❤.

2. Change companion object name

Companion object was introduced to replace static members. It is not only for declaring static properties but also to name them. How? Let’s have a look at this example.

By default, Kotlin creates a static nested class Companion for every companion object. That is why you need to use CustomButton.Companion to access static members from Java code(you can also use it in Kotlin but it is not necessary). Kotlin lets you change the default name of companion object to whatever name you want. Refactored code looks like this.

The biggest drawback is that Kotlin does not support multiple companion objects for a class. It would be great for grouping static properties.

3. Compose functions

I bet you used function references before but have you ever tried to use them to compose functions? Imagine that you want to map an array of prices to prices that are taxed, discounted and rounded. Using common approach you will end up with something like this.

This example is begging for composition so do not disregard it and make the code better place. Abracadabra!

Functions composition not only makes your code cleaner but also faster. Once you understand it, you will be able to compose almost everything.

4. Change name of generated class

Extension functions are one of the most attractive features in Kotlin but using them in Java code can give you a serious headache. It is ugly and besides is nothing else like invoking a static method.

Kotlin generates class AnyKt with a static method so you can use it in Java. There is an option to change the name of generated class to achieve better readability.

5. Validate an assignment and “veto” it

The way in which Kotlin handles delegation is pretty spectacular so if you are not familiar with it, you should totally check my article: “Zero boilerplate delegation in Kotlin”.

Besides of “class delegation”, there is an interesting mechanism called “delegated properties” which is used for lazy property initialization. How would you solve scenario in which you need to be able to intercept an assignment and “veto” it? Is there any clean way to do it? Yes, there is!

Sample shows usage of a built-in vetoable delegate. Lambda passed to the vetoable is called before the assignment of a new value to property. Returning false from the lambda allows you to “veto” the assignment but if you want to pass it through return true.

Zero boilerplate delegation in Kotlin

If this was interesting to you, please do hit the heart button ❤ or let me know on Twitter.

Five Small Things You Probably Don’t Know About Kotlin was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Systems that aren’t testable aren’t verifiable. Arguably, a system that cannot be verified should never be deployed. — Robert C. Martin

Sleep is one of the most important and healthiest things you can do for your body. It is said that good sleepers have better concentration and productivity, isn’t that what we are all aiming for? I have been producing code for almost ten years now and I have seen and written tons of smelly, spaghetti code. Testing allows me to sleep well at night and that is why I want to share my thoughts and practices about it.

Start writing tests

Writing tests should be an integral part of our daily duties as you consider yourself professional software engineer. If this sounds new to you, please start testing your code from today. Trust me. I was in your boots and I know how hard is to kick off but in fact, it is easier than you think. In the beginning, you will feel a little bit disappointed because it will perturb your productivity but I can assure you that “test investment” pays off sooner than later. In addition, over time you will become more confident and a faster engineer in test.

Treat tests like your codebase

Almost all software engineers I have met know who is Robert C. Martin. He is a clean code evangelist and the author of amazing books and articles that changed our way of thinking about software development. Nowadays there is a lot of buzz about code refactoring, code readability, and code conciseness so why are you not applying this knowledge to your tests? People tend to draw a strong line between code and tests but for me, there is no difference and I see them as siblings. That is why I treat my tests like I treat my codebase caring about readability, conciseness, and usefulness. DRY and SOLID testing!

Document code through tests

Documentation is always a big pain because of hardness in maintaining it, and additionally, it is often outdated. In my opinion, the code has to be self-documented by being clear, simple, and having a full suite of tests. I always try to make my tests as readable as it is possible to provide the best documentation for my code. It is a hidden benefit of testing that every software engineer should be aware of.

Make them fail

If there are no failing tests every now and again, it is a sign that you are not doing them right. It is a very good practice to write tests first but this is not what I mean. Fail them to check if your setup works as incorrect mocking can make your assertions and verifications weak.

Happy path is not enough

The worst thing is the code covered with “happy path” tests as they give an illusory safety. Designing robust and reliable test cases is the hardest and the most satisfying part of my daily duties. To make it more interesting take your craft to extreme and use test driven development and pair program with your colleagues.

Do not change code to write tests

This point is crucial in conjunction with architecture and security so it should be as important as your date of birth. Think twice while breaking an encapsulation to test your code because the leaking architecture will slow down your work in the future. Actually, this kind of situations is always pointing on bad design. I made this mistake and in most cases, I ended up rewriting components from the scratch.

Be careful with test doubles

Simply do not misuse test doubles as they can lead to non-obvious implementation leak. When implementation details in your production code change, you will have to refactor your tests to reflect these changes. Moreover, tests will become less readable and maintainable because of huge setups.

Review test cases

Code review is the best tool to examine pre-production code and find bugs in it. Lately, I was interviewing a couple of engineers and I noticed that their code reviewing skills were terribly neglected. Most of them do not even try to open a test class to check what is inside, scary right?

Personally, I love to review test cases and I always investigate them first. I use built-in code coverage tool in IntelliJ to check “Hits”. Too many or too little of them can tell you if the code is over or under covered.

Test picked up use cases

Reading and understanding someone else’s code is our daily routine. Do you know that feeling when you have to change the non-tested code? During it you research repository, talk to other programmers, make notes and then you apply changes. There is one step missing in that chain. Before changing the code you should write the test to every single use case that you picked up. Also, you can use “characterization testing” against an existing code to understand the logic behind it.

Try different frameworks

It is not just that software engineers fear new tools, though they undoubtedly do. It is also that they truly believe that when you have been doing something a particular way for some time, it must be the best way to do it. I notice a strong tendency in Java world to use JUnit as a main tool to write unit tests despite the fact that it has a lot of pitfalls. I use Spock in exchange for JUnit to apply robust Groovy syntax to my tests and it works like a charm. There are many other, great frameworks like TestNG and the latest Spek that can help you to achieve conciseness and readability.

Be pragmatic

With growing skills hunger accelerates rapidly, and to feed it you try to test everything. Remember that the more tests you write, the more code you have to maintain. Being pragmatic will stop you from testing boilerplate code such as getters, setters, constructors etc.

Summing up, I hope that you have found some helpful bits of advice or at least I inspired you enough to start working on your own best testing practices.

If this was interesting to you, please do hit the heart button ❤ or let me know on Twitter.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!

Test well, sleep well was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sometimes a large number of independent extensions are possible and would produce an explosion of subclasses to support every combination. — (GoF)

As a kid, I was a fan of diving as it gave me freedom and measureless joy. Over the years my passion changed and I have started diving in deep waters of the ocean of programming. Knowing how things work brings a lot of satisfaction so let’s try to understand amazing extensions in Kotlin.

It is said that problems with architecture design are strictly connected with lack of knowledge about how language mechanisms work and what they are for. Sadly but truly nowadays countless amount of engineers have gaps in fundamentals and that is why we need to evangelize them over and over again.

What are extensions for?

Kotlin introduces extension functions and extension properties to solve some common scenarios. Imagine that there is a need to add or extend existing functionality to a class. What are the options?

• Extend an entire class
• Use util function
• Decorate

Extending a class is always a risky option, util function will become a big static pain for testing and even using sophisticated Decorator Pattern(if applicable) generates tons of boilerplate. Kotlin extensions give the fourth and the best option you can get.

Extend non-extendable

Extension mechanism provides an ability to add functionality even to final classes. Let’s have a look at this code.

From the newbie perspective, it looks pretty odd. Adding functionality to String class? How is that even possible? Extensions do not actually modify classes they extend.

The sample above shows that compiler generates a class and the static function with a receiver as a parameter. The receiver has a type of extended class. Now it is obvious why the code is so awful when extension functions are used in Java. In the end, they are only static functions.

Inlining matters

Inline functions are extremely beneficial in case of a having function that takes functions as parameters. That sounds like an inception but do not be frightened. It is just a functional programming and it is closely related to extension functions.

Lately, I was dealing a lot with collections and for most of the time, I had to search through them in reverse order. My pre-refactored code looked like this.

As soon as I typed .reversed().forEach() twenty times I realized that it is a really good idea to squash it into .reversedForEach(). Refactored code used extension function which I added to Iterable type.

Everything was great except a performance. I accidentally forgot to inline my function so my code was creating redundant objects. This is a common mistake in designing extension functions.

The picture shows Java code generated from Kotlin. It is clear that inlining has a great impact on bytecode. For the closer look, I suggest to read carefully inline functions section in Kotlin reference and play with some samples.

Summing up extension functions have a great potential to cure a lot of headaches but it needs to be remembered that with a great power comes a great responsibility so use them consciously.

If this was interesting to you, please do hit the heart button ❤ or let me know on Twitter.

Quick dive in Kotlin extensions was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Delegation is an implementation mechanism in which an object forwards or delegates a request to another object. — (GoF)

It is said that inheritance is useful only in case of having Donald Trump as a father. Abstract classes have a lot of gotchas in term of designing scalable and reusable architecture. How many times did you create the superclass in your codebase that could not be replaced and blocked you from doing new fancy features? Thanks to Henry Lieberman our programming toolbox include an amazing delegation, so it can be used against wrong abstractions. Remember! The wrong abstraction is worse than no abstraction.

Words are cheap, let’s compose a CopyPrinter class.

The sample above is pretty straightforward, but still begging for some code generation because of having boilerplate in it. It would be so nice to have delegation as a built-in language feature. In old Java world things like that does not exist, so is there any way to solve that problem differently? It is possible to use annotation processing to create a library for code generation or implement reflection to invoke methods dynamically. That sounds pretty scary, right? As a fan of Kotlin, I will show you how to delegate like a pro.

Kotlin

As I have already mentioned, there is a huge need of having delegation pattern implemented in language. Guess what! Kotlin has it❤.

Kotlin delegation mechanism squashes 30 lines of Java code in just 11. When I saw it for the first time it literally blew my mind. Kotlin makes it so clear and concise that there is no need for explanation. However, nothing is for free and there is no magic behind it. As an engineer, I always dig deeper to fully feed my appetite and see how things work internally.

The easiest way to understand how Delegates work is by using IntelliJ IDEA.

IntelliJ IDEA comes with bundled Kotlin decompiler so you can explore generated bytecode and translate it to Java. By doing it on our sample you are able to see such a beauty.

I intentionally deleted imports and metadata to improve readability, so now it can be seen that everything is generated and no dark magic is involved in Delegates.

And if that is not enough, Kotlin have the whole concept of Delegated Properties. If you are not familiar with it, you should read about it and start using as soon as possible.

Any piece of code that you’re forced to duplicate or that can be automatically generated by an IDE is a missing language abstraction feature. — (Mario Fusco)

If this was interesting to you, please do hit the heart button ❤ or let me know on Twitter.

Zero boilerplate delegation in Kotlin was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.