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.
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.
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
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.
I've implemented the new IAB in my application, but when I tested it on two different device the result were different on galaxy S3 the flow was great but on galaxy S1 (gt-i9000), after purchasing onActivityResult method isn't called and the application restarts.
any suggestions?
I had the same problem, in my case the reason was that I had a flag set in the intent that called the activity which hosted the purchase process
i.addFlags(Intent.FLAG_ACTIVITY_NO_HISTORY);
after removing the flag it works, I guess it is because when the startIntentSenderForResult starts the purchase interface the activity is destroyed, not kept in history and somehow there is no point to handle the onActivityResult
Are you using TABActivity? If answrer is yes than procedure is somewhat different,As the
onActvityResult will be called for the parent class which is your activity that extends TABActivity,I dont know why but it seems that parent is cathcing the onActivityResult.So your code for startActvityForResult or startIntentSenderForResult should be in that actvity.
i used this link and made some changes according to my app and it works
onActivityResult is never called in TabActivity
My gremlin for this problem was using a negative requestCode. That breaks the result dispatching mechanism.
I have a little problem with the google analytics API on IOS.
When I try to track two events, or two page views, between two dispatches (called automatically with the dispatchedPeriod), the second event is never fired.
When I set the debug flag to YES, it shows that the dispatcher is busy...
Moreover, if I try to restart the app, every new event will be added on the event stack but never called neither.
Everything is working fine if I call the dispatch methods of the shared GANTracker just after the tracking calls, but with this solution, the dispatchedPeriod just become useless...
Anyone has encountered the same issue ?
Thanks !
EDIT : it seems to work with 3G connection but not with WIFI
The problem is solved !
It was a network configuration problem.
Thanks !