Une évolution majeure : Swift arrive officiellement sur Android

Officiel — Mars 2026

Le monde du développement évolue vite, et certains changements passent parfois inaperçus. Swift 6.3, publié fin mars 2026, introduit le premier SDK officiel de Swift pour Android. Ce n'est plus une initiative communautaire ou un prototype : c'est une release stable, portée par le Swift Android Workgroup.

Ce que ça permet concrètementÉcrire de la logique métier en Swift, la compiler pour iOS et Android, et l'intégrer côté Android via une interopérabilité avec Kotlin/Java (JNI) grâce aux outils Swift Java et Swift Java JNI Core. Swift compile directement en code machine natif sur Android, avec des performances comparables au code C/C++ natif.

Des applications Swift sur Android existent déjà en production depuis des années — Spark (client mail), flowkey (piano interactif) ou MediQuo (santé) — cumulant des millions de téléchargements. La nouveauté, c'est que cette voie est désormais officiellement supportée et documentée.

Une nouvelle architecture devient possible

Avec cette évolution, un modèle intéressant émerge :

• Une logique métier partagée écrite en Swift

• Une interface iOS en SwiftUI

• Une interface Android en Jetpack Compose

On ne cherche plus à partager toute l'application, mais à partager ce qui a du sens : la logique.

Swift reste distinct de Kotlin pour les UI natives — et ce n'est pas un problème. C'est même le point : chaque plateforme garde son identité visuelle, pendant que la complexité métier est mutualisée.

Du côté de Google : KMP est désormais stable

Stable depuis 2025

Cette dynamique ne vient pas uniquement de l'écosystème Apple. À Google I/O et KotlinConf 2025, Google a annoncé que plusieurs bibliothèques Jetpack sont désormais officiellement stables pour Kotlin Multiplatform (KMP) :

• Room 2.8.3 — support KMP stable (octobre 2025)

• DataStore 1.1.x — support KMP stable

• ViewModel, SavedState, Paging — également ajoutés

Il ne s'agit plus d'expérimental : Google a officiellement déclaré être "all-in on Kotlin Multiplatform". L'objectif affiché est le partage de la logique métier entre Android et iOS, tout en conservant des UI natives sur chaque plateforme.

Un glissement de fond

Ces évolutions convergent vers quelque chose de plus profond : un changement de philosophie dans la façon de concevoir les applications mobiles.

On passe progressivement :

• D'une logique de frameworks cross-plateforme (tout partager, y compris l'UI)

• Vers une logique de partage ciblé du code (partager la logique, garder les UI natives)

Ce n'est pas la mort de Flutter ou React Native — ces outils restent très pertinents pour de nombreux contextes. Mais ils ne sont plus les seules réponses à la question du cross-plateforme.

Alors, changement de paradigme ?

Les lignes entre natif et cross-plateforme deviennent de plus en plus floues. Swift qui tourne sur Android. Des bibliothèques Android partagées avec iOS. Des équipes iOS qui peuvent, sans changer de langage, viser un nouveau marché.

Ce qui est certain : les outils s'adaptent enfin à une réalité que les équipes connaissent depuis longtemps — partager tout n'a pas toujours de sens, mais ne rien partager non plus.

Et vous, comment vous positionnez-vous face à ces évolutions ? Est-ce que ces changements influencent vos choix d'architecture ?

Dans cet article, nous allons voir comment gérer efficacement :

• des listes dynamiques (ajout, suppression)

• des états UI propres

• et éviter les recompositions inutiles

Le tout avec un exemple concret issu d’une application réelle.

Comprendre le problème

Dans Compose, chaque changement de state déclenche une recomposition.

Ce comportement est normal. Cependant, mal maîtrisé, il peut :

• ralentir l’application

• recréer inutilement des composants

• impacter les performances sur les grandes listes

Exemple concret : gestion de zones de livraison

Dans cet écran, on gère :

• l’ajout de zone

• la suppression

• l’affichage dynamique

• les états de chargement

Voici la partie critique :

if (uiState.isLoadingZones) {
    item {
        Box(
            modifier = Modifier
                .fillMaxWidth()
                .padding(vertical = 24.dp),
            contentAlignment = Alignment.Center
        ) {
            CircularProgressIndicator(color = Primary, modifier = Modifier.size(32.dp))
        }
    }
} else if (uiState.zones.isEmpty()) {
    item { ZoneEmptyState() }
} else {
    items(uiState.zones, key = { it.id }) { zone ->
        ZoneItem(
            zone = zone,
            isDeleting = uiState.deletingZoneId == zone.id,
            onDelete = remember(zone.id) {
                { viewModel.deleteZone(zone.id) }
            }
        )
        HorizontalDivider(modifier = Modifier.padding(start = 52.dp))
    }
}

La clé (key) : indispensable pour les listes

items(uiState.zones, key = { it.id })

C’est la bonne pratique la plus importante.

Sans key :

• Compose identifie les éléments par leur position

• une suppression ou insertion entraîne une recomposition inutile de plusieurs éléments

Avec key :

• chaque élément a une identité unique

• seules les lignes impactées sont recomposées

Cela améliore les performances et permet de conserver l’état des composants.

Éviter la recréation des lambdas

onDelete = remember(zone.id) {
    { viewModel.deleteZone(zone.id) }
}

Sans remember :

• la lambda est recréée à chaque recomposition

• cela peut provoquer des recompositions inutiles

Avec remember :

• la lambda est stable

• Compose peut mieux optimiser le rendu

UI pilotée par le state

isDeleting = uiState.deletingZoneId == zone.id

L’interface dépend uniquement du state.

Avantages :

• logique claire

