To answer this question, we're going to build an app that doesn't use APIs. Instead, we will use a spreadsheet as an intermediary to get stock market data. Our app will write ticker symbols to the spreadsheet and get stock prices back from the sheet. Most of the time. Hopefully.
By the end of this demo you should understand that:
API requests are asynchronous, which means:
For the best performance, you should always aim to minimize the total number of calls in your app.
Let's get started by making a copy of this sheet, which has all the functions your app will need. By default the Google Finance function will return the most recent price for a given symbol. Alternatively, you can pass any one of a number of different parameters to find the corresponding value. In the image below, we are showing the price in cell B2 and showing the chance in price in cell B3. With everything set up in our Google Sheet we can connect this directly to our Thunkable project.
The user interface for this example is quite simple, but if you want yours to look identical to the tutorial then go ahead and make a copy of it for yourself.
Next step is to connect to our Sheet. Click on the Data tab on left hand side of your screen and choose "Google Sheets" as your data source.
Finally, choose the Google Finance sheet and create a new data source within your Thunkable project.
Since we're just testing the waters we won't worry too much about data validation just yet. The first thing we'll do is get a ticker symbol from the user and send it to our sheet. In your Thunkable blocks it looks like this:
After a few seconds the data will update and we can call the new values from the Sheet.
Now, the first and last thing we do is show/hide the loading icon. In between, we send a new value to the sheet, wait 3 seconds and then (hopefully!) get the most recent price back. Since we have no control over how long it takes our Sheet to update this 3 second values is really a best guess. Most of the time it will be a lot faster, but other times it will be significantly slower and we'll end up fetching the previous value from the spreadsheet. In general we want to avoid doing things like this in our app and instead make asynchronous calls to an API.
As we've just seen in the previous example, having fixed wait times in our app is a bad idea. In the best case scenario the operation is completed much quicker than our delay and we've kept our user waiting unnecessarily. The worst case scenario is that the delay isn't long enough and we get inaccurate or out of data information for our use. A much more sensible approach is to use an asynchronous approach. In this context asynchronous simply means that the request and response don't happen at fixed, or predefined, intervals. In the case of a synchronous approach we might send a value to our sheet and then repeatedly check, every 1 second, to see if the result has been updated. With an asynchronous request we send our data to the API and when the response is ready it gets sent back to the app. Our app "listens" for this response from the API and only acts when the response has been received.
If you want to learn more about building a stock quotation app and how to do this by connecting to a financial data API then check out our intermediate tutorial: Taking Stock
The other value in our spreadsheet is the change in price. This will either have gone up, gone down or stayed the same. While this isn't - strictly speaking - related to working with APIs, it's nice to demo how you can make decisions in your app, based on different responses you might get. In this case, we want the text to be green if the price has increased, red if it has decreased and black if it's stayed the same.
In this tutorial we learned that we can use Thunkable data sources to read and write data to a spreadsheet in the cloud. This is a fantastic tool to have at our disposal but is poorly suited to something like a simple stock market app. In the next two section we will learn how to request data from an API, parse the response and set the request headers. Armed with this new information we will then be able to create a much more robust and scalable app for stock market data.
Most modern APIs will have support for a variety of CRUD operations. In this context, the acronym CRUD stands for Create, Read, Update, Delete. While most API developers probably won't want to give just anyone free rein to change or remove data on their system there are plenty out there who provide public, read-only access to their end points. This is also convenient for us, since reading data from an API and displaying it in a Thunkable app is probably the easiest way to familiarise ourselves with APIs.
At the end of this tutorial, you should be able to
Send a GET request to an API
Parse (interpret) a response from that API.
The app we're going to build in this example is called "Dogs-as-a-Service". It connects to the dog.ceo API and can "fetch" an image and breed name for a random dog.
At its core we need at least three components to get this app working correctly; a Button to send the API request, an Image to show the picture in the response and a Label to display the name of the dog breed. If you want your project to look the same as the sample project then you can go ahead and make a copy of it for yourself.
Let's begin by sending a GET request the to API. Notice here that the purple Get
block returns three parameters; response, status and error. If anything goes wrong with the request then an error will be returned so it's always a good idea to do some error handling in your app. The status block returns the HTTP status. According to this list there are about 30 different response codes. You don't need to remember what they all mean but it is good to know that a response code in the 200s is successful, codes in the 300s are for redirects and status codes in the 400s correspond to errors. Indeed you may already be familiar with the 404 error code for "Page Not Found". The example below has some basic error handling and, if successful, displays the entire JSON response in a label.
Our response contains just two properties, message
and status
which really makes this API as easy as possible for us to work with.
GET
https://dog.ceo/api/breeds/image/random
All we need to do here is get the value from the message
property and pass that to our image component. The object blocks in Thunkable make this incredibly easy to do and we can set our picture by using just two of them. First we have to convert the raw JSON response into an object using the get object from JSON block, then we can go ahead and get the message value and pass it to the image component using the get property of object block like this:
The URLs for every image also contain the breed names for each dog. If you look closely you'll notice they all follow the same pattern:
https://API-HOST/DOG-BREED/DOG-IMAGE.jpg
What we want to do is grab the name of the dog breed, remove any stray backslashes and convert it to Title Case. In practice, this involves using the make list from text blocks and then the in list get # block to get the name of the breed and then pass that through the Title Case text block to output the nicely formatted dog breed in our label.
While the above approach works perfectly well for pugs and collies, our API is set up in such a way that you might also see responses like "terrier-welsh" or "terrier-westhighland". The second if then do block below shows one way that you can split the text at the hyphen and display the words in reverse order.
In this first example we've learned how make a Get
request in Thunkable and use the object blocks to retrieve information from the API response. We've also seen firsthand how just a handful of list and text blocks can be combined to extract additional information and present it to the end user in an easy-to-read format.
If you have any questions about this tutorial, please post them over in the Thunkable Community
Community Link: https://community.thunkable.com/t/dog-breeds-api-tutorial/
Every time you send a request to an endpoint it takes time and bandwidth. From your perspective, as an app developer you want to minimise wait times in your app. From the perspective of your API developer you want to keep your bandwidth usage as low as possible - especially if it's something they're paying for and you're using for free. Thankfully these issues are two sides of the same coin and
By the end of this lesson you'll understand how to:
Maximise app speeds while minimising API calls.
Set WebAPI headers.
The API allows us to get jokes in HTML, JSON or plain text format. In order for us to specify which format we would like the response in we need to use a header. In the WebAPI drawer, there are four different properties we can set; Body, Headers, QueryParameters and URL. Going back to the API docs, we are asked to specify an Accept
header and a User-Agent
header. To request a response in JSON format from the API we set the value of the Accept header to application/json
. The user agent header is used as a way for us to identify ourselves to the API developer. Recall that this is a free service and we don't want to take advantage of the generosity of the developer. In this case I've used an email address since it gives the developer a way to contact me directly if there are too many calls being made.
The API request is quite similar to the one we saw in the previous tutorial. After specifying the URL and the Headers we send a Get
request to the API. The if error then do
block is for basic error handling and should not be omitted. To display the text of the joke itself we get the joke
property from the response object.
GET
https://icanhazdadjoke.com/
Once the joke is displayed on screen we can temporarily "deactivate" the Get Joke button. This serves two purposes. First of all, it gives the user a moment to read (and appreciate) the joke and secondly it prevents users from making multiple requests to the API per second by repeatedly clicking on the button. In the example below we add a pause of 5 seconds, which means that at most a user can request 12 jokes per minute. This still a good number of jokes, and a lot better than not having any pause at all.
Finally, for a bit of visual interest, we add in a random emoji reaction. This is obviously a pretty simple thing to do, but you can easily expand on this by adding some sound effects or a laugh track to your app.
In this section we've looks at why it's a good idea to use a proper API, how to set the URL and make a GET request, how to implement basic error handling, how to convert a JSON response to an Object and pull information out of that object and finally we learned how to set API headers and implement some basic rate limiting.
In the next section we'll increase the complexity slightly and learn how to use APIs that require some basic auth or an access token before we can perform any other operations.
If you have any questions about this tutorial, please post them in this topic over in the Thunkable Community
Remix link:
According to , icanhazdadjoke.com can be used as an API for fetching a random joke, a specific joke, or searching for jokes in a variety of formats.
Name | Type | Description |
---|
Community Link:
Accept | String | Request a response in HTML, JSON or plain text format. Defaults to text/plain if not specified. |
User-Agent | String | A good user agent should include the name of the library or website that is accessing the API along with a URL/e-email where someone can be contacted regarding the library/website. |