Tasker - Plugin communication: proposal to improve speed

[joaomgcd]

Pent,

Sometimes, when the Android device is under heavy load, plugin actions and conditions will take a long time to execute due to the low priority Android gives broadcasts.

In some cases, for example when the device connects to wifi, where loads of stuff will run at the same time on some phones, these delays can be very significant.

What I'd like to propose is to create an alternative way plugins and Tasker can communicate, namely via Services directly.

Before I start going into too much detail, is this something you, Pent, would consider? This would make plugins very much first class citizens in the Tasker eco-system :)

Thanks in advance

João

[Pent]

Hi Joao,

sorry but my health won't allow so much at the moment and when it does I have
a lot of catching up to do with core Tasker :-(

Pent

[João Dias]

I understand. No worries. Thanks for responding!

--
You received this message because you are subscribed to the Google Groups "Tasker - Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taskerdev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[joaomgcd]

Any chance of this ever happening now that Tasker is "more on track"? :) People really complain a lot about Tasker being slow to respond when being called by my plugins, specially if the device is Doze mode or something similar.

Thanks again for everything!

[Pent]

I can't see it in the medium term, sorry :-(

Apart from switching to basic MD theme
and implementing some of the new stuff that came with
Nougat, I need to switch to Android studio and reimplement some
important stuff with APIs that were reimplemented ages ago and might
be removed soon, like camera interface.

A few years ago it would have all been a week's work but now it's
several months.

But for doze related delays, you can point users at this:

http://tasker.dinglisch.net/userguide/en/androidpowermanagement.html

Doing stuff with services will make no difference if either of the apps
is dozed.

Pent

[João Dias]

Thanks, I understand. :)

I always thought that calling services directly would bypass doze though! Do you know what happens if an app calls another one that's "dozed" via a service? Does it simply not respond?

Thanks again!

--

You received this message because you are subscribed to the Google Groups "Tasker - Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to taskerdev+unsubscribe@googlegroups.com.

[Crafty Apps Support]

I always thought that calling services directly would bypass doze though!

I don't see why a BroadcastReceiver targeted by an intent would not undoze an
app but calling a service would. But who knows ? I havn't tested it of course.

Pent

To unsubscribe from this group and stop receiving emails from it, send an email to taskerdev+...@googlegroups.com.

[João Dias]

Broadcast receivers are notoriously slow compared to service invocations. In my understanding the broadcast gets to Tasker, it just takes a long time to do so :) I'm under the impression that services are given a much higher priority on Android but some real tests would have to be made to figure it out for real.

[Pent]

It would be an awful lot of work developing, testing and documenting this.
A lot of the protocol would change, but would have to stay backwards-compatible.

The problem from my side with doing this work is that it's something my
competitors can just take over for free whereas other work I might do
instead is a contribution to 'staying in the race'.

Pent

[joaomgcd]

Thanks Pent I totally understand :)

But maybe I'm just underestimating the issue, but couldn't we simply replace broadcast receivers with exported IntentServices that could perform the exact same code?