I won’t go into everything in detail, but just briefly go through how it works. The methods used can be used elsewhere as well, and it should be possible to do something similar with other tracking apps.
- One of the main things I wanted to do was to make it read the tracking numbers from the official app, saving me from having to input them somewhere else as well. Luckily, the app stores all tracking numbers in a database file, and having a couple of actions that use sqlite3 to extract data from databases already, I knew it would be possible to get to those numbers. I don’t know sqlite3 though, so I needed a bit of help to get the command right. I might look into sqlite3 a bit more and maybe do a dedicated article on it sometime, but for now, I’m not going to go into it deeper. Suffice it to say, action 1 is a root-enabled Run Shell command that gets the tracking numbers out of the official app’s database files.
- Action 2 checks to see if the output variable contains a line shift, meaning it contains more than one number. If it does, it splits the variable with action 3. If it doesn’t, it sets %output1 to %output using action 4. Since a Variable Split creates an array %output() with each variable %output# containing a new number, action 4 simply makes it so that a single tracking number is turned into an identical array with only one element in it.
- Action 7 starts a For loop with all the items from %output(). Each number is transferred into %number in turn, then run through the actions in the loop.
- Action 8 uses HTTP Get to grab the tracking info for the number using an XML API that’s available.
- Action 9 turns the global %HTTPD variable created by the HTTP Get into a local variable so that it’s faster to work with.
- Actions 10-16 split the data to get to the pieces of information I need, specifically status description, location, time, and date for the latest status updated.
- Action 17 is a way to test for the existence of a file. It uses List Files with *%number* and stores the results in %testres, which is an array where each element is a match for the file. If there’s no file with that name, %testres1 will be empty, and return its own name as the value.
- Action 18 uses this to create an If group for when there is no file with that name. If the file doesn’t exist, %testres1 will be its own name, and so having an If group with the If condition %testres1 ~*testres1 makes action 19 run only when the file doesn’t exist already.
- Action 19 creates a file with the filename %number.txt and contents that include the data split from the XML further up, but only if there’s no file with that name already (thanks to action 18).
- Action 20, being an Else action, makes it so that everything that is grouped within it runs when there was indeed a match to the file name in action 17, meaning a file for that tracking number exists.
- Action 21 reads the file into a variable, %oldstatus.
- Action 22 compares the contents of the existing text file with what it got from actions 10-16. Actions 23-24 only run if they don’t match, meaning that the tracking status has changed since last time.
- Action 23 creates a notification using AutoNotification, letting me know that a change in tracking status has been detected, and includes the information it got from actions 10-16.
- Action 24 overwrites the file with the new information.
- Actions 25-27 simply close If and For groups.
- This task is then tied to a time context for some time in the morning, so that it performs this check once a day. Obviously I can make it do it more often, but once is enough for now.
In human terms, this is what happens: Every morning, the task finds the tracking numbers that are currently in the official app, and tracks them online. Then it looks to see if there’s a file for each number in a specified folder. If there isn’t, it means it’s the first time it’s seen that number, and creates that file. If there is, it compares the information in that file with what it found out from tracking the numbers, and sees if there are any changes. If there are any changes, it creates a notification, and puts that new information in the file. Then, next time it runs, it will compare the status to that information, and so on. That way, it will create a notification every time the status of the shipment has changed.
because it uses the official app’s database of tracking numbers, it’s truly an add-on to that app, and doesn’t require me feeding it tracking numbers or anything like that separately. I tried various scenarios to look for bugs, and haven’t found any yet, but only time will tell if that’s truly the case. In any case it was a fun little project, and it sure took less time than waiting for the official app to get the feature.
