Technology Stack For Android Mobile Application in 2024

Android UI tools:

Android provides some ways to create UI for your applications:

Android pre-built tools

Android provides you with standard pre-built UI tools which you can use just to install the Android SDK package. This implies that you create UI using XML files, where you will declare how your application will look. SDK provides many UI classes like Button, TextView, and ConstraintLayout, which XML uses to describe application UI.

Android Jetpack Compose

Jetpack Compose is the new UI library made by Google, which uses the declarative method to build native UI. Unlike the pre-built way used XML, Jetpack Compose can be declared right in the code. To use Compose, you need to add dependencies, enable compose build feature, and describe the Kotlin compiler extension version in your build.gradle file just like described here. After that, you can use Jetpack Compose in your projects.

Material Design

Android pre-built UI tools and Jetpack Compose can cooperate with the Material Design library to use modern designed UI components. Here you can read more about Material Design and how to integrate it into your project.

Given the trend, Android Jetpack Compose has become more popular than XML in native UI building, but standard methods are still popular too. The mobile technology stack in Android includes not only UI tools, of course, but an application also needs network, storage, and dependency injection technologies for more easy management of dependencies in project code. Read about such elements of the mobile app technology stack below.

Dependency injection technologies in Android apps:

Android app tech stack is vast. It includes many dependency injection technologies that can help you as a developer using your classes more efficiently, and you do not need to manage dependencies between classes and their “parents” or “children”. In terms of creating new class objects, this protects you from memory leaks that can use more system resources than they should. In general, dependency injection gives you the advantages of reusability of code, ease of refactoring, and ease of testing. There are some modern dependency injection libraries in the Android app development stack. Let’s take a look.

Dagger Hilt

Dagger Hilt is one of the modern dependency injection libraries for Android applications. It is easier to learn for beginners. For example, you may hear about Dagger and Dagger 2 libraries. Maybe someone used it and knew how much boilerplate code you need to write into your project to provide dependencies. Hilt can help you with it. For example, if you want to use injection into your Activity or Fragment, you need to provide whatever you need with annotation @Provides and annotate Activity/Fragment with @AndroidEntryPoint annotation. After that, you can inject something with @Inject annotation. Sounds easy, doesn’t it? Here is an example:

You create some class. For example, it will be an Object class:

@Module
@InstallIn(value = [SingletoneComponent::class])
object TestObjectClass {	

	@Provides

	fun provideStableElectricity(electricity: Electricity) : StableElectricity {	

	return electricity.defend().stabilize().provide()

}

}

Here you can see the Hilt module, which provides a StableElectricity object for your project. After that, you can use it in your code, for example, in Activity or Fragment. To provide a singleton object, you need to annotate provide-function with @Singleton.

@AndroidEntryPoint

class YourCityActivity : AppCompatActivity() {

@Inject

lateinit var stableElectricity: StableElectricity


override onCreate(savedInstanceState: Bundle?) {

super.onCreate(savedInstanceState)

…

}

}

That is how you can use provided object with Hilt. Here you can see the Hilt-Dagger annotations cheat sheet, which can help you with the most usable annotations. For more information, see the official documentation.

Koin

This is the youngest DI framework that can be used in Android development. Koin gives you simple tools and API to let you build, assemble Kotlin-related technologies into your application, and scale your business with ease. Here is an example of how to create modules, start Koin, and inject dependencies:

1. Create module:

class MainApplication : Application()
{val myModule = module { 
singleOf(::MyPresenterr) 		
singleOf(::MyRepository)
}   	
	override fun onCreate() {         
		super.onCreate()       	
	startKoin {
		// Log Koin into Android logger 
		androidLogger()
		// Reference Android context
		androidContext(this@MainApplication)
		// Load modules
		modules(myModule)
		}
	}
}

2. Inject dependency:

class MyActivity : AppCompatActivity() {	
	val myObject : MyObject by inject()
}

That is all. Look’s like more simple than Hilt DI Framework! More information about Koin integration can see here. So, what must we use? If you want your application runtime performance to be better, you must use Dagger Hilt. Koin has a much smaller impact on our built time.

Network technologies in Android apps

Modern mobile applications need Internet access for many online features. For example, a user wants to buy something via your application, receive notifications, or upload some stuff. Android tech stack has different libraries that can help you to bring out your application to the Internet.

Ktor

