I want to develop a real-time chat application in Android like WhatsApp or telegram
for the all-purpose client should connect to the server via WebSockets and even
offline or online has to works fine. I decided to use Android architecture like MVP, MVVM, and MVI, but I'm confusing which one is suitable for my app
Can anyone help me to choose one of them?
And my second question: is it ok to use WebSockets for all APIs or it should better use WebSockets and REST APIs together?
Thanks for your help
There are quite a few patterns out there for app architectures. The most well known are the classic three-tier architectures such as:
MVC: Model-View-Controller.
MVP: Model-View-Presenter.
MVVM: Model-View-ViewModel.
All these patterns represent the main similar idea — to structure your project’s code in a way that it is separated by the different generic layers. Every layer has its own responsibility. That’s why your project becomes modular: separated code parts are more testable, and your app is flexible enough for continuous changes.
MVP is strongly recommended because a lot of developers are using it now. Even, Google also provides its best practice example on Github. You can see full document here.
I strongly recommend you use MVVM because Google has adopted this approach for Android Projects recently. You can find a lot of examples about it. Especially LiveData and ViewModel mechanisms have a lot of advantages in terms of separation of concerns and managing the relations between ui and data.
I have been using the SingleLiveData class which can be found here. My questions are:
Is SingleLiveData is actually part of the Android Architecture Components?
Is it a good idea to use it?
Is SingleLiveEvent actually part of the Android Architecture Components Library?
No, and it won't be: https://issuetracker.google.com/issues/122413110.
Basically, the official answer is "Yes, regular livedata wasn't enough, so we introduced it in our examples but it's too hacky to be in the library".
Looking at Live data and its Parent/Children inheritance there is no such thing as SingleLiveData. Reading link provided by #Raghu, I find statement:
The SingleLiveEvent class was created for a sample as a solution that worked for that particular scenario. It is a LiveData that will only send an update once.
So to answer your questions:
Is SingleLiveData is actually part of the Android Architecture Components?
No, it is not!
Is it a good idea to use it?
This depends on many factors. Since I haven't used it I will give general idea. Using classes that you find in demo app or other way might not be guaranteed to be updated or bug-fixed. So if you understand the class so well that you can fix any bug you might find, and if it fits your need, then use it.
But generally I would avoid that if I can find something that is well maintained and does the same job.
Since from skimming the article I get impression he is trying to make some sort of observer pattern, I will suggest you check out rxjava
I'm using ObservableField for single UI events but it requires some hacking to use with Fragments to subscribe/unsubscribe automatically.
I've been reading about architecture to android projects. And I found some stuff, but I guess I misunderstood some concepts or not even understood at all.
One of my questions is about handling api objects, if I have a local database, Should I use the same object from api to store in local database?
I'm also looking for explanation about why use MVVM or MVP, actually they looks like different stuff, I have figured out that MVP is a pattern more concerned about handling UI responsibilities, MVVM I think is oriented to handle communication between UI and database. So I misunderstood the concepts or it make sense?
The last but not least important topic is about dependency injection, I have read about the concept and this question came to my mind, why should I use any framework as dagger to handle this, if I can handle this pattern by myself, once it's not thaaat complicated?
Should I use the same object from api to store in local database?
It can really depend on how good your API object is. You should rather base your local database object on what it really mean in a logical way and if your endpoint is well done it could be the same. The important part in your architecture is to isolate your logic parts from your I/O parts (UI, database, API) so if you want to redesign your UI, change the Webservice you use it will not be too painful.
So I misunderstood the concepts or it make sense?
I am not that familiar with MVVM so I can not really answer that question. But for me the important is not to follow "by the book" one pattern or another but rather to adapt your architecture from what you like from each. I currently try do to so with the Clean Architecture. You can take a look at all the concepts Uncle Bob speak about in this article about making code cleaner and more maintainable.
why should I use any framework as dagger to handle this, if I can handle this pattern by myself, once it's not thaaat complicated?
You don't have to use dagger if you're not familiar with it. But if your project start to grow and you start to be a team of 2, 3, 5... working on it, a framework as dagger can help you keeping a common standard about how you make your dependency injection and then making the code more coherent. Dagger also provide some tools as scopes that can save you some time if you're familiar with it.
I've been using the native Android SQLite library in the last time, but I am not pleased with the re-usability and readability. There are some ORM database libraries I found for Android, but I wonder whether those are useful as I got a whole bunch of complex select and delete operations I have to be able to run.
Can you suggest me any appropriate library?
Tried this once. Pretty good I must say.
http://ormlite.com/
Are there any good database abstraction layers/object relational mappers/ActiveRecord implementations/whatever they are called for Android? I'm aware that db4o is officially supported, but it has quite a large footprint and I'd rather use a more conventional database (SQLite).
I am the main author of ORMLite which was designed to be small[ish] but still provide higher level functionality. ORMLite makes calls to the native Android OS database APIs to support its ORM functionality. See the following for general information
http://ormlite.com/sqlite_java_android_orm.shtml
Here are some Android example applications:
http://ormlite.com/docs/android-examples
I tried the Sugar ORM, which is very basic (and easy to use) but it worked for my needs.
Sugar website
There is an 'android-active-record' project which provides ActiveRecord abstraction for accessing Android SQLite database.
It's available here: http://code.google.com/p/android-active-record
It allows to eliminate most of boilerplate coding when performing CRUD operations on database entities and also minimizes efforts for creating/maintaining a database structure
Try ActiveAndroid. It is free and open source (Apache Version 2.0).
From the website:
ActiveAndroid is an active record style ORM (object relational
mapper). [...] ActiveAndroid allows you
to save and retrieve SQLite database records without ever writing a
single SQL statement. Each database record is wrapped neatly into a
class with methods like save() and delete().
[...] Accessing the database is a hassle, to say the least, in Android.
ActiveAndroid takes care of all the setup and messy stuff, and all
with just a few simple steps of configuration.
If performance and size matter, you should have a look at our open source ORM tool greenDAO. We wrote it because we did not want to compromise on speed. Other tools heavily rely on reflection, which is very slow on Android. Despite the tiny size (<100k), it supports relations, query builders, etc.
Shameless plug, but I've been working on a new open source Android framework called Infinitum. One of its main features is an ORM which has a criteria API similar to Hibernate and a few other nifty features (associations, lazy loading, etc.). It's still in its early stages, but I think it's coming along pretty nicely.
I have written a new ORM, for android, that's aimed and being as easy as possible to implement. It support lists and SQL free migration a couple things which I always found had an overhead in other libraries.
http://www.rushorm.com/
I faced the same problem and looked at both android-active-record and ActiveAndroid. I found android-active-record didn't handle the things I cared about (relationships for example), and ActiveAndroid isn't free. Therefore, I decided to write my own library. It's called AndroidRecord and it's hosted on GitHub and you're free to do with it what you want (I think I'm going to go with the MIT license). I use this every day and I'm content with it, but I'd love to get feedback.
If you need to know how to use it, I'm working on the documentation. If you need it right away, you can check out this lame example project which should be enough to dip your toes in. You can also email me of course.
There's also Neodatis and Perst (Lite).
I've toyed with Perst a year ago and concluded it's not worth it.
After all, a) Android runs on a rather restricted device with ~16mb of heap space per app and b) You customers would really appreciate performance and low power consumption.
So my advice is to go with SQLite and hand-written SQL. It's not hard at all and the wrappers provided by Android SDK are really nice.
EDIT: In 2012 the advice would be to use the ORM component of DroidParts (which is my project).
I was comparing basics of ormlite and greendao some time ago. You might want to take a look there. I plan to write some follow up with more advanced stuff in the near future but for now it's only a basic stuff. In my own project I'm using GreenDAO.
Have a look at Androrm. It is open source and well documented (see here). If you ever worked with django, you will notice, that the syntax is very similar.
Androrm also supports abstraction classes for the most common field types, plus relational fields. This way it enables you to query for your data in an very easy manner with only very little effort on your side.
SQLite is explicitly part of Android:
http://developer.android.com/reference/android/database/sqlite/SQLiteDatabase.html
However you might have to create your own abstraction layer (query builder for simple queries), or otherwise deal with SQL.
Maybe http://developer.android.com/reference/android/database/sqlite/SQLiteQueryBuilder.html is what you need?