In my Android sender I am doing the teardown exactly as described in Android Sender Developer's Guide. The receiver is released OK, reverts to Chromecast Home Screen, but the status of MediaRouteButton doesn't change: it shows that my App is still conected. I need to click Disconnect there before I can connect again. How can I make MediaRouter to re-check the connection status after the teardown?
Thanks.
Then you need to handle various things that the ActionProvider would do for you automatically. After making sure that you are disconnected, call mMediaRouter.selectRoute(mMediaRouter.getDefaultRoute()) and see if it does what you want.
Related
I'm working on an App that sends audio and video content to a chromecast. But I don't want to stop the playback when we disconnect our Sender App.
In the mediaroute-v7 package we find reference to an option to either disconnect or stop the connection. In fact the button to disconnect is hidden on https://github.com/android/platform_frameworks_support/blob/master/v7/mediarouter/res/layout/mr_media_route_controller_material_dialog_b.xml#L103 and to make it visible mediaroute-v7 gets the SelectedRoute and checks the boolean canDisconnect() on https://github.com/android/platform_frameworks_support/blob/39b32a9feea6b821d6a5c92202c400aa1f252200/v7/mediarouter/src/android/support/v7/app/MediaRouteControllerDialog.java#L259.
Is there any way to change the boolean value of canDisconnect(), so we can show the button, with VideoCastManager? Or how is supposed to get that button visible?
I presume you are using CCL (since you'd mentioned VideoCastManager). The current dialog that you see there is put out by CCL and is not the one provided by the mediarouter framework (unless you have overridden getMediaRouteDialogFactory()). In CCL, you have an option to decide if you want to simply disconnect from the cast device or stop the running app on the cast device when you click on that "Stop Casting" in the dialog; by default it just disconnects you and to change that, you have to call setStopOnDisconnect(true) to force it to stop the app. That said, the most common behavior on the receiver side (the default and styled receivers follow that as well) is to stop the app if the last connected device intentionally disconnects (i.e. if the last connected device is disconnected due to, say, network disruption, it doesn't stop the app). This behavior can be controlled on the receiver side by overriding onSenderDisconnected(reason) callback there.
Flurry docs say that I should check the Event log when testing events. Where is the event log? The events menu is the only one without a submenu.
If you have completed a Flurry session on a test device the event log should populate within an hour or so. Be sure to close the app with the home button or relaunch the app once more to guarantee the session is sent.
If the problem persists add these lines of code before you start the Flurry session:
Android
FlurryAgent.setLogEnabled(true) ;
FlurryAgent.setLogLevel(Log.VERBOSE) ;
iOS
[Flurry setDebugLogEnabled:YES];
[Flurry setLogLevel:FlurryLogLevelAll];
Look for a 200 response from our server when the session ends. Make sure you are using the latest SDK Android v5.5 or iOS v6.4
I am experimenting with a modified version of the Cast-HelloText sample app, specifically having two senders connect to the app at the same time.
The castReceiverManager.onSenderConnected() callback is called, and I see I have 2 senders connected (using window.castReceiverManager.getSenders().length) and both can then send messages.
However, when either one disconnects the app is terminated. I have tried logging the number of senders connected in the castReceiverManager.onSenderDisconnected() callback (without success) and I have commented out the window.close() call.
It appears the app is closed (chromecast returns to home screen) on any sender disconnecting.
Any ideas on how to have an app with more than one sender that isn't ended when any sender disconnects?
Check on your sender to see what it does when a disconnect happens. The unmodified version on Github calls Cast.CastApi.stopApplication(mApiClient) when you disconnect your sender from the receiver and that call stops the app on the receiver. If you don't want that to happen, you should not call that method but then you need to make sure
it makes sense for your app to continue
make sure your receiver handles things correctly
Supposed I have a CQRS-based system with a web UI that I want to integrate with some external device, let's say an Arduino board.
Basically, I can think of three scenarios:
When the user clicks on a button in the web UI, the Arduino shall do something.
When the user pushes a hardware button, the domain shall react and the UI shall update.
When the user pushes a hardware button, the UI shall update.
How do I model these scenarios?
This is quite easy IMHO: UI emits a command, business logic runs, emits an event, and Arduino is listening for events. Basically, the Arduino is nothing but an event denormalizer. Is this the correct approach?
This is quite easy IMHO as well: Arduino emits a command, sends it to the command bus, and the same procedure runs as with scenario 1. Basically, there's no difference for the CQRS-system whether the command comes from the web UI of from anything else.
This is where I'm really unsure: Supposed the Arduino handles the button press itself, and flashes an LED in response. I just want to make sure that my application takes notice of "the LED has been flashing". This is no command (as the flashing already happened), instead it's an event. What do I do with this event? Do I simply store it in the event store and bypass my domain? This seems horribly wrong to me. Do I emit a pseudo-command which is turned 1:1 into a matching event? This will work and does not bypass the domain, but it feels wrong as well, as it actually is no command. What should I do?
Any advice on these things?
1.Just use an event handler( updating ui maybe using websocket ) listening on Arduino event if no state should change in your domain.
2. Use a saga listening on Arduino event and fire a command if state should change in your domain.
UI is not a domain concern. So I prefer option 1.
will my server be notified about disconnect on the client side?
I assume the answer is yes if the disconnect happens explictly like below.
pusher.disconnect()
however what happens if the user simply closes the browser?
Another thing is there a way to notify the server that a certain channel has not been in use by the client(s) for some while?
The connection states documentation shows how to bind to connection state changes.
however what happens if the user simply closes the browser?
This really depends on if the browser calls webSocketInstance.onclose so the Pusher JavaScript library is informed before the browser is closed. You could always detect this yourself using window.onbeforeunload, window.onunload or the addEventListener versions.
Another thing is there a way to notify the server that a certain channel has not been in use by the client(s) for some while?
You can use WebHooks so that when a channel becomes vacated your app server will be informed.