Tutorial & Task Explanation
The initial profile is trigger is time based. You can set it to update how every frequently you want the Minimalistic Text widget to refresh.
First up, this task pulls the XML feed from your calendar. The output is written to a text file sdcard/Googlecal.txt
. You can view the file in an explorer to see the data it pulls.
Splitting apart the XML feed (having transferred it to a created variable %GCFEED
for good housekeeping), we extract the three appointment locations and place them in:
As above, this time extracting the description field to:
As above, placing the calendar entry date and time into:
The final splitting task, that gets us the three titles:
You'll notice at action #18 there is a GOTO IF %GCNAV
= 2. This variable is set to 1 when the navigation calendar entry triggers. IF
it is still set to 2, then Tasker knows you already have a pending navigation entry and won't create another one. The GOTO
skips all of the other tasks and goes straight to refreshing the MT widget with the above data, before stopping.
isn't set to 2, the task continues and checks if each of the %GCTIT
s (lol?) MATCHES
'Meeting*' (the '*' being a wild card to allow further body text after). If it does, it sets the main %GCTIT
(lol?) to its contents and is told to perform the task %GCGetJD
You'll note that IF %GCTIT1
(lol?) does match 'Meeting*' the perform task action has a STOP
on, so Tasker will not get to consider the contents of %GCTIT2
(lol?) & %GCTIT3
(lol?). This avoids multiple requests for navigation entries.
If Tasker did find 'Meeting*' in the title fields, a location request is actioned as your assumed starting point (this will change in V3). Once the location information is received, Tasker needs to know which of the three %GCLOC#
variables it needs to include in the URL as the destination.
This is achieved by asking on each HTTP GET
the corresponding %GCTIT#
(lol?) entry contained 'Meeting*'. Using the same GOTO
principle as above, the correct %GCLOC#
can be set to %GCLOC
and is therefore requested in the URL for the direction details.
The output file is written to SDCard/Journey.txt which you can view with a file explorer should you wish.
This task reads from the file Journey.txt and splits it to populate %JOURD
with the journey distance.
Similar to the above, this time we populate %JOURT
with the journey time.
Using similar GOTO
actions to previous tasks, we establish which of the calendar events is the meeting and populate the information to %CALDTD
so we can manipulate it.
The start time of the calendar entry is used for the arrival time and after some variable splits, is set again to %CALDTD
Note: Variable splits can be difficult to understand at first. Often when testing, I add a 'Variable List' action followed by a STOP action after each split. This way I can see what is happening to the data when I split it and the Variable List that appears details all of the parts I may either wish to use or clear for good housekeeping.
This is where it started to get a little tricky... As structured as the data is, there are of course many eventualities when it comes to the possible journey time:
1 hour 1 min
1 hour # mins
# hours 1 min
# hours # mins
Using the method I described earlier of listing the variables after each split, I had to look for constants and newly created variables that I could use to cope with each eventuality.
For example, the first split I do is at the instance of 'hour'. Looking above you'll see that we could end up with the following:
# mins ~ will create no further variables
1 hour ~ will create no further variables
1 hour 1 min ~ will create a variable of '1 min'
1 hour # mins ~ will create a variable of '# mins'
# hours ~ will create a variable of 's'
# hours 1 min ~ will create a variable of 's 1 min'
# hours # mins ~ will create a variable of 's #mins'
Splitting further again by the instance of 'min':
# mins ~ no further variables ~ no further variables
1 hour ~ no further variables ~ no further variables
1 hour 1 min ~ a variable of '1 min' ~ a variable of '1'
1 hour # mins ~ a variable of '# mins' ~ variables of '#' & 's'
# hours ~ a variable of 's' ~ no further variables
# hours 1 min ~ a variable of 's 1 min' ~ a variable of '1'
# hours # mins ~ a variable of 's # mins' ~ variables of '# min' & others
Scrolling through the task, I had to establish which journey time eventualities would lead to which data being populated to which variables! It gave me brain ache, but eventually I cracked with the help of plenty of IF
statements and a GOTO
The result was having journey time hours (%JOURTDH
) and minutes (%JOURTDM
) separated into created variables.
Knowing my arrival time and the journey time, next up was to calculate what time I would need to depart. Unfortunately, simply subtracting one from the other isn't a possibility. An example arrival time of 14:30 with a journey time of 2 hours and 38 minutes may have Tasker trying to get you to leave at 12:-8; if at any time at all!
It's necessary to first deal with possible minus numbers and such issues as 3 hours before 01:00 not being at time of -2.00
Here's a working example:
If the appointment time is #:30 and the journey minutes are 40, then the we are after a departure time of #:50 rather than -10 if Tasker was left to its own devices. Seeing that the journey minutes are greater than (>) the arrival minutes, this gives us a chance to prevent the minus number occurring by adding 60 to the appointment minutes. This of course has to take place after the appointment time has been split apart into hours and minutes...
30 + 60 - 40 = 50 ~ The desired departure minutes
statements to establish whether the above scenarios are true, gives us the opportunity to take the action of adding 60 only IF
journey minutes are greater than arrival minutes.. IF
not, the action is skipped.
we've had to add 60 to the minutes, we can therefore deduce that we need to reduce the hour by 1. The exact same IF
action above tells Tasker whether to perform this or not.
When we are finally left with separate departure time hours and minutes we need to variable join them into a time format. As a note, Tasker uses #.# rather than #:# as a time separator. Joining the hours and minutes using '.' would just be too easy wouldn't it... If the departure time is 02.09 in the morning for example, Tasker currently has them stored separately as 2 and 9. Joining them in this state would give us 2.9 which is no good of course...
We solve this issue by joining the hours to a leading zero IF
they are less than 10, giving us '02'. We join the minutes to '.0' IF
they are less than 10, or just '.' otherwise. We now have 02.09 stored in the created variable %DEPTD
It would be fantastic if the departure time above (%DEPTD
) could be triggered when it equals the inbuilt time variable %TIME
, but alas, that's not yet implemented in Tasker. The work-around to this is to trigger the navigation to start when a calendar entry becomes active with the departure details contained inside it.
The problem to this is that Tasker only enables you to set a calendar entry using 'minutes from now', so yes our example of 02.09 above is currently useless. I'm sure this will change in future releases so I persisted with GoogleNavMaths
despite this, but regardless, next we have to convert the departure time into the number of minutes from now... Oh joy...
It involves a similar practice to GCNavMaths
where we split the hours and minutes of the actual %TIME along with our example of 02.09, convert them both into minutes and find the difference between them. For the example below, lets say the current time is 19.38.
02 * 60 = 120
120 + 09 = 129
19 * 60 = 1140
1140 + 38 = 1178
129 - 1178 = !ERROR!
You can see that if the departure time is earlier the next day than the current time, we'll end up with incorrect data. The answer to this was quite simple - IF
the departure hours are less (<) than current hour, we add 24 to it.
(02 + 24) * 60 = 1560
1560 + 09 = 1569
19 * 60 = 1140
1140 + 38 = 1178
1569 - 1178 = 391 mins
391 = 6 hours and 31 minutes
6 hours and 31 minutes from 19.38 is indeed 02.09
In practice, it was actually easier to deal with the subtraction of the hours and minutes separately and add them together after, but the principle remains the same.
The end result was having the number of minutes stored in %DEPTDCAL
which could be used in the insert calendar entry action, along with %GCTIT
(lol?) and %GCLOC
* Check post 3 for current limitations with this task
is a great application that can display any Tasker variable you send to it. The MT calendar widget backup is included in the .zip file. Once you have it on your home screen, you'll have to edit the font sizes etc to make this look good for you - it's currently fugly.
This task splits out some of the useless data such as the current year and passes the variables you would look to use over to MT.
The profile is triggered by the context of a calendar event becoming active with matching matching variables %GCLOC
Finally, this task loads up the navigation at the equivalent of %DEPTD
with the destination of %GCLOC
. It sets %GCNAV
to 1 to let Tasker know it can set another navigation entry should it wish on the next refresh...
And off you trot...
This should be dragged into the sdcard/MinimalisticTextPreferences
folder. It can then be selected in the MT Preference Manager or by selecting the 'restore' option when creating a new MT widget.