Développer avec le database branching

Il y a quelques années maintenant, le développement d'applications mobiles a connu une révolution. Chez Yield Studio, nous l'avons adoptée avec passion. Vous avez forcément déjà entendu parler des systèmes d’exploitation mobile Android et d'iOS ? Pour nous, concevoir une application pour l'un ou l'autre, revient à la même charge de travail.

‍

En effet, grâce à la technologie React Native, nous sommes capables de développer simultanément pour ces deux géants du mobile. Plongez dans notre guide ultime du développement d’application Android.

‍

Que vous soyez novice ou expert, découvrez comment transformer une simple idée en une application concrète. C'est parti !

‍

📗 Comprendre les bases du développement Android

‍

Android, ce n'est pas seulement un petit robot vert que vous voyez sur votre smartphone. En réalité, il s’agit d’un puissant système d'exploitation, utilisé par des milliards d’appareils mobiles à travers le monde. Avant de plonger dans la création d'une application, quelques notions clés s'imposent.

‍

Premièrement, parlons "langage". Pour développer sur Android, on utilise principalement Kotlin, bien que d'autres langages de programmation comme le Java puissent également être adoptés. Kotlin est donc la pierre angulaire de bon nombre d'applications que vous utilisez quotidiennement si vous disposez d’un smartphone ou d’une tablette fonctionnant sous Android.

‍

Voyons un exemple de code source Kotlin des plus basiques :

‍

Dans cet exemple de code source Kotlin, nous utilisons un élément TextView pour afficher le texte « Bienvenue sur notre application Android ! ».

‍

Ensuite, il y a l’environnement de développement, Android Studio. C'est le logiciel officiel, mis à disposition par Google, pour concevoir des applications mobiles Android. Doté d'une panoplie d'outils, il facilite la vie des développeurs, des plus novices aux plus chevronnés.

‍

Voici une capture d’écran de l’environnement de développement Android Studio avec du code source Kotlin rédigé sur la droite de l’écran :

‍

Mais chez Yield Studio, nous avons une large préférence pour React Native. Open source et ultra performant, il nous permet de concevoir des applications à la fois pour Android et iOS avec une seule et même base de code source JavaScript. Une véritable révolution qui simplifie le processus tout en garantissant une expérience utilisateur optimale.

‍

Grossièrement, ce code source React Native emploie un composant Text au sein d'un élément View, avec un style appliqué pour le positionnement et la mise en forme du texte.

En résumé, le développement Android, c'est un mélange entre un langage de programmation, des outils adaptés et, dans notre cas, une touche de magie avec React Native.

‍

Curieux d'en savoir plus ? Alors, continuons l'aventure ensemble !

‍

👨‍💻 La technologie multiplateforme React Native

‍

Lorsque l’on parle de développement d'applications mobiles, une question majeure revient souvent :

‍

« Comment concevoir pour Android et iOS sans doubler le travail ? ».

‍

Notre réponse : React Native !

‍

Conçue par Méta (anciennement Facebook), React Native est une technologie open source qui a révolutionné la façon dont les développeurs conçoivent des applications mobiles. Avec ce Framework, nous n’avons plus besoin de créer deux applications distinctes pour les appareils fonctionnant sous Android et ceux utilisant iOS. Il suffit d’écrire un même code source JavaScript pour que React Native se charge de le transposer simultanément pour les deux systèmes d'exploitation.

‍

Magique, n'est-ce pas ?

‍

Chez Yield Studio, nous avons adopté cette technologie pour une raison simple : elle optimise notre efficacité ! Grâce à React Native, développer une application Android ou iOS représente exactement la même charge de travail pour nous. Quelques différences demeurent, bien sûr, mais elles sont mineures comparées à l'avantage principal : un gain de temps considérable.

‍

Mais ce n'est pas tout ! React Native offre également des interfaces utilisateur fluides, adaptées à chaque plateforme. Les utilisateurs bénéficient ainsi d'une expérience homogène, que ce soit sur Android ou sur iOS.

‍

En choisissant React Native, on fait le choix d'un développement plus rapide, plus cohérent et tout aussi performant. Chez Yield Studio, c'est cette technologie innovante qui nous guide au quotidien, nous permettant de délivrer des applications de haute qualité sur tous les fronts.

‍

💡 Les étapes clés pour créer une application Android

