Trouble with migrating from Broadcast to IntentService

[Falcosc]

I try to follow https://tasker.joaoapps.com/pluginsservicesmigration.html based on your example.

In your example you did implement the support for old Tasker versions like this

https://github.com/joaomgcd/TaskerPluginSample/blob/941eafb479d11efc69ea7836224eeab6e3fbd5b6/taskerpluginlibrary/src/main/java/com/joaomgcd/taskerpluginlibrary/action/ActionReceivers.kt#L15

How did you handle the isOrderedBroadcast() checks?

I don't understand how your broadcast implementation does support variable return.

The guide tells

In the FIRE_SETTING Service, if you want to return variables, always call TaskerPlugin.signalFinish instead of setting the result directly like it was possible before.

If I look at your example and all the code which is needed to handle actions via IntentService I would like to know if this really can be better than the old solution.

To be honest, I am not comfortable with this migration at all. I worry that the IntentService solution does cause a lot of instability because of all the battery optimization issues I had in the past related to background services.

Could you please tell me the benefits of this migration?

For example, I need to use the application context to access my cached data, with broadcast receiver I get it via the onReceive method. It was very reliable.

I see that you even use the service for your Broadcast implementation:

https://github.com/joaomgcd/TaskerPluginSample/blob/941eafb479d11efc69ea7836224eeab6e3fbd5b6/taskerpluginlibrary/src/main/java/com/joaomgcd/taskerpluginlibrary/extensions/Internal.kt#L56-L61

I am also hesitated to use the library because you added so may wrappers and annotations which makes it really hard to understand which things are doing what.

The old documentation https://tasker.joaoapps.com/plugins.html was a lot more easy to understand. With the old one it was much more easy to understand which data need to be included into the intent to use variables and how they get resolved later.

My biggest concern with using the new library is that something will break in the plugin, and I am unable to troubleshoot it because this thing added a lot of complexity.

How slow is the old Broadcast based solution? I consider keeping the old one.

Would be nice if you could share some details about the performance impact of broadcast intents and benefits of the IntentService to make it more easy to compare the benefits with the effort and risks of this migration.

Thank you.

[joaomgcd]

Hi. When you use the migration guide you mentioned at the top you don't need to use the library at all. You simply need to follow the steps for it to work.

You say

I worry that the IntentService solution does cause a lot of instability because of all the battery optimization issues I had in the past related to background services.

But those issues are even worse for BroadcastReceivers. I have a lot of experience with those and there were devices where BroadcastRecievers simply refused to work where Services worked.

[Falcosc]

How slow is the old Broadcast based solution? I consider keeping the old one.

Would be nice if you could share some details about the performance impact of broadcast intents and benefits of the IntentService to make it more easy to compare the benefits with the effort and risks of this migration.

[joaomgcd]

There is no definite data on each one. It depends on the device/ROM android version. I can tell you that on my Pixel 2 you don't often notice a difference but on other devices people couldn't even get it to work with the broadcastreceivers where it worked with the services.

[Falcosc]

Thank you, that reduces the urge a lot.

I will wait until somebody has trouble, and then I migrate to IntentService only. I guess the needed tasker version exists long enough to reduce the overhead of supporting 2 ways.