Ktor includes a multiplatform asynchronous HTTP client, which allows you to make requests and handle responses, and extend its functionality with plugins, such as authentication, JSON serialization, and so on. Ktor is written 100% with Kotlin. Ktor is very easy to configure and use. If you want to launch the network in your project fast, you must choose this network library. One of the main advantages of Ktor is that it is not wired to anything Android-specific and is completely Kotlin-powered. This means that in the future, if you are planning to extend your android app into a multiplatform app, then you won't need to scratch your head on what to do with making network calls. Ktor will handle it. More information about Ktor integration you can find here.

Retrofit 2

Retrofit 2 is a type-safe HTTP client for Android and Java. Retrofit used in a wide range of Android applications, that have access to the network. You can say that Retrofit 2 is an old tool, that can be deprecated in the near future, let’s use something new libraries for Android networking. Don’t invent a bicycle, Retrofit 2 is a very popular and powerful network library that is used and will be used for a long time. So, if you want a reliable network client in your native project, you should use Retrofit 2, or combine it with OkHttp network library. How to use this library, you can see here.

OkHttp

OkHttp is a compelling library that can be combined with many other libraries and work nicely. Here you can see a list of them. OkHttp has written on Java and is still a trendy network library in the Android tech stack, so you can use it confidently. Here is an example of how to make a synchronous network call with OkHttp:

private val client = OkHttpClient()
	fun run(){    
		val request = Request.Builder()
			.url("https://publicobject.com/helloworld.txt")
			.build()
client.newCall(request).execute().use { response ->
	if (!response.isSuccessful) throw IOException("Unexpected code $response") 
	for ((name, value) in response.headers) {        
	println("$name: $value")      
	}     
	println(response.body!!.string())
	}  
}

Android local data storages: encrypted shared preferences and Room database

Let’s imagine that users don’t have an Internet connection. What will they do with your application? Nothing! What will users do with your application if they know it isn’t secured? Right, they just won’t download it and won’t use it. So what must we do with it? In the technology stack for mobile applications exists some local storage that can securely store user data like user settings. In Android, it calls Encrypted shared preferences.

Encrypted shared preferences

Encrypted shared preferences storage should be used if you want to store a manageable amount of data. To store a large amount of data, you should use a database, specifically Room. We’ll talk about it later. Android has two types of shared preferences:

• Shared preferences;
• Encrypted shared preferences.

What is the difference? It is clear from the name that shared preferences store data in the following form:

‍
<?xml version=’1.0’ encoding=’utf-8’ standalone=’yes’ ?>
<map>
<string name=”SOME_STRING”>string</string>
<map>

It’s not secure; you can easily see all data stored in shared preferences. For example, how it will look if you stored the same data in encrypted shared preferences:
<?xml version=’1.0’ encoding=’utf-8’ standalone=’yes’ ?>
<map>
 <string name="AVz2qCVxm1KudCCJKYuxuoaAXoPeWKjG0w==">ASnO9uni11t3m9sNgDJbiYllL/tE+i99TYKfQ0h8XV6AUN0O3rBxBsMmcpw2DCY</string>
 

Another matter. You can’t easily access the true name and value of this data field. It can be advantageous if your application is data-sensitivity. Note: the best experience in data-sensitivity applications is not storing sensitive information locally.

Room database

The Room database provides an abstraction layer over SQLite to allow fluent database access while harnessing the full power of SQLite.

The Room can be used with Kotlin coroutines, RxJava2/3, Guava, and Paging 3 library. The Room is essential if you want that your application can work in offline mode or to reduce network calls using data locally cached in the database. The main advantage of the Room database is that more easily to use and configure than the SQLite database. To use RoomDB you should do the following:

• create entity data class;
• define data access object (DAO) for manipulating data in the database;
• define the database and describe DAO for it.

The usage-ready RoomDB is next:

• retrieve database object -> val db = Room.databaseBuilder(applicationContext, YourDatabaseClassName::class.java, “Database name”);
• retreive database DAO -> val userDao = db.userDao();
• get all users from the database -> val userList = userDao.getAllUsers().

Looks very easy. So, what with SQLite creation, configuration, and usage? Full list of SQLite configuration tutorials you can find here, but to save your mental health, I recommend you to use RoomDB.

Conclusion

As you can see, in 2024 Android app development stack will be more advanced and will be grown and modernized. Something remains unchanged in terms of use, like OkHttp or Retrofit 2. These compelling things will be leaders in networking for Android for a long time.

What do Axon software developers recommend? Be careful with new libraries. Take your time using them in your large projects. If you want to use some new android stack in mobile application development, integrate it gradually in a test environment. For example, do not simultaneously rewrite all application screens to Android Jetpack Compose. Take one screen and do it in the test environment. It will be safer for project integrity.

Choose your best-fit mobile technology stack, and good luck!