Je veux commencer par dire en disant que je me rends compte que cette question est ancienne et a déjà une réponse acceptée; mais, en tant qu'internaute malheureux qui a utilisé cette question comme un moyen de terminer seulement pour se tromper peu de temps après (mais pas avant de déranger un peu mon client), je veux ajouter mes réflexions et suggestions.
Bien que @DSG et @Giona soient corrects et qu'il n'y ait rien de mal dans leurs réponses, il existe un mécanisme créatif que vous pouvez utiliser pour «contourner», pour ainsi dire, cette limitation. Cela ne veut pas dire que j'approuve le contournement de cette fonctionnalité, bien au contraire, mais juste quelques mécanismes pour qu'un utilisateur «se sente» toujours comme si un fichier vidéo ou audio est en «lecture automatique».
La solution la plus rapide consiste à masquer une balise vidéo quelque part sur la page mobile, car j'ai créé un site réactif, je ne le fais que pour les petits écrans. La balise vidéo (exemples HTML et jQuery):
HTML
<video id="dummyVideo" src="" preload="none" width="1" height="2"></video>
jQuery
var $dummyVideo = $("<video />", {
id: "dummyVideo",
src: "",
preload: "none",
width: "1",
height: "2"
});
Avec cela caché sur la page, lorsqu'un utilisateur "clique" pour regarder un film (toujours en interaction avec l'utilisateur, il n'y a aucun moyen de contourner cette exigence) au lieu de naviguer vers une page de lecture secondaire, je charge la vidéo masquée. Cela fonctionne principalement parce que la balise multimédia n'est pas vraiment utilisée mais plutôt promue vers une instance Quicktime, donc avoir un élément vidéo visible n'est pas du tout nécessaire. Dans le gestionnaire pour "clic" (ou "touchend" sur mobile).
$(".movie-container").on("click", function() {
var url = $(this).data("stream-url");
$dummyVideo.attr("src", url);
$dummyVideo.get(0).load(); // required if src changed after page load
$dummyVideo.get(0).play();
});
Et alto. En ce qui concerne l'UX, un utilisateur clique sur une vidéo à lire et Quicktime ouvre la lecture de la vidéo de son choix. Cela reste dans la limite selon laquelle les vidéos ne peuvent être lues que via l'action de l'utilisateur, donc je ne force pas les données à quiconque ne décide pas de regarder une vidéo avec ce service. J'ai découvert cela en essayant de comprendre comment Youtube a réussi cela avec son mobile, qui est essentiellement une très belle création de page Javascript et un élément de fantaisie caché comme dans le cas de la balise vidéo.
tl; dr Voici une "solution de contournement" pour essayer de créer une fonctionnalité UX de "lecture automatique" sur les appareils iOS sans aller au-delà des limites d'Apple et en laissant les utilisateurs décider s'ils veulent regarder une vidéo (ou un son le plus similaire, bien que je 'ai pas testé) eux-mêmes sans en avoir un juste chargé sans leur permission.
De plus, pour la personne qui a commenté cela depuis sleep.fm, cela n'aurait malheureusement pas été une solution à vos problèmes qui sont la lecture audio basée sur le temps.
J'espère que quelqu'un trouvera cette information utile, cela m'aurait sauvé une semaine de mauvaises nouvelles à un client qui était catégorique sur le fait qu'il dispose de cette fonctionnalité et j'étais heureux de trouver un moyen de la livrer à la fin.
ÉDITER
D'autres découvertes indiquent que la solution de contournement ci-dessus est réservée aux appareils iPhone / iPod. L'iPad lit la vidéo dans Safari avant qu'elle ne soit en plein écran, vous aurez donc besoin d'un mécanisme pour redimensionner la vidéo en cliquant avant de jouer, sinon vous vous retrouverez avec de l'audio et pas de vidéo.