My requirement is this: My app needs to register for certain broadcasts. If my Activity is "showing" when I receive the broadcast, then I update the UI; else, I show a Notification.
Commonsware has come up with an elegant solution for this; using ordered broadcasts. My problem is that I want to do all of this locally, i.e., within my process. Unfortunately, LocalBroadcastManager does not have a sendOrderedBroadcast() equivalent.
Is this just an oversight in the LocalBroadcastManager?
Or is it pointing to a best practice (something to the effect that sending ordered broadcast locally is a bad idea)? If so, why?
Or is this plain unnecessary and can be achieved by alternate means?
Is this just an oversight in the LocalBroadcastManager?
Google does not have infinite engineering time.
Or is it pointing to a best practice (something to the effect that sending ordered broadcast locally is a bad idea)?
I doubt it.
Have you considered using onUserLeaveHint() and onUserInteraction() callacks in Activity class?
onUserLeaveHint() is insufficient here (e.g., does not cover the case where the user accepts an incoming phone call), and I fail to see how onUserInteraction() helps any.
I ended up implementing my own LocalBroadcastManager with ordered broadcast capability. The project is shared at github.
Although it serves my immediate purpose, it is still rough around the edges. It needs a few enhancements (for example, the setResult* and getResult* methods). Code contributions are welcome :)
Related
Intents are taking too long to be process in my app. Is there a better way I can tell different elements of my app that something has happened? For example I use:
Intent i = new Intent("com.ftx.player_died");
I listen for that intent on two different places in my app. I would not like to make the same call twice.
Inventory.playerDied(true);
NotificationBar.playerDied(true);
Doesn't scale nicely.
Is there something I can use that is faster than intents but that I don't make same call twice or three times?
Using LocalBroadcastManager orEventBus is not only faster the normal BroadcastManager, but also is private to your app (that means other application cant listen to your Intent action)
It depends on a lot of factors. It is needed to see of your project to give a piece of advice.
But in some cases it is possible to use usual interface that declared and shared in the static Application class.
I've given a bank application which I should modify so the balance of an account gets updated on every GUI screen. This should be done with RMI(Observable) in my example. I already made this work, at least, I'm almost certain about that.
There is a REMOTE interface called IBankingSession.
This REMOTE interface should have a method like setGUI(BankSessionController) or something like this. But, This isn't possible because the JavaFX parts aren't Serializable. The IBankingSession doesn't have any relationship to a GUI.
How can I link an instance of IBankingSession to this GUI? So I can update the GUI from this instance? It also feels weird to make a method like setGUI in a REMOTE interface. Because the GUI is of course, on the same screen as where the session is created.
I'm curious for some good idea's. Thanks in advance.
IBankingSession session = desk.logIn(tfAccount.getText(), tfPassword.getText());
First of all: you don't want to link your "remote" thing directly to your local clients that make use of it. That IBankingSession has no business knowing anything about the fact that your client wants to use JavaFx to put something on the user screens.
Instead, try something like this: define an interface that allows for callbacks (in other words: some kind of "push" model):
A client registers with the remote server; telling it: "I am interested in balance updates".
Then, upon a "balance" update, the remote service pushes that information to each client.
Now each client will be notified; and can then decide what to do with incoming updates; for example update some JavaFx UI component; or maybe, to log them into some persistent storage - giving you one mechanism that might be useful for a huge variety of different use cases.
You shouldn't be using observables at all, and certainly not over a network.
As far as RMI goes, you should strenously avoid anything in the nature of a client-side callback. There are firewall problems, latency problems, connectivity problems, ... every kind of thing that could cause your client to misfire.
You need to completely rethink this. It is not a viable design.
Recently we switched our push notification system over to Parse.com, but I'm having ridiculous trouble integrating our client on several ends.
These are the two requirements, yet it seems impossible to implement them together:
There are several different types of notifications (different sounds based on type, or icons, etc.) that need to be used depending on the state of the client and the notification received. Therefor I need the option of a custom NotificationBuilder.
I need to track the consumption of the notification.
Their documentation states that if you want to handle everything yourself, all you have to do is add one line when the internal Parse OPEN event is broadcasted:
ParseAnalytics.trackAppOpened(getIntent());
Ha! If only that worked.
By preventing the internal Parse helper from receiving the RECEIVE event (by overriding the onPushReceive() method of the ParsePushBroadcastReceiver), it appears to remove any link between the data pushed to the device and the Parse service running on it (which makes sense why that would be, since it never reached the starting point in the first place). And no, calling the super version is not an option, as it would cause Parse to display its version of a notification since there will be an alert/title key that I have no control over.
I figured, what the hell, might as well try to put the tracking method call in the Activity that is called by the popup (whose Intent does contain all the data originally passed to it). Still, no effect, reaffirming my belief that intercepting the event is preventing the local Parse system from knowing there's a notification to consume, therefor preventing its consumption from being tracked.
So, the question is, does anyone know how to get Parse to use a custom NotificationBuilder so that the events it requires can actually be triggered correctly, allowing me to actually track notification consumption?
Or any kind of solution that enables me to use a custom notification, while still triggering the appropriate events to be tracked?
Possibly some way to save the push_hash and manually send the API call to whatever endpoint handles consumption?
Quite literally pulled some hair out over this one today and would appreciate any help I can get...
Thanks, everyone!
I am doing sharing in my application using ShareActionProvider. However I can not find a way to validate if sharing was successful or not (failed, user cancelled it at some point, etc.). Is it possible to do this?
I know I could make it easy using startActivityForResult but I found out that using ShareActionProvider is a recommended way.
Is it possible to do this?
No.
I know I could make it easy using startActivityForResult
Usually, that will not work either. That will only work for activities specifically designed to be called by startActivityForResult(), and few ACTION_SEND-capable activities are designed that way. The documentation for ACTION_SEND says that there is no output, and therefore few ACTION_SEND-capable activities will bother calling setResult().
I'm working with the sample media player given by the android sdk. MainActivity starts Service MusicService with startService(new Intent(MusicService.ACTION_PLAY)).
I need to find a view by ID inside the Service but I don't know how to do it:
findViewById(R.id.playbutton).setVisibility(View.GONE);
I've found some similar questions but none provide a simple solution (the most similar question's accepted answer is actually "no you can't" and I'm sure it's possible). How can I make this line work inside the Service? Do I have to pass the context from MainActivity to it, how do I do it?
Since the service handles media playback the interface should be updated directly before playing/pausing that's why I need to update the ui from it
No, you do not. You need to let the UI know, if it exists, about the state change. The UI will affect its own changes how it sees fit. There may not be any UI at all, depending upon what the user has done.
For letting any affected bits of UI know about the state change, you can:
send a regular broadcast Intent, or
use LocalBroadcastManager to send a "narrowcast" Intent (works a lot like a broadcast, but it is completely within your process), or
use Otto as an event bus