I came across the Epoxy library while looking for information about RecyclerView.
Epoxy is a library that makes RecyclerView easier to use.
I haven't applied it to my app yet, but I think it will be easier if I apply it.
Because the RecyclerView I use is based on two view types, and both items are dynamically added/removed frequently (DiffUitl is also used).
However, while reading the description of the Epoxy library in Git,
I came across the following:
Additionally, Epoxy adds support for saving view state and automatic diffing of item changes.
I'm curious as to what automatic diffing you're talking about here works based on.
Is it DiffUtil internally or simply notifyDatasetChanged()?
If it uses DiffUtil then I'm going to use Epoxy or I'll consider it.
or simply notifyDatasetChanged()?
They are not using notifyDatasetChanged() as per the documentation:
Epoxy's automatic diffing to reduce the overhead, while also efficiently only updating the views that changed.
Is it DiffUtil internally
DiffUtil is used for the EpoxyController class, but not for EpoxyAdapter class, the documentation says:
The Android Support Library class DiffUtil is used for diffing in
EpoxyController. For legacy reasons, the older EpoxyAdapter uses a
custom solution for diffing.
So, As you still designing your app, I expect that you'll be using EpoxyController rather than the legacy EpoxyAdapter; and therefore, DiffUtil is already utilized.
If it uses DiffUtil then I'm going to use Epoxy or I'll consider it
It's up to you; using libraries in general has pros and cons in terms of continuity, security, limitations, complexity .. etc.
Related
Suppose in a project I have 10 XML file. Within 3 of them don't require data binding feature i.e., we just need the reference of views, thus don't need to wrap all the three XMLs into <layout>...</layout> tag.
So is it a good idea to use both view binding and data binding, or just the data binding as it's superior of view binding?
P.S: Wrapping up into <layout>...</layout> is not a big deal, but I am asking for best practices we should follow.
The answer to your question is yes, you can use data-binding and view-binding together, but it's not recommended because it significantly impacts your build time. There is nothing view-binding can do that data-binding cannot.
You can check this link that compares these two approaches and explains the differences, but normally view-binding can be a better choice due to a lower build time and better effectiveness.
Yes both can be used in a project for the UI where the data is linked to the data of the viewModels used it is preferred to use DataBinding and normally you should use ViewBinding as it is less resource intensive and efficient, lastly you can use both of them synonymously in project.
I am new in Android, I have finished some Android app development courses and now I am trying to apply what I learned. I've chosen a news app for it. It will extract news' from 5-10 source and display them in recyclerview.
I recognized that the course materials I used is outdated. I've used AsynctaskLoader to handle internet connection issues but now in official Android documentation it says "Loaders have been deprecated as of Android P (API 28). The recommended option for dealing with loading data while handling the Activity and Fragment lifecycles is to use a combination of ViewModels and LiveData."
My question is should I convert my code to comply with ViewModels and LiveData or would Asynctask handle my task (or any other suggestion)? As I mentioned I only want to extract news data from a couple of source and display them in the app. It seems I don't need data storage feature. But, for now I have added two news source and the app seems to load news data a little bit late. Does this latency has something to do with using loaders? Would using viewmodels speed up news loading task (especially when there are lots of news source)?
If you've already written it with Loaders there's no reason to rush to change it. Deprecated doesn't mean gone. And no, Loaders don't add significant performance penalty- any perf issues would be elsewhere in your app.
Loaders are good because of its ability to handle life cycle, but it is not as efficient as LiveData and ViewModel. If you care about performance, speed and being latest, use Android Architecture Components (LiveData, ViewModel), also, you don't have to stick to the old system of doing things, you can write a simple AsyncTask and wrap it with ViewModel and LiveData. It works like a magic and better than Loaders. For information on how to wrap AsyncTask in LiveData and ViewModel, visit https://medium.com/androiddevelopers/lifecycle-aware-data-loading-with-android-architecture-components-f95484159de4
Loaders have been deprecated as of Android P (API 28). The recommended option for dealing with loading data while handling the Activity and Fragment lifecycles is to use a combination of ViewModels and LiveData. ViewModels survive configuration changes like Loaders but with less boilerplate. LiveData provides a lifecycle-aware way of loading data that you can reuse in multiple ViewModels. You can also combine LiveData using MediatorLiveData , and any observable queries, such as those from a Room database, can be used to observe changes to the data. ViewModels and LiveData are also available in situations where you do not have access to the LoaderManager, such as in a Service. Using the two in tandem provides an easy way to access the data your app needs without having to deal with the UI lifecycle.
Both of my colleague and I have experience in MVVM of Web App, while we are new to native android development. Now we have contrary opinions about android data-binding -- I'm a fan of it while he is not.
My Arguments:
Reduces boilerplate code which in turns brings
Less coupling
Stronger readability
Powerful, easy to implement custom attribute and custom view
Even faster than findViewById (details)
His Arguments:
The auto-generated .class increases app size.
Harder to debug
I've made some investigation but there are not many discussions about it. Now I want to collect the pros and cons of android data-binding.
Aspects of discussion include but are not limited to:
unit test
app size
performance
learning curve
readability
coupling
I will comment on your arguments first then I will state my opinion:
1.Remove boilerplate code - it will remove some it will just move some in the xml or it will require additional classes. So you have to be careful and balance the use of data binding.
2.Stronger readability - depends if you are a new developer then you may find it easy to learn it but if you previously worked on android you will need extra time to learn it.
3.Powerful - the code has more power, you can implement whatever you like in code. Think about it like this, everything you implement using data binding has a code equivalent (it might be longer and more code to write), but the revers is not valid.
4.Even faster than findViewById - comparing the speed between these two, in my opinion is useless, you will never notice the difference, if you see some difference, then one of the implementation is wrong.
5.Auto generated class - it's true it will increase the app size, but again only if you have tons of it it will matter. It's true that on the android dev web site they state that it's kind of bad to use libraries that create autogenerated code or annotations that will generate extra code.
6.Hard to debug - depends, like readability, of what you are used to, heck debugging is hard either way for some problems, and you will get better by debugging not by using a different library.
So this is pure my opinion, I've developed many apps using different libraries and different approaches, and they all had pros and cons, but what I've learn: balance everything, don't use tons of libraries, don't waste time implementing things that are implemented already and work well, don't "decouple everything", don't "couple" everything, don't use code only, don't try to "generate" everything.
I think it's quite wrong, and you can get a wrong idea, if you ask for 'pros & cons' about some library/implementation, because usually it won't be impartial, you will get a lot of pros from somebody who used the library in a specific way and it worked and others will give you cons because they used different and it didn't work.
So in conclusion, I think you should check what the library can do for you and what can't do for you and decide if it's good for your setup. In other words, you should decide if a library is good for you not other people ;).
Update - 8 August 2018
First of all I still stand with my initial conclusion, balance is the key in these kind of situations, but in my case, data-binding speed-up a little bit the development process and also improved it. Here are a few new points that you should all think about.
Testing the UI -- with data-binding it's much more easy to test the UI, but data-binding it's not enough for that, you also need a good architecture and using the Google suggested architecture will show the actual power of data-binding.
The most visible changes were provided for points 2 & 5 from my original answer. It kind of was easier to read the code after we decided to use data-binding, and the most important thing here is: we as a team decided that we will use data-binding and after that, we kind of expected to have most of the trivial and basic UI setup in the XML file.
For the debugging part, here's a little bit tricky, Android Studio has a lot to improve on the errors and autocomplete for the data-binding but the most common errors you'll get them after the first 2-3 occurrences. Also I've learned that a "clean project" form time to time, helps A LOT.
Another point that you'll have to take in consideration is the project configuration to use data-binding, right now AS (3.1) supports by default data-binding (just set a flag in graddle) for Java, but I had some issues with Kotlin, after a bit of search here on SO, I managed to fix everything.
As a second conclusion (from my original post), if you can and the project deadline/requirements/etc allows you to try data-binding, go for it it will worth (unless you do some really stupid stuff :)) ).
I am working on a huge Android project and the team has decided to phase out Data Binding library. Why? The primary reason is that it is exacerbating build time(10+ mins), by generating a lot of classes in the build process.
Even if i like danypata's answer i would like to add/edit some of his statements to android databinding.
1.Remove boilerplate code - As written in danypatas answer it removes some code and adds some code somewhere else like in layouts. That doesnt mean that the boilercode isnt reduced because usually it is reduced.
For example you may want to create a bindingadapter, which handles several custom arrayadapters for your spinner/recyclerview/listview/.. but requires only one simple adapter. You may want to use the adapter in your layout by using e.g.
app:myCoolAdaptersData="#{model.mydata}"
Now you can create your generic adapter and (re)use your bindingadapter in all your layouts instead of using for example:
ListView lv = findViewById(...);
CoolGenericAdapter<MyModel> coolAdapter = new CoolGenericAdapter<>(...);
lv.setAdapter(coolAdapter);
This is just one simple example which recudes the code alot in larger projects. Another sample to recude code is, that you bind your model to your layout. Updating field-values of your model usually updates your model aswell (if its at least a BaseObservable/ObservableField).
That means that you dont need to find all your views, update your views, update your models, ...
2.Stronger readability - The extra time spent for learning databinding doesnt really matter. Since the layouts are not really different except that you wrap them into a layout tag and put your namespaces there, it doesnt really differs from "regular" layouts. Using bindingadapters and accessing the model in the layout may take some time, but usually you can start beginning with the basics which are easy and beautiful to use aswell. Learning new stuff always takes time, but you will easy overhaul the time when using databinding after a while.
3.Powerful - Yes, its very powerful. Its easier to reuse existing code, reuse existing bindingadapters and may lead to more generated code but thats not always true. For example you may create multiple adapters within several classes instead of creating one bindingadapter, it may be hard to "optimize" it later. Optimizing the Bindingadapter means that it gets updated everywhere. Optimizing may decrease the "lines of code" since the boilerplace is reduced anyway.
I agree to 4. and 5.
6. Hard to Debug Since AS 3.0+ outputs useful hints like syntax issues in your layout (line number and file) its easy to debug databinding generated code. If you have problems finding the issue you may also want to check for errors in the generated code. Some librarys like dagger 2 or android architecture library may confuse you because the error lines doesnt match with the real "error". This is due generated code by other annotation processors. If you know that those annotation processors may get in trouble with databindings error outputs, you can easy fix that.
7. Unit Testing Its possible like if you dont use databinding by using executePendingBindings.
8. Readability Readability may be better without databinding. Since you put some business logic into your layout, some into your real code, it may lead to spaghetti-code. Another problem is that using lambdas in your layout may be very confused if the "layout-designer" doesnt know which param may be used.
Another very big problem is that bindingadapter can be everywhere. Using BindingAdapter annotation generates the code. That means that using this in your layout may lead to problems to find the proper code. If you want to update a bindingadapter you need to "find" it.
When should you use what? For larger projects it is a really good idea to use databinding together with the mvvm or mvp pattern. This is a really clean solution and very easy to extend. If you just want to create a small simple application you'r fine using MVC Pattern without databinding. If you have existing generic bindingadapters which can be used from other projects you may want to use databinding, because its easy to reuse this code.
Data binding, concept wise looks promising to me, but I do not like the implementation part.
I would appreciate a bit more simpler and direct approach to it.
Thus I feel lot more comfortable in keeping it old school.
Model classes, mutable objects, observers feel like too much to me, if some how the data variables used for binding are received as Objects that are mutable and observable directly in a class , then that would make the process lot more cleaner, simpler and concise.
Google has launched a project on Github in order to demonstrate different architecture implementations.
todo-mvp
In its' simple MVP implementation's model layer, which applies the Repository pattern, it simply contains one POJO(Task) and we already have a bloated model layer here.
It's quite common to have dozens of POJOs in a REAL project. And it's easy to imagine how big the repository would grow.
Whenever I want to add or amend something, like adding a Owner(of a Task), I have to add so many lines of code in each one of the classes in the model layer. No need to mention that we have to write so many hard-coded SQL statements.
Is there a better way to avoid these things?
That project structure is good. If you want to save your time and avoid writing many lines of boring SQL statements, you can adopt some ORM libraries such as Realm, GreenORM etc. Same for the other stuffs.
Also checkout a new MVP framework here: http://robo-creative.github.io/mvp. With it, you can avoid writing tangled logic for view-presenter binding. The framework also supports Dependency Injection as well.
What are some pros and cons of using RoboBinding vs Android Binding.
eg.
can RoboBinding be used on fragments ?
What about Android binding for fragments ?
Does any use reflection to slow down Android at run time ?
Also which ones can be obfuscated with proguard ?
Can any of the two auto generate a viewModel interface ?
Android Binding info
RoboBinding cast
I've used both and although I like RoboBinding (I even have some contributions to the code) I've switched to Data Binding for all my binding needs.
http://developer.android.com/tools/data-binding/guide.html
It doesn't have some of the bi-directional binding goodness that I like in RoboBinding but it's really solid at this point and from Google directly. It allows you to do some pretty cool stuff
Here's a post I have that goes into Data binding as well as other stuff
http://blog.liffft.com/2016/01/19/rx-java-spock-groovy-android-bindings-android-might-now-be-testable-say-what/
I didn't use Android Binding, but have some experience with robobinding
yes, quite seemlessly
don't know
I didn't notice any problems with forms binding up to 30 properties
to some extent. you have to preserve all PM properties you bind to, constructors and annotations
no
please note that robobinding is not working well with material design and is not working at all with AppCompat 22+
May I also suggest Anvil (https://github.com/zserge/anvil)? The whole library API is only ~10 most important methods. Inspired by React.js.
No reflection used (other than creating views, but XML inflaters use that as well). Can be used with Proguard, but it's only ~100KB when unstripped, so I normally use with without Proguard. Best used with Kotlin, but also supports Java 6/8.
And if you're familiar with React and are looking for Redux implementation - here's one I normally use with Anvil: https://github.com/trikita/jedux
Just want to let people know who may have Googled this as I did today, that RoboBinding is no longer maintained.
Some alternatives could be RoboMVVM or Anvil, but not sure if either of those are maintained either (last commits were in 2014 and 2019 respectively).
At this point I think the safest option is to use Android Data Binding directly, then you don't have dependencies on third-party frameworks that you might have to remove later. And Android Data Binding does now support two-way data binding, contrary to one of the other answers here.