Forem: Boris Ochieng

Navigating Mobile Development Platforms and Some Common Architecture Patterns

Boris Ochieng — Sat, 29 Jun 2024 15:48:24 +0000

Introduction

Over the years, computers have become increasingly smaller, leading to the widespread use of smartphones, which are among the smallest and most common computing devices. Smartphones run operating systems that support various applications, which need to be developed. This article discusses different mobile application development platforms, which are tools and environments used to create these applications.

Mobile Development Platforms

Android

Built by Google, Android is a mobile operating system based on a modified version of the Linux kernel and other open-source software, designed primarily for smartphones and tablets. Apps targeting Android are developed using various programming languages, including Java, a statically typed language used with XML views to render the UI. Kotlin, now the official programming language, is also statically typed and used with XML, though Jetpack Compose is the modern approach for UI development. C and C++ are used for high-performance applications like video games. Android Studio, combined with Gradle, is the primary IDE for building Android applications.
iOS

Developed by Apple, iOS is used for iPhone and iPad devices. Apps for iOS are built using Swift, the main programming language, with SwiftUI and UIKit for UI development. Xcode is the primary IDE used for iOS development.
React Native

React Native is an open-source UI framework based on the JavaScript library React, developed by Meta (formerly Facebook). It extends React principles to build native Android and iOS applications from a single codebase, making development cost-effective and efficient. The main programming languages used are JavaScript and TypeScript, with development tools including Visual Studio Code and Expo.
Flutter

Created by Google, Flutter is an open-source UI software development kit for building cross-platform applications from a single codebase. It supports Android, iOS, web, and desktop applications. Dart is the main programming language, and development tools include Android Studio and Visual Studio Code.
Xamarin

Developed by Microsoft, Xamarin is used for building cross-platform applications. The main programming languages are C# and the .NET framework. Development tools include Visual Studio Code and Xamarin Studio. Xamarin has been discontinued in favor of MAUI, which primarily uses the .NET framework for cross-platform development, with Visual Studio and Visual Studio Code as development platforms.
Ionic

Ionic is an open-source UI toolkit for building cross-platform mobile, web, and desktop applications using various JavaScript frameworks and libraries such as React, Angular, and Vue. The main programming languages are HTML, CSS, JavaScript, and/or TypeScript, with Visual Studio Code as the development environment.

Architecture Patterns

Architecture patterns generally split applications into loosely coupled layers, including aspects like data sources, state management, and data presentation. This separation of concerns helps create a more modular, testable, scalable, and maintainable codebase, improving the overall quality of the application.

Data Source

Many apps handle data, which could involve reading or writing data from external services like REST APIs or locally on the device.

State Management

State management involves handling the application's state, which describes the current status of the application at any given time. This can include user inputs, UI updates, data fetched from sources, or any information needed for the application to be responsive or dynamic.

Presentation

The presentation layer is responsible for displaying the user interface (UI) and handling user interactions. It is often designed to be separate from the business logic and data layers to ensure a clear separation of concerns.

Model-View-ViewModel (MVVM)

MVVM is an architecture pattern commonly used on Android and iOS with SwiftUI. It separates apps into three layers: Model (responsible for data management), View (the user interface), and ViewModel (which retrieves data from the Model and manages the state observed by the View).

Advantages

Promotes clear separation between UI, data, business logic, and presentation logic.
Easy to test, as business logic is independent of the View.
Useful when multiple Views share the same business logic.
Layers are separated, making code modifications easier.

Disadvantages

Can introduce complexity in small applications.
Not all development environments and frameworks support MVVM.
Requires more setup, increasing initial development time with boilerplate code.

Model-View-Intent (MVI)

MVI is mostly used in Android and focuses on unidirectional data flow. The Model represents the application's state. Each state change produces a new state rather than modifying the existing one. The View renders the UI based on the current state of the Model, and Intents are actions or events triggered by the user or system, processed by a central component called a "Reducer."

Advantages

Unidirectional data flow simplifies debugging and reduces bugs.
Immutability ensures that each state change creates a new state, avoiding issues with simultaneous state access/modification.
Separation of concerns makes the application easier to test and maintain.
The UI always reflects the current state consistently due to a single source of truth.

Disadvantages

Can introduce unnecessary complexity in simple applications.
Steep learning curve compared to other patterns.
Potential performance issues due to the creation of new state objects.

Clean Architecture

