Option to ignore Dialer for Application Context

24 views
Skip to first unread message

Klaus

unread,
Aug 8, 2010, 4:44:37 AM8/8/10
to Tasker
NOTE: I also posted this on the Feature Request forum. I posted here
to discuss with other users.

When there is incoming call, Dialer will show up, and this will
trigger Tasker to "exit" current active Application Context profile.

On certain situation, this is not very nice (for example: an app that
uses GPS).

Here is the scenario:

Profile: Using CoPilot Navigation
Context: Application: CoPilot
Task: Set GPS ON
Task: Set Display Brightness to 180
Task: Set Media Volume to Level 15
Task: Set Speakerphone ON

When I start CoPilot, Tasker activate that profile correctly, executed
all tasks.

Now, I am driving ..................

Someone call my phone ..............

Dialer is shown up ...

And this trigger Tasker to de-activate the above profile. Which result
in shutting down the GPS, Speakerphone, etc.

When I closed the Dialer (end call), Tasker will re-activate
again ...

This situation is not good and annoying when using GPS (and
speakerphone).

People calling is quite common, so I think an option to ignore so
active application context will not be affected.

Please consider this request.

Thanks.

Klaus

BossMan

unread,
Aug 8, 2010, 3:53:43 PM8/8/10
to Tasker
The only suggestion I have is to use a different context for settings
those variables (car dock, ac powerered, bluetooth connected, "not
wifi or localisation"... or a combination of them), instead of app
context :)

BR,
A.

Klaus

unread,
Aug 8, 2010, 4:52:45 PM8/8/10
to Tasker
Well, that's the problem ...

1. Not everybody has car dock in his car

2. I don't want to turn on my GPS, etc. every time I connected my
phone to AC power source

3. Not everybody has or use bluetooth

The thing is, using App Context is logical for this scenario ...

And incoming call is like "interruption" ... or "exception" ... that
BREAK that scenario.

Which should be easily workaround-ed by an OPTION to ignore that
interruption.

Pent, what do you think?

UncleMike

unread,
Aug 8, 2010, 5:31:13 PM8/8/10
to Tasker
Here's something that may help...


Context: Application [Phone]
Context: Variable Value [Name: GPS] [Value: on]
Enter Task:
Set GPS ON
Set Display Brightness to 180
Set Media Volume to Level 15
Set Speakerphone ON

When the phone switches to the phone app, this MAY cause Tasker to
leave the settings alone, and continue to do so if when the phone app
exits, you return to CoPilot. If it does work, I would recommend
creating a named task and using the same task for both profiles. That
way, any change to the named task will affect both profiles.

Klaus

unread,
Aug 9, 2010, 3:12:00 AM8/9/10
to Tasker
Thanks UncleMike,

I don't think that will solve the issue because Tasker will still
restore the GPS when de-activating the navigation app during the
incoming call.

BossMan

unread,
Aug 9, 2010, 3:21:03 AM8/9/10
to Tasker
How about the delay idea, from the other thread?
http://groups.google.com/group/tasker/browse_frm/thread/77d901181dc6129b#

BR,
A.

Klaus

unread,
Aug 9, 2010, 4:02:10 AM8/9/10
to Tasker
2 minutes (or such delay) without GPS is not a good situation for
using navigation system.

When you are in a highway where you drive quite fast and need to make
a decision to exit ... You don't want to loose GPS :)

I think this scenario is just NOT POSSIBLE with current version of
Tasker.

To my opinion, the Application Context should be more extended with
option like I suggested here.

Anyway, I changed my method to use widget in combination of variable
as described in this example:

http://forum.xda-developers.com/showpost.php?p=7424723&postcount=1

One extra step though, to toggle it OFF .... :) No need to do this
with Application Context.

On Aug 9, 9:21 am, BossMan <adam.marynow...@gmail.com> wrote:
> How about the delay idea, from the other thread?http://groups.google.com/group/tasker/browse_frm/thread/77d901181dc61...
>
> BR,
> A.

BossMan

