K-@ Mail integration: QueryReceiver not being triggered reliably

46 views
Skip to first unread message

Emanuel Moecklin

unread,
Mar 25, 2015, 12:41:34 PM3/25/15
to task...@googlegroups.com
Hi there

I'm integrating my email client K-@ Mail (https://play.google.com/store/apps/developer?id=1gravity+LLC) with Tasker.
Creating / Editing an action works like a charm but I struggle with my event plugin.

The flow is basically:
- create a profile (event - plugin - K-@ Mail)
- create the configuration (e.g. mails with subject "Emanuel") -> save
- link some task to the profile
- new mail arrives -> sendBroadcast "com.twofortyfouram.locale.intent.action.REQUEST_QUERY"
- My QueryReceiver receives the configuration and checks whether the newly arrived mail matches the configuration -> RESULT_CONDITION_SATISFIED or RESULT_CONDITION_UNSATISFIED
  1. It all works to the point where the app sends out the REQUEST_QUERY broadcast. Right after I create the profile, Tasker doesn't call my QueryReceiver  and thus nothing happens. Sometimes I just need to disable and re-enable the profile to make it work, sometimes I need to force stop Tasker and then the QueryReceiver is called. I tested this with Aquamail too and there seems to be the same problem, the action is initially not triggered and only after some "pushing" by the user (that's me in this case) the QueryReceiver gets the call. The "pushing" part is kind of unpredictable, sometimes the force close works, sometimes not.
  2. Another issue I observed is that QueryReceiver sometimes gets called with already deleted profiles but not with the active ones. I added a unique id to each configuration to check this and the QueryReceiver indeed got called with a profile that had been deleted already while the active profile was ignored. The following shows some of my log that illustrates this:

Here's my app saving the configuration
E/K-@Debug( 7286): 11:03:11.31 - save TaskerBundle -------------------------------------------------
E/K-@Debug( 7286): 11:03:11.31 - event_subject = Emanuel 2
E/K-@Debug( 7286): 11:03:11.32 - com.onegravity.k10.tasker.INT_VERSION_CODE = 119
E/K-@Debug( 7286): 11:03:11.32 - UNIQUE_KEY = d34a85e5-ccbd-4239-985e-ed10a1cc91b4
E/K-@Debug( 7286): 11:03:11.32 - Unique ID = d34a85e5-ccbd-4239-985e-ed10a1cc91b4

Here's where the app sends the REQUEST_QUERY broadcast:
E/K-@Debug( 7286): 11:03:25.91 - TaskerRelay.messageArrived.sendBroadcast

And here's where my QueryReceiver is called (20ms after the broadcast):
E/K-@Debug( 7286): 11:03:25.93 - QueryReceiver.onReceive
E/K-@Debug( 7286): 11:03:25.93 - match TaskerBundle -------------------------------------------------
E/K-@Debug( 7286): 11:03:25.93 - event_subject = Emanuel
E/K-@Debug( 7286): 11:03:25.93 - com.onegravity.k10.tasker.INT_VERSION_CODE = 119
E/K-@Debug( 7286): 11:03:25.94 - Unique ID = null

As you can see the subject in the saved configuration is "Emanuel 2" while the subject in the Bundle I receive in the QueryReceiver is "Emanuel" which was part of an already deleted profile. Also the Bundle in the QueryReceiver has no Unique ID (I used that profile before I added the unique id).
Another inexplicable case was when I added a second profile and only one of the two were passed into the QueryReceiver.

I found these issue on a Nexus 7 2013 / CM 12 Nightly but had similar/identical issues on a Nexus 5 / Android 5.1. I'm fairly certain it's not related to the Android version.

As it stands now I can't roll out the new version as that would create too many support requests. Maybe I'm just missing something really simple?

Any help is highly appreciated.
Emanuel

Emanuel Moecklin

unread,
Mar 25, 2015, 1:04:54 PM3/25/15
to task...@googlegroups.com
Ok found the answer.

Without leaving Tasker (like with the back button) the configurations won't be active and deleted ones are still around.
Sorry to say that but this is highly counter-intuitive like many other things in Tasker. I'm willing to give some constructive input if you're willing to listen.
There seems to be a very steep and unnecessary learning curve to Tasker not due to the complexity of the app but due to the ui design and ui patterns.
Reply all
Reply to author
Forward
0 new messages