Clean Architecture splits the application into three layers: Presentation, Domain, and Data. The Presentation layer handles the UI and state management, the Domain layer contains entities or data models and Interactors or Use Cases that process data from the Data layer, and the Data layer is responsible for data fetching locally or remotely. It is commonly used in iOS and Android development.

Advantages

Each layer has a clear responsibility, making the code "cleaner" and easier to understand and maintain.
Easier to scale and maintain, designed for large projects.
Simplifies testing as different layers can be tested independently.

Disadvantages

New developers may find it challenging to grasp its concepts compared to MVVM or MVI.
Introduces complexity for small applications.
Requires a lot of boilerplate code, increasing initial development time.

Redux

Redux is popular among React Native developers and shares principles with MVI. It involves three main components: Store, Reducer, and Actions. The Store is the single source of truth for the application's state. Actions define changes to the state, and Reducers use the current state and action to create or return a new state, specifying how the state changes in response to an action.

Advantages

Predictable state management due to immutability.
A single store ensures consistency and simplifies state management.
Middleware support provides powerful ways to handle asynchronous actions and logging.

Disadvantages

Can lead to performance issues if implemented incorrectly in large applications.
Introduces a considerable amount of boilerplate code.

Business Logic Component (BLoC)

Used widely in Flutter, BLoC ensures a distinction between the UI layer and business logic. It involves three main components: Events (user interactions), State (the output of BLoC), and BLoC (where the business logic resides).

Advantages

Highly maintainable with isolated business logic that can be modified without affecting the UI layers.
Facilitates adding new features and scaling the application.
Business logic components can be reused in different parts of the application.

Disadvantages

Adds complexity to smaller projects.
Has a steep learning curve for new developers.

No development platform, tool, or architecture pattern is universally the best; the choice depends on project requirements.

I would like to conclude by sharing my recent journey with the HNG Internship. As a new participant with a Bachelor's Degree in Information Technology and over 12 months of experience working on solo projects, I am eager to collaborate with a team and gain insight into team dynamics. This opportunity excites me not only for the chance to enhance my skills but also to connect with fellow developers at HNG and learn from their experiences.

Room Database Auto Migration

Boris Ochieng — Tue, 19 Mar 2024 17:44:45 +0000

Introduction

Building offline-first Apps to enhance user experience during limited network connectivity is a common practice among developers. The Room Persistence Library, a part of the Android Architecture components, facilitates this by enabling local data storage. As the application scales, developers often encounter the need to fine-tune existing features or introduce new ones. When deploying these changes to end-users, it's crucial to preserve their existing on-device data. However, manual adjustments to the database schema can become cumbersome as the application evolves. This is where auto migration comes into play, automating the process and streamlining development workflows.

Setting up auto migration

To set up auto migration with Room, you'll first need to configure the Gradle Plugin to export the schema to a designated directory. In your project's top-level build.gradle file (/build.gradle.kts), declare the Room plugin and its version:

plugins {
id androidx.room' version '2.6.0' apply false
}

Then, in the app-level build.gradle file (/app/build.gradle.kts), apply the plugin and specify the directory where the schema will be exported:

plugins {
id 'androidx.room'
}
room {
schemaDirectory "$projectDir/schemas"
}

Ensure that the schema storage directory is located outside of your app directory. The $projectDir variable references the root directory of your project, and /schemas denotes the directory where the database file will be stored.

Next, set the exportSchema property to true within the @Database() annotation class. This step is essential as Room relies on the generated schema to execute migrations:

@Database( 
version = SampleDatabaseClass.LATEST_VERSION
entities = [Entity::class]
exportSchema = true
)
abstract class SampleDatabaseClass : RoomDatabase() {
companion object {
const val LATEST_VERSION = 1
}
...
}

After completing these steps, rebuild your project to export the current database schema history into a JSON file.

Performing auto migration

To declare an automated migration between two database versions, specify the existing version and the new version. For instance, if the previous version was 1, and after making changes, the version is updated to 2, you can declare this migration in the database class:

@Database( 
version = SampleDatabaseClass.LATEST_VERSION,
entities = [Entity::class],
exportSchema = true,
autoMigrations = [
AutoMigration (from = 1, to = 2)
]
)
abstract class SampleDatabaseClass : RoomDatabase() {
companion object {
const val LATEST_VERSION = 2
}
...
}

Rebuild your project to let Room handle the migration seamlessly. If further changes are made in subsequent versions, such as migrating from version 2 to 3, simply add the corresponding migration.

When you move to version 3 we will have to migrate from 2 to 3. We will simply add this to the class:

