Understanding Gradle is mandatory if you want to build good Android apps

Bare Minimum

This is the bare minimum you need to be able to compile and run an Android application:

plugins {
    id 'com.android.application'
    id 'kotlin-android'
}

android {
    compileSdk 30

    defaultConfig {
        applicationId "de.creatronix.myapplication"
        minSdk 21
    }
    
}

dependencies {
    implementation 'androidx.core:core-ktx:1.6.0'
}

Let’s dissect the parts

Plugins

Plugins are programs which extend the gradle build process

When you need special feature like annotation processing the Plugin goes here

What is kapt?

Android

In this section you define for which specific android version you are developing:

minSdk means that your app isn’t supported on devices with an API level below.

targetSdk is the preferred Android version you like to run on

You can add buildTypes section to distinguish between release and debug builds.

In the release build you can e.g. enable the minification

How to enable R8 in your build process

What is ProGuard?

How to fix android.view.InflateException: Error inflating class fragment

Depencencies

Dependencies come in many flavors:

implementation

These are dependencies which are needed to run the application

Until gradle 7.0 these dependencies were called “compile”. Now they are deprecated, so use implementation

testImplementation

The dependency is only available in the test source set.

androidTestImplementation

The dependency is only available in the androidTest source set.

The post Anatomy of a Gradle file appeared first on Creatronix.

Motivation

There are a lot of reasons to use Dependency Injection, or even a Framework for it.

In this Article you’ll learn what Dependency Injection is, what benefits and downsides it has and how to use it with the usage of the Koin Framework.

Let’s look at a example of a House with a Doorbell to better understand what dependency injection is.

The House class has a function that returns a String representing the current Ringtone according to the installed doorbell.

Without Dependency Injection:

class House() {
    private val myDoorbell: Doorbell
   
   init {
       myDoorbell = SpeakingDoorbell()
   }
   
   fun ringDoorbell(): String {
       return "Current ringtone " + myDoorbell.getRingtone()
   }
}

fun main() {
    val myHouse = House()
   
    println(myHouse.ringDoorbell())
}

With Dependency Injection:

class House(private val myDoorbell: Doorbell) {
   fun ringDoorbell(): String {
       return "Current ringtone " + myDoorbell.getRingtone()
   }
}

fun main() {
    val myDoorbell: Doorbell = SpeakingDoorbell()
    val myHouse = House(myDoorbell)
   
    println(myHouse.ringDoorbell())
}

As you can see in the variant without Dependency Injection the House class has a direct dependency to the SpeakingDoorbell class.

With Dependency Injection this reference no longer exists. The only reference
remaining is to the generalized Doorbell Interface.

Benefits of Dependency Injection

Flexibility

Lets suppose another class FunnyDoorbell should be used in the future, which also implements the Doorbell interface.

Exchanging the SpeakingDoorbell class later on is less work with Dependency Injection.

In the first example the House class would have to change its implementation to switch to the FunnyDoorbell class.

But with Dependency Injection this change can be done without touching the House class.

In fact the House class does not even know whether it got an instance of SpeakingDoorbell or FunnyDoorbell.

This allows to write more flexible code which can be modified and extended easier.

A looser coupling between classes is achieved.

Testability

When writing tests one cannot test the House class in the first example in isolation to the SpeakingDoorbell class.

With Dependency Injection it’s very easy to insert mocks instead of the real instance.

Downsides of Dependency Injection

There is one part that got more complex though. The main function now knows not only the House class, but also the SpeakingDoorbell class.

This ultimately leads to a really big main function, that knows almost every component.

In this small example this is no issue, but when developing large applications we want the benefits of Dependency Injection, but as few downsides as possible.

This is exactly where Dependency Injection Frameworks comes into play!

They help to structure the whole block how and when to instantiate which classes and usually bring with them a bunch of useful features.

So let us look into the Dependency Injection Framework Koin.

Setting up Koin

Gradle

