I'm looking for the best way to keep a WebRTC video stream + the stream controls (hang up, mute etc.) loaded and active, even if the user navigates to another subpage through the navigation menu.
I thought of the following way, however I don't know if this is the most practical one or if there's a better solution to this nowadays: I'd simply make a wrapper with the navigation menu and put an iFrame where currently the content is. The video stream itself would go in the menu bar itself (it's a sidebar which is wide enough to do something like this), when the user clicks on a menu item, the iFrame src is replaced with the new URL.
Is this the right way to do this? If so however, since I haven't used iFrames that much so far, I have a few more concerns:
Are there any drawbacks as for browser features when using iFrame? For example, I know that Chrome asks you to put several features into the allow attribute of the iFrame, for example when using the camera, microphone or location of the user. Is there anything I absolutely cannot do in iFrames?
Do iFrames share the (PHP) session and cookies with the "main" wrapper, or are those separate sessions?
And probably my biggest concern: How could the JavaScript codes of the wrapper and the iFrames communicate with each other? For example, how could I send a hangup-signal to the video stream in the wrapper from within the iFrame?
Thanks for any hints!
Iframes could work.
Are there any drawbacks as for browser features when using iFrame?
The main issue is that you don't really get control over the presentation of the page while that iframe loads. Users may see a brief moment of solid white, for example, while the previous page is torn down and replaced.
Is there anything I absolutely cannot do in iFrames?
Iframes are pretty flexible. Just keep in mind that they have their own JavaScript context so there is some extra code you need to write to shuffle data back and forth.
Do iFrames share the (PHP) session and cookies with the "main" wrapper
Yes
How could the JavaScript codes of the wrapper and the iFrames communicate with each other?
You can actually access the Document object for the iframe from the outer iframe. (Assuming they're on the same origin, of course.)
const iframe = document.querySlector('iframe');
iframe.contentDocument.querySelector('body').whateveryouwant
Probably the best way though is to use the postMessage API. This allows you send data back and forth as-needed, in a nice isolated way.
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
Related
Is this even possible? To have an mp3 play where it left off when you navigate to a different page on the same website? I seriously don't even know where to begin. Kind of new to HTML, CSS, etc.
Any Ideas? Thanks.
Not across multiple page loads. But you can have a single page which plays audio and provides navigation therein for the user. A couple overarching structural options would include:
Create a Single Page Application (SPA). Here your one "page" would play the audio, and the site navigation would happen within this single page instance with JavaScript/AJAX. The browser would only ever load one "page", but the overall application would dynamically load/unload as elements of that page as you see fit.
(A very old method, but still works) Create a parent page with frames for navigation. The parent (frame) page would contain the audio, and the rest of the navigation through the application would be done in frames within that page.
I'd recommend the first approach, but either would work.
If you reload the entire page (and therefore the audio source), there is no way to provide a seamless playback. There will always be a very noticeable gap due to page load times, even if you try to keep track of the position within the audio track. Slow internet connections will make it worse.
Instead, you can embrace one of those four options:
Single Page App:
As also pointed out by David, my suggestion would be to create a single page application, i.e. a page that loads once, then loads/replaces all additional content dynamically. One the user clicks a navigation link, instead of loading a new page (or reloading the current page), you just replace the main content, using AJAX. The part that provides the audio stays in place.
Additional tab/popup/window
You could create an additional tab, popup window or window just for the sake of playing the audio. One example of this is the German radio station "radioeins". At the time of writing, their website provides an orange button in the top right that will open a popup window for their live stream, allowing the user to continue browsing their website with the music continuing to play uninterruptedly from the popup. I would only go down this route if the single page app is not an option, as popups or additional tabs are bad UX and popups might be blocked by browsers.
iframe
You could provide the main content of your page within an iframe, or the other way round, provide the audio from within an iframe. I would recommend against this, as there are several disadvantages to this approach.
Frames
Frames would provide a similar approach to iframes, but they are deprecated, so I strongly recommend against this one as well.
tl;dr
Make it a single page application if you can, otherwise resort to a popup-solution.
I have a site that is similar in layout and function to the app of any streaming music service (Spotify/Rhapsody/iTunes/). I've got a persistent play control at the bottom, persistent navigation on the left, and the center/bulk of the page is used to pick what you want to play, read more about what you are going to play, etc.
I've implemented it in the most logical (for a programmer) way using an iframe for the center content. But is there a better way, a way more conformant with SEO?
I suspect the current approach is terrible for SEO (even with sitemaps) and might violate some cardinal rule because I would need to add some code on each page to check if it is being viewed through the proper iframed interface and if it is not then the page would need to redirect to load up the full interface with the desired content in the center iframe of that interface (that's how I would and have solved similar problems ten years ago).
Rather than redirect on landing I could simply add the interface elements but unless some unknown magic happens when they explore content the page will reload and anything they were playing would stop playing as the page unloads. I do not want to interrupt play, even to resume it at the right spot.
Is the old and reliable reloading mechanism the only real solution? Can you get do it and not be SEO penalized?
Any ideas?
In your case the UX is the most important thing to consider and to work on it, then the other things come like SEO.
You have to focus only on the most important pages like singers pages, geners and playlists, other pages no need to index them, you can avoid indexing them by adding canonical links or from robots.txt or by adding meta tags noindex.
Other thing is the URLs and advanced techniques, when the user click on link you should get the results without refreshing the page using JS, but here Google will not be able to crawl these pages.
Here you need to use advanced techniques like "Progressive Web Enhancements) and the best example to see is Tumblr.
All the pages are done by using this technique which allow them to add a great user experience and at the same time Google can index all the pages.
Example for the links:
Singer Page
You have to read more about it, also the old technique "graceful degration" for old browsers can help you a lot.
I am making a website for my friends band. I would like to know if its possible (apart from using Ajax) to keep audio playing after clicking on a link to another page on the site?
I currently have it set up using Ajax to reload the content, but I am having a few issues with it, and I'd rather not deal with the bother unless I really have to.
If not possible, is there a way to minimise the disruption (pausing then playing again) while navigating? It would be possible for the new page to continue playing the track from where the last page stopped, but I would like to minimise the pause. Or, on this subject, is it possible to keep certain page elements loaded after changing the URL (without using # urls), like facebook does (as in, you click on it, but the banner never disappears during loading)
Thanks for any help :)
Use Ajax to load content and History API’s pushState() to alter URL without page reload.
For consistent behavior across browsers, consider using a wrapper library like History.js.
Sites like Facebook use JavaScript/AJAX for these kind of things. If you don't want to use it, you can use frames (not recommended). Divide the page in two frames: the player and the website itself. This way you can easily turn it off too, just open the site without frames.
Good luck!
Of course you could also pop up the player in another window/tab.
(For now) It won't be possible without frames or javascript.
It might be troublesome to implement it differently than via AJAX, however you can either use IFrames, where the music would be played in the main one and the content is displayed in the child on or you can always make it a Flash webpage.
Build it in Wordpress and use the AnythingSlider plugin to have the pages shift within the main page. This way you can have tabbed navigation and never leave the actual page. No need to write too much code. The AnythingSlider uses html for the slides.
You can also not use wordpress and just use the AnythingSlider code.
http://css-tricks.com/anythingslider-jquery-plugin/
and
http://wordpress.org/extend/plugins/anythingslider-for-wordpress/
and
http://css-tricks.com/examples/AnythingSlider/
Most of the WebSocket examples out there are centered around a single web page, where the content updates with chat, financial or some other live metrics - makes sense for a single page.
However, given a news feed scroller, where that feed needs to exist on every page of the site, I would like to open the conversation up to some possibilities for this.
Currently the site is a classic ASP site, but will be eventually migrated to MVC/MVP.
Since we don't want to open/close the web socket every time a link is clicked on (currently loads a new page), I was thinking about an IFrame type of UI, which can be done with updatable DIV's and jQuery.
Given a simple containerized UI template with a header (c1) and footer (c2), content in the center (c3) with left (c4) and right (c5) bars, when clicking on a link on the header, where the main menu would reside, instead of updating the entire page, I could load a page into one of the containers (updatable div), preserving the WebSocket container's connection - avoiding needing to re-establish the connection.
What are some other options to consider to accomplish this?
Thanks.
UPDATE
If you take a look at FB's implementation, their status bar on the right and even chat, stay on the page across link clicks. How is that accomplished?
Using IFrames or otherwise modifying your page state (rather than full page loads) is probably the best direction right now but shared Workers may also do what you want. The idea is to allow multiple pages loaded simultaneously from the same origin to share a web worker. I suspect that the shared worker will persist even for page navigation within the same site. However, I have not actually tried it and the W3C spec is not clear to me on this issue. I would be interested to know if this is in fact true.
Note that Shared Workers are in Chrome, Safari and Opera but IE and Firefox have not committed to supporting shared workers yet:
http://dev.w3.org/html5/workers/#shared-workers-introduction
http://caniuse.com/#feat=sharedworkers
The purpose is to let people embed my iframe at a certain size say 100*100, but then per user clicks this iframe should resize itself to the page size and back.
This should be independent of the structure of the HTML embedding the iframe (if possible).
Is it doable?
Guy
That is easily possible since an iframe is just an node on the page. I strongly recommend using iframes, however. My suggestion is to find another way. Iframes tend to be a portal for the passage of malicious client-side code.