RxBonjour | ️ THIS PROJECT IS ARCHIVED | HTTP Client library

by mannodermaus Kotlin Version: 2.0.0-RC1 License: Apache-2.0

X-Ray Key Features Code Snippets Community Discussions(1)Vulnerabilities Install Support

kandi X-RAY | RxBonjour Summary

RxBonjour is a Kotlin library typically used in Utilities, HTTP Client applications. RxBonjour has no bugs, it has no vulnerabilities, it has a Permissive License and it has low support. You can download it from GitHub.

️ THIS PROJECT IS ARCHIVED. No further development is scheduled. A reactive wrapper around network service discovery functionalities for Kotlin and Java.

Support

Quality

Security

License

Reuse

Support

RxBonjour has a low active ecosystem.

It has 153 star(s) with 23 fork(s). There are 8 watchers for this library.

It had no major release in the last 12 months.

There are 8 open issues and 15 have been closed. On average issues are closed in 93 days. There are no pull requests.

It has a neutral sentiment in the developer community.

The latest version of RxBonjour is 2.0.0-RC1

Quality

RxBonjour has no bugs reported.

Security

RxBonjour has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

License

RxBonjour is licensed under the Apache-2.0 License. This license is Permissive.

Permissive licenses have the least restrictions, and you can use them in most projects.

Reuse

RxBonjour releases are available to install and integrate.

Installation instructions, examples and code snippets are available.

Top functions reviewed by kandi - BETA

kandi's functional review helps you automatically verify the functionalities of the libraries and avoid rework.
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of RxBonjour

Get all kandi verified functions for this library.

RxBonjour Key Features

No Key Features are available at this moment for RxBonjour.

RxBonjour Examples and Code Snippets

No Code Snippets are available at this moment for RxBonjour.

Community Discussions

Trending Discussions on RxBonjour

NSdManager ResolveListener Error Code 3: Failure Already active

QUESTION

NSdManager ResolveListener Error Code 3: Failure Already active

Asked 2019-Sep-18 at 19:42

I'm using NsdManager in an Android App to discover NSD services published by another device also developed by me. I only do service discovery on Android App (no service registration needed on this side). There are several instances of the same type of service published at the same time on the network.

I started using the sample code provided by Google (https://developer.android.com/training/connect-devices-wirelessly/nsd) but I had fatal errors due to reusing the same resolver object at the same time for more than one service resolution. Then I found several people suggesting to create a new resolver object each time (like in Listener already in use (Service Discovery)).

I did this and the fatal error was replaced by a Resolve Failure error code 3 that meant that the resolve process was active. Better than before, but only the first service was resolved and the rest was ignored due to this failure.

Then I found a person suggesting to give a special treatment to Error Code 3 by resending the resolve request recursively until it eventually becomes resolved ( NSNetworkManager.ResolveListener messages Android).

I implemented this solution in Kotlin and it kind of works but I'm not really satisfied because:

I believe that I'm creating a lot of additional Resolver objects and I'm not sure if they are later garbage collected or not.
I'm retrying several times in a loop, maybe causing additional and unnecessary burden on the device and the network. Not sure if I should add a short sleep before invoking service resolution again.
If there is some network problem, the program may try thousand of times to resolve the same service instead of just abandoning the resolution and waiting for the service to be discovered again.

The people of RxBonjour2 have come with a more complex and robust solution but it's too complex for me to follow it: https://github.com/mannodermaus/RxBonjour/blob/2.x/rxbonjour-drivers/rxbonjour-driver-nsdmanager/src/main/kotlin/de/mannodermaus/rxbonjour/drivers/nsdmanager/NsdManagerDiscoveryEngine.kt

I feel frustrated that Google's official examples do not handle these problems correctly. The nsd_chat sample uses a single resolver object and fails when more than one service with the same type is published at the same type on the network.

Can you suggest a better solution? Or any improvements to my code below?

...

ANSWER

Answered 2019-Sep-18 at 19:42

I solved the problem by:

Creating a thread-safe queue to store the services pending to be resolved
Using a thread-safe list to store the list of already resolved services
Using an Atomic Boolean flag to see when the ResolveListener is busy

To make the solution more generic, I built an NdsHelper abstract class. It has 2 functions that must be overridden: onNsdServiceResolved(NsdServiceInfo) and onNsdServiceLost(NsdServiceInfo).

I'm using Timber for logging messages but you can replace them by the standard Log function.

This is the NsdHelper class (Kotlin code):

Source https://stackoverflow.com/questions/57940021

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install RxBonjour

RxBonjour 2 is available on jcenter() and consists of three distinct components, all of which are detailed below. For the (less flexible & Android-only) RxJava 1 version, have a look at the 1.x branch.

Support

For any new features, suggestions and bugs create an issue on GitHub. If you have any questions check and ask questions on community page Stack Overflow .

Find more information at: