Le SDK Easemob présente actuellement de nombreux bogues et n'est pas recommandé pour une utilisation en production. La version 2025 semble moins stable que la version de 2014.
La version 'EaseChatUIKit', '4.13.1' est relativement stable, mais présente un problème dans la liste des conversations : le dernier message n'affiche pas l'avatar et le pseudonyme (les notifications sont reçues en production et en environnement de test, et les cellules personnalisées ne flottent pas).
La version 'EaseChatUIKit', '4.15.0' présente le même problème d'affichage dans la liste des conversations, et les notifications ne sont pas reçues en production (fonctionnelles en environnement de test).
La version 'EaseChatUIKit', '4.16.0' corrige le problème d'affichage dans la liste des conversations, mais provoque un dérangement des cellules personnalisées dans l'interface de discussion, avec des notifications non fonctionnelles en production.
La version 'EaseChatUIKit', '4.16.1' corrige les problèmes de flottage des cellules personnalisées, mais les notifications restent non fonctionnelles en production (le code de test a été déployé en production, rendant le binding du deviceToken inefficace).
- Pour l'application mobile, nous utilisons l'interface utilisateur de liste de conversations et de discussion d'Easemob
pod 'EaseChatUIKit'
https://doc.easemob.com/uikit/chatuikit/ios/chatuikit_overview.html
L'initialisation du SDK se fait avec un identifiant et un mot de passe Easemob (notre backend doit enregistrer tous les utilisateurs sur Easemob, puis renvoyer l'identifiant et le mot de passe à l'application mobile lors de la connexion).
Pour l'envoi de messages, notre backend doit renvoyer l'avatar, le pseudonyme et l'identifiant Easemob du destinataire. Il est également recommandé de renvoyer ces informations pour l'utilisateur actuel.
Pour les anciens utilisateurs de l'application qui n'avaient pas la fonctionnalité IM Easemob, il est nécessaire de vérifier : isLoggedInBefore : vérifie si l'utilisateur s'est déjà connecté. Si la méthode logout n'a pas été appelée après une connexion réussie, cette méthode renverra toujours true isConnected : vérifie si le SDK est connecté au serveur de discussion
Messages personnalisés :
// Construction des données de la carte d'informations, transmission de données JSON dans ext
NSMutableDictionary *donneesCarte = [NSMutableDictionary dictionary];
// Définition d'une URL d'avatar par défaut
// Création du corps du message personnalisé, "event" est le type de message personnalisé
EMCustomMessageBody *corpsPersonnalise = [[EMCustomMessageBody alloc] initWithEvent:@"typeCarte" customExt:donneesCarte];
// Création du message
EMChatMessage *message = [[EMChatMessage alloc] initWithConversationID:idConversation
from:EMClient.sharedClient.currentUsername
to:idConversation
body:corpsPersonnalise
ext:@{}];
// Envoi du message
[[EMClient sharedClient].chatManager sendMessage:message progress:nil completion:^(EMChatMessage *message, EMError *erreur) {
if (erreur) {
NSLog(@"Échec de l'envoi de la carte d'informations: %@", erreur.errorDescription);
} else {
NSLog(@"Envoi de la carte d'informations réussi");
}
}];
Notifications push Easemob : le backend d'Easemob nécessite le certificat de notification, et lors de l'initialisation du SDK, le nom du certificat doit être transmis, sinon les notifications ne seront pas reçues.
- Notre backend
Doit enregistrer tous les utilisateurs sur Easemob, puis renvoyer l'identifiant et le mot de pase Easemob de chaque utilisateur à l'application mobile via l'interface de connexion.
Doit également synchroniser les avatars et pseudonymes avec Easemob via un script.
Lorsqu'un utilisateur modifie son avatar ou son pseudonyme, notre backend doit mettre à jour ces informations sur Easemob.
La version gratuite d'Easemob permet d'enregistrer jusqu'à 100 identifiants. Une fois ce quota atteint, il est possible de le réinitialiser pour enregistrer 100 nouveaux identifiants.
- Messages système ou support client
Notre backend doit enregistrer un utilisateur spécifique sur Easemob pour envoyer des messages à tous les utilisateurs.
- Notre métier consiste en une application B2B pour les gestionnaires et une application B2C pour les locataires. Le besoin est que ces deux applications puissent communiquer : les locataires peuvent discuter avec les gestionnaires.
Dans le backend d'Easemob, nous créons une application pour l'environnement de production, utilisée par les deux applications (B2B et B2C) avec le même appkey. L'initialisation du SDK utilise ce même appkey.
Dans le backend d'Easemob, nous créons une application pour l'environnement de démo, utilisée par les deux applications (B2B et B2C) avec le même appkey. L'initialisation du SDK utilise ce même appkey.
appkey
Selon le nom de domaine de notre entreprise, nous utilisons l'appkey de production pour l'environnement de production, et l'appkey de test pour les autres environnements.
Configuration du certificat de notification : le nom doit correspondre à celui défini dans le backend d'Easemob
#if DEBUG
// Environnement de développement
option.apnsCertName = "C_dev" // Nom du certificat de notification
#else
// Environnement de production
option.apnsCertName = "C_release" // Nom du certificat de notification
#endif
- Les deux applications ayant des noms de package différents, doivent toutes deux recevoir les notifications. Il faut donc générer séparément les certificats de notification depuis le compte développeur Apple.
B_dev
B_release
C_dev
C_release