‍

Dès l'instant où l'on décide de se lancer dans le développement d'une application Android, un parcours structuré s'impose. Voici un guide étape par étape pour naviguer dans ce processus avec confiance :

‍

1. Définir le concept : Avant toute chose, clarifiez votre idée. Quelle est la valeur ajoutée de votre application ? À quel besoin répond-elle ?

‍

2. Conception de l'interface utilisateur : Une application réussie est intuitive. Travaillez sur un design ergonomique, adapté aux spécificités des appareils Android.

‍

3. Choisir le bon langage de programmation : Si nous privilégions React Native et donc JavaScript, chez Yield Studio, d'autres options existent. Kotlin et Java sont les langages utilisés pour développer de manière native sous Android.

‍

4. Utiliser Android Studio : Cet outil de développement, mis à jour régulièrement, est essentiel. Il intègre le SDK (pour Software Development Kit) Android offrant ainsi tout ce dont un développeur Android a besoin.

‍

5. Tests et améliorations : Une fois votre application développée, la phase de test est cruciale. Elle vous permet de détecter d'éventuels bugs et d'optimiser l'expérience utilisateur.

‍

6. Mise à jour constante : Le monde des applications évolue vite. Assurez-vous de mettre régulièrement à jour votre application pour répondre aux besoins changeants des utilisateurs et aux mises à jour du système d'exploitation.

‍

7. Lancement et promotion : Une fois que tout est en place, lancez votre application sur le Google Play Store. Ne négligez pas sa promotion pour garantir sa visibilité et son succès.

‍

Créer une application Android est un voyage passionnant, parsemé de défis. Mais avec une méthodologie claire et les bons outils, comme ceux que nous utilisons chez Yield Studio, votre idée peut rapidement devenir une réalité prisée par des milliers d'utilisateurs.

‍

📝 Publication et mise à jour

‍

Entrer dans le monde des applications Android ne se termine pas simplement avec le développement de votre application. Deux étapes cruciales restent à franchir pour assurer sa pérennité : la publication et les mises à jour. Voici un aperçu de ce que cela implique :

‍

1. Avant de soumettre votre application Android sur le Google Play Store, vérifiez sa conformité aux directives de la plateforme. Veillez à préparer tous les éléments visuels et descriptifs nécessaires pour présenter votre application sous son meilleur jour.

‍

2. Une fois prête, soumettez l’application sur le store pour revue. Après validation, elle sera accessible à des millions d'utilisateurs. C'est le moment clé pour voir votre travail récompensé.

‍

3. Les avis des utilisateurs sont essentiels. Ils vous fourniront des informations précieuses pour améliorer votre application au fur et à mesure de son existence.

‍

4. En fonction des retours et avis des utilisateurs et des évolutions technologiques futures, planifiez des mises à jour régulières. Cela garantira la satisfaction des utilisateurs et la compatibilité avec les dernières versions d'Android.

‍

5. Le monde d'Android évolue sans cesse. Intégrez de nouvelles fonctionnalités et tendances pour que votre application reste au goût du jour.

‍

6. Comme tout produit, une application nécessite des réajustements. Analysez régulièrement les performances de votre application et effectuez les modifications qui s’imposent.

‍

Chez Yield Studio, nous sommes conscients de l'importance de chaque étape. C'est pourquoi nous accompagnons nos clients bien au-delà du simple développement. La publication et la mise à jour sont des phases essentielles pour que votre application Android reste pertinente et appréciée de sa communauté.

‍

Le développement d'applications Android a grandement évolué ces dernières années, poussé par des innovations et des technologies comme React Native ou Flutter. Si vous envisagez de développer une application Android, il est essentiel de comprendre les bases, mais aussi d'embrasser les nouvelles tendances qui façonnent l'avenir de la conception d’applications mobiles.

‍

Chez Yield Studio, grâce à notre expertise en React Native, nous sommes prêts à transformer votre idée en une application fluide, performante et adaptée à la fois pour Android et iOS. En se tournant vers le futur tout en maîtrisant les fondamentaux du développement Android, nous vous assurons une présence mobile solide et durable. 

‍

🚀 Alors, prêt à créer la prochaine application révolutionnaire ? Nous sommes là pour vous accompagner.

‍

