Mobile chat clients are undergoing a dramatic rise in importance in both our social and professional lives. The ability to communicate instantaneously is essential, and mobile devices are the only chat devices we can count on having at any given time. Having crafted many chat apps to serve a number of purposes, DB Best understands the development process and the complications that can arise when creating a mobile chat app. Today, we would like to share the architecture solutions that we offer for mobile chat app development.
Chat applications come in all kinds of flavors and vary greatly in complexity. Let’s review them starting with basic functions.
The basis of every such app is the ability for two people to communicate with one another. As complexity increases, additional features are added, such as file and image transfer. Advanced apps have group chats where more than two people can talk at a time. Chats of high complexity will have the ability to send push notifications to users that are offline. An even more complex solution can have the possibility of chat user moderation.
Comparison of XMPP server software
We use two kinds of servers for chat solutions: Openfire and ejabberd. The following table summarizes the major similarities and differences of the two solutions:
Openfire is preferable when communication in the app is desired as a secondary feature and is not the main selling point of the product because it is easier to maintain and build due to being on the popular Java platform. ejabberd is more suited as a primary chatting application for multiple users as it scales better and offers lower resource consumption.
Features
Each app would have to have advanced features in addition to basic ones to stay competitive.
A list of basic features should include:
• View and Edit Chat List, which are components needed for viewing and removing dialogs
• Chat History, Create New Chat, Send/Receive Message, and emojis to be able to adequately communicate
Additional features like two-factor authentication are what makes one’s application stand out.
Two-factor authentication is a popular protective mechanism that adds an additional layer of defense against a hacker by confirming a code sent to the user’s phone.
To implement it, the system needs to have the user’s phone number entered in the correct local format. When a user registers, a confirmation code needs to be sent to the user’s phone to avoid incorrect numbers. Each time the user logs in, a confirmation code gets sent to their number to allow the user to enter the system.
Emojitones is among our latest developed applications that offers engaging real-time conversations with unique emojis.
Our solutions
Over the past years, we have built numerous chat applications using various XMPP servers. Let’s compare two projects, Pikaba and Emojitones, that both have chat possibilities with different design purposes and architectures.
High-level architecture Pikaba V2
Our Pikaba project uses Openfire XMPP servers to communicate with the web API. There are several reasons for that.
Pikaba is a project centered around the possibility to sell and buy goods on the Internet, so its main core is commerce. The chat function is an extension of the app that supplements marketing features. Therefore, the messaging feature is not as heavily loaded as it would be in a general chat app. As Openfire is easier to maintain and build, it perfectly fits the chat purpose of this app.
Emojitones, an application heavily focused on the messaging function, relies on robust, fast, and reliable communication between points. As such, we selected ejabberd as the XMPP server solution that offers great performance, low resource usage, and scalability for future enlargements.
High-level architecture Emojitones
To understand how the architecture works, let’s review the case of user registration. When a user registers, the service layer creates an account, stores credentials on the server, and then contacts the XMPP server through the API for it to create its own instance of account. The backend server then retrieves this information and stores it as a duplicate.
Now when a user logins, the client sends a query to the service layer for it to return user credentials. The server checks whether such data exists and then returns data to the client. The client then validates the received credentials with the XMPP server to seamlessly log in to the chat server.
The design decision of having two servers instead of one is explained by the greater scalability of the application, allowing designers to implement new enhancements in the future.
With a growing number of emerging chat solutions, we are confident to take another step into the world of chat development. Review Emojitones at Google Play Store or App Store, and be sure to tune in again for our future projects.
Now when a user logins, the client sends a query to the service layer for it to return user credentials. The server checks whether such data exists and then returns data to the client. The client then validates the received credentials with the XMPP server to seamlessly log in to the chat server.
The design decision of having two servers instead of one is explained by the greater scalability of the application, allowing designers to implement new enhancements in the future.
With a growing number of emerging chat solutions, we are confident to take another step into the world of chat development.
Be sure to watch our video review of Emojitones, and see you again for our future projects.