• comportement prévisible

• facilité de test

• pas d’état local inutile

Gestion propre des états UI

if (uiState.isLoadingZones) { ... }
else if (uiState.zones.isEmpty()) { ... }
else { ... }

Ce pattern repose sur trois états :

• Loading

• Empty

• Data

Une alternative plus idiomatique :

when {
    uiState.isLoadingZones -> { ... }
    uiState.zones.isEmpty() -> { ... }
    else -> { ... }
}

LazyColumn et performance

LazyColumn {
    items(...)
}

Contrairement à une Column :

• seuls les éléments visibles sont composés

• cela améliore fortement les performances sur les listes importantes

Résultat

Avec ces bonnes pratiques :

• les recompositions sont limitées

• l’interface reste fluide

• le code est maintenable et évolutif

Règles à retenir

1. Toujours utiliser une key dans items()

2. Utiliser remember pour stabiliser les lambdas

3. Structurer l’interface avec Loading / Empty / Data

4. Utiliser LazyColumn pour les listes

Aller plus loin

Pour approfondir :

• utiliser @Immutable sur les modèles

• éviter de recréer les listes inutilement

• centraliser le state dans le ViewModel

• utiliser derivedStateOf si nécessaire

Conclusion

Jetpack Compose offre un modèle puissant basé sur le state. La performance dépend directement de la manière dont la recomposition est gérée.

En appliquant quelques principes simples comme l’utilisation des key, de remember et d’une UI pilotée par le state, il est possible de construire des applications rapides, propres et évolutives.

#AndroidDev #JetpackCompose #Kotlin #MobileDevelopment #CleanCode

Ça va être long donc …..

J’ai beaucoup fait du backend, et j’en fait toujours d'ailleurs, le frontend m’a toujours attiré à côté, en fin d'année 2025 pendant, mes congés, j’ai décidé de découvrir le monde du frontend mobile et plus précisément android.

J’ai donc essayé plusieurs pistes pour faire une app mobile (React native, Flutter, Ionic, Kotlin/xml, Kotlin/Jetpack compose). Après un test rapide sur ces différents outils j’ai décidé de me concentrer sur Jetpack compose et d’en apprendre davantage.

Pourquoi Jetpack compose, et bien c’est simple, Jetpack compose est en Kotlin pure, et je trouve Kotlin plus propre que Dart(Flutter) et TypeScript(React Native), non ça sans blague, cette aspect n’est qu’une préférence personnel, j’aime les langage qui offre une bonne sucre syntaxique.

La première raison qui justifie le choix de jetpack compose, est que c’est l’outils officiel recommandé par google pour la création d’app mobile android moderne en 2025, je voulais surtout pas toucher à Kotlin/XML et utilisé une conception basé sur l'impératif (mon Dieu j’ai essayé quel enfer)

Deuxième raison, je ne voulais pas commencer mon apprentissage du mobile par le cross plateforme ou l’hybride, je voulais comprendre la plateforme en profondeur, peut être je vais passer au cross plateforme après si besoin. Je vais revenir sur le cross plateforme un peu plus bas (tu pourrais découvrir quelque chose de bien).

Ceci étant dit, revenons à Kotlin/Jetpack compose,il s’agit d’une boîte à outils (tollkit) moderne recommandée par Android pour créer des interfaces utilisateur natives. Elle simplifie et accélère le développement d'interfaces utilisateur sur Android. Donner rapidement vie à votre application grâce à moins de code, des outils puissants et des API Kotlin intuitives. (Ça ressemble un peu a flutter).

Mon aventure dans le développement android native m'a donc permis d’apprendre les notions suivantes

La conception d’interface utilisateur avec des composables (c’est le coeur du truc, comme les widgets le sont pour flutter si je dis pas de bétise), les composables vous permet de décrire votre interfaces de façon déclarative, zéro xml juste des fonctions et des class kotlin

La gestion du state avec les api comme remember, remenberSaveable, mutableStateOf, le state hoisting, les viewModels , la navigation avec compose navigation, l’injection de dépendance avec Hilt, la sauvegarde des preferences avec datastore sans être exhaustif.

Les applications faite avec Jetpack compose sont native donc par défaut il ne peuvent que être installé sur android, si vous voulez supporté d’autre plateformes comme ios, il va falloir développer votre app pour ios, c’est pas idéal pour un projet mvp, ou une app qui ne dispose pas de beaucoup de budget, et bien Jetbrains a trouvé une solution pour vous.

Il s’agit de Kotlin multiplateforme (KMP) et Compose multiplateforme (CMP),KPM est approche multiplateforme qui vous permet de choisir la couche de votre application que vous souhaitez partager entre (android et Ios) en gros, vous pouvez partager votre logique métier entre les deux plateforme et gardé vos ui native(Jetpack compose/Xml pour android et objective C/swift ui pour ios), la second approche CMP, utilise un partage de logique métier et ui en utilisant Jetpack compose pour décrire votre interface utilisé, votre interface est compilé en code machine par Skia, vous avez donc une seul code base pour les deux plateformes (ios et android).

C’est bien beau tout ce bavardage mais qu’est ce que j’ai puis réalisé de concret avec Jetpack compose, et bien voilà, j’ai fait une app de suivi de marche, j’ai pour habitude de marche (10km chaque 2jours/7), cela me permet de suivre mes stats nombres de pas, calories bruillés, distance parcourue.

Comptage du nombre de pas grâce au capteur Sensor.TYPE_STEP_COUNTER Sauvegarde des donnés de marche en local grâce a ROOM, Suivi des pas en arriere plan, et envoi des notification grace aux permissions POST_NOTIFICATIONS, FOREGROUND_SERVICE, FOREGROUND_SERVICE_HEALTH, ACTIVITY_RECOGNITION