unread,
Aug 9, 2010, 5:29:15 AM8/9/10
to Tasker
Two minutes delay with GPS on, not off. Mind that GPS handling is done
not by the app context directly but by the other process - and
application exit is delayed.

BR,
A.

UncleMike

unread,
Aug 9, 2010, 9:06:24 AM8/9/10
to Tasker
I just setup the following profiles:

Context: Application [Maps]
Enter Task:
GPS [Set: On]

Context: Application [Calculator]
Enter Task:
GPS [Set: On] If [%GPS = on]


I then began navigation and used the Home button to immediately switch
to the calculator app. GPS did not turn off while the calculator app
was running, and navigation continued normally.

When a single change occurs (i.e. a change in app context, a variable
value changes, the time changes), this can simultaneously trigger some
profiles to become inactive and others to become active. I believe
that Tasker doesn't just blindly restore settings and execute the Exit
Tasks and Enter Tasks, but looks at what the end result will be and
acts accordingly. So in this case, when Tasker realizes that the
Application context has changed, the Maps application context is still
active (about to be deactivated) GPS is still on. Tasker figures out
that the end result of this change is that GPS will be on, so it
leaves it on (instead of turning it off and then immediately turning
in on again).

The same should work for the Phone app, or whatever the app actually
is that appears when you get an incoming call, and won't turn on GPS
every time the Phone app starts.

UncleMike

unread,
Aug 9, 2010, 9:12:21 AM8/9/10
to Tasker
For confirmation of the above, see this message from Pent:

http://groups.google.com/group/tasker/msg/39527a6a1aecae2e

Klaus

unread,
Aug 10, 2010, 4:50:03 PM8/10/10
to Tasker
UncleMike,

Interesting, but I think there is one problem with your approach.

When the Dialer launched, how does Tasker know if the Navigation is
running?

Tasker needs to know this, because it should not turn on some
settings.

For GPS is ok, because there is %GPS variable, which you did a very
good trick here:

Context: Application [Phone]
Enter Task:
GPS [Set: On] If [%GPS = on]

But, how about Auto-Brightness? and might be other settings as well.

Certainly, we cannot use user-defined variable like below:

Context: Application [Phone]
Enter Task:
GPS [Set: On] If [%NAVIGATION = 1]
AUTO-BRIGHTNESS [Set: On] If [%NAVIGATION = 1]

Why? Because at some point we must set the %NAVIGATION to 0.

When? Obviously, after navigation is ended, in the exit task of the
Navigation profile.

However, keep in mind that exit task might have been executed before
the Phone app launched.
Then during the Phone app profile, the %NAVIGATION will always has
value of 0.

So, we still need this ignore Dialer option.

Klaus

unread,
Aug 10, 2010, 4:55:06 PM8/10/10
to Tasker
Thinking about your trick, I think we could come up with workaround
like this:

Context: Application [Phone]
Enter Task:
Perform Task "SETUP_NAVIGATION" If [%GPS = on]

:)

But that does not sound right because we might use GPS on other task
as well.
And we dont want to perform task every time there is incoming call !!!

Where is Pent?

Why he does not comment on this? :)

Pent

unread,
Aug 13, 2010, 3:14:05 AM8/13/10
to Tasker
> When a single change occurs (i.e. a change in app context, a variable
> value changes, the time changes), this can simultaneously trigger some
> profiles to become inactive and others to become active.  I believe
> that Tasker doesn't just blindly restore settings and execute the Exit
> Tasks and Enter Tasks, but looks at what the end result will be and
> acts accordingly.  So in this case, when Tasker realizes that the
> Application context has changed, the Maps application context is still
> active (about to be deactivated) GPS is still on.  Tasker figures out
> that the end result of this change is that GPS will be on, so it
> leaves it on (instead of turning it off and then immediately turning
> in on again).

That's correct.

But in general I guess I agree with Klaus, most people will not want
their
context to drop out with the Phone app and won't want to take
complicated
steps to avoid it.

Pent

UncleMike

unread,
Aug 13, 2010, 7:45:59 AM8/13/10
to Tasker
I think you're right. Hopefully you saw my post (in another thread)
regarding the selectable options for the Application context.

Klaus