Lorsque l’on développe une solution SaaS, il est nécessaire de bien penser son architecture, surtout si à l’avenir vous réfléchissez déjà à faire découpler plusieurs instances de celle-ci.

‍

Pour imager, prenons pour exemple un site e-commerce.

‍

Vous pouvez faire le choix de partir sur une architecture simple pour votre MVP, avec tout simplement votre boutique à Paris, mais dès lors où le besoin d’avoir plusieurs boutiques se présente, plusieurs questions vont venir à vous.

‍

Ces questions pourraient concerner :

La gestion du stock : est-elle centralisée ? Y-a-t’il un stock par boutique ?

La gestion des produits : est-ce que chaque boutique est indépendante, est-ce qu’elle a ses propres produits ?

La gestion des utilisateurs : est-ce que je stocke les données utilisateurs par boutique ? Est-ce que j’ai une base commune d’utilisateurs ?

‍

Toutes vos réponses vont impacter la façon dont vous allez mettre en place le multi-tenant.

‍

Le multi-tenant

Vous l’avez compris, on parle de multi-tenant lorsque l’on doit gérer plusieurs contextes dans une application, si l’on devait reprendre notre exemple précédent on considèrerait chaque boutique comme un contexte.

‍

Gestion en single-database

La gestion du multi-tenant au moyen d'une seule base de données présente plusieurs avantages significatifs.

Tout d'abord, elle simplifie considérablement la maintenance car il n'y a qu'une seule base a gérer en cas de bugs ou de restauration des backups.

‍

De plus, la base de données demeure relativement simple à gérer avec l'utilisation d'un champ tenant_id (store_id) pour distinguer les différents tenants.

‍

Cela offre un avantage financier car il n'y a pas de surcoût au niveau de l'infrastructure.

‍

L'approche du multi-tenant avec une seule base de données comporte également certains inconvénients notables.

‍

Dans le cas de l'utilisation d'un Framework PHP tel que Laravel ou Symfony par exemple, l'adaptation des packages de la communauté ainsi que des requêtes SQL est nécessaire, ce qui peut entraîner des coûts de développements supplémentaires.

‍

En effet, il faudra ajouter un critère à chaque requête pour spécifier le bon tenant à utiliser, un oubli entraînerait des conséquences assez importantes.

‍

De plus, la centralisation des données peut rendre la restauration de données complexe si on a besoin de restaurer les données pour un tenant précis.

‍

Gestion en single-database multi-schema

Une alternative possible dans l'implémentation du multi-tenant consiste à attribuer à chaque tenant ses propres tables au sein de la base de données.

Cette approche offre une isolation accrue et la gestion des données s'en retrouve simplifiée. Tout comme pour l'implémentation précédente, la restauration des données reste simple. En adoptant cette approche, on ajoute donc une séparation des données de tenants.

‍

Cependant, cette approche présente également quelques inconvénients.

‍

La nécessité de restaurer un tenant spécifique peut être plus compliquée, car il faut sélectionner individuellement chacune des tables lors du backup ou lors de la restauration.

‍

De plus, à mesure que le nombre de tenants augmente, le nombre de tables associées peut devenir considérable, ce qui risque de compliquer la gestion à long terme.

‍

Si des modifications sont apportées à la structure d'une table, chaque table dupliquée pour chaque tenant doit être mise à jour individuellement.

‍

Cela rend également la gestion des migrations compliquées avec des frameworks comme Laravel ou Symfony puisqu'ils n'ont pas été prévu à cet effet.

‍

Gestion en multi-database

L'utilisation du multi-tenant avec une base de données spécifique par tenant offre plusieurs avantages.

Une simplicité côté développement, où il suffit de spécifier quel tenant est utilisé sans adaptations complexes de packages ou de requêtes SQL. L'implémentation est donc plus rapide et le code plus facile à maintenir.

‍

Pour le backup et la restauration, il suffit de le faire sur la base de données du tenant.

‍

On peut optimiser les performances en ajustant les ressources allouées à chaque tenant en fonction de ses besoins.

‍

C’est également le schéma idéal si dans un projet chaque tenant correspond à un site client et que ces clients souhaitent une confidentialité et isolation de leur données.

‍

Et pour les désavantages de cette implémentation, on peut avoir plus de serveurs ou plus de base de données à maintenir, il faut avoir quelques bases côté infrastructure pour mettre en place et configurer les environnements et le coût d'infrastructure sera plus conséquent.

