In my post about KLWP I mentioned how AutoTools‘ JSON options power part of my setup. Before I cover the KLWP aspect of that, I thought it only logical to dedicate a post to the features’ usefulness in Tasker itself, as it may just be one of the most powerful plugin options available in Tasker at the moment.
To start off, here’s (part of) the official description of JSON from json.org:
To put that in Tasker terms, JSON is variables and arrays on steroids. It basically allows you to nest arrays and variables in a way that creates a “database” of them that is easy to work with. To give you a visual reference to work with, take a look at some JSON generated by one of my Tasker tasks below.
“episodetitle”: “The Monetary Insufficiency”,
“showtitle”: “The Big Bang Theory “,
“summary”: “Sheldon goes to Vegas to win money for science. Also, Penny and Bernadette take Amy wedding dress shopping, but her terrible choice entangles them in a web of lies.”,
What you’re seeing here is data I generate for a Trakt.tv widget I have in KLWP. It’s the first entry in an array of episodes, and it contains a number of objects (variables in Tasker terms) with various data about an upcoming TV episode. The actual JSON file I have has a bunch of these episodes, each with their individual fields for episode number, month, title, etc. The (imaginary) Tasker equivalent would be to have an array, %episodes(), where each variable in the array contained a subset of variables like %epnumber, %month, etc. That’s not how Tasker works, of course, which is why JSON is useful in Tasker. In essence, it allows you to store large amounts of data much more easily, where doing so using Tasker’s own variables would be difficult (especially if you nest even more arrays and variables). Once I have the data above saved as JSON (which is done with AutoTools’ JSON Write option), I can easily access all of it or just parts of it, either in Tasker (using the JSON Read option) or elsewhere (like KLWP).
Since I finally sat down and learned how to use JSON, I’ve made several Tasker creations that otherwise would have been difficult. Several of them process data from RSS feeds, as the JSON Read option has a setting to convert XML to JSON. The Trakt data above actually originates from an RSS feed, and by using JSON Read I can access the info in Tasker, where I can process it before storing it as JSON in a local file. This processing is partly because I can’t figure out how to access RSS fields with namespaces in KLWP, and partly because the original RSS feed has multiple pieces of information squished together in the same field. To show you what I mean, and how this all works, let me take you through part of it.
First off, here’s an excerpt from the Trakt RSS feed:
<feed xml:lang=”en-US” xmlns=”http://www.w3.org/2005/Atom” xmlns:media=”http://search.yahoo.com/mrss/” xmlns:trakt=”http://trakt.tv/”>
<title>Suits 7×15 “Tiny Violin”</title>
This basically means that the root of the RSS XML is <feed>, which contains information for several episodes (one for each <entry>), where one of the fields for each entry is <title>. By telling AutoTools’s JSON Read action to grab the field path feed.entry.title, outputting to a custom named title() array, I get a Tasker array %title() where each variable in the array corresponds to the title for one of the episodes. Using the full path assumes that you disable JSON Read’s “simple mode”, which in my experience just creates problems, as the root of RSS feeds often has fields with the same name as the entries, messing up the arrays. In the resulting Tasker array, %title1 would give me the title for the first entry in the RSS, %title2 for the second, etc. As long as the array indices are synced (again, disable simple mode, or they may not be), I can read multiple fields and use the same index to reference different fields for the same episode. In other words, %title4, %summary4, %date4 would all reference the same episode.
Once I do this for all the RSS fields I need, I have a number of local Tasker arrays that I can process. One of the problems with the RSS feed’s title field is that it has the show title, episode number, and episode title in the same field, and I want them separated for easy access in KLWP. The screenshot shows you a For loop that does this, using Regex to section off information and storing it in new arrays (update: now with better Regex, thanks to a reader pointing it out on Reddit).
Once I’ve processed other fields in similar manners (splitting the date, for instance) I join the arrays into single variables with a joiner other than a comma, ¥ to be specific. This is because both the title and summary fields may contain commas, which would mess everything up in JSON Write. Then I use JSON Write to output everything as a JSON file, which results in the data you saw further up. From there, I can access it again in Tasker, KLWP, or elsewhere. The process has turned annoying namespace-heavy XML with joined fields into simple JSON with exactly what I need as separate objects.
Employee information for use in For loop
Another JSON creation I have in Tasker is a tool for work. We have an info stream available as RSS, where our shorthand (initials-ish) are mentioned for information specific to us. Checking this manually is a hassle, so I originally made a task that read the RSS using JSON Read, checked for my shorthand (hardcoded into the task), and notified me. Some colleagues heard about this, and wanted in. The simplest way to do this (as they are clueless about tech and couldn’t run Tasker themselves) was to simply have my phone check for other people as well. As such, I rewrote my little checker task to be able to check for the shorthand of others, and then email them using a Tasker plugin I won’t name due to how annoying its trial system is. To make this work, I needed a way to easily store a list of initials and email addresses, and also a way to make sure it only notified people once. The solution was JSON.
In its finished form, the new checker consists of two tasks. One of them simply allows me to add new people to the list, taking a %shorthand and %email input and adding to the JSON “address book”. The second is the checker itself, which reads the information stream RSS, the address book JSON, and then runs a For loop for each employee nested inside a For loop for each RSS entry, checking each RSS item for mentions of each employee’s shorthand. If it finds one, it emails the RSS info to the person in question, and then adds the UID (unique ID) of that RSS item to an aptly named “okuid” object in the JSON. The next time it runs, it will skip any mentions with a UID that’s listed in the JSON, independently for each employee. As everything is done using local variables, having nested For loops isn’t a problem; there’s only a dozen or so entries in the RSS at any given time, and even with all 150 employees on the list that would take only a few seconds to process.
JSON, the final frontier
The possibilities with JSON in Tasker are endless. If I still wrote the storage aspect of my todo list setup myself, it would be a prime candidate. My Audible series notification tool is another prime candidate, as soon as I get around to rewriting it to not use global variables for data storage (I know, lazy solution). Others have also done awesome things with JSON, such as Rory’s JSON visualizer web screen. JSON (and XML) are used by so many information sources, in addition to being an awesome tool for storing your own data, that having it as an option in Tasker really does make AutoTools one of the most game changing plugins out there, even if you ignore all the other options it has to offer.