Service binding and scheduling from 'working' thread

[almozavr]

Service binding and scheduling from 'working' thread

[roman-mazur]

Both schedule and onServiceConnected bodies are supposed to be synchronized using lock... Hence, it's not really obvious for me why this does not work. I will try to reproduce.

[almozavr]

Yes, but it doesn't save you, because client calls bindOneshot (which starts onServiceConnected in main thread) and only then calls schedule.
Possible api-friendly solution could be bindOneshot changes:

    @Override
    public <T> ObservableFuture<T> bindOneshot(String queueName, Callable<T> task) {      
      synchronized (lock) {
        oneshot = true;
      }
      ObservableFuture<T> future = schedule(queueName, task);
      GoroService.bind(context, BoundGoroImpl.this);
      return future;     
    }

[almozavr]

I've tried ↑ but saw it breaks the flaw of wrapping BoundGoro with decorators like RxGoro. So it's not the way. Another solution comes to my mind is to delegate unbinding from onServiceConnected to some another place or, check if there is no pending jobs scheduled and make double check for unbind from schedule call.

[roman-mazur]

Ah, now I see the problem... onServiceConnected is invoked before schedule, and in case of bindOneshot we unbind from the service as soon as onServiceConnected completes. Hence, postponed list is never processed.

I'm thinking about making a separate Goro implementation that will bind to the service if schedule is invoked and unbind as soon as current work is delegated.
So, in your case, bindOneShot will not be called at all (and we'll deprecate this method). Binding will be performed on every schedule if it's required.
And there will be 2 implementations for Goro that communicates with a service:

• current BoundGoro with explicit control allowing to adjust bind()/unbind with another component lifecycle
• Goro.oneshot() without no extra methods beyond Goro interface that will do binding on demand and unbind asap.

Opinions?

[almozavr]

Sounds good, +1.

On Mon, Jul 13, 2015, 4:20 PM Roman Mazur [email protected] wrote:

Ah, now I see the problem... onServiceConnected is invoked before schedule,
and in case of bindOneshot we unbind from the service as soon as
onServiceConnected completes. Hence, postponed list is never processed.

I'm thinking about making a separate Goro implementation that will bind
to the service if schedule is invoked and unbind as soon as current work
is delegated.
So, in your case, bindOneShot will not be called at all (and we'll
deprecate this method). Binding will be performed on every schedule if
it's required.
And there will be 2 implementations for Goro that communicates with a
service:

• current BoundGoro with explicit control allowing to adjust bind()/
  unbind with another component lifecycle
• Goro.oneshot() without no extra methods beyond Goro interface that
  will do binding on demand and unbind asap.

Opinions?

—
Reply to this email directly or view it on GitHub
#4 (comment).

[roman-mazur]

Although we have a few thing to finish before 3.0 release, version 3.0.0-RC1 will be in Maven Central soon (it's already released, waiting for the sync). Please let me know how it works for you, if you get some time.

[almozavr]

@roman-mazur LGTM, thanks!