We are also preparing the next Kotlin Coroutines open workshop 🔥
*️⃣ We’d love to hear your thoughts and suggestions for this newsletter. Please share them with us by replying to this email 📩
Enjoy! ⏬
“In google I/O 2019 Android team released its Security Cryptographic library named Jetpack Security to ease developers in building secured applications.”
Secure Secrets 🔑 in Android using Jetpack Security (In-Depth) — Android Security-02 by Ali Azaz Alam👇
We are also preparing the next Kotlin Coroutines open workshop 🔥
*️⃣ We’d love to hear your thoughts and suggestions for this newsletter. Please share them with us by replying to this email 📩
Enjoy! ⏬
“In google I/O 2019 Android team released its Security Cryptographic library named Jetpack Security to ease developers in building secured applications.”
Secure Secrets 🔑 in Android using Jetpack Security (In-Depth) — Android Security-02 by Ali Azaz Alam👇
We are also preparing the next Kotlin Coroutines open workshop 🔥
*️⃣ We’d love to hear your thoughts and suggestions for this newsletter. Please share them with us by replying to this email 📩
Enjoy! ⏬
“In google I/O 2019 Android team released its Security Cryptographic library named Jetpack Security to ease developers in building secured applications.”
Secure Secrets 🔑 in Android using Jetpack Security (In-Depth) — Android Security-02 by Ali Azaz Alam👇
We are also preparing the next Kotlin Coroutines open workshop 🔥
*️⃣ We’d love to hear your thoughts and suggestions for this newsletter. Please share them with us by replying to this email 📩
Enjoy! ⏬
“In google I/O 2019 Android team released its Security Cryptographic library named Jetpack Security to ease developers in building secured applications.”
Secure Secrets 🔑 in Android using Jetpack Security (In-Depth) — Android Security-02 by Ali Azaz Alam👇
We are also preparing the next Kotlin Coroutines open workshop 🔥
*️⃣ We’d love to hear your thoughts and suggestions for this newsletter. Please share them with us by replying to this email 📩
Enjoy! ⏬
“In google I/O 2019 Android team released its Security Cryptographic library named Jetpack Security to ease developers in building secured applications.”
Secure Secrets 🔑 in Android using Jetpack Security (In-Depth) — Android Security-02 by Ali Azaz Alam👇
Secure Secrets 🔑 in Android using Jetpack Security (In-Depth) — Android Security-02
In google I/O 2019 Android team released its Security Cryptographic library named Jetpack Security to ease developers in building secured applications.
Are you ready for loads of great content? 🔥 If so, check out the shortcut below and keep reading 👇
⇢ Articles 👉 Consider factory functions instead of constructors 👉 Consider a primary constructor with named optional arguments 👉 How does suspension work in Kotlin coroutines? 👉 How to Secure Secrets 🔑 in Android — Android Security-01
⇢ New benefits for our workshops attendees! ⇢ Angular & Angular Essentials courses
Enjoy! ⏬
What factory functions are and why they are so important patterns for object creation ⚙️
Consider factory functions instead of constructors by Marcin Moskała 👇
Security is a key requirement while building an application that’s dealing with APIs, Tokens received from a server, Storing credentials in local DB, Sending secure data onto the network, and many other scenarios.
For a long time, I wanted to migrate Gradle files to Kotlin DSL, but I was always procrastinating. I finally put an end to it and I also implemented buildSrc. It’s really important to check dependencies and versions. Especially in applications with more than one module, we can prevent different dependency management in each module with the buildSrc module. Kotlin DSL 🤝 buildSrc
Let’s see, how we can do it?
What we will do in this article?
refactor settings.gradle to settings.gradle.kts,
create buildSrc package to project root directory,
change .gradle files to .kts file,
move versions and dependency strings to Kotlin files,
extract keys from build.gradle and movekey.properties file,
create product flavors and set configurations with Kotlin DSL.
The default project directory is like this:
1. Refactor settings.gradle to settings.gradle.kts
Rename settings.gradle file settings.gradle.kts and change a few code lines:
//before rootProject.name = "KotlinDSL-BuildSrcExample" include ':app'
// after rootProject.name = "KotlinDSL-BuildSrcExample" include(":app")
2. Create buildSrc package
Create “buildSrc” module to root project directory. And create build.gradle.kts file into it.
import org.gradle.kotlin.dsl.`kotlin-dsl`
plugins { `kotlin-dsl` }
repositories { mavenCentral() }
now rebuild project.
We have a buildSrc module. So, we can create Kotlin files in the module.
We will add Configs.kt,Versions.kt, Libraries.ktinto buildSrc/src//main/kotlin directory later.
3. refactor .gradle files to .kts file
We must change .gradle files to .gradle.kts. It’s the hardest part:
build.gradle(proje)
We use Kotlin in Gradle files. Let’s get the define Libraries.kt and Versions.kt Kotlin objects to buildSrc/src/main/kotlin
Hello Kotlin ✋
build.gradle(app module)
4. Move versions and dependency strings to Kotlin files
Now, we move out from defaultConfig to Configs.kt for app configs.
5. Extract keys from Gradle files (key.properties)
For more reliable codes, we must extract keys from Gradle and move another file like key.properties:
create key.properties file in the root project directory,
store keys (like signing keys) in this file,
create a helper class for getting the value of a key.
manifestPlaceholders( mapOf( "appIcon" to "@mipmap/ic_launcher_prod", "appIconRound" to "@mipmap/ic_launcher_prod_round" ) ) resValue("string", "app_name", "KotlinDslExample$versionNameSuffix") buildConfigField("String", "ONESIGNAL_APP_ID", KeyHelper.KEY_ONESIGNAL_APP_ID_DEV) }
In my case, besides the completely changed values, the change in base url was only in the extension part. And I handled it in the applicationVariants.all block.
And that’s all. I know it took a while, but I wanted to touch on the details. If you find any wrong info please leave a comment. I will fix it.
Share your Gradle configuration with the Gradle Kotlin DSL — A guide for Android projects
This guide will help you to convert your Gradle build scripts from Groovy to Kotlin, allowing you to take advantage of some great benefits! These include:
Shareable Gradle configuration, minimizing the amount of duplicate code across your module build scripts
Shared dependency notation and versioning, making tasks like bumping dependency versions a breeze
Improved IDE support, enhancing features such as autocompletion, navigation to source, quick documentation, etc.
Step 1 – The buildSrc module
First, we will create a new directory at the root of our project named buildSrc. This is where all of our shared Gradle configuration, dependencies, versioning, etc. will live.
To make this directory a module we create a Kotlin build script at the root, so that the file path is {your_project}/buildSrc/build.gradle.kts
You should ensure that the versions used for com.android.tools.build:gradle and org.jetbrains.kotlin:kotlin-gradle-plugin match what you already have specified in your project build script ({your_project}/build.gradle) rather than using the versions in this example.
It’s also important to note the comments added to this file, it isn’t possible to utilise the shared versioning here so these dependencies will need to be updated manually.
Step 2 – Shared dependencies & versioning
It’s time to create the objects that will store our dependency notation and versioning, the process of moving all of your dependencies to these shared objects can be a bit painful depending on the number of dependencies your app uses.
Let’s start by creating the object that will hold our dependency notation. This should be created at {your_project}/buildSrc/src/main/kotlin/Dependencies.kt. I recommend going through your :app module’s build.gradle and copying any dependencies from there as a starting point.
I find it useful to group dependencies in nested objects as it increases readability, though you may structure this however you like. We can also group dependencies that are commonly included together using DependencyHandlerScope (you’ll see this in use later).
Now, let’s create the object that will house all of our versioning, create it alongside Dependencies at {your_project}/buildSrc/src/main/kotlin/Versions.kt.
As you can see, we’ve added all versions required by our dependencies, along with some versioning specific to our app in the nested App object.
I find it useful to also create a Modules object for storing module paths and a Plugins object for storing plugin identifiers to share even more values across build scripts!
Step 3 – Converting app module build script to Kotlin
The steepest learning curve with the Gradle Kotlin DSL is the syntax. Below is an example Kotlin build script for the :app module which covers some common configuration, along with using our previously created Dependencies, Versions, Modules, and Plugins objects. If you have some complicated configuration that you’re struggling to convert, there are some links at the bottom of this guide to documentation that may help.
In my opinion, this is the greatest benefit of using the Gradle Kotlin DSL, the ability to easily share build script configuration across modules. First, let’s create a script that contains our shared configuration.
Now you can go through each of your module build scripts and convert them to Kotlin, all whilst moving any dependencies, module paths, plugin identifiers, and versioning to the objects we created in step 2 so that they can be shared; allowing for easy alterations/updates in the future.
Step 5 – Converting project build script and settings.gradle to Kotlin
The final step is to convert your top-level (project) build.gradle and settings.gradle to Kotlin. This should be fairly straightforward as they won’t contain many configurations.
That’s it! 🎉 I hope this guide was useful and that you enjoy your new Gradle setup. All example code shown can be viewed in the example project linked below 🙂
Let’s start by explaining the context of our story.
Mob-programming
My colleagues Sarah and Peter and I were doing a session of Mob programming.
The goal was to solve the kata of The observed PIN, where an unreliable spy tells that he saw the PIN 1357 being used. But actually, he’s not quite sure. Each digit could be one of its neighbors on the keyboard layout. So, the actual PIN could be 1357, but also for example 2357 or 1368.
The project was a Java project built with Maven. It contains two files: PinGuesser.java and PinGuesserTest.java. It compiles and runs the unit tests in a matter of seconds, not minutes, like in many Android apps. That makes for a better developer experience IMHO.
We were doing well and have solved the Kata in Java, then refactored it to a satisfactory state.
Sarah: Is there anything else we could improve?
Peter: I don’t know, looks good to me.
Me: Well, we have 20 minutes left, why not rewriting the whole thing in Kotlin?
Sarah: Oh, I’ve heard about Kotlin but haven’t had the chance to use it yet. 20 minutes though, do you think we can do it?
Me: Let’s get started and see where it leads us!
Tools > Kotlin > Configure Kotlin in project
Peter: Ok, so I have never done any Kotlin in my life, tell me what to do.
Me: There is a command IntelliJ called Convert Java File to Kotlin File. It’s a great starting point!
Peter: Let’s give it a try.
Peter: IntelliJ tells me that Kotlin is not configured, that makes sense. How do I configure Kotlin in Maven?
Me: I don’t know, I’ve always used Gradle. Just let IntelliJ do it! By the way, what it will do is the same thing as Tools > Kotlin > Configure Kotlin in project.
Peter: Let’s do it…. It seems to have worked. There are updates to the file pom.xml.
Me: Before we try the Java to Kotlin converter, there is something we want to take care of. As you know, Kotlin has integrated nullability in the type system while Java by default has not. Therefore, the converter is going to allow nulls everywhere, which is technically correct but not what you want.
Sarah: But there are annotations in Java to say if something is nullable or not, right?
Me: Exactly! And the one we want is to tell by default everything is non-null. Conveniently, it’s exactly how it works in Kotlin too.
PinGuesserTest: Convert Java File to Kotlin File and manual fixes
Sarah: So I open PinGuesserTest.java and run the command. How is it called?
Peter: Convert Java File to Kotlin File .
Sarah: Let’s go! … I now have a PinGuesserTest.kt . It has some errors though.
Peter: Maybe apply the suggestion to optimize imports?
Sarah: Ok… It worked.
Me: As you see it’s not perfect, but it’s an awesome learning tool: you start with what you already know (in Java) and see it converted in what you want to learn (in Kotlin).
Sarah: Let me run the unit tests… I have some weird JUnit errors.
Me: Ok, so I understand that. Java has static methods while Kotlin has the concept of a companion object { … }. Its methods look like static methods but are a bit different. Here JUnit really wants static methods, and we need an annotation to make it happy.
Me: It’s possible to create List, Set and Map the traditional Java way, but the Kotlin standard library contains plenty of small utilities to streamline that, that would be my first change. Let me do it:
Me: That looks better. Are the unit tests still green?
Me: Something else contained in the Kotlin Standard Library are functions found in the functional programming languages like .map(), .filter(), .flatmap() and much more.
Sarah: A bit like the Java Stream API that we are using?
Me: Yes, like this but less verbose and more performant under the hood.
Me: Look, we have this PinGuesser class, but what is it doing exactly? It’s doing nothing, it’s a dumb namespace. It’s a noun that prevents us for accessing directly the verbs who are doing the real work. One of my favorite programming language of all time is Execution in the kingdom of nouns by Steve Yegge.
Sarah: I know that rant, pure genius ! So, how do we free up the verbs/functions?
Me: We remove the class and use top-level functions.
Peter: Can we go a step back? What does it bring us to make the code nicer like this? At the end of the day, the customer doesn’t care.
Me: Well, I don’t know you, but I often don’t really understand the code I’m supposed to work on. I tend to work hard to simplify it and, at some point, it fits in my head and the solution becomes obvious.
Peter: What would it look like here?
Me: Now that the code is in a nice functional idiomatic Kotlin, I realize that the program can be solved using a single functional construct: List.fold().