‍

Conclusion

Chaque architecture a ses avantages et inconvénients, la décision devra se prendre en fonction de vos besoins, de vos coûts, de l’effectif de votre équipe et de nombreux facteurs qui composeront la pérennité de votre projet.

‍

Sur le Framework Laravel, plusieurs packages existent pour gérer le multi-tenant. Si on devait en opposer deux, le package Laravel Multitenancy de Spatie propose une implémentation simple et légère qu’il faudra agrémenter de “Tasks” selon le mode de gestion que vous allez choisir, tandis que le package Tenancy d’ArchtechX propose plutôt une architecture plus complexe qui répond à un maximum de besoins avec plus d'opinion.

‍

Il est primordial de s’intéresser à chacune des solutions existantes et de créer des POCs avant de se lancer tête baissée dans l’implémentation du multi-tenant.

‍

Et vous ? Lequel de ces packages choisiriez-vous ?

‍

Si vous hésitez encore pas de panique ! Nous étudierons sans doute plus en détails les différences dans un prochain article.

Dans l'article précédent nous avons initialisé notre monorepo, la CI, le framework de test et préparé la structure de notre projet et plus précisément de notre Architecture Hexagonale pour la lib core.

Dans ce nouvel article de la série notre objectif va être de mettre en place l'Architecture Hexagonale et de montrer comment grâce à elle nous allons pouvoir développer et créer de la logique métier sans UI (donc sans ouvrir le navigateur ou l'app mobile). Pour cela nous allons travailler en TDD (Test-Driven Development, vous pouvez voir mon article à ce sujet) et utiliser le feedback des tests.

‍

L'Architecture Hexagonale

‍

La structure cible

Pour rappel, voici la structure que l'on va mettre en place à l'issue de cet article :

- src
    - wallet
       - __ tests __
‍         - wallet.service.test.ts
       - domain
‍         - wallet.ts
‍         - wallet.repository.ts
‍         - wallet.service.ts
       - infrastructure
         - in-memory-wallet.repository.ts
         - local-storage-wallet.repository.ts
         - mmkv-wallet.repository.ts
       - user-interface
‍         - wallet.store.ts

‍

Chose promise, chose due ! Nous allons maintenant rentrer dans le détail de chaque fichier, à quoi ils servent et ce qu'ils contient.

‍

Développer en TDD

‍

Lorsqu'on travaille en TDD on commence par le test et ce test va nous guider vers un objectif. Il va nous assurer qu'on suit le bon chemin à l'aide de la boucle de feedback régulière qu'on obtient à l'aide des tests. Pour en savoir plus sur la méthodologie à suivre pour faire du TDD je vous invite à nouveau à lire mon article à ce sujet.

Nous allons commencer par travailler sur l'entité Wallet qui correspond à un portefeuille qui a un solde négatif ou positif (par exemple on peut avoir le portefeuille "Compte Principal Julien" qui a un solde positif de 1000€).

Voici les tests mis en place pour cette entité :

‍

describe('Wallet Service', () => {
	let service: WalletService

	beforeEach(() => {
		const repository = new InMemoryWalletRepository()
		service = new WalletService(repository)
	})

	test('getAll > should retrieve all wallets', async () => {
		const newWallet = { id: '1', name: 'Wallet 1', balance: 0 }

		await service.create(newWallet)
		const retrievedWallets = await service.getAll()

		expect(retrievedWallets).toEqual([newWallet])
	})

	test('get > should retrieve a wallet according to an id', async () => {
		const newWallet = { id: '1', name: 'Wallet 1', balance: 0 }

		await service.create(newWallet)
		const retrievedWallet = await service.get(newWallet.id)

		expect(retrievedWallet).toEqual(newWallet)
	})

	test('create > shoudl create a wallet', async () => {
		const newWallet = { id: '1', name: 'Wallet 1', balance: 0 }

		const createdWallet = await service.create(newWallet)
		const retrievedWallets = await service.getAll()
		const retrievedWallet = await service.get(createdWallet.id)

		expect(createdWallet).toEqual(newWallet)
		expect(retrievedWallets).toEqual([newWallet])
		expect(retrievedWallet).toEqual(newWallet)
	})

	test('update > should update the specified wallet', async () => {
		const newWallet = { id: '1', name: 'Wallet 1', balance: 0 }
		const updatedWallet = { id: '1', name: 'Wallet 1', balance: 100 }

		await service.create(newWallet)
		const retrievedWallet = await service.get(newWallet.id)
		const modifiedWallet = await service.update(updatedWallet)
		const retrievedModifiedWallet = await service.get(modifiedWallet.id)

		expect(retrievedWallet).toEqual(newWallet)
		expect(modifiedWallet).toEqual(updatedWallet)
		expect(retrievedModifiedWallet).toEqual(updatedWallet)
	})

	test('delete > should delete a wallet according to an id', async () => {
		const newWallet = { id: '1', name: 'Wallet 1', balance: 0 }

		await service.create(newWallet)
		const retrievedWallet = await service.get(newWallet.id)
		await service.delete(newWallet.id)
		const retrievedWallets = await service.getAll()

		expect(retrievedWallet).toEqual(newWallet)
		expect(retrievedWallets).toEqual([])
	})
})

