gistfile1.txt

You will probably want something like this in a run block for your app:

window.NativeBridge.closestLocation = function (location) {
  $rootScope.$broadcast('locationChange', location);
};

And then a service to do all the stuff:

.service('ClosestLocation', function ($rootScope) {
  var that = this;
  
  $rootScope.$on('locationChange', function (event, location) {
    onChange(location);
  });
  
  function onChange (newLocation) {
    // update location record
    that.location = newLocation === '(null)' ?
                      null :
                      newLocation;
    
    // send any orders that were waiting in the queue
    flushQueue();
  }
  
  function flushQueue () {
    if (that.location === null) return;
    
    // send the orders that have been waiting since you have a nearest location now
  }
});

Finally, to get the device token is an asynch operation (but it should be snappy), we use the following code in our app:

NativeBridge.call("getDeviceInfo", [1], function(data) {
	if (data === '(null)' || typeof data === 'undefined') {
		$log.error('Failed to get device info, retrying in 500 ms');
		$timeout(function (){
			that.getInfo().then(defer.resolve);
		}, 500);
	} else {
		try {
			var parsedData = JSON.parse(data);

			that.info = parsedData;
			defer.resolve(parsedData);
		} catch(e) {
			alert('deviceError::' + e.message)
		}            
	}
});

It's up to you if you want to put that in its own service and get it in the resolve for a route that needs it, or if it's only used once or something then just get it at the time it's needed and use it in the callback.

===============================================================

How to log:

NativeBridge.call('log', JSON.stringify(logObject));

Po thinks something like this will be appropriate for logging the login of a user:
{
	action: 'userLogin',
	target: 'coffee app',
	customFields: {
		imageUrl: 'http://location-of-their-profile-image',
		name: 'whatever their name is',
		deviceToken: deviceToken
	}
}

The custom fields in that object are arbitrary and you and I can jointly agree on what they'll be named. Elasticsearch will happily accept whatever customFields you specify.