deviceready does not fire in latest update about corber HOT 18 CLOSED

I highly recommend adding device ready to the docs for this. It's the #1 thing people do with this. I would also recommend adding the list of possible cordova events on the bottom of that md page.

from corber.

reproduced on my side. assigning @anulman

from corber.

Broken in isleofcode/ember-cordova@38ed4fa

Working on a patch now; will post thoughts re: next steps once pushed

from corber.

Right now, there are 3 ways to subscribe to ember-cordova events: object.on(...), subscribe(), and onCordova: {...} registrations.

Implementations look something like:

import Ember from 'ember';
import EmberCordovaEventsMixin from 'ember-cordova/mixins/events';

import subscribe from 'ember-cordova/utils/subscribe';

const {
  Route,
  inject,
  on
} = Ember;

export default Route.extend(
  EmberCordovaEventsMixin, {

  cordova: inject.service('cordova'),

  beforeModel() {
    // fires
    this.get('cordova').on('deviceready', function() {
      console.log('object.on');
    });
  },

  // does not fire (injected service availability)
  didFire: on('cordova.deviceready', function() {
    console.log('Ember.on');
  }),

  // fires
  didSubscribe: subscribe('cordova.deviceready', function() {
    console.log('subscribe');
  }),

  onCordova: {
    // fires
    deviceready: function() {
      console.log('onCordova');
    }
  }
});

I think we should explicitly favour the subscribe(...) form, as it better fits with the trend toward generator functions.

@optikalefx how are you consuming deviceready?

If we decide to coalesce toward subscribe, I'll add a deprecation notice for the onCordova form to the PR, or quickly open a new one if already merged.

from corber.

In the application route

onCordova: {
    deviceready: 'deviceready'
},
deviceready() { ... }

I'm not sure what feels right on this one. I feel like ember-evented exists, so I wonder why you need to introduce your own pub/sub. I think something as necessary as deviceready shouldn't require this additional import to work.

But maybe i'm not aware of all the events needing to take place. I would think that you would just do on('event') just like any other event. Without an extra paradigm needed.

from corber.

On event has never worked because that's not how ember evented works

from corber.

? According to http://emberjs.com/api/classes/Ember.Evented.html you can trigger any named event, and then on to subscribe to it. If cordova service extended evented couldn't you have this.get('cordova').on('deviceready'); internally it would have done this.trigger('deviceready');

from corber.

@optikalefx It seems you're starting to see the difference in your comment but haven't quite grasped why subscribe exists.

Pulling from the example above:

import Ember from 'ember';
import subscribe from 'ember-cordova/utils/subscribe';

const {
  Route,
  inject,
  on
} = Ember;

export default Route.extend({
  cordova: inject.service('cordova'),

  // does not fire (injected service availability)
  didFire: on('cordova.deviceready', function() {
    console.log('Ember.on');
  }),

  // fires
  didSubscribe: subscribe('cordova.deviceready', function() {
    console.log('subscribe');
  })
});

The Cordova service does implement Evented. The thing to note here is that the reason on('cordova.deviceReady' does not work is because this is not within the same object, and on will not follow paths longer than one segment. I wrote subscribe to allow for following paths of two segments with guaranteed cleanup so that we can avoid writing the following code.

import Ember from 'ember';

const {
  Route,
  inject
} = Ember;

export default Route.extend({
  cordova: inject.service('cordova'),

  init() {
    this._super();
    this.get('cordova').on('deviceReady', this, this._readyHandler);
  },

  _readyHandler() { console.log('on fired'); },

  willDestroy() {
    this._super();
    this.get('cordova').off('deviceReady', this, this._readyHandler);
  }
});

from corber.

Thanks for posting the details @runspired. @optikalefx this is what I was referencing w/ // does not fire (injected service availability) in the original snippet.

subscribe is my preferred form as it better matches Evented's on, and will offer an easier migration if / when the generic Ember.on supports injected deps.

Seems that's where the conversation's moved, so I'm going to add a deprecation notice to the onCordova form (which predates availability of the subscribe util).

from corber.

Yes deprecation notice works for me. I'll include it in the next release
which also includes the live reload changes.

On Sunday, 31 July 2016, Aidan Nulman [email protected] wrote:

Thanks for posting the details @runspired https://github.com/runspired.
@optikalefx https://github.com/optikalefx this is what I was
referencing w/ // does not fire (injected service availability) in the
original snippet.

subscribe is my preferred form as it better matches Evented's on, and
will offer an easier migration if / when the generic Ember.on supports
injected deps.

Seems that's where the conversation's moved, so I'm going to add a
deprecation notice to the onCordova form (which predates availability of
the subscribe util).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/isleofcode/ember-cordova/issues/83#issuecomment-236441319,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPEciHiWcJn1NQgB3w63fVq351-woQyks5qbNM1gaJpZM4JUb9z
.

@alexblom http://www.twitter.com/alexblom
647 704 5272
http://www.alexblom.com

from corber.

Deprecation notice added & docs updated in d20bb28

For clarity, both the onCordova and subscribe forms were borked by the fixed commit

from corber.

Just an update, pr #90 by anulman fixes this. We're just waiting for a documentation fix and it will be merged/released. Thanks.

from corber.

Hi, any idea why the events might not be firing at all? I'm using the subscribe function and tried deviceready and a few other events and none are firing.

didSubscribe: subscribe('cordova.deviceready', function() { console.log('ready'); })

I'm on
Ember CLI 2.7.0
Cordova 6.3.0

from corber.

Thanks for the report @and2, will definitely look into this. Two dumb questions in the interim:

• what version of ember-cordova?
• can you provide the context around which didSubscribe is invoked? e.g. is it invoked at the top-level of the exported object, in a lifecycle hook, etc.

from corber.

Hey, @anulman, tried it at the top-level of a route as per existing docs. With ember-cordova 0.2.0.

import Ember from 'ember';
import subscribe from 'ember-cordova/utils/subscribe';

const { Route } = Ember;

export default Route.extend({

  cordova: Ember.inject.service(),

  didSubscribe: subscribe('cordova.deviceready', function() {
    console.log('ready');
  })

});

from corber.

Ok, I believe the issue is actually with live reaload. Running the app without it from index.html triggers all the events as expected. Once <allow-navigation href="*" /> is added in config.xml and live reload with ember cdv:serve switches to the local IP, the events are lost.

from corber.

Ah! That could be it. Your snippet looks great :)

@and2 want to create an issue for this, vs. reopen this one?

from corber.

Hey @anulman, I'll open a new one, think the problem is with how cordova.js is built. With live reload on I get an empty file with:

No-op script for when serving to both browser and Cordova device.

from corber.