Voici des captures de l’app et lien vers des resources

https://developer.android.com/compose https://kmp.jetbrains.com/?android=true&ios=true&iosui=compose&includeTests=true https://kotlinlang.org/multiplatform/

Dans ce tutoriel, nous allons construire un écran d’onboarding moderne avec Jetpack Compose, en utilisant :

• HorizontalPager

• Animations fluides (fade + scale)

• Indicateurs de pagination animés

• Bouton dynamique (Suivant / Commencer)

1 - Modéliser les pages

On commence par définir une classe représentant une page d’onboarding :

data class OnboardingPage(
    val title: String,
    val subtitle: String,
    val icon: ImageVector? = null
)

Ensuite, on crée une liste de pages avec du texte généré qui nous permettra de rendre les donnés de l'onboarding totalement dynamique.

private val pages = listOf(
    OnboardingPage(
        title = "Lorem ipsum dolor sit amet",
        subtitle = "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.",
        icon = Icons.Filled.Apartment
    ),
    OnboardingPage(
        title = "Consectetur adipiscing elit",
        subtitle = "Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.",
        icon = Icons.Default.Money
    ),
    OnboardingPage(
        title = "Sed do eiusmod tempor",
        subtitle = "Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.",
        icon = Icons.Default.Description
    )
)

2 - Implémenter le composable HorizontalPager

HorizontalPager est un composable qui permet d’afficher du contenu sous forme de pages glissables horizontalement, un peu comme :

• un carrousel d’images

• un onboarding (écran d’introduction)

• des onglets que l’on swipe

• un système type ViewPager (ancien Android)

HorizontalPager est fournit via foundation.pager , voici comment l'implémenter très simplement.

val pagerState = rememberPagerState(pageCount = { pages.size })

HorizontalPager(
    state = pagerState,
    modifier = Modifier.weight(1f)
) { pageIndex ->
    // Contenu a swipper
}

3 - Structurer l’UI avec des Composables réutilisables.

Jepack compose recommande de découpé votre UI en de petit composable, et nous allons respectez ce conseil dans ce cas. Créer un petit compsable TextSection qui affichera nos textes, contenu dans les différente page.

@Composable
private fun TextSection(title: String, subtitle: String) {
    Column(
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        Text(
            text = title,
            fontSize = 26.sp,
            fontWeight = FontWeight.Bold,
            textAlign = TextAlign.Center
        )

        Text(
            text = subtitle,
            fontSize = 15.sp,
            textAlign = TextAlign.Center
        )
    }
}

, nous avons besoin aussi d'un indicateur pour connaitre la position actuel dans la liste de page, pour ce faire on utiliséra un box

val width by animateDpAsState(
    targetValue = if (index == current) 24.dp else 8.dp,
    animationSpec = tween(durationMillis = 300)
)

Box(
    modifier = Modifier
        .height(8.dp)
        .width(width)
        .clip(CircleShape)
)

Terminons par le bouton qui pourra aussi être utilisé pour défiler les page,

Button(
    onClick = {
        if (pagerState.currentPage < pages.lastIndex) {
            scope.launch {
                pagerState.animateScrollToPage(
                    pagerState.currentPage + 1
                )
            }
        } else {
            onNavigateToAuth()
        }
    }
) {
    Text(
        text = if (isLastPage) "Commencer" else "Suivant →"
    )
}

voici le code complet de notre écran d'onboarding de notre superbe app mobile android, qui inclut les éléments suivant

• HorizontalPager

• Animation scale + fade

• Pagination animée

• Bouton dynamique

• Structure propre et modulaire

• Preview fonctionnel

package com.example.onboarding

import androidx.compose.animation.core.animateDpAsState
import androidx.compose.animation.core.tween
import androidx.compose.foundation.background
import androidx.compose.foundation.layout.*
import androidx.compose.foundation.pager.HorizontalPager
import androidx.compose.foundation.pager.rememberPagerState
import androidx.compose.foundation.shape.CircleShape
import androidx.compose.foundation.shape.RoundedCornerShape
import androidx.compose.material.icons.Icons
import androidx.compose.material.icons.filled.Apartment
import androidx.compose.material.icons.filled.Description
import androidx.compose.material.icons.filled.Money
import androidx.compose.material3.*
import androidx.compose.runtime.*
import androidx.compose.ui.Alignment
import androidx.compose.ui.Modifier
import androidx.compose.ui.draw.clip
import androidx.compose.ui.graphics.Color
import androidx.compose.ui.graphics.graphicsLayer
import androidx.compose.ui.graphics.vector.ImageVector
import androidx.compose.ui.text.font.FontWeight
import androidx.compose.ui.text.style.TextAlign
import androidx.compose.ui.tooling.preview.Preview
import androidx.compose.ui.unit.dp
import androidx.compose.ui.unit.sp
import kotlinx.coroutines.launch
import kotlin.math.absoluteValue

// ---------------------------
// Data Model
// ---------------------------

data class OnboardingPage(
    val title: String,
    val subtitle: String,
    val icon: ImageVector
)

private val pages = listOf(
    OnboardingPage(
        title = "Lorem ipsum dolor sit amet",
        subtitle = "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.",
        icon = Icons.Filled.Apartment
    ),
    OnboardingPage(
        title = "Consectetur adipiscing elit",
        subtitle = "Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.",
        icon = Icons.Filled.Money
    ),
    OnboardingPage(
        title = "Sed do eiusmod tempor",
        subtitle = "Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.",
        icon = Icons.Filled.Description
    )
)

