We want to make an audio based web based app that will have many sound snippets. We want to cache these files so that performance is good and not dependent on network speed. Can HTML5 cache audio for offline mode?
It certainly seems to me that this should work, and I can't find any documentation that says it shouldn't work (either from the W3C or from vendors like Apple), but putting audio files as resources in cache manifest just doesn't seem to work with Safari on the iPad & iPhone at least.
Sounds play fine when the app is in online (although it seems to load them anew each time and not cache them) and it doesn't complain about the resources not being there when in offline mode (which is does immediately if you forget to include a JavaScript, CSS, HTML or image resource).
Instead of complaining (or loading); if the element has a control that control is replaced with a box that says "Cannot play audio file.". Alternatively, if it's an element without a control - i.e. accessed via JavaScript all to .play() - then it simply just doesn't play (it doesn't cause any errors, there is just no sound, the JavaScript otherwise continues to execute normally).
I have tested this with pretty small (<20k) files and the result is the same, so it doesn't seem to be size related, just a blanket refusal to copy. I'm not sure if you can encode sound as a resource in a page (e.g. encoded in base64) the way you can with images, but I'm going to investigate that option - I suspect that would be possible. I tried encoding audio data as data URI strings and even tried generating audio on the fly - both work fine in Safari on the desktop but do not work on the iPhone / iPad OS (at least on version 3.x - I have not tried on iOS 4, but it won't be out for a week, and is not expected for the iPad for a few months, even if they do fix it).
I would guess the refusal to cache sound files in iOS is an implementation bug or intended limited functionality. It's certainly annoying and a show stopper for a lot of use cases.
I am not sure what happens with other HTML5 clients, I'd be interested to know (in particular on Andriod). Google's support for audio hasn't been stellar either, so it may suffer from the same limitations.
You could always develop a decoding/encoding layer that talks to the client SQLlite DB
I don't see any reason why you can't specify audio files in the cache manifest.
Related
i was poking in the Youtube-app for the Nintendo Switch and saw that it's the cobalt browser pointing to youtube.com/tv. Since the switch is lacking a (good) browser*, i thought that it may be possible to compile a/the browser for the Nintendo switch myself. Learning about the topic showed me that i don't know nearly enough to do this myself and i also have no idea where to get some help with this.
Switch apps are compiled with the nx_sdk, which is reserved for "approved" developers and under an NDA, so its not exactly easy to try to copy what Youtube did. We do have a toolchain to compile homebrew and it features a lot of the same things of the official SDK but it's still just for hombrews.
In my despair i tried to modify the Youtube-app to just use a different domain than youtube.com, which works but there are other checks in place that i cant really solve with my limited assembly knowledge.
So i my question(s) is/are: Is there a way to get cobalt to the switch as homebrew? If yes, where can i start and what do i need? Is the youtube-app (switch) source code available somewhere (minus the switch SDK)? What else could lead me to an acceptable solution of having a/the browser on the Nintendo Switch?
* Officially the switch has no browser, however there is a very limited Netscape browser for situations like wifi-captive portals or triggered by ingame TOS, health notices or video playback. The browser can be run by homebrew any time but like said above, it lacks functionality that other browsers all have.
The Cobalt source is available from https://cobalt.googlesource.com/, but it won't include the Switch port code. You could try implementing your own Switch port, but it is not going to be trivial.
More importantly, though, Cobalt is not a general-purpose browser. It is not based off of WebKit, and it only implements a greatly reduced subset of web specifications. Websites will not work out of the box on Cobalt, so it's not a promising endeavor.
Cobalt is designed to run single-page web apps that target Cobalt directly. By making many simplifying assumptions, it can be more embedded-friendly.
TL:DR - How can I stream content (specifically music and videos) from a Cloud Storage solution, like Google Drive without having the entire file cached first? My goal is to create a Netflix/YouTube-esque experience with my movie/music library.
So, this seems to be an issue that many people are having, and so many forum posts say that PlexCloud is the solution, but it isn't available anymore, so I want to find another way.
Essentially, I would like to free up space on my local machine, offloading my movies and music to the cloud. I would like these files to be available instantly from any of my devices.
The solutions I have come across so far are:
Google File Stream (or similar)
Expandrive
CloudMounter
These apps mount your cloud storage as a network drive and allow you to store files on the cloud and have "instant" access. These sound great in prinicple, but the issue with all of them is that the entire file has to be cached first before you can watch/listen. This defeats the whole purpose of having the files saved to the cloud, as every time you want to watch a video, the entire file has to be cached. This is very inconvenient for me, as I have a rather slow internet connection, monthly transfer limits, and you have to wait until the file has been cached before you can watch.
The closest I've got to making this work is with Kodi, but the interface is horrible on anything other than a TV. On desktop or mobile, it's useless! But, as far as functionality, the way it retrieves files is perfect. On their website, it says that it only caches up to ~60MB at a time, meaning you can start watching/listening instantly, and the file doesn't need to be cached in its entirety.
So my questions are:
Is there an alternative to Kodi that works on all major OS's, where the files are instantly available and the caching system works like YouTube, Netflix, where only a small portion of the file is cached at once?
Is it actually possible to play a video natively in the OS (in an app like VLC) before the entire video is stored on the local disk, either in storage or in cache?
If so, how would I go about doing this?
A few conditions for the solution:
I don't want to have to use the browser every time - A desktop/mobile app, Finder, or File Explorer is essential.
Ideally something that will run on Android TV, or at least is able to use Chromecast.
Files must be instantly accessible - nothing that will cache the entire file first (unless this is impossible due to how OS's work).
If possible, I would prefer NOT to have to go through some massively complicated set up with coding, terminal commands, or using a dedicated server. The solution must use cloud storage, ideally with an app that works on major OS's.
Thanks in advance for help and suggestions!
I am in the process of speeding the perceived load time of a website specifically aimed at the mobile platforms (iPhone primarily, Android secondarily, who cares about the rest...) I have already tried several general techniques for speeding load times for normal websites but I was wondering if anyone had specific pointers for the mobile web performance.
I am already bundling scripts, spriting images, lazy loading as much as possible, putting fixed sizes on things, linking css in the head etc. I want insights specifically for mobile.
For example I have heard that the iPhone will only cache files less than 25k so sometimes splitting a script/file into 25k chunks may give an overall boost since now they can be cached even though it caused additional connections to be made. Any other insights like this would be much appreciated.
Also, does anyone know of a good tool to test the load times in iphone?)
Ok, here's some measuring tools for you...
Steve Souders' mobile bookmarklet - http://stevesouders.com/mobileperf/mobileperfbkm.php (a bit limited on he timing front but has lots of interesting other features)
Stoyan Stefanov's iOS app for exploring page load - http://calendar.perfplanet.com/2011/i-see-http/ (very new, so not sure about it's limitations)
3P Mobile have their own iOS browser in beta that produces waterfalls - Android version was very good.
As far as optimisation goes...
The mobile cache may be small but you still have access to localstorage i.e. include CSS/js inline and extract and save to local storage - Bing mobile does this.
DataURIs are another way of reducing requests but of course the user loses the option to turn off images
Ensure you make good use of keep-alive and connection pipelining - splitting between multiple hostnames can get in the way of these so be careful if you do this.
Caching varies wildly between different phones an OS versions saw an article on it recently will see if I can find it again.
Yahoo! has a nice page about how to squeeze the most performance out of your site.
They also have a Firefox plugin (YSlow) that automatically checks whether your site follows them and suggest improvements. That plugin covers also performance problems that may affect mobile browsers.
I'd like to answer your call for a mobile web site profiling tool - WebDevTools:
https://play.google.com/store/apps/details?id=com.voltcode.webdevtools
disclaimer - I am connected to the company that released this software
While not being targeted for iphones, you could definitely test on various android models and get the load times.
From my experience, IPhone 4+ will load pages the same or better than HTC Desire and similar - both in general speed, but also in HTTP concurrency, etc.
Check out this testing solution:
Tutorial: Does Your Website Load in 3 Seconds?
http://blog.testobject.com/2013/09/does-your-website-load-in-3-seconds.html
I have been following the usage of JavaScript for the past few years, and with the release of extremely fast scripting engines (V8, SquirrelFish Extrene, TraceMonkey, etc.) the possibilities of JavaScript have increased dramatically. However, the usage share of Internet Explorer coupled with it's total lack of support for recent standards makes me want to drop a bomb on Microsoft's HQ, as it creates a huge amount of problems for any website.
The game will need to be pretty dynamic client-side, with animations and other eye-candy things, but not a full-blown game like those that run directly in the OS using DirectX or OpenGL. However, this might be a little stretch for JavaScript and will certainly feel extremely slow in Internet Explorer (given that the current IE engine can be hundreds of times slower than SFX; gotta see what IE9 will bring), would it be better to just do the whole thing in Flash? I know this means requiring the plug-in AND I have no experience whatsoever with Flash (other than browsing YouTube :P). It also means I can't just output directly from PHP, I would have to use XML or some other format to pass data to it (JSON is directly integrated in JS and PHP can deal with it easily).
Another idea would be to provide an alternative interface just for IE, though I don't know how (ActiveX maybe? or with Flash, then why not just provide it to all browsers) or totally not supporting it and requiring the use of other browsers, although this is plain stupid from a business perspective.
So here am I, wondering what approach to take and thus asking for your advice. How should I build the client-side? AJAX in all browsers, Flash in all browsers or a mix (AJAX for "modern" browsers and something else for the "grandpa": IE).
I recommend a plug-in platform (Flash, Silverlight, or Java) over AJAX. Having a clean layer of abstraction between your game and the client's browser is a big advantage. In any non-trivial AJAX game look forward to endless corner-cases where browsers differ in performance or implementation.
Personally, I think Flash is easy to learn if you are coming from AJAX experience. Flash is currently the most widely installed and proven plug-in for browser games. However, Silverlight and Java are both building momentum. Also, the Unity engine has become a popular choice for commercial browser games.
I think you shouldn't leave Java out of the equation. It's a powerful, fast language, and with Java applets, you can do almost anything. If you want hardware-accelerated graphics via OpenGL, JOGL can do it, even in an applet.
On the other hand, it might not be right for you. But at this early stage, I think you should evaluate all of your options, and since you have no experience with Flash but sound like you've got a bit of programming experience, you might feel more at-home with Java.
I believe the current answer is Flash game.
Alternatives:
Java Applet: getting less and less common those days and it is not commonly installed as a plugin on many computers.
SilverLight: too new and might vary and change in time. not commonly installed on many computers and it's Microsoft (whom tends to change technology every 2 years ...)
JavaScript / AJAX: Still a new kid on the block, it's on the rise it is true with many nice features, but still lack of good cross browser for IE even IE8, can not play sounds internally, still slower than the others, and you don't know where will it evolves.
Eventually probably the best solution for now is Flash development:
Cross platform. Works fast. Long time already alive and have a lot of support.
I hope this answer will change in the next year. Happy Peasach.
Check out Jmonkey. The "plugin" loads if you have Java on your machine. Once it's cached, the next time the visitor goes to the page, it your game loads very quick. Check out their website for demos and see what I mean: http://www.jmonkeyengine.com/
Oh, I forgot to say, it's a 3D scenegraph Java engine. I just tried it again, and it loaded in linux. Looks they've put in some good work.
Don't do it with javascript in the browser. And Flash really can be a pain just because it's closed source and you don't know if you've made a mistake or found a bug - speaking from experience. I'd never want to make another Flash game again.
How about using RaphaelJs , it is a Javascript library that make dinamyc images using SVG, and for IE, it try to make those images using the IE alternative: VML. Im using it on my own WebGame, but i dont really make complex graphics in it. The most complex thing done on RapahelJs was a heath map (20 * 20 tiles ) with a dinamyc opacity slider. An it work with jquery without any problem or configuration!
We provide a web application with a frontend completely developed in Adobe Flash. When we chose Flash 6 years ago, we did so for its large number of features for user interaction, like dragging stuff, opening and closing menus, tree navigation elements, popup dialogs etc.
Today it's obvious that AJAX/JS offers roughly the same possibilities and because of the number of frameworks that are readily available, it's very feasible to implement them.
Is there a technical reason one should choose either technology over the other? By "technical", I mean performance, security, portability/compatibility and the like. I don't mean aspects such as the very non-programmer way development is done in Flash or whether it makes sense to switch an app from one to the other.
As I just explained in another question, it seems to me that JS is way ahead in terms of market share and I'm wondering whether we are missing some important point if we stick to Flash.
In addition to what others have said, Flash is constrained in the "rectangle" and cannot be added to a normal html page in an un-obtrusive manner.
#Gulzar I think when more browsers will support the video tag like mozilla 3.1 does we'll see even more adoption of ajax/js over flash.
Adobe Actionscript is a statically typed language, Javascript is dynamically typed. Depending on your point of view, this may be a good thing or a bad thing.
With Javascript/HTML/CSS you're going to be heading into cross-browser compatibility hell, especially if you want to support older browsers. This can be mitigated by the libraries that are available, but it's still a big headache. With Flash, you write the code once and it just works in all browsers.
Even with the libraries available, Flash user controls are simply more advanced than anything you can find in the world of Javascript/HTML. In Javascript, you are not going to find anything that comes close to the simplicity and power of a databound user control that Flash provides.
I don't see how Javascript has more of a "market share" than Flash. Pretty much anyone with a web browser has a Flash plugin installed. I'd be curious to know how many people disable Javascript but have a Flash plugin.
Also keep in mind that you're going to be in for a huge learning curve and lots of development time if you decide to switch your technology base so you'd really better have a good business reason to do it.
This decision also has a lot to do with what your application does and who your install base is.
Edit: I see people have mentioned that the iPhone doesn't have Flash support. I would expect this to change with the install base of the iPhone - Adobe would be crazy not to support it.
Correctly designed AJAX apps are more googleable than Flash
Correctly designed AJAX apps are more easily deep linkable than Flash
AJAX doesn't require a plugin (Flash is pretty ubiquitous, so it's not really a big deal)*
AJAX isn't controlled by a single company the way Flash is
Edited to add:
* Except for the iPhone, as Abdu points out.
JS and Flash both have great presence on the web with overlapping capabilities. One area JS is still lacking is in rendering video.
Flash, used well, allows easy localization and internationalization.
Furthermore, it is much easier to use Flash in an accessible manner; you can feed screen readers the right text, instead of having them iterate over all of the possible form elements.
I think Flash should be limited to online games, videos and animation. Otherwise use html and Ajax. It's a web standard and supported by almost all devices.
AFAIK, the iPhone doesn't support Flash. That's a fast growing segment you're blocking out already. Keep it simple and efficient.
Although flash is pretty ubiquitous on desktop browsers, mobile support is very limited (flash lite? yeah, right). I get really frustrated looking up a restaurant on my phone only to find the entire site is flash based and I can't even get a phone number or address!
One benefit of Flash is that it has a few facilities to help do cross domain type operations safely, which can be helpful. Flash also has (limited) support for some hardware, which is not possible with Javascript.
Personally, I'd try to use as much Ajax as possible before turning to something like Flash. From the UI perspective, it is better in that the controls and basic authoring is a little more developed. The Sound Manager project is a good example of effectively using a small amount of Flash while keeping the remainder in Javascript.
I suspect one of the reasons javascript is becoming more popular is that it's more easy to retrofit into an existing application.
As I can't accept two answers, I'm going to merge Christ Upchurch's and 17 of 26's answers in my own post. I think, these two together pretty much sum up what I wanted to know. Thanks guys!
If you're dealing a lot with polygons, then Flash is still easier to program and debug. With AJAX there are a lot of libraries to handle polygons, but the more libraries your app uses, the slower it gets.