I just want to know is that. For creating the cast application we have to develop or provide both functionality sender and receiver. I mean as the user downloads the Cast app in mobile, user also have to download it in the LED. Now the mobile becomes the sender and the LED tv app becomes the receiver.
Is this is the way it all works??
The Google Cast SDK enables you to extend your Android, iOS, or Web app to direct its streaming video and audio to a TV or sound system. Your app becomes the remote control to play, pause, seek, rewind, stop, and otherwise control the media.
The scenario you are asking above is one of the feature we support called "Cast connect" https://developers.google.com/cast/docs/android_tv_receiver which allows users to launch the Android TV application and acts as a receiver.
Please read the document for more information on Senders and receivers:
Get Started - https://developers.google.com/cast/docs/get-started
Sender - https://developers.google.com/cast/docs/android_sender
Web Receiver - https://developers.google.com/cast/docs/web_receiver
Android TV receiver(Cast Connect) - https://developers.google.com/cast/docs/web_receiver
Related
I read that it is possible to use the Web SDK to build a sender app that would run on Chrome in iOS or Android. Is it possible to make that same app being also the receiver to cast to a web enabled TV? So instead of having multiple apps, I'd only have one PWA?
Same codebase? Yes. Same app? No.
The sender and receiver do very different jobs. It's not a bad idea to write your sender and receiver as part of the same project, or to serve them from the same server, but if make your own receiver app then your receiver needs its own URL. (To publish a receiver app, you tell Google your receiver URL, and then Chromecast devices load that url whenever you cast to them.)
Your sender app is complicated. It's responsible for giving the user controls they can click on and sending those messages to the receiver, but it can have a variety of other responsibilities depending on your application. It might do search and browsing, real-time updates, or notifications, and it might let your users write messages or play games or draw beautiful digital art - anything you want your app to accomplish.
The receiver's job is much simpler: play an audio or video file when the sender tells it to. The receiver also needs to respond to play/pause/stop commands and display basic status info, but this functionality is built in to the Cast receiver library, so you don't have to write any of it yourself. You can add bells and whistles like pop-up notifications or custom css styling, but all user interaction happens through the sender app (or from the Google Home app, which acts as a simple remote control). This limitation means that a lot of your features belong only in your sender app, not in the receiver.
Your receiver app is also limited because it has to run on a tiny Chromecast dongle with limited processing and cooling power. Putting unnecessary code into your receiver app could result in the Chromecast overheating and shutting down.
To keep your code as simple as possible, consider using the default Chromecast receiver. This way, you don't have to write or maintain any receiver code. If you need more control over the receiver's styling or behavior, then build your own, but it doesn't have to be complex. The basic Cast Receiver app is thirteen lines of HTML - that's it. Depending on your requirements, you might add css styling, custom message or event handling, or an autoplay queue, but even with all of these features the sample CastReceiver project is only 636 lines of code. Your receiver definitely doesn't need to be as complex as a Slack or Steam desktop web app.
Take advantage of the project-management wins from sharing a codebase with your sender app, but you must keep your receiver small and lightweight. Use the full js/html/css stack if you need to, but consider writing your receiver as a short HTML document, or even using the default receiver. When you keep your receiver functionality to a minimum, you give your users a reliable and responsive Chromecast experience, while still allowing rich interactive features through the sender app.
I'm an iOS app developer and not familiar with Android. I'd like to implement the feature that playbacks audio over the internet when the mobile receives a push notification.
I've investigated it for iOS and concluded that it is impossible in iOS because Apple prohibits downloading data over the internet in background from being developed.
I'd like to know if this feature is feasible or not in Android. Could you give me any advises ?
You need to implement PendingIntent to get you notification and start ForgroundService or this or this to play your audio and close it when the user leaves your app or while they are using your app depending your particular needs.
I'm writing an Android application with DJI-SDK to monitor when a video is recording. My drone uses its control application, but I need to spy on the drone's camera activity to send a notification when a new video has started recording, but I can't to have two Android applications use the DJI SDK at the same time.
Can I listen a "message or intent" sent by DJI-SDK service which will allow me to send a notification of a new recording video?
You cannot listen in on the DJI app but if you write your own app you could broadcast camera activity that can na picked up by another app.
Look away broadcasters in android, there are ways to publicly broadcast between apps or services.
I'm working on an Android app that will simply play a video (from the web) on my Chromecast device. For this purpose I'm fine with just using the Default Media Receiver mentioned here, in which case I don't have to register my app to develop it. However, the app (in development) can't seem to find any of my Chromecast devices. On the page mentioned earlier, it did state (regarding the Chromecast device):
To turn your device into a development device and gain access to your receiver app while it is not yet published, you must register the device.
This kind of makes it sound like I only have to register the Chromecast if I'm writing my own receiver app. Do I still need to register the Chromecast even if I'm just using the Default Media Receiver?
You do not need to register your app if you want to use the Default Receiver.
I have this use-case for Android Beam. I could have tested it myself but my app is not available in Google Play yet.
Here it goes:
I want to beam some content from my phone and the receiver phone does not have it. So with AAR, the app will be fetched from Google Play on the receiver phone. So far so good. So I download and login.
My question is: Once the app is downloaded will the receiver app still have the information that was beamed or should the sender initiate Beam again? Will my data in first Beam be lost? How should this be handled?
Theoretically, the onResume should be called to handle the intent.
Any thought if someone has come across such a kind of case.
The data will be lost, unfortunately. Think of it as if the NDEF message with the AAR will have been delivered to the Play Store app. (The Play Store app will not be able to deliver it to your newly installed app.)
The only solution is to Beam again.