// ---------------------------
// Main Screen
// ---------------------------

@Composable
fun OnboardingScreen(
    onNavigateToHome: () -> Unit
) {
    val pagerState = rememberPagerState(pageCount = { pages.size })
    val scope = rememberCoroutineScope()

    Surface(
        modifier = Modifier.fillMaxSize(),
        color = Color.White
    ) {
        Column(
            modifier = Modifier
                .fillMaxSize()
                .padding(horizontal = 24.dp, vertical = 50.dp),
            verticalArrangement = Arrangement.SpaceBetween
        ) {

            TopBar(onSkip = onNavigateToHome)

            HorizontalPager(
                state = pagerState,
                modifier = Modifier.weight(1f)
            ) { pageIndex ->

                val pageOffset = (
                        (pagerState.currentPage - pageIndex) +
                                pagerState.currentPageOffsetFraction
                        ).absoluteValue

                Column(
                    modifier = Modifier
                        .fillMaxSize()
                        .graphicsLayer {
                            alpha = 1f - pageOffset.coerceIn(0f, 1f)
                            scaleX = 1f - (pageOffset * 0.1f)
                            scaleY = 1f - (pageOffset * 0.1f)
                        },
                    verticalArrangement = Arrangement.SpaceEvenly,
                    horizontalAlignment = Alignment.CenterHorizontally
                ) {
                    IllustrationSection(page = pages[pageIndex])
                    TextSection(
                        title = pages[pageIndex].title,
                        subtitle = pages[pageIndex].subtitle
                    )
                }
            }

            PaginationDots(
                total = pages.size,
                current = pagerState.currentPage
            )

            Spacer(modifier = Modifier.height(25.dp))

            NextButton(
                isLastPage = pagerState.currentPage == pages.lastIndex,
                onClick = {
                    if (pagerState.currentPage < pages.lastIndex) {
                        scope.launch {
                            pagerState.animateScrollToPage(
                                pagerState.currentPage + 1
                            )
                        }
                    } else {
                        onNavigateToHome()
                    }
                }
            )
        }
    }
}

// ---------------------------
// Top Bar
// ---------------------------

@Composable
private fun TopBar(onSkip: () -> Unit) {
    Row(
        modifier = Modifier.fillMaxWidth(),
        horizontalArrangement = Arrangement.End
    ) {
        TextButton(onClick = onSkip) {
            Text(
                text = "Passer",
                fontWeight = FontWeight.SemiBold
            )
        }
    }
}

// ---------------------------
// Illustration Section
// ---------------------------

@Composable
private fun IllustrationSection(page: OnboardingPage) {
    Box(
        modifier = Modifier
            .size(150.dp)
            .clip(CircleShape)
            .background(Color(0xFFE8F5E9)),
        contentAlignment = Alignment.Center
    ) {
        Card(
            shape = CircleShape,
            elevation = CardDefaults.cardElevation(6.dp)
        ) {
            Box(
                modifier = Modifier
                    .size(100.dp)
                    .background(Color.White),
                contentAlignment = Alignment.Center
            ) {
                Icon(
                    imageVector = page.icon,
                    contentDescription = null,
                    tint = Color(0xFF2E7D32),
                    modifier = Modifier.size(60.dp)
                )
            }
        }
    }
}

// ---------------------------
// Text Section
// ---------------------------

@Composable
private fun TextSection(title: String, subtitle: String) {
    Column(
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.spacedBy(12.dp)
    ) {
        Text(
            text = title,
            fontSize = 26.sp,
            fontWeight = FontWeight.Bold,
            textAlign = TextAlign.Center
        )

        Text(
            text = subtitle,
            fontSize = 15.sp,
            textAlign = TextAlign.Center,
            color = Color.Gray
        )
    }
}

// ---------------------------
// Pagination Dots
// ---------------------------

@Composable
private fun PaginationDots(total: Int, current: Int) {
    Row(
        modifier = Modifier.fillMaxWidth(),
        horizontalArrangement = Arrangement.Center
    ) {
        repeat(total) { index ->
            val width by animateDpAsState(
                targetValue = if (index == current) 24.dp else 8.dp,
                animationSpec = tween(300),
                label = ""
            )

            Box(
                modifier = Modifier
                    .padding(horizontal = 4.dp)
                    .height(8.dp)
                    .width(width)
                    .clip(CircleShape)
                    .background(
                        if (index == current)
                            Color(0xFF2E7D32)
                        else
                            Color.LightGray
                    )
            )
        }
    }
}

// ---------------------------
// Next Button
// ---------------------------

@Composable
private fun NextButton(
    isLastPage: Boolean,
    onClick: () -> Unit
) {
    Button(
        onClick = onClick,
        modifier = Modifier
            .fillMaxWidth()
            .height(56.dp),
        shape = RoundedCornerShape(16.dp)
    ) {
        Text(
            text = if (isLastPage) "Commencer" else "Suivant →",
            fontSize = 16.sp,
            fontWeight = FontWeight.SemiBold
        )
    }
}

// ---------------------------
// Preview
// ---------------------------

@Preview(showBackground = true, showSystemUi = true)
@Composable
fun OnboardingPreview() {
    MaterialTheme {
        OnboardingScreen(onNavigateToHome = {})
    }
}

Cet article explore en profondeur ces deux approches, leurs cas d'usage, et comment les implémenter efficacement dans vos projets Django.

Le Problème : La Concurrence de Données

Imaginons un scénario classique d'e-commerce. Deux utilisateurs consultent le même produit dont il ne reste qu'un seul exemplaire en stock. Ils cliquent tous les deux sur "Acheter" au même moment. Sans mécanisme de gestion de concurrence approprié, voici ce qui pourrait se passer :

