The set up I have is:
An Activity that creates and registers a BroadcastReceiver every time it starts. In addition it starts a Service which listens for new sensor data and sends Intents to the BroadcastReceiver. My problem is that each I close the Activity, I stop the Service and unregister the BroadcastReceiver and if I start the Activity again, I get two instances of the BroadcastReceiver with the old data that is not changing and new data constantly refreshing.
I would like to know if there is a way to have only one instance of the receiver? (maybe make it static or add a flag similar to launchMode="singleInstance"). Thanks in advance.
Ok finally I solved this problem. The reason for having multiple receiver data, was not multiple instances of the receiver itself but a separate thread that was instantiated multiple times and was never finished.
Related
Currently I have two streams implemented in two different widgets I'm listening to. I'm disposing this streams as per best practice when widget is not existent anymore. The problem I'm facing now is, that I want to trigger local notifications whenever new entries are received from db via stream, if my app is in background and/or I'm on another page (where the stream is disposed already). How can I achieve this, without running into memory leakage problems. And where should I place my stream.listen and local notifaction trigger, to have them "globally" available? Hope you understand my question. Otherwise I can add some code.
Thanks in advance.
Say I have a generic 'Button' in any kind of modern UI framework (I'm working with Android's right now but the problem is pretty much plaform-agnostic). I can put a listener onto this button to listen for click events. My listener gets notified about click events on the UI-thread. This is a problem from a reactive-point-of-view, more specifically in the context of threading.
I can easily create a Subject for the click events. The Observer would most likely want to do processing on another thread. But I can't easily extract (without hacking or ugly workarounds) the Scheduler's Worker from an .observeOn() operator, for dispatching the event onto the correct Worker.
How do I create an Observable stream from these click events, so that the stream will respect the Scheduling requirements of the .observeOn() operator?
It's not clear to me what exactly the issue is here. ObserveOn puts the events to the specified scheduler, which behind the scenes may end up on different threads for different subscribers. If you want to make sure every subscriber will receive the events exactly on the same thread, you need to have a Scheduler with exactly one backing thread. The easiest way of getting such Scheduler is by wrapping an ExecutorService:
Scheduler s = Schedulers.from(Executors.newSingleThreadedExecutor());
PublishSubject<Event> ps = PublishSubject.create();
Observable<Event> events = ps.observeOn(s);
events.subscribe(...);
events.subscribe(...);
ps.onNext(...);
I am broadcasting data (file download complete) from AsyncTask to Fragment and updating ListView accordingly.
I have read that broadcast receiver should be registered/unregistered in onStart()/onStop() respectively.
But in this case i will miss data which has been broadcasted when app is not foreground but running in background (onStop() called but onDestroyView() not called) .
So to resolve this issue can I register/unregister broadcast receiver in onCreateView()/onDestroyView() respectively?
Also suggest if there is any alternative solution to this.
Many thanks in advance.
I beleive it is common practice that broadcast receivers be registered in any method including onCreate() and be unregistered in any method including onDestroy(). Used in the onCreate() and onDestroy() methods are really common practice. I also know of maybe the only other way to register a broadcast receiver and that is to register it in the Manifest. That basically means that as soon as the app is run for the first time the broadcastReceiver will always be running in the baground. Hope this helps you.
Background
On Android, there are 2 possible ways to listen to system events via BroadcastReceivers :
statically, via the manifest
programmatically, via the code.
Since some projects contain a lot of activities, services, and "manager"-classes , it could be useful to have a single BroadcastReceiver that will notify all of its listeners on the app about what has happened, instead of having multiple BroadcastReceivers being used (and their code handling).
An example of such a BroadcastReceiver, is the one that listens to the connectivity changes:
#Override
public void onCreate() {
super.onCreate();
...
registerReceiver(new ConnectivityChangedBroadcastReceiver(), new IntentFilter(
ConnectivityManager.CONNECTIVITY_ACTION));
...
}
The question
The purpose is to listen to the events while the app is "alive" (by services and/or activities) .
Using the manifest would miss this purpose, as it will wake the app each time the event occurs, even if the app doesn't need it.
Thing is, unregistering doesn't occur, and maybe it causes the OS treat the app in a different way because of it.
Does having a call to "registerReceiver" on the class that extends from Application is a good known practice?
Does it have any side effects and things to know about when using it?
Is there any alternative to this?
I just want to be sure it's considered safe to use.
we can't really know what is good or better for you.
I advise you to learn more about the difference between the registration ways of the receiver:
1/ in the manifest :
the handler of the receiver will be triggered each time that the correspondent event comes. Example: the messenger of facebook is lunched every time that you have internet connection to show you your notifications... or other applications are lunched when you connect to propose updates ...
in other words, the receiver is always registered.
2/ in a service or an activity or an application :
the receiver will be unregistered when the context of where it is registered is killed.
in other words, it depends totally of the context where it is registred , and you are obliged to unregister it somewhere in the code. exemple : one activity is waiting that a service ( which is doing something in the background) sends an alert to update something , then you can register the receiver in your onResume() and unregester it in your onPause().
Conclusion : It depends only in the life-cycle requirement of the receiver.
see also Broadcast Receiver Register in Manifest vs. Activity
Main difference between Manifest and Programmatic registering of BroadcastReceiver
I have a program with about 8 Activity classes, and 1 Application class. I want my Application class to be able to communicate with every Activity, but on its own terms. I don't want the activity to ask the Application for data, I want the Application to send the Activity data. The problem with this, is that depending on the current state of the program I'm unsure what Activity will be open.
Is there a method of some sort which will send information from the Application to the CURRENT activity?
The Application class connects with an embedded Bluetooth Device and needs to receive different pieces of data depending on which Activity the user is currently in. I originally had it as a regular class, which was initialized in the MainMenu of my program and passed a Handler. However, it seemed like weak design to pass that Handler from Activity to Activity time and time again.
You could use a Callback Method
Every Activity has it's own callback method and registers that method onResume() in the Application Class. (it's like an onApplicationWantsToDoSomethingWithMeListener() ;)
or why not a Service in background? instead of the Application, since what you want sounds like a Service. More details?
EDIT:
I made a similar application with bluetooth, you should definetly use a Service for that, but you can communicate with your service per Application. Say the Service calls the callback in the Application look here for an implementation uf such a thing