Add the following to your gradle configuration.
Get the latest Koin version [here](https://insert-koin.io/docs/setup/v3).

// Add Maven Central to your repositories if needed
repositories {
    mavenCentral()    
}
dependencies {
    // Koin for Android
    implementation "io.insert-koin:koin-android:$koin_version"
}

Application

Create an application class if you have none yet (don’t forget to add it to the manifest).

class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()
     
        startKoin {
            androidContext(this@MyApplication)
            modules(
                module {
                    single { House(get()) }
                    single<Doorbell> { SpeakingDoorbell() }
                }
            )
        }
    } 
}

Profit

That’s it! This is the basic Koin setup. As you can see the House class now even fetches its needed instance of Doorbell.
Simply call startKoin, configure the AndroidContext and define some Beans. These can also be injected like this into Android components like activities:

val myVariable: MyVariableType by inject()

ViewModel injection

The avid reader might already have noticed something. “What about our ViewModels. They have a lifecycle and should not get created just like that”.

To fix this issue there exists an extension for Koin.

Instead of declaring a Bean like that

single { MyClass() }

we use

viewModel<MyViewModelType> { MyViewModel() }

The injection is then done inside the fragment like that:

val myViewModel: MyViewModelType by viewModel()

Conclusion

Using Dependency Injection, especially with a framework, can be intimidating for a new programmer.

But in the most cases the positive aspects outweigh the negatives and the complexity of setting up a dependency
injection framework is quite low.

There are a lot of other things Koin can do like defining factories instead of singles, directly helping out with tests, instantiating fragments, or much more.

Have a glance at the official documentation

The post Dependency Injection with Koin and Kotlin in Android appeared first on Creatronix.

E/AndroidRuntime: FATAL EXCEPTION: main
Process: de.creatronix.levelup, PID: 17026
java.lang.RuntimeException: Unable to start activity ComponentInfo{de.creatronix.levelup/de.creatronix.levelup.MainActivity}: android.view.InflateException: Binary XML file line #18: Error inflating class fragment

after enabling minification in my build.

The issue is that with the usage of safeargs with custom objects we use the the @parcelize annotation which seems to be optimized away with R8

Fix

Add

-keepnames class * extends android.os.Parcelable

to your proguard-rules.pro file

The post How to fix android.view.InflateException: Error inflating class fragment appeared first on Creatronix.