@Database( 
version = SampleDatabaseClass.LATEST_VERSION,
entities = [Entity::class],
exportSchema = true,
autoMigrations = [
AutoMigration (from = 1, to = 2),
AutoMigration (from = 2, to = 3)
]
)
abstract class SampleDatabaseClass : RoomDatabase() {
companion object {
const val LATEST_VERSION = 3
}
...
}

Auto Migration Specifications

In some cases, Room may require additional information to perform migrations, particularly when changes involve deleting or renaming tables or columns. For such scenarios, you can use AutoMigrationSpec to provide the necessary details.

For example, if you need to rename a table, you can define an AutoMigrationSpec class within your database class and annotate it accordingly:

@Database( 
version = SampleDatabaseClass.LATEST_VERSION,
entities = [Entity::class],
exportSchema = true,
autoMigrations = [
AutoMigration (from = 1,
 to = 2, 
 spec = SampleDatabaseClass.YourAutoMigration::class),

]
)
abstract class SampleDatabaseClass : RoomDatabase() {
companion object {
const val LATEST_VERSION = 3
}

@RenameTable(fromTableName = "old_name", toTableName = "new_name")
class SampleAutoMigration : AutoMigrationSpec { }
...
}

Conclusion

The implementation of auto migration in Room significantly simplifies the process of managing database schema changes, enhancing the overall developer experience. By automating migration tasks, developers can focus more on building and refining app features without the burden of manual data management.

References

See it in action

https://github.com/slowburn-404/NoteWave

View Binding in Android.

Boris Ochieng — Sun, 05 Feb 2023 15:54:28 +0000

On the 23rd of November 2020, Google announced that Kotlin Synthetics had been deprecated where the findViewById() method was used to find an existing view in your XML layout by it's android:id attribute. Enter View Binding.

If you're like me, you often have to go back to the official documentation and read on how to integrate this into your project. I wrote this article as a quick reference for future me and probably you😉.

Enable view binding.

In your tool window bar, switch to Project View and under Gradle Scripts, in the app module, select the build.gradle file and set the viewBinding to true as shown below:

android {
    ...
    buildFeatures {
        viewBinding = true
    }
}

Behind the scenes, a binding class is generated for all the XML layout files. Each binding class holds references to the root view and all views that possess an ID. The name of the binding class comes from the name of the XML file. The name is changed to a special format called Pascal case and the word "Binding" is added to the end.
Suppose you have a layout file named activity_main.xml;

<RelativeLayout ...>
  <TextView android:id="@+id/hello" />
</RelativeLayout>

The generated class will be named ActivityMainBinding with a TextView named hello.

Use view binding in activities.

In the MainActivity.kt file, add the following code or adjust accordingly:

private lateinit var binding: ActivityMainBinding

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    binding = ActivityMainBinding.inflate(layoutInflater)
    val view = binding.root
    setContentView(view)
}

You can use the binding class to access any of the views now.

//change the text to "Hello World"
binding.hello.text = "Hello World"
//do something when clicked
binding.hello.setOnClickListener {
   //do something
}

Use view binding in fragments.

Suppose you have a fragment named HelloWorld.kt with a layout file fragment_hello_world.xml. Add the following code or adjust accordingly:

private var _binding: FragmentHelloWorldBinding? = null
// This property is only valid between onCreateView and
// onDestroyView.
private val binding get() = _binding!!

override fun onCreateView(
    inflater: LayoutInflater,
    container: ViewGroup?,
    savedInstanceState: Bundle?
): View? {
    _binding = FragmentHelloWorldBinding.inflate(inflater, container, false)
    val view = binding.root
    return view
}

override fun onDestroyView() {
    super.onDestroyView()
    _binding = null
}

That's just about it, you can get an in depth look in the official documentation and a practical tutorial here.

Forem: Boris Ochieng

Navigating Mobile Development Platforms and Some Common Architecture Patterns

Introduction

Mobile Development Platforms

Android

iOS

React Native

Flutter

Xamarin

Ionic

Architecture Patterns

Data Source

State Management

Presentation

Model-View-ViewModel (MVVM)

Advantages

Disadvantages

Model-View-Intent (MVI)

Advantages

Disadvantages

Clean Architecture

Advantages

Disadvantages

Redux

Advantages

Disadvantages

Business Logic Component (BLoC)

Advantages

Disadvantages

Room Database Auto Migration

Introduction

Setting up auto migration

Performing auto migration

Auto Migration Specifications

Conclusion

References

See it in action

View Binding in Android.

Enable view binding.

Use view binding in activities.

Use view binding in fragments.