Currently there is no MedaiStatus.PLAYER_STATE_LOADING state to tell if the video is being loaded to the chromecast device.
Is there a way i can ask the GoogleCast device if I am loading data, as apposed to Buffering, Idle, Playing, or Paused?
We don't have such event exposed through the SDK. There is a couple of nice diagrams here that show the flow and events that are captured (see section Media Events). If there is a any reason that you need a certain event (exposed by MediaElement) that are not exposed through the SDK, you should consider doing the following:
Listen to that event on the MediaElement directly and inform your senders accordingly. The receiver SDK does exactly the same thing; it gets all its media events from the media element.
Open a feature request on our SDK tracker. There, you need to explain in detail why you need that feature and basically build a case that shows it is a valuable feature not just for your particular case, but in general.
Related
I wish to make automated calls to a list of numbers to then play a recorded audio message to them. The ones that don't pick up get a call back later.
What's the cheapest and easiest way to develop this using some pre-existing tools? Any directions welcome.
Note: You can play back the audio data only to the standard output
device. Currently, that is the mobile device speaker or a Bluetooth
headset. You cannot play sound files in the conversation audio during
a call.
from the official docs
I ended up using automated flow apps (Automate [link below] is one such app that I used. Disclaimer: I've no affiliation with app) to trigger automated calls. The flow was initiate on a GCM notification to the phone, which provided the number for call. With all permissions granted and conditions fulfilling (network, sim, call credits, etc.), app should be able to make call to the number.
Now, I'm trying to figure out how to play an audio message for the receiver.
So, if you were looking for 'how' part, here's the how part. If you know the next steps, enlighten me!
https://play.google.com/store/apps/details?id=com.llamalab.automate&hl=en&gl=US
I have built an application that uses Cast Companion Library (CCL) to remotely play video to cast comparable devices. Every thing is working find but I need to be able to change video files and not kill and restart the activity and fragment.
I have implemented my own custom version of the VideoCastControllerActivity that implements the same interface but I am re-using the VideoCastControllerFragment that CCL comes with. One problem is that the VideoCastControllerFragment does not really give specific notice when the end of a video file is reached. It somewhat does by calling closeActivity() from the IVideoCastController interface so I tried to use that event to know when to load the next video file. But loading the next video file by calling
getCastManager().loadMedia( mSelectedMedia, autoPlay, position );
but doing that results in another call to close activity and a loop until the end of the playlist is reached without playing any video.
Is there another way to go about this without re-writing my own VideoCastControllerFragment?
To answer your first question (or observation), you can listen to various callback events directly in your implementation of VideoCastControllerActivity; you have access to the VideoCastManager so you know when your media status goes to IDLE with the reason FINISHED. Outside of that, you seem to be trying to implement some sort of playlist functionality in your sender while the right place for that is on the receiver (i.e. you need to write a custom receiver); if your playlist knowledge/logic lives on your phone, then the whole thing becomes dependent on your phone so if it goes to sleep, you chromecast doesn't know what to do. In addition, if a second device connects to the same cast device, it cannot correctly reflect the playlist, etc. So a phone device can let user form a playlist and then it has to send the information about that playlist to your custom receiver and your custom receiver should handle playing them in queue and your sender(s) should be able to send custom messages to move to the next/prev, etc and your receiver should do the right thing accordingly. We have a very rudimentary sample on our GitHub repo that shows how you can do video playlist on the receiver.
Is it possible to bind HTML5 video playback to a scroll event on mobile devices? Specifically, I would like the user to be able to scroll to a certain part of the page (already have this functionality configured via jQuery waypoints plugin, and it works flawlessly on desktop) and have the video automatically start playing.
I am well aware of some of the limitations pertaining to video playback on mobile devices (link), but I have been able to work around some of these problems in the past. I have previously began video playback on user tap event interaction, but have not attempted to do so via scroll event interaction.
Does anyone know if this is possible? I would like to avoid having the user tap to begin the video, and it seems like since scrolling is an event just like tapping or swiping, it could in theory work. In practice is another issue.
I have tested on iPad 2 and Android 4.2
As I understand Apple policy on playing HTML5 video on iOS you indeed need a user interaction to initiate playback --- but also this user interaction needs to be related to a "button". A "scroll" event is just not a valid user interaction to initiate playback.
As stated here
In other words, a user-initiated Play button works, but an
onLoad="play()" event does not.
My experience is that Android on mobile devices has the same limitation.
One approach to accomplish what you want is to bind to a previously fired touch event (like with a "touch to enter this site button" or when a user touches on a link to navigate to some point on your page), initiate the play sequence on that event and then immediately pause the video until your user scrolls to where you want on your page and then resume playback.
Thanks
I am trying to create an app that automatically uploads a picture to my server. The idea is that a user creates a picture with the native/normal camera and my app gets a notification (catches the event) and uploads the picture (in the background).
I found a solution for Windows Phone (see here), but not for Android. How can I do this? - Is this technically even possible (with the given APIs) or is it a special feature just for contracted services (Facebook or Dropbox do that)?
Thank you!
Right now i don't believe there is a Broadcast that is fired for a camera capture event that other activities can listen to.
But here's what you can do.
Declare an intent filter for "android.intent.action.CAMERA_BUTTON" and provide it the highest priority - 999
This will give you a handle on the broadcast fired by the native camera. However this would steal the broadcast from the native app. So you might have to handle saving the file yourself, or formulate a hack to give back control to the native app.
Don't know if there is a better way. Also can't say much about the use-case of third-party cameras.
EDIT:
On further inspection, there is a better way. Listening to android.media.action.IMAGE_CAPTURE would yield better results and should fit right into your requirements.
I am trying to figure out what is the correct (new) approach for handling the Intent.ACTION_MEDIA_BUTTON in Froyo. In pre 2.2 days we had to register a BroadcastReceiver (either permanently or at run-time) and the Media Button events would arrive, as long as no other application intercepts them and aborts the broadcast.
Froyo seems to still somewhat support that model (at least for the wired headset), but it also introduces the registerMediaButtonEventReceiver, and unregisterMediaButtonEventReceiver methods that seem to control the "transport focus" between applications.
During my experiments, using registerMediaButtonEventReceiver does cause both the bluetooth and the wired headset button presses to be routed to the application's broadcast receiver (the app gets the "transport focus"), but it looks like any change in the audio routing (for example unplugging the headset) shits the focus back to the default media player.
What is the logic behind the implementation in Android 2.2? What is correct way to handle transport controls? Do we have to detect the change in the audio routing and try to re-gain the focus?
This is an issue that any 3rd party media player on the Android platform has to deal with, so I hope that somebody (probably a Google Engineer) can provide some guidelines that we can all follow. Having a standard approach may make headset button controls a bit more predictable for the end users.
Stefan
Google has a detailed blog post on implementing the newer 2.2 AudioManager media button event receiver while maintaining backwards compatibility with older devices.
http://android-developers.blogspot.com/2010/06/allowing-applications-to-play-nicer.html
After some experiments, I was able to get a working solution with the new transport and audio focus infrastructure in Android 2.2.
What I end up doing is requesting both the Audio Focus (using AudioManager.requestAudioFocus) and the Trasport Focus (using AudioManagter.registerMediaButtonEventReceiver) every time my application starts playback.
requestAudioFocus takes a callback that is called when the audio focus is taken away from you (for example the internal player starts a playback). In my case I just pause the playback in my application if the focus is taken permanently. Same callback also now tells you that the focus is taken only temporary (for example the Nav system is talking) so you can "duck" your playback - lower the volume or pause and resume after it is done talking.
The only issue remaining is that the built in Music Player takes the transport focus every time you connect a Bluetooth headset. This has the effect where the first press of the Play button on the headset after connecting it, always starts the playback in the default Music Player.
There is probably a way to detect the headset connection and "hijack" the transport focus. In my case, I decided to not "fight" the default player, and get the transport focus back when the user manually starts the playback in my application.
If somebody has more insight or knows of a better way of handling the transport/audio focus, please share it.
I also have this same issue with the media button registration.
Periodically the Android returns the media button registration to the default music player. I have not been able to figure out why. This can happen while may application is actively playing as well as while my application playback is paused.
After a number of users complained that their Bluetooth pause and play control buttons would periodically stop working to control my application, I implemented code that re-registers my application by calling registerMediaButtonEventReceiver every 2 seconds. This allows me to get the button registration back and for the most part avoids the time window where where the user presses a Bluetooth media button and the default media player ends up responding.
My application is holding the audio focus during this entire time period, but still loses the Bluetooth button events periodically while it has audio focus. My application always unregisters the media button event receiver if it is called with a notification that it is losing the audio focus, and then registers again if it is later called when a temporary audio focus loss returns the audio focus.
The work around to keep the 2 second timer running and re-registering has been working, but I would like to get rid of this 2 second timer if someone has found a work around for the media button registration periodically switching back to the default media player.