[Android Apps and Games] brandall:
Tutorial & Task Explanation

Google-Calendar

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.

GCGetData

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.

GCAppLoc

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:

%GCLOC1

%GCLOC2

%GCLOC3

GCAppDesc

As above, this time extracting the description field to:

%GCDESC1

%GCDESC2

%GCDESC3

GCAppTime

As above, placing the calendar entry date and time into:

%GCTIME1

%GCTIME2

%GCTIME3

GCAppTit

(lol?)

The final splitting task, that gets us the three titles:

%GCTIT1 (lol?)

%GCTIT2 (lol?)

%GCTIT3 (lol?)

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.

Assuming %GCNAV isn't set to 2, the task continues and checks if each of the %GCTITs (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.

GCGetJD

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 action, IF 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.

GCJD

This task reads from the file Journey.txt and splits it to populate %JOURD with the journey distance.

GCJT

Similar to the above, this time we populate %JOURT with the journey time.

GCAT

Using similar GOTO and IF 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.

GCJTMaths

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:

# mins
1 hour
1 hour 1 min
1 hour # mins
# hours
# 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 action.

The result was having journey time hours (%JOURTDH) and minutes (%JOURTDM) separated into created variables.

GCNavMaths

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

Using IF 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.

IF 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. Sorted.

GCEntry

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.09
02 * 60 = 120
120 + 09 = 129

19.38
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.09
(02 + 24) * 60 = 1560
1560 + 09 = 1569

19.38
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

GoogleMT

Minimalistic Text 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.

Google-AutoNav

The profile is triggered by the context of a calendar event becoming active with matching matching variables %GCLOC & %GCTIT (lol?).

GCAutoNav

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...

Google_calendar_mtpref

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.