Is there a geolocation API part of google closure (ultimately for use in ClojureScript) ?
I've been looking for it, but all I can find is something that looks like an old shim.
If there is none, is it because Google doesn't use that feature of web browsers (they find our location using other means), or because the browser API doesn't require that (already unified), and what would be the best alternative in ClojureScript ?
Nothing is in Closure for this right now. Generally, Closure only wraps these native APIs when there are cross-browser compatibility issues, is potential for a polyfill, or potential for improvement. I'm not personally too familiar with these APIs, but my guess is it's not in Closure because it's pretty standardized across the browsers that implement it.
The "shim" link you provided is what's called an externs file. It's used in conjunction with the Closure Compiler to avoid renaming certain properties. See this resource for more info.
Related
I have started a crash course of IndexDB API. I have heard from the author that the API is a little bit confusing. Primarily, as we have been working with the promise pattern as this API doesn’t use this pattern. Secondary, there are different wrappers, one of them seems is from Github author’s personal library so I suppose he have created it.
However looking for a different flavor, I found this one: http://dexie.org/. Also supports the Promise pattern. See http://dexie.org/docs/Promise/Promise, http://dexie.org/docs/API-Reference#query-items . It seems “promising”.
Also I found that the IndexDB 2.0 API was created post the video time. It is already being supported since beginning of 2017. From a Mozilla developer, I found since Firefox 51 (Jan 2017) it is already there. And he wrote what’s the differences among 1 and 2 versions https://hacks.mozilla.org/2016/10/whats-new-in-indexeddb-2-0/
So my question is if at this point is better to use the wrapper libraries or to use the native IndexDB API in terms of cross-browsing and support and better practices?
It all depends on what you want to do with indexeddb -
If you are learning indexeddb for your interest or for knowledge then you should go for plain indexeddb. Learn and research as much you can, because it has too many apis and you will have to write code for every type of situation.
You want to use indexeddb in your project and dont have much time to explore indexeddb. You only want to do some database operations and release your project. In this case - you should go for indexedd library. This way you dont need to worry about indexeddb code . You will just write simple code using the library.
For instance : check out this article - https://dzone.com/articles/crud-operation-in-indexeddb-using-jsstore. How a library makes indexeddb so easy.
Hope this will help you.
I'm building a Google Cast integration for a music app in Chrome.
What is the difference between cast.framework.RemotePlayer and chrome.cast.media.Media?
The documentation uses cast.framework.RemotePlayer and cast.framework.RemotePlayerController, but they don't have functions for managing the queue, while chrome.cast.media.Media does.
Which one should I use?
I discovered the cast.framework namespace is used for a high-level API built on top of the chrome.cast namespace, which is a low-level API.
It doesn't matter whether you use cast.framework.RemotePlayer or chrome.cast.media.Media, both of them will work, but Media has more functions and callbacks.
In my experience, Media is easier to work with than RemotePlayer, so I don't really get why they created the RemotePlayer class.
Is possible to use QT QWebChannel without websockets, but using WebKit ICP?
I only found examples using webSockets.
Unfortunately, the documentation states that:
It works on all browsers that support Qt WebSockets, [...]. Additionally, a custom transport mechanism can also be implemented using Qt WebSockets to support Qt WebChannel-based communication.
It seems that you cannot use it without WebSockets, and it would explain why all the examples you find actually use them.
Anyway, it also states that:
The transport mechanism is supported out of the box by the two popular web engines, Qt WebKit 2 and Qt WebEngine (experimental).
Despite the fact that it is experimental, it looks like an alternative to the WebSockets.
Actually, while digging into the linked documentation, I've found that page where it is said about WebKit that it implements internally the required interface and it can be used in place of the WebSockets, but no example is provided.
You can find spare information all throughout the linked page, as an example it is said that:
For HTML clients run inside Qt WebKit, you can load the file via qrc:///qtwebchannel/qwebchannel.js. For external clients you will need to copy the file to your webserver.
Then, it follows a brief description of the steps to be done to achieve the same on those clients, as far as I understand by using no WebSockets in this case.
That said, It seems to me that the solution based on the WebSockets is the suggested one, so probably you should reconsider you architecture and use them. Otherwise, be ready to deal with experimental and poor documented features.
Per the documentation here:
Can I replace:
map.data.loadGeoJson('https://storage.googleapis.com/maps-devrel/google.json');
with a local path such as:
C:\path\file.json ?
or must it be hosted on a server?
Thanks
In general, this used to be not allowed by design. It's a violation of the sandbox.
From Wikipedia -> Javascript -> Security:
JavaScript and the DOM provide the potential for malicious authors to deliver scripts to run on a client computer via the web. Browser authors contain this risk using two restrictions. First, scripts run in a sandbox in which they can only perform web-relatedactions, not general-purpose programming tasks like creating files.
However, it's now possible in current browsers using the FILE API specification.
This should in theory allow you to read it using the FileReader interface, although you might need to use something like JSON.parse() (or $.parseJSON if you're using JQuery) to then interpret it in the way you need. Lots more detail and examples of how to do this are here:
http://www.html5rocks.com/en/tutorials/file/dndfiles/
Is it possible to convert a standard PHP based widget integrated with google maps API to a flash based widget? If yes, what are the ways?
I expect it will generally be a manual process, because the code styles are so different, code-to-code conversion would be likely to be difficult/fragile/error-prone. The only automatic way that I could conceive of is a html-to-flash-ui conversion, which would get you a static look or prototype to start with, but wouldn't help you in the creation of the active/reactive/dynamic elements of the new flash widget.
A quick google search brings up a few paid references to html to flash conversion, as well as a few pages mentioning some libraries that might be worth pursuing, if just as a shortcut to creating a prototype that you would have to refine:
http://drawlogic.com/2008/01/11/as3-flash-to-html-conversion-library-htmlwrapper/
and here:
http://osflash.org/flashml
Since there is one free library, there may quite likely be others as well.