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
Related
I want to use the media buttons to control a foreground app, but not for audio use.
So the goal is to detect button clicks to do certain things in the app.
I can achieve that by using MediaSession and the MediaButtonReceiver. see here
The problem is that when the app is used, often users play music in the background, so the audio focus of the background app takes over the MediaSession and i cannot control my app anymore.
Is there a way to achieve that? Directly listening for button clicks with onKeyDown does not seem to work.
sadly there is no way for two active MediaSessions at the same time. if another app is playing music and run MediaSession then yours doesn't have focus and isn't active... this is made for purpose - better UX - only one "player" app can play music (or video). if this wouldn't work like that and you could play music by few apps at once then how should work media button on e.g. headphones? pasuing/resuming all players? this is just not user-friendly, so Android team introduced MediaSession pattern with option for calling "focus on me now" by any app, but then another app/MediaSession pauses and doesn't get any inputs (this active session does)
if you need physical buttons presses then onKeyDown should work (inside Activity or eventually using AccessibilityService, which would work "globally" in whole system). if you need some on-screen notification buttons presses then just make custom layout for your notification with as much buttons as you like, even styled as a player
note that in Android 11 active MediaSessions notification is stickied to top of notification section when you drop down status bar. your custom notification will be somewhere below between all others (you can manipulate position a bit using priority param for notification/channel)
I really don't know what I'm asking here but I'm going to try my best. 😜
I want to make a video that will run on an android box in our office.
We are a company that installs and programs home automation systems. I want to make a demo video that will be shown to clients. The video will say something like "this is how lighting control works" and the office will then turn lights on and off. "This is multi-room audio, you can listen to one thing here" and then speakers will switch off in one room, on in the next room "or listen to something else in here at a different volume" the speakers will then switch back to the theatre demo room. "We can also control the shades" shades will move up and down. The problem is I have to script things based on delays...that's fine if a client watches the entire video, but I want them to be able to pause and ask questions.
My question is can I trigger an HTTP post or another networked trigger from the android box to an onsite web server or the actual automation controller? Is this possible, when the video reaches 1:12 do POST "trigger theatre lights" I can make the action work on my automation system I just need to make a video trigger events at specific times...
You didn't tell us which videoplayer you use (or on which OS it runs) but most of them should have some sort of progress listener that you can set. The listener will be called every x seconds telling you the current progress of the video in playback.
Example:
videoPlayer.setOnProgressListener(new ProgressListener {
void onProgress(Long position){
}
})
Should your videoplayer not have such a progress listener within it's API, it will at least have a method to retrieve the current playpack position.
You could then actively ask for the current playback position every x seconds and do all your funky home automation stuff based on the current video playback position.
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.
Alright, so I'm writing an app to make an external headset perform certain functions. I'm trying to replicate functionality similar to this guy:
https://market.android.com/details?id=com.kober.headset
The list of things it can make the headset button click do is: play/pause, previous track, redial last phone #, launch specified app, etc. I don't know how to do this stuff though! Sort of lost with how to get started here. I'm also kind of confused how the overall program flow should work.
Right now I can register button clicks via a broastcast receiver and correctly and pass that number (single/double/triple click) to a service to run in the background. I'm using a background service so the user doesn't need to be in the app to use the functionality.
Am I on the right track? How do I go about making clicks play/pause music, next/previous track, etc? Are there certain intents I should be using?
Cheers.
Am I on the right track?
Be sure to stop your service when it is no longer needed (e.g., after you have determined the clicks and performed the operation). Otherwise, I see no problems there.
How do I go about making clicks play/pause music, next/previous track, etc?
First, write a music player app. There are no documented and supported APIs to "play/pause music, next/previous track, etc" for most of the several thousand music players out there.
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.