we are in process of developing google chrome extension, in which we need to store all the video information from a particular website. so we are considering the option of webdb.
and now we are getting confused between to use webdb or indexdb..
As of now i think that, indexdb is still experimental, is that correct?
and, if we use indexdb, the db even will not show up in dev. tools db section, where as webdb will show up, so that we can do query stuff in there..
please shed some light and put us in correct direction
Use IndexedDB. WebSQL has been officially deprecated and will be removed from Chrome in the future. The dev channel of Chrome has experimental dev tools support for viewing IndexedDB databases.
It's been a few months since I checked, but based on the work I did then, I would suggest WebSQL. The primary reason is that support is complete (it's basically SQLite). Here's what I wrote at the time:
If you're doing web app development and need to utilize a local
(client-side) database, you should be using either localStorage
(assuming you can live with the limitations of size and limited
queries/indexing) or WebSQL. IndexedDB is not a contender yet, as
essential functionality such as deleteDatabase is missing from for
instance Chrome. WebSQL doesn't give you schemaless functionality
without any glue, but on the other hand it works great (has a lot of
uses outside of browsers as well), has full features functionality and
probably limited or no practical size limitations.
In addition, the debug console (at that time) had WebSQL support, and no IndexedDB support. Things may have changed and YMMV, but at least you should be aware.
Related
I have been debating whether using polymer in my chrome extension is worth while.
Here is the scoop. (or should I say scope, haha bad programmer jokes)
My extension relies heavily on web components which have been available natively in chrome since the release of chrome 36
Now, if the browser statistics listed here are correct, then logically, there isn't much of a reason to polyfill web components since only a small percentage of chrome users use versions earlier than 36 (and lets face it, chances are they aren't using extensions).
What do you guys think? Are there any other reasons using polymer in this case which I fail to see?
I want to detect whether a browser supports the Ember.js library. If not, I will show users a message to let them download the latest version of their browser. How can I do that?
There is an answer to a similar question contributed by an Ember.js core team member.
In it, he states that the majority of the browsers on browserstack.com are supported, meaning they do thorough testing.
Rather than show the message based on a functionality test of the user's browser each time they load your application, I suggest you instead build a list of known incompatible browsers (anything older than what is on BrowserStack would be a good start) and expand it based on monitoring your access logs or reported issues from the likely minority users on unsupported browsers.
That "blacklist" approach would serve most efficient, as Ember.Js and other libraries like jQuery are usually designed to continually support all new browsers.
I've found this nice article about the "injected Way", but the author never finished it :
http://hightechstartups.blogspot.ch/2012/05/different-way-of-developing-browser.html
I would like a bare bone cross browser extension, without any 3rd party extensions or framework (to be as light as possible and not dependant on a 3rd party) that would load Jquery and a JS from a distant server and the ability to load it before or after the page is fully loaded.
I've read a lot of topics about the subject, but since IE10, Chrome 26 and FF20 are out with their new cross-link limitations, i was wondering if somebody had ressources, source code or tutorial about the following requirements :
I need :
Cross browser extension supporting (IE 8+ or 9+ worse case, Chrome
26+, FF20+, Safari)
Ability to inject a single JS hosted on another server. Inserts a script tag that references a javascript file in the head of the HTML
page and then be executed
Not be dependant on a third party extension (greasmonkey) or framework (Kango, Crossrider)
Ability to load before or after the page is fully loaded
This method allows me to customise the browser extension depending on the user's location and it also avoid having updates as the JS is updated on each page refresh.
I'm aware of the downsides, but i would like to achieve this.
I'm aware of cross browser framework like Kango or crossrider, but both don't fit me needs.
The closest example i could find is this How can I run a <script> tag that I just inserted dynamically from a BHO
but it only covers IE and as i got very little Csharp experience, i would like to see a full example to understand it properly and learn from example.
I would LOVE to have a few examples, even if it's not cross-browser (IE being the worst part for me).
Thanks a lot for your support !
Update1:
About Kango and Crossrider, Kango is 2000$ if you want to use IE and for Crossrider you're required to be distributed and monetized by them.
I've managed to code for IE and Chrome, but i was looking for an "elegant" way and figured it was the best place to ask given the level of knowledge of people on this site.
For the installer i currently use NSIS, but i'll test Wix too.
Finally i guess the only way for me would be to learn C++ and .net to get it to work with IE, but if anyone could provide more source code it would be great to test speed and compatibility and discuss here what's the best solution.
Why do Kango or Crossrider not fit your needs? Both frameworks allow you to manipulate the page's DOM (which is what you want):
Kango: Adding content script
Crossrider: documentation, example code
If you want to code your own solution, take a look at the relevant documentation:
Content scripts (Chrome)
The Page mod Jetpack API (Firefox)
Injected scrips (Safari)
Injected scripts (Opera)
Internet Explorer does not natively support extensions. It took me about 80 hours to create a stable and reliable IE extension which supports cross-site AJAX, a (preference) storage method and injection of scripts as early as possible in any frames based on its URL. I developed and tested the extension with Visual Express 2010 on Windows XP and Windows 7, for IE 8-10 (the extension might work on IE6/7, but I decided to not support these ancient and rarely used browsers).
First, I wrote an extension in C# based on LiveReloadIEExtension (a sample IE extension, which in turn is based on this Stack Overflow answer - see also this blog post). It was functional, but it required .NET 4, lacked support of frames, and it's relatively slow.
So, I decided to write an IE extension from scratch in C++. A good starting point is available at http://www.wischik.com/lu/programmer/bho.html: Sample code for C++ BHO, which changes the document's background based on key/mouse events. I've also learned a lot by looking at other code samples on CodeProject, topics on the MSDN forums, questions and answers on Stack Overflow, lots of other blogs, and the MSDN documentation:
DWebBrowserEvents2 interface lists several events which you use to find an appropriate injection point.
Scripting Object Interfaces (MSHTML) lists even more interfaces. You'll be mainly interested in the iHTMLDocument, iHTMLDocument2, ... interfaces.
After creating the IE extension, you want to deploy it of course. I used Wix toolset to create a MSI.
The html + css standards difficulties of supporting IE as a browser translate into using it as part of the WebView control where there are further limitations on functionality.
Other difficulties include:
It renders on top of the XAML
- Using the recommended approach of WebViewBrush isn't a valid scenario if your pages have dynamic content on them.
It doesn't support HTML5
You can't access the content
You can't access the content
- Trying to debug issues with it is nigh on impossible.
Are there any alternative embeddable browsers available or in the works?
To answer your question, I think Jim is correct that there are no other embeddable browsers available, and it's not something I'd expect to see.
I would also recommend that you review the Windows Store Certification requirements, as many may be applicable in this case, including:
2.4 "The primary experiences your app provides must take place within the app" (as opposed to coming from the web)
3.6 "Your app must fully support touch input, and fully support keyboard and mouse input" which covers requirements for touch, including the need for your app's touch support to be consistent with the Windows 8 touch language.
While it's obviously appealing to re-use content across platforms, it's also important to keep in mind that this may lead to degraded experiences for end-users. If those experiences are too far afield of the established behaviors for Windows Store apps, they could also result in your app failing store certification.
For more info on Windows Store app development, register for Generation App.
I'm someone who wants to be up on the latest web technologies but also appreciate that alot people still use IE6/7/8. Is it a waste of code/time if half of it wont be displayed on most browsers? Is it just a case of using different style sheets, or just use one style sheet and if a browser doesnt support text-shadow, then screw it, they can see it without the nice effects. What are peoples thoughts?
It depends on your userbase. I am an intranet developer and my company still uses IE6(!!!) so we have no choice but to support IE6. I also develop some public facing websites and we use Analytical tools to see the which Browser is being used more and ignore ones which are less used. in this case IE6 was the least used Browser.
I won't go for HTML5 and CSS3 till Internet Explorer 9 or Firefox 4 (absolute release, not alpha or beta) is released, because these two browsers make up the most of web traffic (afaik, correct me if I'm wrong) and using html5 or css3 will be a big loss.
And yeah, it depends on your userbase too.
I'm developing a small-business oriented online app and decided to support only IE8, FF and Chrome. I also went for one stylesheet that degrades nicely (text-shadow, rounded corners). IE8 users will see square corners but it doesn't make the site unusable in any way.
I just think that the cost of making everything look perfect in all browsers (and maintaining it!) is much higher than the benefits.
The above also applies to HTML5 IMHO - unless you know that vast majority of your users will have an HTML5-compatible browser there's no need to invest in it right now. Unless the whole point of your site is to use one of the newest features.
Just tell yourself what problem of your users you are actually solving and solve that one.