How develop realtime chat application in 2019? — part I
First of all, I have to introduce the realtime chat application that I published a short time ago.
It is Society. Society, allows people to meet other people and interact them with instant messaging. It has a lot of instant messaging feature like the other equivalent apps.
In this article series, I intend to get a cross my development methods that I applied my project end to end.
Also, in this part of the series, I will mention these matters:
- Platform Choices
- Single Activity
- Package Structure
- MVVM — Repository Pattern
- Effective RxJava Usage
In client side, I developed with native Android SDK. Android native development is also my profession.
Also, I used Socket.io for realtime infrastructure. Socket.io supports only node.js for server side development. Socket.io has client libraries in Android and iOS platforms. In my opinion, this is awesome, because when I decide, develop Society’s iOS app, I can use same methods with Android side and it will be make development process easier.
Last year, Google had advised Single Activity per App approach officially. So, I followed this advice.
I only have HomeActivity as an activity in all of project and it is responsible to host fragment’s in its own.
This was my first single activity experience in all of my projects. I liked this approach, it is very useable and manageable for applications which has few screens especially.
Here is the project’s package structure.
Business: API models and project’s service endpoints are in business package.
Infrastructure: Notification, networking and analytics/reporting feature’s are here. This package contains all of infrastructural things.
Presentation: This package contains project based, general classes. For instance, base activity/fragment classes, base widgets, adapters etc. like you see in the screenshot which you see in left.
Screens: Contains screen’s own packages. Each screen has a package to handle easily manage them.
MVVM — Repository Pattern
Android’s official sources tells that:
- Repositories must be only responsible to get data from local database or remote server.
- ViewModels must be responsible get data from repository and provides to controller classes.
- Controllers (activity/fragments) must know and interact only viewmodels.
I adopted this approach end to end in my side project Society. For example, we can analyse login action over code of pieces.
LoginFragment knows only it’s own viewmodel and access datas over it.
LoginViewModel knows only it’s own repository and access over it. If necessary, maps data here in background thread under favour of Rx’s nature.
LoginRepository can access service layer. Service’s methods return Rx Observables. Repository is only responsible for get data source.
In my own structure, developer (it’s me in this project) can only access the service layer in repository classes.
Effective RxJava Usage
I like RxJava and I used it in my Android framework. I make network calls over RxJava and subscribe observables that have the meaning for network calls.
Also, I handle realtime event’s with Rx Observables.
For instance, in ChatFragment, I subscribe message receiving event.
We will continue to this series with socket.io client and server side, and handle events in Android application and notify screen with best practices when an event fired.
Thank you for using your precious time to reading this article. If you liked it clap your 👏 to say “thanks!” and help others find this article.