MediaRoute Dialog: Disconnect vs Stop - google-cast

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.

Related

Possible to control garage door with Garmin IQ?

I'd like my Fenix 3 to do the following:
Trigger = hold down start button (i.e. shortcut)
Send message via BT or WiFi to a server (Linux or Windows or Arduino or whatever)
I'll take care of the message and open/close my garage door.
After a bike tour I'd like to easily and safely open my garage door. I have a VmWare server running at home. I could use one of the machines on this server to listen to the messages or I could set up an Arduino or similar.
The main question is: Can I write an IQ app that utilizes the shortcut concept on the clock, i.e. triggered by long click on start or lap button?
Clarification: There seems to be some kind of global actions for long press. I can for example assign "Save position" to long press on start/stop. This works even from inside of other apps.
Can the clock communicate with sensors (i.e. Arduino or other BT client) even if not in training mode?
Clarification: I need to communicate directly with my Arduino via Bluetooth, i.e. not via my iPhone.
Thanks in advance.
Short answer: Yes
Long answer: If you record the time a keydown event comes in, and then check for a "long" press when the key is let up based on the time difference, you can fake it. There is not an event for a long press of a physical key though. I am also pretty sure your app needs to be the current one for this to work.
Link to the InputDelegate event options: http://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/WatchUi/InputDelegate.html
As for the sensors question, I am not sure exactly what you are asking. Your app can do whatever you want, and it is my understanding that only one app will be running at a time.
Disclaimer: Thus far I have only been working with the emulator, I'm still waiting for my watch to get here.
You cannot write anything that hijacks user input events from another active application (including the watch face). You could make your own watch face, but it wouldn't have the ability to send network messages and it has only one way to accept user input (the look-at-watch gesture).
This is something that you can do pretty easily from a watch-app or a widget. Assuming that your fenix3 is connected to your phone via bluetooth, you can send http get requests as you see fit.
I've written a simple app that I call GIFTTT that uses the IFTTT Maker channel to open/close my garage door (and all sorts of other things).

How to handle external events in CQRS?

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.

Pusher disconnect & timeout

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.

Compact framework socket timeout

I have problem detecting the loss of socket connection in CF app for PDA device.
I have static class that has static methods for communication (Connect(), Write(), Disconnect()). Static because all forms can call Write method.
In Connect method i call socket.Connect(ipEndpoint);
But when device hasn't got wifi connection program halts at this line for about 20 s which is too long. Also if user starts Write() method (saving some data) and wifi connection is lost, user cannot interact with form and thinks that application frizzed. Since there is no timeout option for CF socket connection, what is the best way to control socket behavior?
My idea is to show some kind of "Communication form" when socket doesn't response for 5 seconds which will try to reestablish connection. This form will have graphical indicator (rotating clock or something like that) to show user that program is trying to connect and exit button if user decides to exit app. If socket.connect succeeds, i will show last used form to user.
I assume that this has to be done with Threads, but since i don't have experience with it. i need help how to manage this behavior.
You can call Socket.BeginConnect() to launch the connect in the background. You can then specify the callback method that will get invoked when the socket has connected (or timed-out). Additionally, to implement your progress bar counting down as it tries to connect you can do:
IAsyncResult ar = moSocket.BeginConnect(...)
And then you can have your connection form use a timer to count down, checking the status of the connection by calling:
ar.IsComplete
Polling is not very efficient, but in this case it works well with your described pop-up connection form.

NSUserDefaultsDidChangeNotification and multitasking issue

I am using Settings app to store application settings. I also userdefaults to store internal application settings (which are not exposed in Settings app). For eg, I use user defaults to store the last tab bar index which is not exposed in Settings app.
I am subscribing to NSUserDefaultsDidChangeNotification to listen to any changes in settings while my app is in background and that works fine.
The issue is that when I update user defaults (for my internal application setting parameters) from within my app, this also triggers NSUserDefaultsDidChangeNotification and which I do not want.
Is it possible to just listen to change in settings from Settings app and not from within the application?
Is it possible to listen to the notification only when the app is in background? I tried to subscribe to notification only in applicationWillResignActive (just before moving into background) (and that works fine for registration), but I could not find a way to deregister once the application is made Active again (applicationDidMakeActive does not seem to be the correct callback since notifications are delivered after this callback).
Or is there some other simple way to achieve this?
applicationDidMakeActive? You must mean applicationDidBecomeActive.
You might consider implementing applicationDidEnterBackground and applicationWillEnterForeground instead of applicationWillResignActive and applicationDidBecomeActive.
The "Active" methods are also called when the app starts and ends, which mean you will stop listening to the notification once it starts (you weren't actually listening to this notification) and if you implement applicationDidBecomeActive you will start listening to the notification once your application ends (for nothing).

Resources