I have a working sample with IndexedDB that works perfect for my Desktop Chrome. Nevertheless, my main aim is to develop for iOS devices (Chrome-Safari) and this API isn't available there yet.
What should I do?
I have seen this Polyfill: http://nparashuram.com/IndexedDBShim/. But, I tested it with my iPod Touch 5th Gen and somehow the 19th test doesn't work...
Should I use WebSQL which was deprecated?
I liked the idea of the Polyfill but that it not working for me...
Are there any plans to support IndexedDB in the future for all the non-supported browsers?
Thanks!
Here is another similar polyfill you can try, but in my (albeit limited) experience, both polyfills are buggy/incomplete. They both also have many open issues on GitHub of people reporting problems. And when I tested one of them (I forget which one) it was significantly slower than native IndexedDB.
Maybe it's possible to create a decent polyfill, but the current ones don't seem to be doing the job.
Should I use WebSQL which was deprecated?
The problem with WebSQL is that it's never going to be supported in IE or Firefox. You could probably get away with WebSQL if you're only targeting mobile browsers, at least until Firefox OS or Windows Phone grabs significant market share.
Are there any plans to support IndexedDB in the future for all the non-supported browsers?
Let's be clear. You're asking about Apple, since everyone else supports IndexedDB in their latest browser (iOS Chrome uses Apple's rendering engine because Apple won't let them do anything else).
Not only does Apple not support IndexedDB, they haven't publicly said anything about it (as far as I can tell... and I have done a fair amount of searching). Which seems pretty weird. So as best I can tell, nobody has any idea if Apple ever plans to support IndexedDB. The conspiracy theorist in me thinks maybe they're trying to sabotage HTML5 apps to force people to write native apps, but that's purely speculation.
In total, this leaves us developers in a pretty shitty situation. There is no good cross-platform solution. I recommend you complain to Apple about it. That's what I've done, and I've asked my users who want to use my IndexedDB-based app on iOS to do the same. Still no word from Apple.
UPDATE - Indexeddb is now supported in iOS 8 as stated in WWDC 2014 - but unfortunately it's broken pretty badly.
Looks like IndexedDB is not working as web app (pinned to the home screen).
Works inside Safari.
IndexedDB was never be made to be directly used by developers. It is more like an API that can be used to build a "real" database on top of it.
Nowadays there are many alternatives that you could use instead.
NeDB used heavily, but deprecated
PouchDB
RxDB
If you still need to use IndexedDB, at least I would recommend to use a wrapper like dexie.js which at least makes it easier.
Related
I'm unsure whether to create a desktop app via Electron or create a WebApp instead. My customers are to 70% IE (i believe mostly older versions) users and I don't want the app to run slow, crash or not support features and animations. So knowing how IE does nowadays would help me with this decision greatly.
IE does not support a lot of new functionality. But if you write your pages correctly that is not a problem. It can be difficult and expensive to get things to work in up-to-date browsers, mobile browsers and IE, but it can be done.
Electron is great since it provides the same browser interface for everyone. But Electron Apps can become very bloated and large. If you want to only use the latest HTML, CSS and JavaScript then Electron is much simpler to use then a Web App. But using Electron means that your customers will not be able to get at your code from their mobile devises.
I am in charge of developing and maintaining several website on client-side. When it comes to temporary storage, I always think about localstorage in the first step. It is a fantastic feature which is introduced from html5 and it help me conquer many tasks for a long time.
However, it doesn't perform so well on private mode of safari browser. Precisely, it will broken when calling localstorage.setItem(...). So every time I use localstorage, I need to do some workaround only for private safari and it is depressing.
I am just curious why private safari does not support it? Is it really a big deal for making such feature compatible with current version? After all, we have a 95.37% support from modern browser now. (I know merely about the inside of modern browsers so if it sounds stupid please just ignoring it)
I am also looking for alternative solution which support all modern browsers.
Any suggestions?
thanks.
One of the requirements of one of my clients is to show a message to a user that's using an older version of Firefox, Chrome, IE or Safari. For the last two it's easy (IE 9+ and Safari 5+). But for Firefox and Chrome, the requirement is that the site supports the current and the previous version of each browser.
To get the clients browser and version is quite simple, but I need to know what is the last version of each browser. Is there any way of doing that?
Well, technically, all you need is a place that keeps track of what the latest version of each browser (Ideally with a web service).
A quick Googling I was able to find: http://www.webdevelopersnotes.com/articles/latest-browser-versions.php
It's not a web service, but you could simply parse that HTML and get the latest version of each browser. Alternatively, you could keep track yourself and manually update this information in your database.
You should only ever have to worry about IE when it comes to version enforcement. Exception being, of course, if you need a specific API that's just not available in previous versions of Chrome/Firefox, but in that case you'd look and enforce the API, not the browser version. Adding to that, if Chrome/Firefox don't have an API, chances are even the most bleeding edge version of IE won't either, so the point is moot. The fact is Firefox and Chrome, and in part Safari, are far ahead of IE when it comes to browser hosted capabilities that trying to enforce specific versions of the former would likely be a lot of wasted time and effort to yield nothing substantial.
The best I could find was this. It has an export option that allows to export in JSON, XML...
I would strongly suggest that you don't check the browser version, instead try doing feature detection using, say, Modernizr.
What features of your client's site depends on specific versions of each browser? If you use Modernizr you could perform a check on a feature, say some video stuff, and if the current browser does not support that feature, then display a message to the user suggesting they upgrade their browser.
Detecting browser versions via Javascript is very flakey at best.
The only reason I'd say you need this kind of verification is because your webpage has features only available to latest browsers. Instead of relying on version numbers, I suggest learning Modernizr.js for your website.
http://modernizr.com/
It can detect particular html5/css3 features individually.
as I am getting more and more into Android PhoneGap app development, I can see more and more nuances and little details between built-in Android browsers throughout the versions. I searched for some official or fan document, which would deal with these browser version differences. But I can't find anything useful.
It's a lot frustrating, because you have to test everything on all versions of Android emulator and if app grows big, it's A LOT of work to test all the features in all versions.
Everyone is excited about HTML5, I was too, but only to the point when I moved to doing the real thing. I realized that there is so many problems when dealing with different versions of Android behaving sometimes a lot differently.
If anyone has some good resource to share, I would be very happy. Thanks
EDIT: Added example of different behaviour betweeen Android browser versions ( but there is many of them):
This works in Android browser in 1.6, 2.2, 2.3 and 2.3.3. But it failes (application crashes or stops JS execution) in Android 2.1:
Object.keys(var).length
You asked a pretty general question. The general purpose answer is that any sort of cross browser development (even cross versions of the same browser) requires that you develop a familiarity with what features are safe across the targeted browsers, which features are not safe across the targeted browsers and which ones must be used only with careful testing or feature detection with fallback.
While one wouldn't exactly expect the type of difference you saw with the one example you referenced, it is clear that that is a fairly new feature in ECMAScript and it's not consistently implemented across normal browsers so I would put it in the category where it is not safe to assume that it works on all versions of Android, even if you've seen it some versions of Android. That means to me that you should only use it if you've explicitly tested that it's reliable in all the browser versions you are targeting or devise a feature test and only use it when you know it's present and reliable or develop a safer work-around.
As I think has been mentioned previously, this thread has a bunch of proposed work-arounds for the specific issue you mentioned.
I am not aware of any detailed written material that would document in advance for you the details of the differences between different Android browser versions. Since it's open source, there are probably developer checkin notes and some level of release notes, but that will probably be like looking for a needle in a haystack and may not even contain what you want. It is rare for any developers to produce such detailed information. We don't generally get that level of detail from any of the existing desktop browsers or iOS browsers and, even if you were on the development team itself, you probably would only see part of this info. I don't think you're going to find official documentation that covers what you want.
You're going to have to learn to treat is as more of an unknown and learn what areas are "safe", what areas require extensive testing before using and what areas are just too risky. Even when doing that, you'll find Android bugs in some version that trip you up. That's just the nature of building on someone else's platform. At least the Android set of browsers are a much simpler target than trying to target all desktop browsers from IE6 to IE9, Firefox 3 to 5, Safari 3 to 5, Opera 9 to 11, Chrome 9 to 12, all Android, all iOS and use HTML5 when available which is what I'm working on.
Once you've been through this wringer a couple times, you will realize that if the newer language/library feature carries any risk, you shouldn't use it at all unless it's absolutely central to what you're trying to accomplish and then you will have to test the hell out of it. If it's something like getting the length of the associative array which is just a programmer's convenience, then it's probably simpler to stick with a work-around that is guaranteed to be safe and just not spend your time dealing with any browser-support risk.
The only official documentation I am aware of is part of the Android developer documentation. If I were a betting man, I would bet that it only covers a subset of what you are seeking.
The general idea behind cross browser Javascript is inline feature testing (at least how I've come to accept it.) I don't know exactly what "features" you are specifically looking for but it's generally wise to test for the existence of a feature set then use it and have a fallback if that doesn't exist. (Even if the fallback is, "This site requires a browser that supports 'foo'")
Since you didn't give any examples, I'll pick on Ajax. It's always best to check for the existence of window.XMLHttpRequest, then act upon it. Of course, this is not performant if you are doing it for every instance of need so you could write a check procedure or a wrapper to accept your list of necessity let your wrapper cache/call the appropriate methods to perform that task.
Without examples of "features" that you are talking about being different from browser to browser though, it's hard to give any concrete advice on direction.
It's the year 2009. Internet Explorer 8 has finally been released, and Firefox is coming up to 3.5. Many of the large browsers are starting to integrate features from CSS3 and HTML 5, or have been doing that for quite a while now. Still, I find myself developing web pages exactly the same way I did back in 2005.
A lot of progress has been made since then, and I think the reason that I haven't started taking advantage of these new possibilities is that it's so hard to know which of the new features that work in all major browsers. Since I'm mostly a backend developer I just don't have the time to keep up these developments anymore. Still, I feel like I'm missing out on a lot of cool stuff that actually would make my life a lot easier.
How can I quickly determine if a feature of CSS3 or HTML5 is supported by all major modern browsers?
Can I Use is a website which tracks browser support for current and upcoming web standards. Check it out if you would like to know whether or not a given feature is widely supported.
Font embedding through CSS, using #font-face. Webkit/Safari has been supporting it since version 3.1, Microsoft since IE4, Mozilla since Firefox 3.5 (browser support overview).
Also, the varied implementations of the Selectors API, which provides a browser-native CSS selector engine for use in DOM scripting.
For other examples, When Can I Use... seems to be a very good reference.
I would say display:table and a range of CSS2.1 selectors are the big wins for designers. display:table solves some unsolvable or difficult layouts like 100% height and inside borders without breaking semantics and using actual tables.
Multiple classes (.c1.c2)
I use min/max-width/height a lot.
Also working :hover and !important are awesome.
I would have liked to add SVG support to that list but naturally Microsoft messed that up.
BTW, big warning to those getting excited about HTML5 features. There is no official date for the adoption of this spec. It's even been implied it could take another 10 years (though I doubt that). The point is anything you do with HTML5 now is subject to breakage when the official spec does arrive and in the meantime you can expect plenty of browser inconsistencies, bugs and API changes (not to mention browsers that don't support the features at all).
Browser support for local storage should enable a bunch of new ideas now that some content can be saved on a user's machine.
Reference docs:
Mozilla Firefox
Internet Explorer