My team is writing an HTML5 app that uses the appcache and localstorage heavily. Our target platform is ipad and android tablets (and design time we work extensively in desktop browsers, though that's not necessarily a must-have).
Now we want to add some offline-available features that will be beyond what the browser-based storage can support-- namely a library of video & binary content that will be bigger than the appcache can handle.
Without the major mobile browsers implementing the html5 filesystem api, it seems very much like some kind of native app approach will be required (PLEASE correct me if I'm wrong here... I'd love to be wrong on this!). So, I'd love to hear opinions/experiences folks have had. We're noodling around with a few different ideas involving one or more of the following:
Compiling in phonegap + using their file apis
Using the Dropbox sdk (which would also require some kind of native support, not sure if phonegap would work)
writing per-platform custom native apps that host webkit controls, then providing the majority of functionality with our existing, cross-platform html5 app (basically we'd be writing a per-platform custom browser using the standard webkit controls).
Note that I'm a fan of #3 because I feel like we could release a relatively stable shell but then preserve the html5 cross-platform goodness & ease of distribution of our app. However, I don't know if this approach works (and/or if Apple frowns upon this type of approach-- seems like a bit of an App Store loophole).
Very interested to hear what you've tried and/or heard about.
This might be a completely stupid idea but, if you're looking for a cheap way to get extra storage, why not just use an html or js file to contain the data? You could even, for whatever reason, store it as a 64-bit data uri and run the media natively. I think you could even save data to it by just manipulating the manifest to be reflective. It'd take a bit of tom foolery, but it should work.
If you use approach 1 you will be well positioned to move to a web app once the major browsers support the File API. You see the File API in PhoneGap is based on the W3C spec that the browsers will implement.
2, I started working on a Dropbox plugin for PhoneGap Android but I need some "spare time" to finish it.
3, Apple will probably reject your app if it is just a wrapper around your web site. They've done that in the past.
Simon
Related
Our product, a desktop app, is composed of a ton of HTML5 and JavaScript together with a thin platform-specific layer that is basically a WebKit shell. Since this is much the same strategy as a framework like Appcelerator Titanium, and we waste way too much effort on this custom WebKit shell code, we were hoping to switch to Titanium or a similar framework to handle that for us.
However, such a switch would be much more compelling if we could pick up a nice modern JavaScript engine in the process. Like Titanium, we're currently on JavaScriptCore, which sucks (they still don't have Function.prototype.bind!). We'd take either V8, for speed and modernity, or Rhino, for yummy JavaScript 1.7/ECMAScript Harmony features.
Does anyone know of a framework for building desktop apps with HTML5 that uses either of these engines? Or some way of making either work with Titanium that will be very little effort? I saw the v8_titanium and rhino_titanium projects on GitHub, but see no mention of them anywhere else, or any documentation on how to use them. And the Adobe AIR WebKit page has nothing encouraging either.
Node-webkit is just about done being ported to use cef3. https://github.com/rogerwang/node-webkit/tree/cef
To follow up on this, we've just published binaries for all 3 platforms at https://github.com/milani/appjs | http://appjs.org. That's Chromium and Node, provided as a package that works out of the box with no configuration cross platform.
I think you could count Mozilla XULRunner as "app framework". It's more like embedded Firefox than framework, though.
https://developer.mozilla.org/en/xulrunner
It's much much more complex and powerful than Adobe AIR or Titanium.
We ended up on Chromium Embedded, which is a bit rough around the edges but definitely gets the job done.
You can use Adobe AIR to build HTML5 desktop apps.
AIR uses the webkit engine:
http://help.adobe.com/en_US/AIR/1.5/devappsflex/WS5b3ccc516d4fbf351e63e3d118666ade46-7ec1.html
See also:
http://help.adobe.com/en_US/AIR/1.5/devappshtml/WS5b3ccc516d4fbf351e63e3d118666ade46-7ecc.html
I'm currenlty desigining and building a website where I need to embed some audio files (some 60sec extracts from various tracks from a band's album) so people can listen to their material quickly without having to download any files to their desktop etc.
I know QuickTime was a favourite in the past (perhaps it still is?) but I've had some experience with lag and poor load times of a web page because of this. Also, I understand there's an tag in HTML5 but I wonder about compatibility?
Really I just wondered if anyone had any recommendations on the a tried and tested approach to accomplish this?
Not an ideal solution, but I went for a Flash based plugin in the end - seems to work resonably well on compatible devices (shame it's not particularly well supported on mobiles/tablets etc. though).
Give 'dewplayer' a Google if you're interested...
I want to make a single web application avoiding any flash code. This application must contain videoconference, and I want to implement it in pure HTML5. It is possible? I know about websockets, but don't know really if videoconference can be implemented through them with a relative performance (at least, 24fps + sound at a right resolution, minimum 640x480), and both endpoints being web apps (both endpoints should use browser).
Thanks in advance
Anyone following up this question - on Feb 4th, 2013 they produced the solution with WEBRTC in Chrome and Firefox. For examples see https://hacks.mozilla.org/2013/02/hello-chrome-its-firefox-calling/ or http://www.html5rocks.com/en/tutorials/webrtc/basics/ or https://code.google.com/p/sipservlets/wiki/HTML5WebRTCVideoApplication
You can't really use HTML5 video for live streaming at the moment, and it doesn't have support for web cams yet.
Ericsson has modyfied a WebKit browser and is showing how this can be done with hopfully upcoming HTML5 Stream API. See Beyond HTML5 - Implementing and stream management in WebKit
It is impossible to capture web-cam images/microphone feed just through JavaScript (although there are plug-ins which let you handle output through flash), so it would be necessary for you to have some kind of application/plug-in installed.
The speed part is just for the client to worry. I mean, web sockets will be as fast as the connection permits.
You should do some research about web workers, since they would be very useful for speeding up your application (you could have microphone interface, web-cam interface and UI all with their particular worker, thus never blocking the application or rendering it unresponsive).
EDIT: the aforementioned jQuery plug-in works through the use of <canvas>.
As Jonas said, according to the situations now, we can't build video conference with HTML5. There are many limitations with browsers also. As there is no common video codec supported by all browsers. And live-streaming is also properly supported by safari only(using HTML5 video tag). As per my experience we can't build live-streaming on windows with any browser properly.
But if you wanna get some information about live streaming see https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html
you can use this source to test your live-streaming examples
"http://xfunoonx.api.channel.livestream.com/3.0/playlist.m3u8"
This content will work only with safari on Mac.
a client wants to "modernize" a 5 year old web/html-based Blackberry "application".
The application allows field service technicians and franchisees to inquire on warranty
and service status. Currently they use very simple php/html pages.
Application seems slow, especially on repeated inquiries which require constant reload.
Blackberry/Java seems to be obvious choice, but client seems to think that
development and maintainace is expensive, which I suppose is true because this skill
is not very common around here.
I am thinking of maybe loading all pages in a single initial load and use a javascript
hide/show type technique to reveal pages as user requests them, and using ajax to populate/update data.
They want to target javascript enabled Blackberry devices (OS 4.5 and later). I know that issues and limitations
with css and js on early browsers. i would like to hear other people's experiences.
I know jQuery so that would be obvious choice, but it is pretty fat for wireless. Is there a better
toolkit for this purpose - I found the iqTouch site, but that was not Blackberry specific. Any sites with examples that I can harvest?
If you're targeting OS 4.5 and later, all I can say is good luck. BlackBerry support for HTML was pretty poor in older devices, and you're hit and miss at best with anything more than the most basic use of JavaScript. I've had very little luck with anything other than non-dynamic HTML websites with the older browsers.
With OS 5.0 and later you have a lot more options. Support for the Gears APIs and better JavaScript. The Widget SDK even lets you easily create HTML/JS based 'Widgets' for BlackBerry that can contain a bunch of pre-cached data. BlackBerry 6 of course, with its WebKit based browser and HTML5 support can do pretty much anything that iOS or Android devices can.
So my recommendation is to only go dynamic if you can target 5.0 and later. Or potentially a site that degrades gracefully to browsers that don't support JS well (either user agent detection or some fancy JS coding) and users with older devices have to deal with a slower experience.
have you looked at features available in HTML 5?
we've trying to develop a mobile web app that will provide offline capabilities, not just reading but also creating content.
Gears supports three important aspects:
- local server so we can have cached static content such as html, css, js, etc
- local database so that we can have data stored locally for offline access as well as store new content inside of it while offline
- workerpool, used for a background process that syncs data back to the server
By the looks of the gears page and some other articles, gears is being abandoned in favour of html 5 which is understandable.
However, at this stage there are two problems:
there's still a long way to have HTML 5 supported by major desktop browsers,let alone mobile ones
HTML 5 does not support workers, there is a draft http://dev.w3.org/html5/workers/ but I assume real browser support is still far away.
Do what does one do today? (e.g. within the next year)
Cheers
Rok
I think that you have slightly misinterpreted Google's position on Gears. According to an article in the LA Times:
The Google spokesman wrote to clarify in a follow-up e-mail, "We're continuing to support Gears so that nothing breaks for sites that use it. But we expect developers to use HTML5 for these features moving forward as it's a standards-based approach that will be available across all browsers."
It sounds to me like it is completely safe to continue using Gears, until and after HTML 5 is ubiquitous.
HTML5 support is a little better then you think.
Android has various support for HTML5 standards, with the inclusion of Google Gears into most versions and Android 2.0+ having native support for HTML5 (at least as far as audio/video, canvas, offline storage, and geolocation go). IPhone also supports offline storage along with audio/video tags. WebOS seems to have offline database support, but I don't know much beyond that.
http://www.whatwg.org/specs/web-workers/current-work/ is the web worker draft implemented in Firefox 3.5 and Safari 4, so they should wind up in IPhone's version of Safari eventually.
So if you can live without worker threads and don't mind limiting yourself to Android, WebOS, and IPhone, you can use a hybrid approach of HTML5 with a fallback to Gears.
I don't think supporting other smart-phones is going to be possible in a truly portable way, although Firefox for Mobile (which is nearing release on the Nokia N900) will support all the HTML5 as Firefox 3.6.
Appcache, Web storage & Web workers works on Firefox and newer Android devices.
Use this handy test http://dev.w3.org/2008/mobile-test/v2/ to profile browsers.
HTML 5 does not support workers, there is a draft http://dev.w3.org/html5/workers/ but I assume
real browser support is still far away.
I coded a working example of web workers using the WebKit engine included in Qt 4.6.2. Looking at the code history, support was incorporated sometime in 2008.
I've been surprised by the level of HTML5 already in (desktop) browsers (excepting IE of course). Mobile lags a few years. I've found this site useful: http://caniuse.com/