Re: [paho-dev] Why connect() method has been designed to work only synch

["Mike Milinkovich" <mike.milinkovich@xxxxxxxxxxx>]

Mehdi,

In other words, code contributions would be gratefully received :)


> -----Original Message-----
> From: paho-dev-bounces@xxxxxxxxxxx [mailto:paho-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Nicholas O'Leary
> Sent: April-10-12 3:29 PM
> To: General development discussions for paho project
> Subject: Re: [paho-dev] Why connect() method has been designed to work
> only synchronously?
> 
> Hi Mehdi,
> 
> I can't remember all the reasons for the design decisions that were made
> with the client; the foundations of the API were done about 3 years ago!
But
> I can say that Android did not factor in the discussions at that point in
time.
> That said, one of the goals was a critical analysis of the many callbacks
> provided by the IA92 client (and the other v3 Java Client that ships with
Lotus
> Expeditor) to see which were actually useful and which just complicated
> implementations.
> The result of which is the API in the Paho client.
> 
> A common pattern with this client is to create a connection thread in the
> application that is responsible for maintaining the connection in the
> background to the application; when the connectionLost callback is called,
> the thread is poked to get the client reconnected (if appropriate). This
moves
> the blocking call off the main application thread, which could be the UI
> thread.
> 
> Fast-forward to today and as Andy mentioned in his reply to your other
> thread, we have much more experience using the client on Android.
> Hopefully we can find a way to incorporate that experience into the Paho
> code base.
> 
> Regards,
> Nick
> 
> 
> On 10 April 2012 19:20, Dr. Mehdi Hasan Khan <mhasan@mpower-
> health.com> wrote:
> > Hello everyone,
> >
> > All the network operations like sending/receiving messages or ping of
> > Eclipse Paho MQTT client library are designed to work asynchronously.
> > One can even use MqttDeliveryToken.waitForCompletion() method if he
> > wants to work synchronously, a huge plus. But unfortunately the
> > connect() method works only synchronously, it waits and waits until
> > timeout occurs. That causes additional trouble if you want to use this
> > library on Android, you have to maintain additional thread to connect,
> > otherwise on UI thread there is a chance to face ANR (application not
> responding) error.
> >
> > Is there any specific reason behind this design? Or, may I request
> > additional callback methods to handle login result in future releases,
> > so that I can work in asynchronous manner?
> >
> > Regards,
> > Mehdi
> >
> >
> >
> > _______________________________________________
> > paho-dev mailing list
> > paho-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/paho-dev
> >
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/paho-dev