1. Utilisateur A lit : stock = 1

2. Utilisateur B lit : stock = 1

3. Utilisateur A décrémente : stock = 0

4. Utilisateur B décrémente : stock = 0 (devrait être -1, erreur !)

Ce problème de "race condition" peut entraîner des incohérences de données, des surventes, ou même des pertes financières. C'est là qu'interviennent les stratégies de verrouillage.

Verrouillage Pessimiste (Pessimistic Locking)

Concept

Le verrouillage pessimiste part du principe que les conflits sont probables. Il verrouille donc les données dès qu'elles sont lues, empêchant toute autre transaction de les modifier jusqu'à ce que le verrou soit libéré.

C'est comme si vous mettiez un panneau "En cours de modification - Ne pas toucher" sur vos données.

Comment ça fonctionne en Django ?

Django implémente le verrouillage pessimiste via la méthode select_for_update() qui utilise la clause SQL SELECT ... FOR UPDATE.

Exemple Basique

from django.db import transaction
from myapp.models import Product

@transaction.atomic
def purchase_product(product_id, quantity):
    # Verrouille la ligne en base de données
    product = Product.objects.select_for_update().get(id=product_id)

    if product.stock >= quantity:
        product.stock -= quantity
        product.save()
        return True
    else:
        return False

Dans cet exemple :

• select_for_update() verrouille la ligne du produit

• Aucune autre transaction ne peut modifier cette ligne jusqu'à la fin de la transaction

• Le décorateur @transaction.atomic garantit que le verrou est maintenu pendant toute la durée de la transaction

Exemple Avancé : E-commerce avec Gestion de Panier

from django.db import transaction
from django.db.models import F
from myapp.models import Product, Order, OrderItem

@transaction.atomic
def process_order(user, cart_items):
    """
    Traite une commande en verrouillant tous les produits concernés
    pour éviter les surventes.
    """
    order = Order.objects.create(user=user, status='pending')

    # Récupérer tous les IDs de produits
    product_ids = [item['product_id'] for item in cart_items]

    # Verrouiller TOUS les produits en une seule requête
    # nowait=True : échoue immédiatement si un verrou existe déjà
    products = Product.objects.select_for_update(nowait=True).filter(
        id__in=product_ids
    )

    # Créer un dictionnaire pour un accès rapide
    products_dict = {p.id: p for p in products}

    # Vérifier la disponibilité de tous les produits
    for item in cart_items:
        product = products_dict.get(item['product_id'])
        if not product or product.stock < item['quantity']:
            raise ValueError(f"Stock insuffisant pour {product.name}")

    # Si tout est OK, créer les items de commande et décrémenter le stock
    for item in cart_items:
        product = products_dict[item['product_id']]

        OrderItem.objects.create(
            order=order,
            product=product,
            quantity=item['quantity'],
            price=product.price
        )

        product.stock -= item['quantity']
        product.save()

    order.status = 'confirmed'
    order.save()

    return order

Options de select_for_update()

Django offre plusieurs options pour affiner le comportement du verrouillage :

# nowait : échoue immédiatement si la ligne est déjà verrouillée
Product.objects.select_for_update(nowait=True).get(id=1)

# skip_locked : ignore les lignes déjà verrouillées
available_products = Product.objects.select_for_update(skip_locked=True).filter(
    stock__gt=0
)

# of : verrouille seulement certaines tables liées
Order.objects.select_for_update(of=('self',)).select_related('customer').get(id=1)

Exemple avec Timeout Personnalisé

from django.db import transaction, OperationalError
import time

@transaction.atomic
def safe_update_with_timeout(product_id, timeout=5):
    """
    Tente de verrouiller un produit avec un timeout personnalisé.
    """
    start_time = time.time()

    while time.time() - start_time < timeout:
        try:
            product = Product.objects.select_for_update(nowait=True).get(
                id=product_id
            )

            # Effectuer la modification
            product.stock -= 1
            product.save()

            return True

        except OperationalError:
            # Le verrou n'est pas disponible, attendre un peu
            time.sleep(0.1)

    return False  # Timeout dépassé

Avantages du Verrouillage Pessimiste

• Simplicité conceptuelle : facile à comprendre et à implémenter

• Cohérence garantie : impossible d'avoir des modifications concurrentes

• Idéal pour les opérations critiques : transactions bancaires, gestion de stock

Inconvénients

• Performance : peut créer des goulots d'étranglement

• Deadlocks potentiels : deux transactions s'attendent mutuellement

• Scalabilité limitée : problématique avec beaucoup d'utilisateurs concurrents

Verrouillage Optimiste (Optimistic Locking)

Concept

Le verrouillage optimiste part du principe que les conflits sont rares. Au lieu de verrouiller les données, il vérifie au moment de la sauvegarde si elles ont été modifiées entre-temps.

C'est comme si vous disiez : "Je vais travailler sur ces données, et au moment de sauvegarder, je vérifierai si quelqu'un d'autre les a modifiées."

Comment ça fonctionne ?

L'approche la plus courante consiste à utiliser un champ de version :

1. Lire les données avec leur numéro de version actuel

2. Effectuer les modifications en mémoire

3. Au moment de la sauvegarde, vérifier que le numéro de version n'a pas changé

4. Si changé : conflit détecté

5. Si inchangé : sauvegarder et incrémenter la version

Implémentation Manuelle avec un Champ de Version

from django.db import models
from django.core.exceptions import ValidationError

