Google-Calendar

GCGetData

GCAppLoc

GCAppDesc

GCAppTime

GCAppTit

GCGetJD

GCJD

GCJT

GCAT

GCJTMaths

Code: # mins 1 hour 1 hour 1 min 1 hour # mins # hours # hours 1 min # hours # mins

Code: # 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'

Code: # 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

GCNavMaths

Code: 30 + 60 - 40 = 50 ~ The desired departure minutes

GCEntry

Code: 02.09 02 * 60 = 120 120 + 09 = 129 19.38 19 * 60 = 1140 1140 + 38 = 1178 129 - 1178 = !ERROR!

Code: 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

* Check post 3 for current limitations with this task

GoogleMT

Google-AutoNav

GCAutoNav

Google_calendar_mtpref

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. 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 variablefor 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:(lol?)The final splitting task, that gets us the three titles:(lol?)(lol?)(lol?)You'll notice at action #18 there is a= 2. This variable is set to 1 when the navigation calendar entry triggers.it is still set to 2, then Tasker knows you already have a pending navigation entry and won't create another one. Theskips all of the other tasks and goes straight to refreshing the MT widget with the above data, before stopping.Assumingisn't set to 2, the task continues and checks if each of thes (lol?)'Meeting*' (the '*' being a wild card to allow further body text after). If it does, it sets the main(lol?) to its contents and is told to perform the taskYou'll note that(lol?) does match 'Meeting*' the perform task action has aon, so Tasker will not get to consider the contents of(lol?) &(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 threevariables it needs to include in the URL as the destination.This is achieved by asking on eachaction,the corresponding(lol?) entry contained 'Meeting*'. Using the sameprinciple as above, the correctcan be set toand 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 populatewith the journey distance.Similar to the above, this time we populatewith the journey time.Using similarandactions to previous tasks, we establish which of the calendar events is the meeting and populate the information toso 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 toThis 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: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:Splitting further again by the instance of 'min':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 ofstatements and aaction.The result was having journey time hours () and minutes () 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.00Here'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...Usingstatements to establish whether the above scenarios are true, gives us the opportunity to take the action of adding 60 onlyjourney minutes are greater than arrival minutes..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 sameaction 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 zerothey are less than 10, giving us '02'. We join the minutes to '.0'they are less than 10, or just '.' otherwise. We now have 02.09 stored in the created variable. Sorted.It would be fantastic if the departure time above () could be triggered when it equals the inbuilt time variable, 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 withdespite 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 towhere 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.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 -the departure hours are less (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.The profile is triggered by the context of a calendar event becoming active with matching matching variables(lol?).Finally, this task loads up the navigation at the equivalent ofwith the destination of. It setsto 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 thefolder. It can then be selected in the MT Preference Manager or by selecting the 'restore' option when creating a new MT widget.