I've recently had some tasks requiring that I need to log an Android app for some events, like adding to cart, checkout, signing in to the app, pressing on a specific button, etc... to Facebook and Firebase platforms.
Since these are non-functional requirements, I figured out it could be a good idea to start implementing the AOP (Aspect Oriented Programming) method, so events can be intercepted without changing any code in the app.
I've made my research and found out that you could implement AOP using either the AspectJ lang (which is compiled to Java Bytecode and can talk to java directly), or AspectJ annotations like #Before #After and #Around to intercept the pointcuts.
However, I have read some articles like This one And This one, they don't seem to be working for me, the code before of after the pointcut calls do not get invoked at all. I feel like I might have something missing or outdated in the build.gradle aspect code that is mentioned in the first article (which is 8 years old really).
I won't be providing any code here since I've tried the exact same examples in the tutorials and didn't work for me.
I'm asking for someone recently implemented AOP in his Android app.. And could provide me with some steps that I can follow, so I can get the code in the aspects invoked and working.
Also, I've seen some people on the internet trying to implement the aspects in another Android module, and some in another src directory, if someone would explain the difference? And since I'm using Firebase and Facebook dependencies to log the events, wouldn't making the aspects in a different module affect me in any way?
Also, if anyone knows if I'm approaching the best way here to log the events (for Firebase and Facebook), or there could be better? I've went to AOP since I don't feel like changing the existing code to log some events is ideal.
Please, and thank you.
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.
I've been looking into this for a while now but there seems to be old solutions that focus on mainly calling frege from Java. Is there a way to write an complete app/Activity purely in Frege? If not, why?
You might look here, it's most recent. http://mchav.github.io/frege-on-android/
Don't be shy to contact the author directly.
The short answer to your question: It is possible to write a complete App in Frege, except for a bit of glue code that implements the interface android.app.Activity. The reason being that we can't implement interfaces in Frege.
So my company is very strict and tedious when it comes to bringing in new libraries. We do have RXJava though and I really want to use that in order to replace some of the async tasks that are a pita, and to make a really solid auto suggest without firing off long network calls on every text change.
My question is this:
Given some code like this
final EditText etSearch = (EditText) findViewById(R.id.crew_search_box);
Observable<EditText> searchTextObservable = ViewObservable.text(editText);
Can I set my observable to accomplish this same thing WITHOUT using RXAndroid and only using RXJava?
I am new to RX so forgive me if this is really just an out-there question.
Sure you can!
First of all, since you're mentioning ViewObservable: it's no longer there when you update your dependencies. ViewObservable and WidgetObservable have been moved, for various reasons. The initial 1.x release of RxAndroid meant a major refactor in terms of what is in there compared to the 0.x releases. You can read more about that here.
If you don't want to add RxAndroid as a dependency (or RxBinding) for that matter, just refer to the implementation details of the classes you're interested in and copy that into your own project. There's probably no need to make any modifications, but of course making copies means that you don't get the benefits of improvements either.
All RxAndroid (and RxBinding) really does is expose a bunch of convenience methods and implementations relevant to Android (surprise, surprise) that makes the lives of many a little easier. No one is, however, forcing you to use them. You can maintain your own code that you're interested in in parallel. Not sure that makes a lot of sense, but hey, it's possible.
You could always code review the parts of RxAndroid that you want and include only them. To be honest RxAndroid will implement view observables better than you will on your own.
Ok, so it might be a stupid question that is very obvious... anyway, I am making a new application and I wanted to know if I should make a package for every category of objects,
for example: Monsters, PowerUps, Powers, FrameWork(where I make classes that I implement from) etc.
I am using canvas and a thread class to handle what happens inside the canvas(lockcanvas, unlock and post etc.)
So, should I make everything in one package or few packages, and will it be harder or do I need to know something to use these packages? Thanks!
It's entirely up to you how you group your classes. In terms of coding, it makes little difference as Eclipse will work everything out for you. Instead, consider how you can use packages to help you quickly go to the right place when you return to your code in six months time to correct a bug.
IMHO, your proposal seems to result in a few too many packages for comfort. I don't know how complicated your code is, but if you've only got a handful of classes per package, that's probably a bit too fine. Probably better to break your app into larger chunks of functionality. It's also worth spinning common "helper" or "utility" classes into their own package too.
As with any aspect of coding style, opinions will vary. But I found the following article to be well argued...
Package by feature, not layer
You could get the same organizing effect you are looking for by using folders inside the package to group code without all the hassle of additional packages. Unless you have a special technical requirement for multiple packages I would try to keep things as simple as possible.