I'm just getting started with a simple sender app and the default media receiver. Is it possible to either:
a. send a list of images that Chromecast will loop over
b. send a single url that Chromecast will refresh on an interval, letting the server "cycle" the images through
I'd want this to continue without the sender application needing to be open. I was hoping to not have to create a custom media receiver, as I'm assuming I'd be able to do what I want to do. It seems like I'd have to implement a lot of boilerplate and register the custom application just for some fairly simple functionality.
Yes, it is possible but you need to write your own receiver to do that; the Default/Styled receivers that are available for you do not do what you have in mind.
Related
In order to display text in the correct language on startup of a chromecast receiver app we rely on a customMessage from the sender app containing the user's language.
But this message won't be sent before the application is done starting up and we want to display it as soon as possible, so before loading is done.
I noticed that sender-apps have the possibility to set a language in castContext.setOptions(options).
https://developers.google.com/cast/docs/reference/web_sender/cast.framework.CastContext#setOptions
https://developers.google.com/cast/docs/reference/web_sender/cast.framework.CastOptions#language
The question is: Is there any way to get the castOptions's language on receiver side?
Or: Is there any other way to get a language from sender app before the receiver is done loading?
I've been following this tutorial and have reached the point where I am able to receive push notifications (only working with android for now). My code is almost identical to the tutorial's. I'm now looking to expand the functionality. In the tutorial, when the app receives a RemoteMessage object, it parses out the "action" value from the data. It then passes that string to the NotificationActionService which triggers an action.
public override void OnMessageReceived(RemoteMessage message)
{
if (message.Data.TryGetValue("action", out var messageAction))
NotificationActionService.TriggerAction(messageAction);
}
The downside to this is that the only information it passes to the rest of the program is the name of the action. I want to add additional information. I would usually just add another parameter to the TriggerAction method, but the implementation of INotificationActionService is pretty involved. I'm wondering if its like that for a reason, or if I can just process my message in the OnMessageReceived. What makes me hesitant to change this is that the this action string is also pulled from the Intent on start up, and I'm not sure if if this will break it. I'm not entirely sure how android intents work, but both the RemoteMessage and the Intent would require this extra data inside the dictionary.
So, what is the best way to modify this tutorial to allow extra context to be passed in the push notification?
This is a good question - and realistically there isn't really one answer. Basically, all Android applications are going to be a collection of Activities and Services. You can think of them like independent threads that the OS is aware of and can help manage. Intents are a standardized way to communicate between these threads using a small set of types that are safe to serialize, so the OS can make stronger guarantees about the how and when it'll be delivered. There's a lot of documentation, and a whole world of different ways to architect your application with these. Each approach will have pros and cons, with some options being way too sophisticated for some applications, and others way too simple.
The Xamarin sample you're referencing keeps two separate threads: one for receiving remote notifications and one for rendering notifications. In principle, a developer may do this to allow notifications to be rendered in response to a message from a remote service OR in response to events local to the phone. For instance, my banking app alerts me that I'm being logged-out after 15 minutes of inactivity, and also when new tax documents are available. The first scenario is best served locally, where a notification will be rendered because a timer reached 15 minutes without being reset. The second scenario is better served by a remote notification so the app doesn't need to poll for new documents.
Bottom line - the sample app may be using an approach that introduces more overhead than your scenario calls for. For others it will be too simple. Choose what is right for your application.
I'm trying to queue a song to Spotify Desktop (Windows 8.1) making use of Spotify Remote Control Bridge. I want that song to be appended after the current playing track.
Due to the restrictions Spotify applies to this API, there's no public documentation and I can't get in contact with their developers. This is one of the posts I've been following to understand how this API works: https://medium.com/#b3ngr33ni3r/hijacking-spotify-web-control-5014b0a1a360
I've successfully played a song with https://XXXX.spotilocal.com/remote/play.json?oauth=XXXX&csrf=XXXX&uri=XXXX, but it jumps to playing queue instantly and replaces it entirely.
When I call https://XXXX.spotilocal.com/remote/queue.json?oauth=XXXX&csrf=XXXX&uri=XXXX it always returns "Method not implemented". Do I need a special Oauth token? Or CSRF token?
Just giving an update, you can now add tracks to a queue via a BETA endpoint.
https://developer.spotify.com/documentation/web-api/reference/player/add-to-queue/
I've tested it, and it seems to work as expected.
queue.json endpoint
This endpoint appeared in their js-library, although it never worked and it's, like you said, not implemented. It doesn't matter which arguments you supply.
play.json endpoint
So, this endpoint is more interesting. First of all, in the past you could use the following parameter ?action=queue to add a song to the queue, but sadly this doesn't work with the latest versions for whatever reason. The only thing you currently can supply is the play-context ?context. A context basically tells spotify what to play next (like setting a new queue). So if you want to play a track of an album and simultaneously want the album to finish after the specific song ends, you can supply a ?context=spotify:album:albumid. There is some more information about it in this issue of my library.
Summarizing, you currently can't add songs to the spotify queue, but add your own context which will be used as a future queue
Although it would be nice to know why spotify isn't releasing any documentation about the local-API.
Is it possible to have a Chromecast sender application to pass custom data to the receiver in the URL? The goal is to pass user-specific data to the receiver so it can generate the appropriate contents each time it's called.
An example of this would be a simple to-do list. When the user casts to their device, that user's data should be passed via URL to the receiver so that their task list can be loaded in the custom receiver.
I haven't seen any tutorials or much information on this in the Cast documentation.
If you mean passing parameters as part of the receiver url that loads the receiver, the answer is no; there is no such thing. You can either use the customData that can be passed to the receiver in a number of APIs, or you can create a custom data channel if the former is not adequate for your needs.
The Cast receiver URL is specified as a static URL when you're registering/publishing the app on the Google Cast SDK Developer Console so it is not possible to add custom parameters.
However you can use the Cast Messages system to send data between a Cast sender and Cast receiver. It's similar to the messaging system in modern browsers.
Is there anyway when receiving a call to add data to the incoming call screen?
I'd like to be able to add text to that screen if possible.
Update:
If there is no way to currently add text to this screen is there a way to trigger code based off of an incoming phone call?
The only way you can do anything in relation to an incoming call is be informed that this has happened via the Obscured event.
Be aware that other things (such as an alarm) also trigger this event and there is no way within your app to know what caused your app to be obscured.