dependencies {
    implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.4.0'

ViewModel class and LiveData

class PracticeProgressViewModel : ViewModel() {
    
    private val _text = MutableLiveData<String>().apply {
        value = ""
    }

    val text: MutableLiveData<String> = _text

    fun setText(value: String){
        _text.value = value
    }
}

Fragment

class PracticeProgressFragment : Fragment() {

    private val homeViewModel: PracticeProgressViewModel by activityViewModels()

Observer Pattern

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View? {

        homeViewModel.text.observe(viewLifecycleOwner, {
            textView.text = it
        })

Update the ViewModel

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        val button = binding.button
        button.setOnClickListener(View.OnClickListener {
        
            val totalAmoint = practiceDao.getTotalAmount()
            homeViewModel.setText(totalAmoint.toString())
        })
    }

The post How to use ViewModel in Android appeared first on Creatronix.

Stetho is a sophisticated debug bridge for Android applications. When enabled, developers have access to the Chrome Developer Tools feature natively part of the Chrome desktop browser. Developers can also choose to enable the optional dumpapp tool which offers a powerful command-line interface to application internals.

Gradle

implementation 'com.facebook.stetho:stetho:1.6.0'

Initialization

class PracticeTrackerApplication : Application() {

    override fun onCreate() {
        super.onCreate()
        Stetho.initializeWithDefaults(this)
    }

Chrome DevTools

chrome://inspect/#devices

The post Stetho – A debug bridge for Android applications appeared first on Creatronix.

Why do I need it?

tl;dr; every time you use an annotation in a Kotlin file you need to use kapt.

E.g. @Parcelize  in Pass custom objects via SafeArgs

Prerequisites

dependencies {
    kapt("groupId:artifactId:version")
}

plugins {
    kotlin("kapt") version "1.5.31"
}

Further reading

https://kotlinlang.org/docs/kapt.html

The post What is kapt? appeared first on Creatronix.

• Up to Marshmallow / 6,0 the build system was based on GNU Make
• In Nougat / 7.0 and later, the build is run by ninja
• Ninja works from a pre-processed manifest generated by kati and soong

kati

kati converts Android.mk files into ninja manifests

soong

soong converts blueprint files (Android.bp) into ninja manifests

Example bp file

https://android.googlesource.com/platform/system/core/+/refs/tags/android-11.0.0_r46/logcat/Android.bp

Further reading

https://ninja-build.org/

The post What is Ninja? appeared first on Creatronix.

Room is an ORM which runs on Android and persists its data into an sqlite database.

Gradle

Room makes use of the kotlin annotation processing tool KAPT. So we need to apply the plugin:

plugins {
    ...
    id 'kotlin-kapt'
}

These are the dependencies we need to use room and kapt:

    implementation "androidx.room:room-runtime:2.3.0"
    kapt "androidx.room:room-compiler:2.3.0"

    // optional - Kotlin Extensions and Coroutines support for Room
    implementation "androidx.room:room-ktx:2.3.0"

Entity class

an entity class represents the entry which is persisted in the database

import androidx.room.ColumnInfo
import androidx.room.Entity
import androidx.room.PrimaryKey

@Entity(tableName = "practice_session")
data class PracticeSession(
    @PrimaryKey(autoGenerate = true) val uid: Int = 0,
    @ColumnInfo(name = "start_time") val startTime: Long,
    @ColumnInfo(name = "stop_time") val stopTime: Long
)

DAO

DAO is short for data access object

import androidx.room.Dao
import androidx.room.Insert
import androidx.room.Query

@Dao
interface PracticeDao {
    @Query("SELECT * FROM practice_session")
    fun getAll(): List<PracticeSession>

    @Insert
    fun insert(drink: PracticeSession)
}

RoomDatabase

@Database(entities = [PracticeSession::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun practiceDao(): PracticeDao

    companion object {
        // Singleton prevents multiple instances of database opening at the
        // same time.
        @Volatile
        private var INSTANCE: AppDatabase? = null

        fun getDatabase(context: Context): AppDatabase {
            // if the INSTANCE is not null, then return it,
            // if it is, then create the database
            return INSTANCE ?: synchronized(this) {
                val instance = Room.databaseBuilder(
                    context.applicationContext,
                    AppDatabase::class.java,
                    "practice_session"
                ).allowMainThreadQueries().build()
                INSTANCE = instance
                // return instance
                instance
            }
        }
    }
}

Own application class

tbd

Hint: Database Inspector is now called App Inspection

Hint 2: just works with API Level >= 26

Hint 3 Action -> Navigate to database folder

https://developer.android.com/codelabs/basic-android-kotlin-training-intro-room-flow#0

The post Dababase Stuff with Room appeared first on Creatronix.

https://developer.android.com/reference/android/os/StrictMode

The post How can you use StrictMode in your Android app? appeared first on Creatronix.

val mImageView = findViewById<ImageView>(R.id.img_view) 
mImageView.setOnClickListener(View.OnClickListener

This has worked properly over the last years but what are the drawbacks?

Or what are the promises of the new View Binding concept?

• View Binding is always null-safe and type-safe
• It compiles faster

Gradle

Enable View Binding in gradle:

android { 
    ... 
    buildFeatures { 
        viewBinding true 
    } 
}

Implementation

In your Fragment or Activity you need to instantiate the View Binding class for your layout:

private var _binding: YourFragmentBinding? = null
// This property is only valid between onCreateView and
// onDestroyView.
private val binding get() = _binding!!
_binding = YourFragmentBinding.inflate(inflater, container, false)

Now you can use it as follows:

binding.imgView.setOnClickListener { ... }

Instead of searching via findViewById ViewBinding generates properties which you can access directly.

Further Reading

https://medium.com/androiddevelopers/use-view-binding-to-replace-findviewbyid-c83942471fc

The post Replace findViewById with View Binding appeared first on Creatronix.