becvert / cordova-plugin-zeroconf

Cordova ZeroConf Plugin
MIT License
81 stars 57 forks source link

How do I use this? #54

Closed borisreitman closed 5 years ago

borisreitman commented 6 years ago

Hi,

I want to run the code inside cordova android app to map 192.168.43.1:8080 to my-android.local, so that if I type http://my-android.local:8080 in Google Chrome chrome on the Android device, it will resolve. Is this possible ? Or, would it work if I remove the port number altogether?

I was trying to use the plugin, and registered things like these:

zeroconf.register('_http._tcp.', 'local', 'kukureku7', 8080, {
    'foo2' : 'bar2'
}, function success(result){
    var action = result.action; // 'registered'
    var service = result.service;
    console.log("in callback: ", action, service);
});

and I got this response,

{domain: "local.", type: "_http._tcp.", name: "kukureku7", port: 8080, hostname: "android-4ce82332a09e2883.local.", …}

What is the weird android domain android-4ce... -- is this the device name of my Google Nexus ? In any case, accessing using kukureku7.local:8080 or just kukureku7.local didn't work. Neither from the phone nor macbook.

I have registered with the watch api, and I got this in the log,

service resolved 
{domain: "local.", type: "_http._tcp.", name: "kukureku7", port: 8080, hostname: "android-4ce82332a09e2883.local.", …}

So, someone is resolving it, but I don't know who.

I installed Zeroconf Browser app, and it shows an "HTTP server", but doesn't provide any detail.

Boris

becvert commented 6 years ago

this is the hostname: your service should be accessible at http://android-4ce82332a09e2883.local:8080 the name you gave kukureku7 serves just as a friendly name/description, it does not serve to resolve the device's address in your network.

also beware, last time I checked android devices will not resolve any .local address. so you might need an IP address anyway.

emcniece commented 6 years ago

I can confirm that resolving .local addresses does not work well on Android. My app waits for services to be resolved then uses the IP addresses to connect.

weahoo commented 6 years ago

Hi, may I know the proper behavior of watching service? As far as what I tried on device, each time I trigger the watching action, I got the resolved service list later on, but what I expected is it worked in background, and once new service published by other network entity, it could be discovered. Is it possible or I did something wrong to watch the services? Best regards Yuexin

becvert commented 6 years ago

as long as you keep a reference to the callback of watching (and you don't call stop) you should receive events of added, resolved and removed services. none of these events are instantaneous, there's some latency. does it answer your question? otherwise can you clarify more.

weahoo commented 6 years ago

May I understand as the following: set the cordova.plugins.zeroconf to the global reference and that will maintain the callback reference and make the watch behavior in javascript level, another approach is go to the native impl and hold the callback in the native part, I don't think the second is your preferred.

becvert commented 6 years ago

Sorry I don't quite understand. On the native side it does not watch in the background and does not hold a list of services for you if that's what you mean. This plugin is merely a wrapper around the underlying libraries: the events are passed to the javascript level in the success callback "on-the-fly", and you do what you want with them.

weahoo commented 6 years ago

I understand what you explained in the native part. May I know what you mean on "you keep a reference to the callback of watching", for instance, the following part is what I am trying to do previously:

  1. Used with angularjs;
  2. catch the device ready event and then watch services, register a new service:
    $scope.$on("application_device_ready", function(e, status) {
    var zeroconf = cordova.plugins.zeroconf;
    zeroconf.watch("_http._tcp.", "local.", function(result) {
          var action = result.action;
          var service = result.service;
          if (action == "added") {
            console.log("service added", service);
          } else if (action == "resolved") {
            $scope.serviceDetected(service);
          } else {
            console.log("service removed", service);
          }
        });
    zeroconf.register(
          "_http._tcp.",
          "local.",
          "Lead",
          8080,
          {
            foo: "bar"
          },
          function success(result) {
            var action = result.action; // 'registered'
            var service = result.service;
          }
        );
  3. observe the behavior with two iOS devices, both have same code installed. Of course, the device can detect its own service registered after the watch process started, I started the 2nd device after several seconds/mins while keep the 1st device alive on screen. I suppose the 1st device can detect the new service published by 2nd device. This is the original reason I asked for your help.
  4. I am trying to do in the next step is set "zeroconf" as $scope.zeroconf to follow your instruction, is my understanding correct? Thanks for your answer again.
becvert commented 6 years ago
  1. I dont know anything of angular
  2. it looks good.
  3. it should work. what is the problem?
  4. you shouldn't need that. cordova.plugins.zeroconf is global already. forget my poor explaning.

do you see the 2nd device on the first one? is too much delay the problem?

weahoo commented 6 years ago

Unfortunately I didn't see the new registered service from 2nd device on 1st device, this is also root reason I asked for the correct behavior of this plugin. The delay might be one possible factor, if so, shell I force the 1st device use watch action in a specific interval, e.g. 1 min/2 mins, will that help? Because I expect once the 2nd device register a new service, the 1st device could discover that asap, the maximum latency had better less than 20 seconds. Thanks for your instruction step by step.

becvert commented 6 years ago

I suppose your devices are on the same Wifi network? not mobile carrier network?

weahoo commented 6 years ago

Yes. same wireless network.

emcniece commented 6 years ago

@weahoo I'm revisiting some old issues. Did you ever discover a solution?

becvert commented 5 years ago

Closing old issue. Feel free to reopen.