class Product(models.Model):
    name = models.CharField(max_length=200)
    price = models.DecimalField(max_digits=10, decimal_places=2)
    stock = models.IntegerField(default=0)
    version = models.IntegerField(default=0)

    def save(self, *args, **kwargs):
        """
        Sauvegarde avec vérification de version pour le locking optimiste.
        """
        if self.pk is not None:  # C'est une mise à jour
            # Incrémenter la version
            new_version = self.version + 1

            # Mettre à jour seulement si la version n'a pas changé
            updated = Product.objects.filter(
                pk=self.pk,
                version=self.version
            ).update(
                name=self.name,
                price=self.price,
                stock=self.stock,
                version=new_version
            )

            if updated == 0:
                raise ValidationError(
                    "Ce produit a été modifié par un autre utilisateur. "
                    "Veuillez recharger et réessayer."
                )

            # Mettre à jour la version locale
            self.version = new_version
        else:
            # Nouvelle instance
            super().save(*args, **kwargs)

    class Meta:
        db_table = 'products'

Utilisation du Verrouillage Optimiste

from django.core.exceptions import ValidationError
from myapp.models import Product

def update_product_price(product_id, new_price, max_retries=3):
    """
    Met à jour le prix d'un produit avec retry automatique.
    """
    for attempt in range(max_retries):
        try:
            # Lire le produit avec sa version actuelle
            product = Product.objects.get(id=product_id)
            original_version = product.version

            # Modifier le produit
            product.price = new_price

            # Sauvegarder (vérifie automatiquement la version)
            product.save()

            return True

        except ValidationError:
            # Conflit détecté, réessayer
            if attempt == max_retries - 1:
                raise
            continue

    return False

Exemple Avancé : Système de Réservation

from django.db import models, transaction
from django.utils import timezone
from datetime import timedelta

class Event(models.Model):
    name = models.CharField(max_length=200)
    total_seats = models.IntegerField()
    available_seats = models.IntegerField()
    version = models.IntegerField(default=0)

    def reserve_seats(self, quantity):
        """
        Réserve des sièges avec verrouillage optimiste.
        """
        if self.available_seats < quantity:
            raise ValueError("Sièges insuffisants disponibles")

        # Simuler une latence (traitement métier)
        # Dans un cas réel : validation de paiement, etc.

        # Décrémenter les sièges
        self.available_seats -= quantity
        self.save()  # La méthode save() vérifie la version

        return True

class Reservation(models.Model):
    event = models.ForeignKey(Event, on_delete=models.CASCADE)
    user = models.ForeignKey('auth.User', on_delete=models.CASCADE)
    seats_reserved = models.IntegerField()
    created_at = models.DateTimeField(auto_now_add=True)
    expires_at = models.DateTimeField()
    status = models.CharField(
        max_length=20,
        choices=[
            ('pending', 'En attente'),
            ('confirmed', 'Confirmée'),
            ('cancelled', 'Annulée'),
            ('expired', 'Expirée'),
        ],
        default='pending'
    )

def create_reservation(user, event_id, seats_count, max_retries=5):
    """
    Crée une réservation avec gestion des conflits.
    """
    for attempt in range(max_retries):
        try:
            with transaction.atomic():
                # Récupérer l'événement
                event = Event.objects.get(id=event_id)

                # Tenter de réserver
                event.reserve_seats(seats_count)

                # Créer la réservation
                reservation = Reservation.objects.create(
                    event=event,
                    user=user,
                    seats_reserved=seats_count,
                    expires_at=timezone.now() + timedelta(minutes=15),
                    status='pending'
                )

                return reservation

        except ValidationError as e:
            # Conflit de version, réessayer
            if attempt == max_retries - 1:
                raise Exception(
                    "Impossible de réserver après plusieurs tentatives. "
                    "L'événement est peut-être complet."
                )
            continue
        except ValueError as e:
            # Plus de sièges disponibles
            raise e

    return None

Utilisation avec Django-Concurrency

Pour simplifier l'implémentation, vous pouvez utiliser la bibliothèque django-concurrency :

pip install django-concurrency

from django.db import models
from concurrency.fields import IntegerVersionField

class Product(models.Model):
    name = models.CharField(max_length=200)
    price = models.DecimalField(max_digits=10, decimal_places=2)
    stock = models.IntegerField(default=0)
    version = IntegerVersionField()  # Gère automatiquement le versioning

    class Meta:
        db_table = 'products'

# Utilisation
from concurrency.exceptions import RecordModifiedError

try:
    product = Product.objects.get(id=1)
    product.stock -= 1
    product.save()
except RecordModifiedError:
    # Quelqu'un d'autre a modifié le produit
    print("Conflit détecté ! Veuillez réessayer.")

Exemple avec Timestamp au lieu de Version

from django.db import models
from django.utils import timezone