‍

‍

On peut comprendre via ces tests que les cas d'utilisations de notre entité sont :

• getAll, récupération de tous les portefeuilles
• get, récupération d'un portefeuille en particulier
• create, création d'un portefeuille
• update, mise à jour d'un portefeuille
• delete, suppression d'un portefeuille

Nous allons voir maintenant comme réussir à mettre en place ces tests.

‍

Domain

‍

Nous allons commencé par créer le contenu de la partie Domain. Dans cette partie nous allons retrouver tout ce qui représente le problème à résoudre (problème métier). C'est une partie qui doit être totalement indépendante.

‍

L'entité

‍

Commençons par créer notre entité Wallet correspondant à un portefeuille.

‍

type Wallet = {
	// un identifiant unique (ex: 4d0c2e72-be1a-4e2c-a189-2f321fcdc3a4)
	id: string

	// un nom (ex: Compte Principal Julien)
	name: string

	// un nombre positif ou négatif pour le solde (ex: +1000€)
	balance: number
}

‍


Le repository

‍

Maintenant que notre entité est définie, nous allons définir une interface que l'on appelle également port qui va préciser comment interagir avec cette entité. Nous utilisons ici un modèle de conception d'inversion de dépendances qui nous permet de rester totalement libre sur les outils à utiliser pour respecter cette interface. Nous pourrons très bien implémenté cette interface en utilisant une base de données, une API ou un localStorage par exemple, le domaine s'en fiche.

‍

interface WalletRepository {
	getAll(): Promise<Wallet[]>
	get(walletId: string): Promise<Wallet | undefined>
	create(wallet: Wallet): Promise<Wallet>
	update(wallet: Wallet): Promise<Wallet>
	delete(walletId: string): Promise<void>
}

‍

Le service

‍