unread,
Aug 13, 2010, 10:30:38 AM8/13/10
to Tasker
Thanks Pent,

Your comment bring some peace on my mind :)

I hope you will enhance the Application Context to include this option
in the near future.

And ideas from UncleMike are also very good.

Regards,

Klaus

Pent

unread,
Aug 13, 2010, 11:49:00 AM8/13/10
to Tasker
The latest beta ignores the phone app for app-detection purposes if
the phone isn't
idle (it also detects phone/contacts with phone NOT ringing which
wasn't working before).

> Hopefully you saw my post (in another thread)
> regarding the selectable options for the Application context.

Could you link or copy here for me, don't see it.

Pent

Klaus

unread,
Aug 13, 2010, 2:47:38 PM8/13/10
to Tasker
Hi Pent,

I just installed the latest beta 1.0.8b1m, also rebooted my phone to
make sure.
Checked the Tasker version and it is correct 1.0.8b1 (validated).

I tested this, but I don't think it works.

Profile: Sygic
Context: Application Sygic Mobile Maps 10
Enter task: GPS ON, Auto-brightness ON, Media volume 15, Flash "Start
navigation"
Exit task: GPS OFF, Auto-brightness OFF, Flash "Stop navigation"

Tasker monitor is ON.

I started Sygic and Tasker executed the Enter task correctly.

GPS was ON and got a fix.

Waited some minutes (to simulate driving).

Then I called my phone ........................... (but I did not pick
up the phone, I left it ringing).

Dialer (Phone app) came up and I saw Tasker executed the Exit task
(turning off GPS and Flashed "Stop navigation").

I stopped the call from my other phone.

Dialer was gone. Sygic became active in the foreground again ........
(GPS was off).

Tasker (again) executed the Enter task.

So, that's my test. It still does not work.

I am wondering, what do you mean with "if the phone isn't idle"?
Probably the above condition is considered idle?

Regards,

Klaus

Klaus

unread,
Aug 14, 2010, 9:54:08 AM8/14/10
to Tasker
I updated to 1.0.8b3 and re-tested.

It works OK, but not perfect :(

Because sometimes, Tasker is still closing the running app context
profile.

I don't know why, because I could not reproduce it.

I think to add OPTION (checkbox) is the way to go ... to really sure
the phone dialer does not stop current running app context profile.

Pent

unread,
Aug 14, 2010, 10:16:33 AM8/14/10
to Tasker
Hi Klaus,

> It works OK, but not perfect :(
>
> Because sometimes, Tasker is still closing the running app context
> profile.

If you could send me a log when that happens it would be useful.

> I don't know why, because I could not reproduce it.

Probably timimg. When it exits, is is imediately, when the call ends,
or in between ?

> I think to add OPTION (checkbox) is the way to go ... to really sure
> the phone dialer does not stop current running app context profile.

What would the option do in itself ? Could you clarify again what
option you
have in mind, sorry if I havn't followed the discussion closely.

Pent

Klaus

unread,
Aug 14, 2010, 10:30:50 AM8/14/10
to Tasker
On Aug 14, 4:16 pm, Pent <tas...@dinglisch.net> wrote:
> If you could send me a log when that happens it would be useful.
> Probably timimg. When it exits, is is imediately, when the call ends,
> or in between ?

Hi Pent, I will do some more tests and enable the logging. I did not
do this last time.

The exit was imediately.

> What would the option do in itself ? Could you clarify again what
> option you
> have in mind, sorry if I havn't followed the discussion closely.

Option like this:

When creating Application Context, there is a checkbox:

[ ] Incoming call will not end this profile

Then (if checked), if there is incoming call (Phone dialer shown up),
Tasker should NOT do anything with current App Context profile that IS
running.

If not checked, if there is incoming call, Tasker will process current
App Context exit task.

Klaus.

Klaus

unread,
Aug 16, 2010, 2:07:31 AM8/16/10
to Tasker
Hi Pent,

I did some testing this morning and I was able to reproduce this issue
twice (on 2 tests!).

I sent the log file to your email.

Regards,

Klaus
Reply all
Reply to author
Forward
0 new messages