Is EventBus suitable for the tasks I am trying to complete? I need a callback whenever any application prints a document.
Yes it is good for getting callback.
But if you only need to use it single time then do not use EventBus library for that, you can use BroadcastReceiver or our own defined interface listener.
Because for using one time the library is not a good idea. If There are many use of callbacks then No-doubt EventBus is best.
I need a callback whenever any application prints a document.
Android does expose this information to apps.
Is EventBus suitable for the tasks I am trying to complete?
No, insofar as an event bus does not cause Android to provide you with information that it otherwise would not.
Related
What's the equivalent of an NSNotification in Android?
I need to be able to send and receive the notification from arbitrary classes (not necessarily activities).
This pattern is called EventBus, and theres some libraries for that.
You can use LocalBroadcastManager or can implement Observer interface to accomplish your task as iOS NSNotification.
My app is heavily depended on Local broadcast ,for every activity invocation am invoking the broadcast registration method so is it good to move to any event bus.
Two primary concerns of using Local broadcast Manager.
Every activity require the registration
Registration method execution time(Around 10 actions are registered)
I think the event bus will improve overall execution and performance of my app.
Most event bus libraries provide reflection-based registration which is less efficient than LocalBroadcastManager. The main reason for using the event bus would be coding ease.
afaik, there are some benefits using event-bus instead of LocalBroadcastManager:
Code decoupling.
By decoupling your code, you will minimize your class which formerly using LocalBroadcastManager. Simpler code less error and improve code readability.
Ease of Maintenance.
This somewhat related to no.1, decoupled code make it easy to maintained.
Localizing error.
Avoids complex and error-prone dependencies and life cycle issues.
Avoid further bugs.
EventBus FAQ
How is EventBus different to Android’s BroadcastReceiver/Intent system?
Unlike Android’s BroadcastReceiver/Intent system, EventBus uses
standard Java classes as events and offers a more convenient API.
EventBus is intended for a lot more uses cases where you wouldn’t want
to go through the hassle of setting up Intents, preparing Intent
extras, implementing broadcast receivers, and extracting Intent extras
again. Also, EventBus comes with a much lower overhead.
A library that I am using has an Android activity. I would like to pass a callback to the activity to get notified of certain user events like when user enters a specific code or draws something on the screen. I am not able to find a way to pass callbacks to the android activity.
Note: I can edit the library, however, I prefer to leave the activity within the library for architectural reasons and ease of testing without integrating with the larger app.
What is the best possible way to solve this? Are there any Android design patterns?
What is the best possible way to solve this?
Modify the activity to post an event on an event bus (greenrobot's EventBus, Square's Otto, LocalBroadcastManager when these things occur. Then, listen for those events elsewhere in your app.
I prefer to leave the activity within the library for architectural reasons and ease of testing without integrating with the larger app
Then convince the developer of the library to modify the activity to post an event on an event bus (greenrobot's EventBus, Square's Otto, LocalBroadcastManager when these things occur. Then, listen for those events elsewhere in your app.
Or, convince the developer to offer some other means of accomplishing this (e.g., you subclass the activity and override certain methods to be notified of these events).
It sounds like you have access to the library src code, so create an AIDL interface for communication between your app and the lib. You can set up a callback via AIDL and have the lib send your app the data in real-time as it gets generated.
There's quite a bit of code involved but it is achievable. You can start here:
https://developer.android.com/guide/components/aidl
I just want to check if there may be a simpler way to do this.
If I have some generic ASyncTask and it's done I want to pass a success boolean back to the original caller. Normally I create an interface inside the custom AsyncTask class with just one method void onSuccess(boolean success);
The caller would implement that and so on.
I just feel that it clutters the project with mini interfaces.
I could also pass along a handler, but I would have to create a handler for only that purpose which often feels like "just a bit too much code for the purpose".
I could pass a runnable along, but I would have to fire it on a thread and that could cause trouble.
What I want I to execute a method of the calling object when the asynctask has finished. In Objective C I can pass along a "block" of code and maybe there is something similar in Android.
It is a theoretical question and there is no urgency, just curiosity.
You can incorporate event bus into your app, like GreenRobot's EventBus, OTTO or other available but this still requires some work. I personally still do not see problems creating Interfaces and stuff whenever it makes sense for my project.
The first thing I think of is lambdas but since Android doesn't support Java 8 that might be a problem.
If you just need the lambdas and not the other new things in Java 8 you can have a look here:
https://hakanyamanyar.wordpress.com/2014/07/08/using-java-8-lambda-expressions-in-android-developer-tools/
He is basically using a gradle dependency called gradle-retrolambda that allows you to use lambdas in Android. I have not tried this my self though.
Other things that might work for your use case except using Interfaces might be EventBus or Square.io's Otto. They are both based on an publish/subscribe event pattern. I've tried EventBus my self and it's very easy to use and works well.
I am having trouble grasping the correct way to implement a centralized data access for different resources.
I want to have a single class, call it DataAccess.class that will call from both a SQLiteDatabaseHelper.class and a ServerAccess.class depending on what is appropriate when I call it's methods.
I thought extending DataAccess.class from a Service was the best approach so I can use ASyncTask for the ServerAccess.class. Now I am having doubts. The DataAccess.class needs to be accessible by most of the Activities in my Application, and I want it to stop when the Application does.
According to the google developer resources it sounds like a Service is well used for ongoing operations in the background but I am unsure how to handle the life cycle given the scope that I am trying to incorporate. Can I make the Service call startService() and stopService() internally when I use the DataAccess.class methods? Does it make sense to call it every time I access the Service or should this only happen once at the start and stop of the Application?
Thanks for the help,
I would recommend
1) Use all AsyncTask based solution because Service - Activity Communication is limited. (Unless of course you need to run something in the background) BUT I would love to hear the counterargument to this, why use a service instead.
2) Don't use just one Facade like DataAccess but make it specific to your app functions (ie sort of like System Services in Android).
3) You should use factories just like Android does to get the DataAcccess object you need. This addresses second part of where you get DataAccess object. Follow same model as getting and Android System service.
4) Use Content Providers where indicated and manage as indicated in Android docs.
Update: I think these are sort of the Axioms of a good solution. Not the whole thing. I will update as we consider this in depth.