Nous avons notre entité et nous savons commencer interagir avec, maintenant nous allons créer un service qui va consumer une implémentation du de notre interface repository (partie suivante dans l'infrastructure).

‍

class WalletService implements WalletRepository {
	constructor(private repository: WalletRepository) {}

	getAll() {
		return this.repository.getAll()
	}

	get(walletId: string) {
		return this.repository.get(walletId)
	}

	create(wallet: Wallet) {
		return this.repository.create(wallet)
	}

	update(wallet: Wallet) {
		return this.repository.update(wallet)
	}

	delete(walletId: string) {
		return this.repository.delete(walletId)
	}
}

‍

Infrastructure

L'infrastructure est composée des différentes implémentations des ports du domaine, on les appelle également Adapters. Ici, nous aurons du code spécifique pour consommer une technologie concrète (une base de données, une API, etc.). C'est une partie qui ne doit dépendre uniquement du domaine.

‍

L'implémentation du repository

Nous allons maintenant voir l'une des implémentation possible de notre WalletRepository. Pour commencer nous allons faire du in-memory, pratique notamment pour la mise en place des premiers tests de nos cas d'utilisations.

‍

class InMemoryWalletRepository implements WalletRepository {
	private wallets: Wallet[] = []

	getAll() {
		return Promise.resolve(this.wallets)
	}

	get(walletId: string) {
		return Promise.resolve(this.wallets.find((wallet) => wallet.id === walletId))
	}

	create(wallet: Wallet) {
		this.wallets.push(wallet)
		return Promise.resolve(wallet)
	}

	update(wallet: Wallet) {
		const index = this.wallets.findIndex((w) => w.id === wallet.id)
		this.wallets[index] = wallet
		return Promise.resolve(wallet)
	}

	delete(walletId: string) {
		const index = this.wallets.findIndex((w) => w.id === walletId)
		this.wallets.splice(index, 1)
		return Promise.resolve()
	}
}

‍

Comment dis précédemment, il s'agit d'une des multiples implémentation possible de notre WalletRepository. Nous pouvons très bien imaginer plus tard mettre en place un LocalStorageWalletRepository ou bien un SupabaseWalletRepostory.

Vous pouvez consulter mon répertoire public de broney sur GitHub pour voir mon implémentation de ces 2 repository et notamment de comment j'ai adapté ma série de test pour garantir leur bon fonctionnement.

‍

‍

User Interface

‍

La partie user interface est composée de tous les adaptateurs qui constituent les points d'entrée de l'application. Les utilisateurs utilisent ces adaptateurs pour pouvoir interagir avec le coeur de l'application. Dans notre cas nous allons régulièrement utiliser des stores en utilisant la libraire Zustand. Il s'agit d'une libraire JS minimaliste pour la gestion d'états (une solution plus complexe serait par exemple Redux).

‍

Voyons voir comment articuler notre store Zustand pour permettre à l'utilisateur d'interagir avec le coeur de l'application.

‍

import { createStore } from 'zustand/vanilla'
import { InMemoryWalletRepository } from '../infrastructure/in-memory-wallet.repository'
import { WalletService } from '../domain/wallet.service'
import { Wallet } from '../domain/wallet'

const repository = new InMemoryWalletRepository()
const service = new WalletService(repository)

type States = {
	wallets: Wallet[]
	currentWallet: Wallet | undefined
}

type Actions = {
	load: () => void
	setCurrentWallet: (wallet: Wallet) => void
	getWallet: (walletId: string) => void
	createWallet: (wallet: Wallet) => void
	updateWallet: (wallet: Wallet) => void
	deleteWallet: (walletId: string) => void
}

export const walletStore = createStore<States & Actions>()((set) => ({
	wallets: [],
	currentWallet: undefined,

	load: async () => {
		const allWallets = await service.getAll()
		set({ wallets: allWallets })
	},

	setCurrentWallet: (wallet) => set({ currentWallet: wallet }),

	getWallet: async (walletId: string) => {
		const wallet = await service.get(walletId)
		set({ currentWallet: wallet })
	},

	createWallet: async (wallet: Wallet) => {
		const newWallet = await service.create(wallet)
		set((state) => ({ wallets: [...state.wallets, newWallet] }))
	},

	updateWallet: async (wallet: Wallet) => {
		const updatedWallet = await service.update(wallet)
		set((state) => ({
			wallets: state.wallets.map((w) => (w.id === updatedWallet.id ? updatedWallet : w)),
			currentWallet: state.currentWallet?.id === updatedWallet.id ? updatedWallet : state.currentWallet,
		}))
	},

	deleteWallet: async (walletId: string) => {
		await service.delete(walletId)
		set((state) => ({
			wallets: state.wallets.filter((w) => w.id !== walletId),
			currentWallet: state.currentWallet?.id === walletId ? undefined : state.currentWallet,
		}))
	},
}))

‍


Avec ce store on remarque qu'on va pouvoir facilement, dans n'importe quel environnement JavaScript, charger, définir, récupérer, créer, mettre à jour et supprimer des portefeuilles, tout en maintenant un état global pour l'ensemble des portefeuilles et du portefeuille courant.

‍

‍

Conclusion

Nous avons maintenant terminé ce deuxième article de cette série sur le développement d'une application web et mobile avec l'Architecture Hexagonale et le partage de la logique métier et des composants UI.

Dans cette deuxième partie nous avons vu comment travailler en TDD et surtout comment écrire de la logique métier sans avoir à ouvrir une quelque interface à l'exception du terminal pour les retours de tests.

Nous avons également eu un aperçu de comment nous allons interagir avec nos applications avec le coeur de l'application, via notre store Zustand. Nous irons plus loin à ce sujet dans le prochain article, la troisième partie : Partager de la logique métier et des composants entre le Web et le Mobile.

‍