DEV Community: Atlantis

Angular Performance Optimization: techniques and strategies

Atlantis — Sun, 16 Feb 2025 08:31:20 +0000

In modern web development, high performance is crucial for delivering a seamless user experience. Angular, with its comprehensive framework, provides numerous ways to optimize performance. However, optimizing an Angular app for production requires a deeper understanding of the framework's internals and the proper use of advanced techniques. This article will cover the most effective strategies to boost performance in Angular applications, complete with advanced code examples.

1. Change Detection Strategies

Default Change Detection

Angular’s default change detection mechanism re-evaluates the entire component tree when any change is detected. This can be resource-intensive, especially in large applications with numerous components.

To understand the problem, let’s consider the following example:

@Component({
  selector: 'app-parent',
  template: `
    <app-child [data]="parentData"></app-child>
  `
})
export class ParentComponent {
  parentData = { name: 'Soumaya', age: 33 };

  updateData() {
    this.parentData.age += 1;
  }
}

In the default strategy, Angular runs change detection on app-child every time any change happens in app-parent, regardless of whether the data passed to app-child has changed. This can lead to performance degradation.

Optimizing with `OnPush`

By using the OnPush change detection strategy, you can limit these checks. OnPush only runs change detection if the component’s inputs change by reference.

@Component({
  selector: 'app-child',
  templateUrl: './child.component.html',
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class ChildComponent {
  @Input() data: any;
}

However, OnPush comes with a caveat. When using complex objects or arrays as inputs, Angular doesn’t detect changes if you mutate the object without changing its reference. For example, this won't trigger change detection:

updateData() {
  this.parentData.age += 1; // Change detection won't run
}

Instead, you should return a new object:

updateData() {
  this.parentData = { ...this.parentData, age: this.parentData.age + 1 }; // Change detection triggers
}

Advanced Use: Manual Change Detection

For advanced cases where neither the default nor OnPush strategies are suitable, you can use manual change detection control with ChangeDetectorRef.

export class ChildComponent {
  constructor(private cdr: ChangeDetectorRef) {}

  manualCheck() {
    this.cdr.detectChanges(); // Trigger change detection manually
  }
}

This approach is useful when you have more granular control over when change detection should run, for example, in high-performance apps like gaming or real-time financial dashboards.

2. Angular Signals

Angular Signals offer a new paradigm for managing reactivity in Angular applications. Signals allow you to manually control how and when certain parts of your app should update, leading to better performance and more predictable UI updates.

Implementing Signals

With Signals, you can avoid change detection entirely in some cases by binding the state directly to the UI.

import { signal } from '@angular/core';

const counter = signal(0);

@Component({
  selector: 'app-counter',
  template: `
    <button (click)="increment()">Increment</button>
    <p>{{ counter() }}</p>
  `
})
export class CounterComponent {
  increment() {
    counter.set(counter() + 1);
  }
}

In this example, the counter() function updates only when the value changes, bypassing the need for traditional Angular change detection altogether. This leads to significant performance improvements in cases where you need ultra-responsive UIs.

Advanced Signals Use: Deriving State

You can also create derived signals that depend on other signals, allowing for more complex state management while maintaining high performance.

const firstName = signal('Soumaya');
const lastName = signal('Erradi');

const fullName = signal(() => `${firstName()} ${lastName()}`);

@Component({
  selector: 'app-name-display',
  template: `<p>{{ fullName() }}</p>`
})
export class NameDisplayComponent {
  updateFirstName(newName: string) {
    firstName.set(newName);
  }
}

Here, fullName is derived from firstName and lastName, but it only recalculates when one of those values changes, avoiding unnecessary recalculations.

3. Lazy Loading Standalone Components

Lazy loading is one of the most effective ways to reduce the initial load time of an Angular app by deferring the loading of certain components or modules until they are needed.

Lazy Loading Standalone Components with Dynamic Imports

While lazy loading is common with modules, Angular 14 introduced the ability to lazy load standalone components using dynamic imports.

const routes: Routes = [
  {
    path: 'lazy',
    loadComponent: () => import('./lazy/lazy.component').then(m => m.LazyComponent)
  }
];

This approach loads the LazyComponent only when the user navigates to the /lazy route. However, lazy loading can be further optimized by combining it with preloading strategies, ensuring that key components are loaded in the background when network bandwidth is available.

Preloading Strategy for Critical Components

In cases where you want to preload essential components without blocking the main thread, you can use Angular’s built-in preloading strategy:

@NgModule({
  imports: [RouterModule.forRoot(routes, { preloadingStrategy: PreloadAllModules })],
  exports: [RouterModule]
})
export class AppRoutingModule {}

This strategy ensures that critical components are loaded asynchronously, without affecting the user experience, thus optimizing performance for subsequent page loads.

4. Minimizing HTTP Requests

Reducing the number of HTTP requests is essential for optimizing network performance. Angular provides several built-in tools to help with caching, batching, and reducing redundant API calls.

Caching Strategy with Interceptors

One way to handle caching is by using an HTTP interceptor. This allows you to cache the results of HTTP requests and serve cached data when available, reducing the number of actual network calls.

@Injectable()
export class CacheInterceptor implements HttpInterceptor {
  private cache = new Map<string, any>();

  intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    if (req.method !== 'GET') {
      return next.handle(req); // Only cache GET requests
    }

    const cachedResponse = this.cache.get(req.url);
    if (cachedResponse) {
      return of(cachedResponse);
    }

    return next.handle(req).pipe(
      tap(event => {
        if (event instanceof HttpResponse) {
          this.cache.set(req.url, event);
        }
      })
    );
  }
}

This interceptor caches GET requests, serving them from memory for subsequent calls, drastically reducing HTTP traffic and improving app performance.

Debouncing and Throttling API Requests

In some cases, like search bars or infinite scrolling, you may want to limit the frequency of HTTP requests. You can use debounceTime or throttleTime from rxjs to accomplish this.

import { debounceTime, switchMap } from 'rxjs/operators';
import { Subject } from 'rxjs';

searchTerm$ = new Subject<string>();

this.searchTerm$.pipe(
  debounceTime(300), // Wait for 300ms of inactivity
  switchMap(term => this.http.get(`/api/search?query=${term}`))
).subscribe(results => {
  this.searchResults = results;
});

This implementation ensures that the search request is only triggered after the user stops typing for 300ms, reducing unnecessary API calls and improving network efficiency.

5. Server-Side Rendering (SSR)

Server-Side Rendering (SSR) is built directly into the framework, making it easier to boost performance and improve SEO by rendering pages on the server. This approach results in faster initial page loads, especially for content-heavy applications, and ensures that your app is more accessible to search engines.

Setting Up SSR

Here's how you can configure it:

Generate a new Angular application with SSR enabled:

   ng new angular-ssr-app --standalone --server

This command sets up a new Angular application with SSR pre-configured and ready to go.

Build and Serve the SSR Application:

After your app is set up, build it for SSR using:

   ng build --ssr

To serve the SSR version locally:

   npm run dev:ssr

This command runs your Angular app with server-side rendering, ensuring the server sends pre-rendered HTML to the browser for faster first paint and improved SEO.

Optimizing SSR for Performance

SSR can be further enhanced by applying advanced techniques such as route preloading, critical CSS inlining, and deferring non-essential scripts to improve the perceived performance.

Preload Critical Routes: Ensure that routes essential for user interaction are preloaded on the server, allowing users to interact with key sections of your app immediately.
Critical CSS Inlining: By inlining the CSS required for above-the-fold content, you reduce render-blocking resources, improving the perceived load time. This can be done as part of the SSR rendering process to include only the styles needed for the initial page.

Example: Preloading Key Routes and Lazy Loading Non-Essential Parts

const routes: Routes = [
  {
    path: 'home',
    component: HomeComponent,
    data: { preload: true }
  },
  {
    path: 'lazy',
    loadComponent: () => import('./lazy/lazy.component').then(m => m.LazyComponent)
  }
];

By preloading critical routes like the home page and lazy loading non-essential components, you can strike a balance between fast initial load times and optimized resource usage.

Advanced Server Caching for SSR

To optimize performance further, implement server-side caching for frequently requested pages. This allows your server to reuse pre-rendered HTML instead of regenerating it for every request, drastically reducing response times for users.

6. Code Optimization Techniques: AOT, Lazy evaluation and more

AOT Compilation

Ahead-of-Time (AOT) compilation is an Angular feature that pre-compiles templates during the build phase. This reduces the amount of work the browser needs to do at runtime, improving performance.

ng build --aot

AOT ensures that your application ships optimized and smaller JavaScript bundles to the client, making it one of the easiest ways to speed up your Angular app.

Advanced Code Splitting with Dynamic Imports

In some cases, you may want to split specific parts of your application into separate bundles to load them dynamically, reducing the size of the initial payload.

import('./heavy-module/heavy-module.component').then(m => m.HeavyModule);

This ensures that only when the component is needed does it get downloaded and executed.

Avoiding Expensive Template Operations

Angular templates are often where performance issues arise. Avoid heavy logic in templates and instead delegate complex calculations to the component class or use ngOnInit.

export class AppComponent {
  result: number;

  ngOnInit() {
    this.result = this.calculateComplexOperation();
  }

  calculateComplexOperation() {
    // Expensive operation here
    return ...;
  }
}

By pre-calculating data in the component class, you avoid recalculating it on every change detection cycle, significantly improving performance.

Conclusion

Angular provides a wealth of tools to optimize performance, but advanced techniques like Signals, manual change detection, SSR, and caching with interceptors can take your optimizations to the next level. Combining these strategies allows you to create fast, scalable, and highly performant Angular applications that provide a better user experience. Regularly monitor performance using tools like Chrome DevTools and Lighthouse to identify bottlenecks and ensure your optimizations are effective.

Binary classification with Machine Learning: Neural Networks for classifying Chihuahuas and Muffins

Atlantis — Wed, 15 Jan 2025 07:56:11 +0000

[Article by Elia Togni]

Introduction to Image Classification

Image Classification is one of the most fundamental and studied topics in the field of machine learning. It refers to the ability to understand and categorize an image as a whole under a specific label.

In image classification, the goal is to predict the class to which an input image belongs. While humans excel at this task, mimicking human perception is challenging for machines. Traditional computer vision techniques rely on local descriptors (algorithms or methods that capture information about the local appearance or features of specific regions in an image) to find similarities between images. However, advances in technology have shifted the focus toward Deep Learning, which automatically extracts representative features and patterns from images.

One of the most prominent tools in modern image classification is the Convolutional Neural Network (CNN), a specialized class of neural networks designed for visual data analysis. CNNs are characterized by their ability to apply the convolution operation to extract features from small portions of input images, making them ideal for tasks such as image recognition, object detection, and more.

Chihuahuas vs. Muffins

This article explores the challenge of binary classification, which involves predicting one of two possible outcomes. Specifically, the task is to classify images as either chihuahuas or muffins. While this might seem trivial for humans, it poses a unique challenge for machine learning models due to the visual similarities between the two categories.

We compare the performance of a Multi-Layer Neural Network (MLNN) and a Convolutional Neural Network (CNN), focusing on their suitability for image classification and their ability to generalize well to unseen data.

Dataset Overview

This project is based on the Chihuahua vs. Muffin dataset from Kaggle. The dataset consists of two folders, each containing images of the two classes—one for training and one for testing. After combining and inspecting these folders, the dataset was found to include:

3199 chihuahua images
2718 muffin images

Data Cleaning

A manual inspection of the dataset revealed several issues, such as mislabeled or irrelevant images. These images were classified into:

Correctly labeled chihuahua images
Incorrectly labeled images, such as muffins in the chihuahua folder
Unrelated images, such as drawings or entirely unrelated objects

Some examples of images removed include:

After cleaning, the dataset was restructured to ensure only relevant images for each class were included. Images containing both chihuahuas and muffins or completely unrelated content were discarded.

Addressing Data Imbalance

Classifiers perform best when the dataset is balanced. To assess balance, the Imbalance Ratio was calculated:

Imbalance Ratio ρ=Number of Instances in Majority ClassNumber of Instances in Minority Class\text{Imbalance Ratio } \rho = \frac{\text{Number of Instances in Majority Class}}{\text{Number of Instances in Minority Class}}

For this dataset, ρ=1.22\rho = 1.22, which is sufficiently close to 1, indicating no significant imbalance.

Preprocessing

Preprocessing Pipeline

The following steps were applied to preprocess the images:

Image Resizing: All images were resized to $128 \times 128$ to ensure uniform input dimensions.
Cropping and Padding: Large white borders were removed to help the model focus on relevant features. Zero-padding was used to maintain aspect ratios.
Normalization: Pixel values were scaled to $[0, 1]$ to improve convergence.
Data Augmentation: Techniques such as rotation, flipping, and brightness adjustments were used to increase dataset variability and reduce overfitting.
Segmentation: Simple Linear Iterative Clustering (SLIC) was employed to isolate key regions in the image, removing irrelevant details.

Dataset Variants

From the preprocessing steps, three dataset variants were created:

Original RGB Images
Augmented RGB Images
Segmented RGB Images

Models

Multi-Layer Neural Network (MLNN)

The MLNN model consists of fully connected dense layers, batch normalization, dropout, and activation functions. It was configured to test various architectures:

Code Implementation

from tensorflow.keras import layers, models, Input
from tensorflow.keras.optimizers import Adam
from tensorflow.keras.metrics import BinaryAccuracy, Precision, Recall, AUC

def MLNN_model(input_size, num_classes, hidden_layer_units, hidden_activation, 
                output_activation, dropout_perc, n_channels, loss, learning_rate=0.001):
    """
    Builds a Multi-Layer Neural Network (MLNN).
    """
    input_layer = Input(shape=(input_size[0], input_size[1], n_channels))
    flatten_layer = layers.Flatten()(input_layer)
    hidden_layer = layers.Rescaling(1./255)(flatten_layer)

    for units in hidden_layer_units:
        hidden_layer = layers.BatchNormalization()(hidden_layer)
        hidden_layer = layers.Activation(hidden_activation)(hidden_layer)
        hidden_layer = layers.Dropout(dropout_perc)(hidden_layer)
        hidden_layer = layers.Dense(units, activation=hidden_activation)(hidden_layer)

    output_layer = layers.Dense(1, activation=output_activation)(hidden_layer)
    model = models.Model(inputs=input_layer, outputs=output_layer)
    model.compile(optimizer=Adam(learning_rate=learning_rate), loss=loss, metrics=[BinaryAccuracy(), Precision(), Recall(), AUC()])

    return model

MLNN Training Summary

Convolutional Neural Network (CNN)

CNNs are designed to handle spatial data and are more effective for image classification. This baseline CNN includes convolutional layers, pooling layers, and a dense layer for classification.

Code Implementation

from tensorflow.keras import layers, models

def CNN_model(input_size=(128, 128), n_channels=3, conv_filters=[32, 64, 128], kernel_size=(3, 3),
              pool_size=(2, 2), dense_units=128, output_activation='sigmoid', loss='binary_crossentropy',
              learning_rate=0.001):
    """
    Builds a Convolutional Neural Network (CNN).
    """
    model = models.Sequential()
    model.add(layers.Rescaling(1./255, input_shape=(input_size[0], input_size[1], n_channels)))

    for filters in conv_filters:
        model.add(layers.Conv2D(filters, kernel_size, activation='relu'))
        model.add(layers.MaxPooling2D(pool_size))

    model.add(layers.Flatten())
    model.add(layers.Dense(dense_units, activation='relu'))
    model.add(layers.Dense(1, activation=output_activation))
    model.compile(optimizer=Adam(learning_rate=learning_rate), loss=loss, metrics=[BinaryAccuracy(), Precision(), Recall(), AUC()])

    return model

CNN Training Summary

TogNet

TogNet is a custom CNN designed to address overfitting. Dropout layers were added to improve generalization.

Code Implementation

from tensorflow.keras import layers, models

def TogNet_model(input_size=(128, 128), n_channels=3, conv_filters=[32, 64, 64], kernel_size=(3, 3),
                 pool_size=(2, 2), dense_units=128, hidden_activation='relu', output_activation='sigmoid',
                 loss='binary_crossentropy', learning_rate=0.001, dropout_rate=0.2):
    """
    Builds the TogNet CNN.
    """
    model = models.Sequential()
    model.add(layers.Rescaling(1./255, input_shape=(input_size[0], input_size[1], n_channels)))

    for filters in conv_filters:
        model.add(layers.Conv2D(filters, kernel_size, activation=hidden_activation))
        model.add(layers.MaxPooling2D(pool_size))
        model.add(layers.Dropout(dropout_rate))

    model.add(layers.Flatten())
    model.add(layers.Dense(dense_units, activation=hidden_activation))
    model.add(layers.Dropout(dropout_rate))
    model.add(layers.Dense(1, activation=output_activation))

    model.compile(optimizer=Adam(learning_rate=learning_rate), loss=loss, metrics=[BinaryAccuracy(), Precision(), Recall(), AUC()])

    return model

TogNet Training Summary

Results

Performance Metrics

Model	Dataset	Binary Accuracy	Precision	Recall	AUC
MLNN 512_256_128	RGB	80.38%	78.02%	80.08%	88.01%
	Augmented	82.92%	89.06%	80.95%	91.54%
CNN 32_64_128	RGB	92.88%	91.73%	95.48%	97.01%
	Augmented	93.61%	94.18%	92.27%	96.60%
TogNet	RGB	92.88%	92.45%	94.36%	97.37%
	Augmented	91.53%	89.40%	92.86%	97.03%

Comparative Visualizations

Loss and Accuracy Trends for TogNet

Metrics Comparisons for MLNN Variants

Conclusion

This study demonstrates that CNNs, particularly the custom TogNet architecture, outperform MLNNs in binary image classification. Data augmentation improved model performance, while segmentation showed mixed results. Future work will explore advanced architectures and larger datasets to further enhance classification accuracy.

All the code is available on GitHub.

Cross-Platform UI Development with Jetpack Compose Multiplatform

Atlantis — Sun, 15 Dec 2024 14:36:40 +0000

[Article by Matteo Somensi]

What is Compose Multiplatform?

Compose Multiplatform is a declarative UI toolkit designed to create native interfaces for multiple platforms, such as Android, iOS, Desktop, and Web, while sharing a significant portion of the codebase. You can think of it like digital LEGO blocks: build your bricks (UI components) once and reuse them to assemble different structures (applications).

Why Compose Multiplatform?

Accelerated Time-to-Market: Reusing code across platforms reduces development time, enabling you to focus on features.
Consistent UI: A single codebase ensures design consistency and a cohesive user experience.
Boosted Productivity: The learning curve is relatively gentle, especially if you're already familiar with Jetpack Compose.
Growing Community: Supported by Google and JetBrains, Compose Multiplatform has a thriving and growing ecosystem.

What Are We Building?

In this article, we'll create a simple application that:

Fetches data from a REST API: Retrieves content from an external service.
Uses a local database: Stores data locally for offline functionality.
Delivers a seamless UI: Built entirely with Compose Multiplatform.

Desktop	Android

The architecture we'll use

We’ll follow the Presentation-Domain-Data (PDD) architecture.

This architectural pattern clearly separates the concerns of our application into three distinct layers: Presentation, Domain, and Data. The Presentation layer handles the user interface, the Domain layer encapsulates the business logic, and the Data layer manages data access. By adhering to this pattern, we'll create a more maintainable and scalable application.

Here's a breakdown of each layer:

Presentation layer: This layer is responsible for the user interface and user interactions. In our case, this will be implemented using Compose Multiplatform.
Domain layer: This layer contains the core business logic of the application. It defines entities, use cases, and rules related to the domain.
Data layer: This layer handles data access, such as fetching data from a REST API or storing data in a local database.

By separating these concerns, we gain the following benefits:

Improved Maintainability: Changes in one layer are isolated from the others.
Better Scalability: The app can grow more easily to meet evolving requirements.
Easier Testing: Each layer can be tested independently.

Let's get started

First, let’s review the structure of a Compose Multiplatform (CMP) project. Unlike a typical Kotlin Multiplatform (KMP) project, the UI is also defined in the common module.

To create the project, use the JetBrains wizard since CMP project creation isn’t yet integrated into IntelliJ IDEA.

Structure of a Compose Multiplatform Project

A Compose Multiplatform (CMP) project typically has a well-defined structure to organize code and resources across different platforms. Here's a breakdown of the common directory structure:

Root directory:
- build.gradle.kts: The main build script for the project, defining modules, dependencies, and build configurations.
- gradle: Contains Gradle-specific files and scripts.
- settings.gradle.kts: Specifies the root project and includes subprojects.
- composeApp: Contains the common code shared across all platforms, including business logic, data models, and UI components that can be rendered on different platforms.
- commonMain: Contains the core business logic, data models, and platform-independent UI components.
- androidMain: Contains Android-specific implementations or overrides.
- iosMain: Contains iOS-specific implementations or overrides.
- desktopMain: Contains desktop-specific implementations or overrides.

Plugins and Dependencies

Plugins and libraries play a crucial role in Compose Multiplatform development. The libs.versions.toml file specifies the tools we’ll use:

Ktor: For network requests.
Room (SQLite): For local database storage.
Navigation Compose: For managing app navigation.
Kotlin Coroutines: For asynchronous operations.
Compose: To build the UI.
Coil: For fetching and displaying images from the network.
Kotlin Serialization: For JSON parsing.

Note: We’ll use the Marvel Comics API to fetch data, which requires API keys. For more information, visit Marvel Comics Developer Portal.

The build.gradle.kts file defines the project's build configurations, including the necessary plugins for compilation and external dependencies. Here, we'll find both dependencies shared across all platforms (like Ktor or Compose) and those specific to a particular platform (e.g., native Koin dependencies for Android or iOS).

plugins {
    alias(libs.plugins.kotlinMultiplatform)
    ...

    sourceSets {
        val desktopMain by getting

        androidMain.dependencies {
            implementation(compose.preview)
            ...

        commonMain.dependencies {
            implementation(compose.runtime)
            ...

        desktopMain.dependencies {
            implementation(compose.desktop.currentOs)
            ...

        nativeMain.dependencies {
            ...

        dependencies {
            ...
    }
    ...

The Domain Layer

The Domain Layer represents the core of the app, encapsulating the business logic and shared data models. Kotlin data classes are used to define these models concisely and safely.

To make future modularization easier, we organize features into distinct packages. For example, the Character feature will include a domain package housing the Character data class and the CharacterRepository, which bridges the Presentation layer with business logic.

The Presentation Layer

After defining the domain classes, we’ll build the user interface using the Model-View-Intent (MVI) pattern. In this pattern, the View is represented by a composable function, the Model is a ViewModel (a successful concept in Android that we're bringing into the multiplatform world).

Why MVI?

Unidirectional Data Flow: MVI promotes a unidirectional data flow, making it easier to reason about the application's state and handle side effects.
Testability: Separating concerns makes it easier to write unit tests for both the View and the ViewModel.
Scalability: As the application grows, MVI helps maintain a clear and organized architecture.

// CharacterListAction.kt

sealed interface CharacterListAction {
    data class OnSearchQueryChange(val query: String) : CharacterListAction
    data class OnCharacterClick(val character: Character) : CharacterListAction
    data class OnTabSelected(val index: Int) : CharacterListAction
}

// CharacterListState.kt

data class CharacterListState(
    val searchQuery: String = "",
    val searchResults: List<Character> = emptyList(),
    val favoriteCharacters: List<Character> = emptyList(),
    val isLoading: Boolean = true,
    val selectedTabIndex: Int = 0,
    val errorMessage: UiText? = null
)

// CharacterListViewModel.kt

class CharacterListViewModel(
    private val characterRepository: CharacterRepository
) : ViewModel() {

    private var cachedCharacters = emptyList<Character>()
    private var searchJob: Job? = null
    private var observeFavoriteJob: Job? = null

    private val _state = MutableStateFlow(CharacterListState())
    val state = _state
        .onStart {
            if (cachedCharacters.isEmpty()) {
                observeSearchQuery()
            }
            observeFavoriteCharacters()
        }
        .stateIn(
            viewModelScope,
            SharingStarted.WhileSubscribed(5000L),
            _state.value
        )

    fun onAction(action: CharacterListAction) {
        when (action) {
            is CharacterListAction.OnCharacterClick -> {

            }

            is CharacterListAction.OnSearchQueryChange -> {
                _state.update {
                    it.copy(searchQuery = action.query)
                }
            }

            is CharacterListAction.OnTabSelected -> {
                _state.update {
                    it.copy(selectedTabIndex = action.index)
                }
            }
        }
    }
    ...

// CharacterListScreen.kt

@Composable
fun CharacterListScreenRoot(
    viewModel: CharacterListViewModel = koinViewModel(),
    onCharacterClick: (Character) -> Unit,
) {
    val state by viewModel.state.collectAsStateWithLifecycle()

    CharacterListScreen(
        state = state,
        onAction = { action ->
            when (action) {
                is CharacterListAction.OnCharacterClick -> onCharacterClick(action.character)
                else -> Unit
            }
            viewModel.onAction(action)
        }
    )
}

The Data Layer

The Data Layer focuses on retrieving data from external sources and managing local storage. We implement a feature-specific repository as defined by the domain interface:

interface CharacterRepository {
    suspend fun searchCharacters(query: String): Result<List<Character>, DataError.Remote>
    suspend fun getCharacterDescription(characterId: String): Result<String?, DataError>

    fun getFavoriteCharacters(): Flow<List<Character>>
    fun isCharacterFavorite(id: String): Flow<Boolean>
    suspend fun markAsFavorite(character: Character): EmptyResult<DataError.Local>
    suspend fun deleteFromFavorites(id: String)
}

The implementation will abstract the retrieval of data from the network and the saving of the favorites list to a local database.

What is Ktor?

Ktor is a lightweight and flexible framework designed for creating connected applications in Kotlin. It’s ideal for building web services, HTTP clients, and other applications requiring efficient network communication. Since Ktor is built on Kotlin coroutines, it handles asynchronous operations seamlessly.

In our core package, we define an HTTP client factory using Ktor’s DSL to configure the client. This includes setting up the contentNegotiation responsible for parsing, customize timeouts, and add an interceptor for logging:

object HttpClientFactory {

    fun create(engine: HttpClientEngine): HttpClient {
        return HttpClient(engine) {
            install(ContentNegotiation) {
                json(
                    json = Json {
                        ignoreUnknownKeys = true
                    }
                )
            }
            install(HttpTimeout) {
                socketTimeoutMillis = 20_000L
                requestTimeoutMillis = 20_000L
            }
            install(Logging) {
                logger = object : Logger {
                    override fun log(message: String) {
                        println(message)
                    }
                }
                level = LogLevel.ALL
            }
            defaultRequest {
                contentType(ContentType.Application.Json)
            }
        }
    }
}

What is Koin?

Koin is a dependency injection (DI) framework specifically designed for Kotlin. It aims to be simple, lightweight, and easy to use, while still providing the benefits of DI, such as loose coupling, testability, and maintainability.

We use Koin to supply platform-specific implementations for the HttpClientEngine (OkHttp for Android/Desktop and Darwin for iOS) and inject dependencies like our repository and database:

//initKoin.kt in CommonMain

fun initKoin(config: KoinAppDeclaration? = null) {
    startKoin {
        config?.invoke(this)
        modules(sharedModule, platformModule)
    }
}

//Modulse.kt in CommonMain

expect val platformModule: Module

val sharedModule = module {
    single { HttpClientFactory.create(get()) }
    singleOf(::KtorRemoteCharacterDataSource).bind<RemoteCharacterDataSource>()
    singleOf(::DefaultCharacterRepository).bind<CharacterRepository>()

    single {
        get<DatabaseFactory>().create()
            .setDriver(BundledSQLiteDriver())
            .build()
    }
    single { get<FavoriteCharacterDatabase>().favoriteCharacterDao }

    viewModelOf(::CharacterListViewModel)
    viewModelOf(::CharacterDetailViewModel)
    viewModelOf(::SelectedCharacterViewModel)
}

//Modules.android.kt in AndroidMain

actual val platformModule: Module
    get() = module {
        single<HttpClientEngine> { OkHttp.create() }
        single { DatabaseFactory(androidApplication()) }
    }

What is Room?

Room is an abstraction layer over SQLite that simplifies database management in Android applications. It’s part of the Android Jetpack architecture components and offers features like type safety, compile-time verification, and ease of use.

Room generates boilerplate code at compile time based on your entity, DAO, and database definitions, letting you focus on higher-level logic.

expect/actual CharacterDatabaseConstructor Object

In a Compose Multiplatform project, certain functionalities, such as database creation, require platform-specific implementations. Kotlin's expect/actual mechanism facilitates this by allowing you to define a shared interface (expect) in the common module and provide corresponding platform-specific implementations (actual) in the target modules.

For instance, the CharacterDatabaseConstructor object is declared as expect in the shared module. Its responsibility is to create an instance of the database. Each target platform then provides its actual implementation.

On Android, the actual implementation uses Room's Room.databaseBuilder() to handle database creation efficiently.
For iOS or other platforms, the implementation might leverage an alternative database solution or use an in-memory database, particularly for testing purposes.

This approach ensures that the database creation logic is tailored to the specific requirements and constraints of each platform while maintaining a consistent interface in the shared module.

Abstract FavoriteCharacterDatabase

The FavoriteCharacterDatabase class is an abstract representation of the application's database, annotated with @Database. It specifies:

Entities: The data models that correspond to tables in the database.
DAOs: Data Access Objects that provide methods for interacting with the database.

By extending RoomDatabase, the class inherits Room's built-in functionalities for managing the database lifecycle and transactions. You define abstract methods in this class to access DAOs, and Room automatically generates the implementation for these methods at compile time.

DAO (Data Access Object)

DAOs, annotated with @Dao, are interfaces that define methods for accessing and modifying data in the database.
You use annotations like @Query, @Insert, @Update, and @Delete to define SQL queries that Room will execute. DAOs provide a convenient and type-safe way to interact with your database.

Taking the favorite characters database as an example, this database must be created using the platform-specific factory. We then specify the DAO for the relevant table, which is mapped to the CharacterEntity entity.

// CharacterEntity.kt in CommonMain

@Entity
data class CharacterEntity(
    @PrimaryKey(autoGenerate = false)
    val id: String,
    val name: String,
    val description: String,
    val imageUrl: String
)

// CharacterDatabaseConstructor.jt in CommonMain

@Suppress("NO_ACTUAL_FOR_EXPECT")
expect object CharacterDatabaseConstructor : RoomDatabaseConstructor<FavoriteCharacterDatabase> {
    override fun initialize(): FavoriteCharacterDatabase
}

// FavoriteCharacterDatabase.kt in CommonMain

@Database(
    entities = [CharacterEntity::class],
    version = 1
)
@TypeConverters(
    StringListTypeConverter::class
)
@ConstructedBy(CharacterDatabaseConstructor::class)
abstract class FavoriteCharacterDatabase: RoomDatabase() {
    abstract val favoriteCharacterDao: FavoriteCharacterDao

    companion object {
        const val DB_NAME = "marvel.db"
    }
}

// FavoriteCharacterDao.kt in CommonMain

@Dao
interface FavoriteCharacterDao {

    @Upsert
    suspend fun upsert(character: CharacterEntity)

    @Query("SELECT * FROM CharacterEntity")
    fun getFavoriteCharacters(): Flow<List<CharacterEntity>>

    @Query("SELECT * FROM CharacterEntity WHERE id = :id")
    suspend fun getFavoriteCharacter(id: String): CharacterEntity?

    @Query("DELETE FROM CharacterEntity WHERE id = :id")
    suspend fun deleteFavoriteCharacter(id: String)
}

// DatabaseFactory.kt in CommonMain

expect class DatabaseFactory {
    fun create(): RoomDatabase.Builder<FavoriteCharacterDatabase>
}


// DatabaseFactory.kt in AndroidMain

actual class DatabaseFactory(
    private val context: Context
) {
    actual fun create(): RoomDatabase.Builder<FavoriteCharacterDatabase> {
        val appContext = context.applicationContext
        val dbFile = appContext.getDatabasePath(FavoriteCharacterDatabase.DB_NAME)

        return Room.databaseBuilder(
            context = appContext,
            name = dbFile.absolutePath
        )
    }
}

To summarize, the CharacterRepository has a concrete implementation named DefaultCharacterRepository. Koin injects the RemoteDataSource (a specific implementation leveraging Ktor) and the FavoriteCharacterDao into this implementation, enabling it to fetch and update the list of favorite characters stored in the database. The DAO itself is also provided by Koin via dependency injection.

The App and The Navigation

The entry point for the application on each platform is their respective main functions.
However, all these functions do is utilize the root composable, which is defined in the Common Main module.
This root composable leverages the composables available in the Material library (which is continuously growing to include what already exists for the Android world).
The latest addition is navigation! It is now possible to use NavHost to define the routes within our application.

// App.kt in Common Main

@Composable
@Preview
fun App() {
    MaterialTheme {
        val navController = rememberNavController()
        NavHost(
            navController = navController, startDestination = Route.CharacterGraph
        ) {
            navigation<Route.CharacterGraph>(
                startDestination = Route.CharacterList
            ) {
                composable<Route.CharacterList>
                   ...
                }

                composable<Route.CharacterDetail
                >...
                }
            }
        }
    }
}
...


// main.kt in Desktop Main

fun main() = application {
    initKoin()
    Window(
        onCloseRequest = ::exitApplication,
        title = "Cmp Heroes",
    ) {
        App()
    }
}

For ease of use, the routes are defined with a sealed class.

// Route.kt in Common Main

sealed interface Route {

    @Serializable
    data object CharacterGraph: Route

    @Serializable
    data object CharacterList: Route

    @Serializable
    data class CharacterDetail(val id: String): Route
}

Conclusion

As demonstrated in this article, Compose Multiplatform provides developers with a powerful toolkit for building cross-platform applications using a shared codebase. By leveraging Kotlin's capabilities and the Compose UI framework, we have created an application where most of the logic, including UI and navigation, resides within the commonMain module.

The core functionality and user interface are implemented in a platform-agnostic manner, significantly reducing code duplication and lowering development time and cost. This allows developers to focus on building features rather than rewriting logic for each platform. Platform-specific folders contain only minimal code for tasks like database creation and the initialization of Koin for dependency injection, ensuring seamless integration with platform services.

This approach streamlines development while fostering a consistent and unified user experience across all platforms. By centralizing logic and UI in the shared module, Compose Multiplatform achieves high code reusability and maintainability, with platform-specific code limited to essential integrations.

Compose Multiplatform is a compelling solution for cross-platform development, enabling efficient code sharing while supporting platform-specific functionalities. As the ecosystem grows, it holds great promise for creating universal applications that are both efficient and adaptable.

Git Tricks You Should Know: Aliases, Bisect, and Hooks for Better Workflow

Atlantis — Fri, 15 Nov 2024 07:55:44 +0000

[Article by Paolo Tagliani]

Git is one of the fundamental tools we (developers) use every day and with which (at least for me), have a love-hate relationship.
Have you ever deleted all the changes you just made on a project due to a wrong git command? 🙋 I did it.

This article is a collection of useful git commands you should know that will improve your day-to-day life.
In this article we will explore three useful git features:

Git Alias
Git Bisect
Git Hooks

Let's start.

Git Alias: create your own git commands

Git aliases allow you to create custom shortcuts for frequently used or complex Git commands. They can significantly improve your workflow efficiency.

How to add

Add aliases to your Git config either through commands or by editing ~/.gitconfig:

# Command line setup
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status

Or in ~/.gitconfig:

[alias]
co = checkout
br = branch
ci = commit
st = status

Useful Aliases

1. Pretty Log Output

[alias]
lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short

Below is an example of the lg output using the lazygit repo:

Work in Progress

[alias]
# Quickly save work in progress
wip = "!git add -A && git commit -m 'WIP: Work in progress'"

# Undo last WIP commit
unwip = "!git log -n 1 | grep -q -c 'WIP' && git reset HEAD~1"

When you commit WIP, don't forget to edit your commits with git amend or include multiple commits into one using git rebase (maybe that's for the next article).

Git Bisect: blaming the commit that breaks everything

You pulled the latest version of develop into your branch, and things aren’t working as expected. How to identify which commit broke your functionality? Git Bisect to the rescue.

The concept is simple. You provide 2 commits: the initial bad and initial good.

Git divides the space between those commits in 2.
Takes the commit that divides the two halves and places your HEAD there. You test it and inform git if the bug is still there with git bisect good or git bisect bad.
Depending on the result, one of the two halves is marked as good, and the bad one is divided again in two.
The process repeats until there is only one commit left, which is the source of your error.

A practical example

Here I created a simple calculator library, where I added an error hidden in one of the commits.

I need to identify what was the commit breaking the current implementation. Git bisect is the right tool for this job.

Watch the following screencast to see git bisect in action. The bottom terminal shows tests running in watch mode, while the top shows the current list of commits:

Here what I did to bisect it:

I start bisecting with git bisect start
It needs the first good and bad commits: I indicated the first one 911bbde as good with git bisect good 911bbde. The bad one is the current HEAD, git bisect bad head.
The bisecting process starts and I just need to watch the tests and provide git bisect good/bad depending if the tests pass or not. Note that git will tell you how many steps in the process are remaining with roughly X steps.
After some passes, it correctly identifies that 64f1d0beb41fc03ae38c42b01fa2a0907cd236b7 is the first bad commit.

A deeper look

To help you visualize, here is how I mentally map the bisect process.

1. Identify good and bad (the boundaries)

2. Start bisecting in the middle of the interval

If the current one is good, it means that all the commits before are good.

3. Divide the bad interval and re-evaluate

4. Detect the bad commit

Git Hooks: customize git with scripting

Hooks are scripts that are executed on some events. Here are some common types of hooks:

Pre-commit Hook: Runs before a commit is created
Prepare-commit-msg Hook: Runs before the commit message editor is launched
Commit-msg Hook: Runs after the commit message is created
Pre-push Hook: Runs before a push is executed
Post-commit Hook: Runs after a commit is created

Why are those useful? They allow you to run ANY script before operating git commands, and can help streamline your workflow.

** Important Note: Remember that hooks are local by default - they need to be explicitly shared and set up on each developer's machine.

Useful examples

TODO checks

I often leave // TODO: comments in my code. I use them for everything: remembering to delete code, planning refactors, or noting implementation details that weren't core to the feature I was working on.
I don't want these TODOs to be committed to the main repository, so I created a git hook that will warn me.

Here is the hook:

#!/bin/sh
# Path: .git/hooks/pre-commit-todo

# Get all staged files
STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(js|jsx|ts|tsx|py|rb|php|go|java|cpp|h)$')

# Skip if no relevant files are staged
if [ -z "$STAGED_FILES" ]; then
exit 0
fi

# Function to check for TODOs
check_todos() {
local file="$1"
local todos=$(git show ":$file" | grep -n "TODO\|FIXME" || true)

if [ ! -z "$todos" ]; then
echo "⚠️ Found TODOs in $file:"
echo "$todos" | while IFS= read -r line; do
echo " Line $line"
done
return 1
fi
return 0
}

# Track if we found any TODOs
FOUND_TODOS=0

# Check each staged file
for file in $STAGED_FILES; do
if check_todos "$file"; then
continue
else
FOUND_TODOS=1
fi
done

if [ $FOUND_TODOS -eq 1 ]; then
echo "----------------------------------------"
echo "❌ Error: Found TODO comments in staged files"
echo "Options:"
echo "1. Remove or resolve the TODOs"
echo "2. Create an issue for each TODO"
echo "3. Use git commit --no-verify to bypass this check"
echo "----------------------------------------"
exit 1
fi

# Silent success - no output if no TODOs found
exit 0

And here is what git will tell me in case I have TODOs in my staged files:

⚠️ Found TODOs in src/components/Payment.js:
Line 45: // TODO: Implement payment validation
Line 67: // TODO: Add error handling for failed payments
⚠️ Found TODOs in src/utils/api.js:
Line 23: // FIXME: Need to handle token expiration
----------------------------------------
❌ Error: Found TODO comments in staged files
Options:
1. Remove or resolve the TODOs
2. Create an issue for each TODO
3. Use git commit --no-verify to bypass this check
----------------------------------------
[Error: Git commit aborted due to TODO comments]

Force conventional commits

I heavily use conventional commits, here's a git hook that forces me to have my commit messages formatted in that way:

#!/bin/sh
# .git/hooks/commit-msg

commit_msg_file=$1
commit_msg=$(cat $commit_msg_file)

# Enforce conventional commit format
if ! echo "$commit_msg" | grep -qE "^(feat|fix|docs|style|refactor|test|chore)(\(.+\))?: .+"; then
echo "❌ Error: Invalid commit message format"
echo "----------------------------------------"
echo "Your message: '$commit_msg'"
echo "Required format: <type>(<scope>): <description>"
echo "Valid types: feat|fix|docs|style|refactor|test|chore"
echo "Example: feat(user-auth): add password reset functionality"
echo "----------------------------------------"
exit 1
fi

Here's what I see when the commit message is not right:

❌ Error: Invalid commit message format
----------------------------------------
Your message: 'Added new login feature'
Required format: <type>(<scope>): <description>
Valid types: feat|fix|docs|style|refactor|test|chore
Example: feat(user-auth): add password reset functionality
----------------------------------------
[Error: Git commit aborted due to invalid commit message format]

Key Takeaways

Git aliases can significantly speed up your daily Git commands
Git bisect is a powerful tool for finding problematic commits
Git hooks help automate checks and maintain code quality
All these features can be customized to match your team's workflow

See you soon 👋

DEV Community: Atlantis

Angular Performance Optimization: techniques and strategies

1. Change Detection Strategies

Default Change Detection

Optimizing with OnPush

Advanced Use: Manual Change Detection

2. Angular Signals

Implementing Signals

Advanced Signals Use: Deriving State

3. Lazy Loading Standalone Components

Lazy Loading Standalone Components with Dynamic Imports

Preloading Strategy for Critical Components

4. Minimizing HTTP Requests

Caching Strategy with Interceptors

Debouncing and Throttling API Requests

5. Server-Side Rendering (SSR)

Setting Up SSR

Optimizing SSR for Performance

Example: Preloading Key Routes and Lazy Loading Non-Essential Parts

Advanced Server Caching for SSR

6. Code Optimization Techniques: AOT, Lazy evaluation and more

AOT Compilation

Advanced Code Splitting with Dynamic Imports

Avoiding Expensive Template Operations

Conclusion

Binary classification with Machine Learning: Neural Networks for classifying Chihuahuas and Muffins

Introduction to Image Classification

Chihuahuas vs. Muffins

Dataset Overview

Data Cleaning

Addressing Data Imbalance

Preprocessing

Preprocessing Pipeline

Dataset Variants

Models

Multi-Layer Neural Network (MLNN)

Code Implementation

MLNN Training Summary

Convolutional Neural Network (CNN)

Code Implementation

CNN Training Summary

TogNet

Code Implementation

TogNet Training Summary

Results

Performance Metrics

Comparative Visualizations

Loss and Accuracy Trends for TogNet

Metrics Comparisons for MLNN Variants

Conclusion

Cross-Platform UI Development with Jetpack Compose Multiplatform

What is Compose Multiplatform?

Why Compose Multiplatform?

What Are We Building?

The architecture we'll use

Let's get started

Structure of a Compose Multiplatform Project

Plugins and Dependencies

The Domain Layer

The Presentation Layer

Why MVI?

The Data Layer

What is Ktor?

What is Koin?

What is Room?

expect/actual CharacterDatabaseConstructor Object

Abstract FavoriteCharacterDatabase

DAO (Data Access Object)

The App and The Navigation

Conclusion

Git Tricks You Should Know: Aliases, Bisect, and Hooks for Better Workflow

Git Alias: create your own git commands

How to add

Useful Aliases

1. Pretty Log Output

Work in Progress

Git Bisect: blaming the commit that breaks everything

A practical example

A deeper look

1. Identify good and bad (the boundaries)

Optimizing with `OnPush`