igorpreston / ember-cli-geo Goto Github PK

In my application, I was able to isolate this addon as the culprit by uninstalling in my fastboot app and having the app start successfully. Could we update this addon to be fastboot compatible?

The ember-cli-babel dependency should be updated to the latest version to allow consuming apps to drop ember-cli-shims as a dependency of ember 2.16+ apps.
https://www.emberjs.com/blog/2017/11/20/ember-2-17-released.html#toc_changes-in-ember-cli-2-17

I saw there's a pr #19 can you merge it please.

Currently, there's no way to stop watching a users location. This is done by calling navigator.geolocation.clearWatch(id) (https://developer.mozilla.org/en-US/docs/Web/API/Geolocation/clearWatch). However, the watchPosition id is not currently being stored, so there is no id to use for clearing it.

The watchPosition id is returned from the navigator.geolocation.watchPosition method (https://developer.mozilla.org/en-US/docs/Web/API/Geolocation/watchPosition), so the return value could be stored on the service (

It would then be convenient to round out the API with a public method to stopping tracking the location. The method would just need to call clearWatch with the stored watchPosition id.

Version

4.0.0

Why

"ember-cli-babel": "^5.1.6" depends on [email protected]

How to reproduce

git clone https://github.com/bartocc/ember-2.18.2-barebone.git
cd ember-2.18.2-barebone
yarn install
ember install [email protected]

Actual result

You should see the following deprecation message

DEPRECATION: An addon is trying to access project.nodeModulesPath. This is not a reliable way to discover npm modules. Instead, consider doing: require("resolve").sync(something, { basedir: project.root }). Accessed from:   new NPMDependencyVersionChecker (/Users/julien/Projects/ember-2.18.2-barebone/node_modules/ember-cli-geo/node_modules/ember-cli-version-checker/src/npm-dependency-version-checker.js:11:33)

Expected result

No deprecation message

@igorpreston or anyone else having any issues?

All browsers, development and production.

PositionError 
{ 
code: 2, 
message: "Network location provider at 'https://www.googleapis.com/' : Returned error code 403."
}

Does this service expose any way to see whether the user has blocked the geo location? As far as I can tell, the promise just never resolves. I'd like to be able to provide a UX where we can display a message to our users explaining that the feature they are trying to use will not work if they block geolocation. Thanks.

I can't get the current location.I write the following codes.

this.get('geolocation').getLocation().then(() => {
      let location = this.get('geolocation').get('currentLocation')
      console.log(location)
    })

But I got the following error.

map User denied Geolocation
Please help me.

This add-on appears to be abandoned since the last commit was 12 months ago.
@igorpreston Are you planning to update the add-on and maintain it? If not, I will be happy to maintain the following !

Currently the Package Ember-CLI-geo is using Ember-CLI-Babel V 5.x and there has been depreciation warning since long to update the Babel Package , Update the dependancies to let the Add-on Roll

Currently, in order to use geolocation service you should firstly inject it to the route where you want to use it, like so:

geolocation: Ember.inject.service()

And then look up the instance through geolocation property:

this.get('geolocation').getLocation()...

I deicided to go that way at first because there was an Ember.Service object available in official API that is meant to be used for easy dependency injection and service instantiation. But, when using it this way, you are obliged to inject the service directly through the property to each route you want it to use that quickly becomes annoying.

Proposal: We can change it by creating initializer that will register the factory and inject geolocation service into all routes, so you won't need to inject it yourself through the property and could use it directly like the next:

this.geolocation.getLocation()...

Of course this could break existing API of using geolocation service. But, we can just deprecate the old way of looking up the instance and recommend using new way of looking up a service, until some new major version release where it will be completely removed.

What do you think about it?