class Document(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    last_modified = models.DateTimeField(auto_now=True)

    def update_content(self, new_content, expected_timestamp):
        """
        Met à jour le contenu seulement si le timestamp correspond.
        """
        updated = Document.objects.filter(
            pk=self.pk,
            last_modified=expected_timestamp
        ).update(
            content=new_content,
            last_modified=timezone.now()
        )

        if updated == 0:
            raise ValidationError(
                "Le document a été modifié. Actualisez et réessayez."
            )

        # Recharger l'instance
        self.refresh_from_db()
        return True

# Utilisation
document = Document.objects.get(id=1)
original_timestamp = document.last_modified

# L'utilisateur modifie le document (peut prendre du temps)
# ...

try:
    document.update_content(
        "Nouveau contenu",
        expected_timestamp=original_timestamp
    )
except ValidationError as e:
    print("Conflit détecté:", e)

Avantages du Verrouillage Optimiste

• Meilleures performances : pas de verrouillage de base de données

• Scalabilité : supporte beaucoup d'utilisateurs concurrents

• Pas de deadlocks : pas de verrous à gérer

• Idéal pour les lectures fréquentes : les lectures ne sont jamais bloquées

Inconvénients

• Complexité de gestion des conflits : nécessite une logique de retry

• Expérience utilisateur : l'utilisateur peut perdre son travail en cas de conflit

• Plus de code : implémentation plus complexe

Comparaison et Choix de la Stratégie

Quand Utiliser le Verrouillage Pessimiste ?

Situations idéales :

• Transactions financières (virements, paiements)

• Gestion de stock critique (derniers articles en stock)

• Systèmes de réservation à forte demande (billets de concert)

• Opérations courtes et critiques

• Forte probabilité de conflits

Exemple de cas d'usage :

# Virement bancaire - DOIT être pessimiste
@transaction.atomic
def transfer_money(from_account_id, to_account_id, amount):
    # Verrouiller les deux comptes
    accounts = Account.objects.select_for_update().filter(
        id__in=[from_account_id, to_account_id]
    ).order_by('id')  # Ordre fixe pour éviter les deadlocks

    from_account = accounts.get(id=from_account_id)
    to_account = accounts.get(id=to_account_id)

    if from_account.balance < amount:
        raise ValueError("Solde insuffisant")

    from_account.balance -= amount
    to_account.balance += amount

    from_account.save()
    to_account.save()

Quand Utiliser le Verrouillage Optimiste ?

Situations idéales :

• Édition collaborative de documents

• Mise à jour de profils utilisateurs

• Systèmes de gestion de contenu (CMS)

• Opérations longues avec faible probabilité de conflit

• Applications à fort trafic avec beaucoup de lectures

Exemple de cas d'usage :

# Édition de profil utilisateur - peut être optimiste
class UserProfile(models.Model):
    user = models.OneToOneField('auth.User', on_delete=models.CASCADE)
    bio = models.TextField()
    avatar = models.ImageField()
    version = IntegerVersionField()

def update_profile(user_id, bio, avatar):
    try:
        profile = UserProfile.objects.get(user_id=user_id)
        profile.bio = bio
        if avatar:
            profile.avatar = avatar
        profile.save()
        return True
    except RecordModifiedError:
        # Conflit rare, l'utilisateur peut réessayer
        return False

Approche Hybride

Dans certains cas, vous pouvez combiner les deux approches :

from django.db import transaction
from concurrency.fields import IntegerVersionField
from concurrency.exceptions import RecordModifiedError

class Inventory(models.Model):
    product = models.ForeignKey(Product, on_delete=models.CASCADE)
    warehouse = models.ForeignKey(Warehouse, on_delete=models.CASCADE)
    quantity = models.IntegerField()
    version = IntegerVersionField()  # Optimiste pour les MAJ non-critiques

    class Meta:
        unique_together = ['product', 'warehouse']

@transaction.atomic
def transfer_inventory(product_id, from_warehouse_id, to_warehouse_id, quantity):
    """
    Transfert d'inventaire : pessimiste pour la lecture, optimiste pour l'écriture.
    """
    # Verrouillage pessimiste pour garantir la cohérence
    inventories = Inventory.objects.select_for_update().filter(
        product_id=product_id,
        warehouse_id__in=[from_warehouse_id, to_warehouse_id]
    )

    from_inv = inventories.get(warehouse_id=from_warehouse_id)
    to_inv = inventories.get(warehouse_id=to_warehouse_id)

    # Vérifications métier
    if from_inv.quantity < quantity:
        raise ValueError("Quantité insuffisante")

    # Modifications
    from_inv.quantity -= quantity
    to_inv.quantity += quantity

    # Sauvegarde avec check de version (optimiste)
    try:
        from_inv.save()
        to_inv.save()
    except RecordModifiedError:
        raise Exception("Conflit détecté lors du transfert")

Bonnes Pratiques

1. Toujours Utiliser des Transactions

from django.db import transaction

# ✅ BON
@transaction.atomic
def update_with_lock():
    obj = MyModel.objects.select_for_update().get(id=1)
    obj.value += 1
    obj.save()

# ❌ MAUVAIS - le verrou sera libéré immédiatement
def bad_update():
    obj = MyModel.objects.select_for_update().get(id=1)
    # Le verrou est déjà libéré ici !
    obj.value += 1
    obj.save()

2. Gérer les Exceptions

from django.db import OperationalError
from concurrency.exceptions import RecordModifiedError

@transaction.atomic
def safe_operation(obj_id):
    try:
        obj = MyModel.objects.select_for_update(nowait=True).get(id=obj_id)
        # ... opérations
    except OperationalError:
        # L'objet est déjà verrouillé
        raise Exception("Ressource occupée, réessayez plus tard")
    except RecordModifiedError:
        # Conflit de version (optimiste)
        raise Exception("Données modifiées, veuillez actualiser")

3. Éviter les Deadlocks

# ✅ BON - Toujours verrouiller dans le même ordre
@transaction.atomic
def transfer(from_id, to_id, amount):
    # Trier les IDs pour garantir un ordre cohérent
    ids = sorted([from_id, to_id])
    accounts = Account.objects.select_for_update().filter(
        id__in=ids
    ).order_by('id')
    # ...

# ❌ MAUVAIS - Ordre variable peut causer des deadlocks
@transaction.atomic
def bad_transfer(from_id, to_id, amount):
    from_account = Account.objects.select_for_update().get(id=from_id)
    to_account = Account.objects.select_for_update().get(id=to_id)
    # ...

4. Implémenter des Retries Intelligents

import time
from functools import wraps

def retry_on_conflict(max_attempts=3, delay=0.1, backoff=2):
    """
    Décorateur pour réessayer automatiquement en cas de conflit.
    """
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            attempt = 0
            current_delay = delay

            while attempt < max_attempts:
                try:
                    return func(*args, **kwargs)
                except (RecordModifiedError, ValidationError) as e:
                    attempt += 1
                    if attempt >= max_attempts:
                        raise

                    time.sleep(current_delay)
                    current_delay *= backoff

        return wrapper
    return decorator

# Utilisation
@retry_on_conflict(max_attempts=5, delay=0.2)
def update_product(product_id, new_stock):
    product = Product.objects.get(id=product_id)
    product.stock = new_stock
    product.save()

5. Monitorer les Performances

import logging
from time import time
from contextlib import contextmanager

logger = logging.getLogger(__name__)

@contextmanager
def log_lock_time(operation_name):
    """
    Contexte pour mesurer le temps passé avec un verrou.
    """
    start = time()
    try:
        yield
    finally:
        duration = time() - start
        logger.info(f"{operation_name} - Lock duration: {duration:.3f}s")

        if duration > 1.0:  # Alerter si > 1 seconde
            logger.warning(f"Long lock detected: {operation_name}")

# Utilisation
@transaction.atomic
def monitored_operation(obj_id):
    with log_lock_time(f"Update object {obj_id}"):
        obj = MyModel.objects.select_for_update().get(id=obj_id)
        # ... opérations
        obj.save()

Conclusion

Le choix entre verrouillage optimiste et pessimiste dépend fortement du contexte de votre application :

Choisissez le verrouillage pessimiste quand :

• La cohérence des données est critique

• Les conflits sont fréquents

• Les transactions sont courtes

• Vous gérez des opérations financières ou du stock

Choisissez le verrouillage optimiste quand :

• La performance et la scalabilité sont prioritaires

• Les conflits sont rares

• Les opérations peuvent être longues

• Vous avez beaucoup de lectures et peu d'écritures

Dans tous les cas :

• Testez votre implémentation sous charge

• Mesurez les performances réelles

• Gérez correctement les erreurs

• Documentez votre choix pour l'équipe

N'oubliez pas que Django offre tous les outils nécessaires pour implémenter ces deux stratégies efficacement. À vous de choisir celle qui correspond le mieux à vos besoins !

Ressources Complémentaires

• Documentation Django sur select_for_update()

• Django Concurrency

• Database Transactions in Django

Cet article vous a été utile ? N'hésitez pas à partager vos expériences avec le locking en Django dans les commentaires !

Eh bien, une des solutions possibles est d'utiliser l'opérateur RxJS forkJoin. Il permet de combiner plusieurs observables en un seul, attendant que tous les observables se terminent avant de commencer à émettre.

Voici quelques avantages que l'opérateur forkJoin apporte à votre application, au cas où vous doutez encore de son utilité 😌😎 :

• Performance : En envoyant plusieurs requêtes HTTP en parallèle, vous économisez du temps de traitement et améliorez la performance globale de votre application.

• Simplicité : Gérer plusieurs observables individuellement peut rapidement devenir complexe forkJoin simplifie ce processus en centralisant la logique d'attente et de traitement des réponses. Perso, je ne demande pas mieux 😌.

• Fiabilité : En attendant que toutes les requêtes se terminent avant de traiter les données, vous minimisez le risque d'erreurs liées à des requêtes incomplètes ou mal ordonnées.

Assez parlé, je vous montre comment je procède lorsque je suis dans un contexte où l'utilisation de forkJoin est appropriée.

Supposons que nous sommes sur un tableau de bord et souhaitons obtenir d'une API les derniers utilisateurs, les articles et les commentaires créés sur une application X. On pourrait avoir un composant de tableau de bord comme ceci

import { Component, OnInit,signal } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { forkJoin } from 'rxjs';
import {User, Article,Comment} from '../models'; 

@Component({
  selector: 'app-dashboard',
  templateUrl: './dashboard.component.html',
  styleUrls: ['./dashboard.component.css']
})
export class DashboardComponent implements OnInit {
  users!:User[];
  articles!: Article[];
  comments!: Comment[];

  constructor(private http: HttpClient) {}

  ngOnInit() {
    const users$ = this.http.get<User[]>('https://api.example.com/users');
    const articles$ = this.http.get<Article[]>('https://api.example.com/articles');
    const comments$ = this.http.get<Comment[]>('https://api.example.com/comments');

    forkJoin({
        users:users$, 
        articles:articles$, 
        comments:comments$
    }).subscribe({
        next: (responses) => {
          this.users = responses.users.data;
          this.articles = responses.articles.data;
          this.comments = responses.comments.data;
        },
        error: (error) => {
            console.error('Erreur lors de la récupération des données', error);
        },
        complete: () => {
            // Fermer le loader ou effectuer toute autre 
           //action de nettoyage ici
        },
      })
  }
}

En utilisant forkJoin, nous pouvons attendre que ces trois requêtes se terminent avant de traiter les données, garantissant ainsi que notre application agit de manière cohérente et fiable.

Conclusion

Enfin, nous sommes à la fin de cette découverte de l'opérateur forkJoin.

ForkJoin est un opérateur puissant et flexible dans le cadre de l'utilisation de RxJS avec Angular. Il offre une manière efficace et organisée de gérer et de synchroniser plusieurs requêtes HTTP, contribuant ainsi à une meilleure performance et à une expérience utilisateur fluide.😌😌

Source

https://www.learnrxjs.io/learn-rxjs/operators/combination/forkjoin

https://www.learnrxjs.io/

https://angular.dev/