![]() When you create a network socket with port 0, the system actually allocates you the next available port from the high range, which is exactly what we want. The way I found out here feels a bit like a hack. This was incompatible with NanoHttpd approach that expects you to give it a static port number. There’s two things that I came across on Android worth noting.įirst, it’s good practice to use a dynamic port number and not hardcode it. Mostly, building this was quite uneventful and everything worked like it should have. It doesn’t have all the conveniences of stopping/starting at backgrounding, and it doesn’t know anything about Bonjour, so I needed to implement all of those myself. It’s a simple thing that I could just drop in to my app. On Android, I use NanoHttpd simply because it’s the first popular one that I came across that seemed to do what I needed. CocoaHTTPServer used to be a popular choice in earlier days. GCDWebServer handles all the details like stopping both the server and service advertising when the app goes to background, and restarting them once you come to foreground again. It implements the Bonjour registration internally, so you don’t need to do any of that: you just give it the desired service name and type, and off you go. I actually submitted a patch to it last year for custom Bonjour service names. On iOS, I use GCDWebServer that I can only say good words about. So we need a small webserver on both sides, since I’m building a HTTP-based service. It doesn’t actually implement the service, which you must do on your own. It says, “here’s a service with this name running on this port”. Service discovery is only about what it says, discovery. When a service is found, you don’t talk to it directly: you must first invoke another step, “resolve”, to resolve the actual service address. On the consumer/client side, you ask the manager/browser to listen to services of some type ( _jktest._tcp in my example), and you implement the delegate/callback methods that are called when new services are found. On the provider/server side, you just create your service and register it. On iOS, the relevant classes are NSNetService and NSNetServiceBrowser, while their Android equivalents are NsdServiceInfo and NsdManager. If you’ve built it on one, you’ll feel right at home on the other. The programming model is similar on both platforms. The contains the OSX tool that discovers the services and talks to them, and service implementations on iOS and Android.Ī few notes about the implementation. And both of them are implementations of “zero-configuration networking” using “DNS-SD (Service Discovery)” and “Multicast DNS” and… enough alphabet soup yet? Let’s just use “Bonjour” in this post.) The Android implementation officially calls itself Network Service Discovery. (I know that technically it’s “Bonjour” only on Apple platforms. Apps on both platforms should advertise themselves as the same Bonjour service on the network, and respond with the same kind of information. I wanted to have a demo of a crossplatform service that implements the same protocol on both iOS and Android. Implementing Bonjour across iOS and Android
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |