DEV Community: Airkit

How to build a Calendly clone using Airkit's low code platform

Ismaen Aboubakare 🥑 — Mon, 17 Oct 2022 21:54:21 +0000

I use Calendly a lot in my day to day to book meetings that fit within my schedule, and as I continued to use it, I wanted to see if I could build the core functionality of the tool in Airkit. There were a few things I wanted to make sure we could do in Airkit, which is connect to both google calendar and zoom, be able to programmatically get all of the free slots on my calendar in 30 minute increments, and programmatically generate zoom links attached to calendar invites.

With that in mind, this tutorial will walk through the steps on how to build a Calendly clone, integrated with Google Calendar and Zoom.

Application Overview

When a user visits the application, they will see a calendar with an availability list of 30 minute appointment slots where they can choose and confirm an appointment time of their choice.

Once the user selects the time slot. They will be presented with a form where they enter details about themselves (name and email address), add additional guests, and a message for the meeting. When they click on Schedule Event, Airkit will then create an appointment, send out meeting invitations to all participants along with a Zoom Meeting link.

You can check the application out here: https://app.airkit.com/calendly

Prerequisites

To build along with this tutorial, you will need a few things to get started:

Creating APIs for the Google Calendar and Zoom Meetings

Let’s start with the Google Calendar API. One of the first things you will need to do to get started is create a project in the Google Developer Console. You will need to create a new project called Calendly Airkit and then select it. Next add the Google Calendar API.

After enabling the Google Calendar API, you will need to configure the Credentials with an OAuth client id.

Provide the OAuth consent screen with the appropriate information and then you will need configure any scopes which are necessary for the Google Calendar API to work with this newly established Project:

Google Calendar API – /auth/calendar
Google Calendar API – /auth/calendar.readonly
Google Calendar API – /auth/calendar.events

Now are you able to create the OAuth Credential. You will need the redirect URI which can be found in this doc. Because my organization is in the US region, I use the below redirect URI.

“`

https://us.api.prod.airkit.com/internal/sessions/v1/auth/callback

“`

Next let’s configure the Zoom Developer API. Like Google, you will need a Zoom Developer account. You will be creating an OAuth app type. The app will be an account level application.

You will be using the information from the App credentials later. Like before refer to the Custom Integrations documentation for the URL information for Redirect URL and Allow List. Now you are able to create the application. Finally you will need to add Scopes:

View and manage all user meetings

All of our integrations setup on Google Cloud and Zoom are done and ready to to be integrated into Airkit.

Creating the Integration

Now that you have the API integrations setup with Zoom and Google Calendar, it’s time to create the custom integration within our Airkit application. In the Airkit Console, go to the Integration tab. We will be creating two custom integrations. First, we will create a custom integration with Zoom and then will create a connected account to our application there. Next, we will repeat this process again with Google Calendar .

Zoom Integration

Create a new Custom Integration, with a name and key that you indicate an integration with Zoom. The authentication type we are going to use is OAuth 2.0. The Integration Parameters are client_id and client_secret.

The OAuth2 Configuration will be using the following configuration parameters listed below and shown in the sample:

Authorization Grant Type: Authorization Code
Access Endpoint: “https://zoom.us/oauth/token”
Access Token Verb: POST
Authorization Endpoint: “https://zoom.us/oauth/authorize”
OAuth Scope: meeting:write:admin
Client ID: {client_id}
Client Secret: {client_secret}

The Auth token configuration will be the following configurations:

Token Parameter: Header
Token Parameter Name: Authorization
Token Parameter Value Template: Bearer {token}

Google Calendar Integration

Create a new Custom Integration, with a name and key that you indicate an integration with Google Calendar. We will follow similar steps as done for the Zoom Integration. The authentication type we are going to use is OAuth 2.0. The Integration Parameters are client_id and client_secret.

The OAuth2 Configuration will be using the following configuration parameters listed below and shown in the sample:

Authorization Grant Type: Authorization Code
Access Endpoint: “https://oauth2.googleapis.com/token”
Access Token Verb: POST
Authorization Endpoint: “https://accounts.google.com/o/oauth2/v2/auth?access_type=offline&prompt=consent”
OAuth Scope:
Client ID: {client_id}
Client Secret: {client_secret}

The Auth token configuration will be the following configurations:

Token Parameter is Header
Token Parameter Name is Authorization
Token Parameter Value Template is Bearer {token}

Refer to this snippet of the video on how to pair the connected accounts for Zoom and Google Calendar API or refer to this document on Connected accounts.

Functionality through Data Flows

Now we have the integrations ready for use in the Airkit Application, next we will need to build out six Data Flows for the application for self-service appointment scheduling. Refer to the YouTube Video for complete details on how to create all these Data Flows.

First, we will create three Data Flows for finding all the available time slots on a particular day. The main Data Flow will be called “Get Free Slots” and then we will create two additional supporting Data Flows called “Merge Objects” and “Generate 30 Min Slots”.

Get Free Slots Data Flow: We will be setting the appointment window starting time and ending time, finding the existing appointments via the Google Calendar API, and creating a list of 30 minute available time slots.

Google Calendar API expects the date to be in RFC 3339 format. We will need to use the following Airscript function: FORMAT_DATETIME in order to format the date into RFC 3339.

We can use this FORMAT_DATE Airscript in a Transform Function for both the Start of the Day and End of the Day Variable.

<https://support.airkit.com/reference/format_datetime>

Now we will need information from Google Calendar API to find the busy times so we will leverage the integration we set up already. In order to make this request, we will use HTTP Request Data operation and use the following settings:

Service: Google Calendar API
Method: POST
URL: “https://www.googleapis.com/calendar/v3/freeBusy“
Content Type: “application/json”
Body will use results from previous Data Operations show in the screen shot below

The resulting busy time slots will look like the following:

Merge Objects Data Flow: Since we have a few time slot objects, we will need to bring some different object data together and we will create and use another Data Flow called Merge Objects. This Data Flow will use the Airscript Function [MERGE_OBJECT](https://support.airkit.com/reference/merge_objects). Refer to the YouTube Video for more details on this Data Flow.

Additionally there will be some additional time formatting needed to produce a list of 30 minute available time slots. Key Airscript functions will be TIME_FROM_FORMAT, UPDATE_TIMEZONE, and DATETIME_FROM_FORMAT refer to the documentation to learn more about these functions.

Generate 30 min Slots Data Flow: To generate a list of available time slots, we will create another supporting Data Flow called “Generate 30 min slots”. This Data Flow will take two inputs of start_time and end_time and create an object with a list of slots in 30 minute increments. In order to accomplish the list, use a Query Expression to create the list.

The list of time slots will be used later when we build the Airkit application.

Now we will create the last three Data Flows which will schedule the Calendar event and create a Zoom Meeting. We will create another main Data Flow called “Schedule Event” and two supporting Data Flows: “Create Zoom Meeting” and “Create Google Calendar Event”.

Create Zoom Meeting Data Flow: Let’s build this Data Flow! This Data Flow takes an input of starting time and a list of emails and then makes a HTTP request to Zoom for the meeting information.

We will use the Zoom API integration we configured before and will use the HTTP Request Data operation with the following settings:

Service: Zoom OAuth API
Method: POST
URL: “https://api.zoom.us/v2/users/me/meetings”
Content type: “application/json”
Body will need the following parameters modified:
- “schedule_for” :
- “Meeting_invitees” : Use a query expression to all the emails to send invites to
  - FROM email IN list_of_emails SELECT { “email”: email }
- “start_time” : Use the start time and format appropriately for Zoom
  - “{{FORMAT_DATETIME(start_time, “yyyy-MM-ddTHH:mm:ss”)}}”

The result can be customized accordingly with a Transform operation and then sent back to the “Schedule Event” Data Flow to be used in the “Create Google Calendar Event” Data Flow.

Create Google Calendar Event Data Flow: Let’s build it! This Data Flow takes the input of the following variables: summary, start_time, end_time, list_of_emails, and a description. And then makes a HTTP request to Google Calendar API to create a Google Calendar Meeting.

We will use the Google Calendar API integration we configured before and will use the HTTP Request Data operation with the following settings:

Service: Google Calendar API
Method: POST
URL: “https://www.googleapis.com/calendar/v3/calendars/primary/events?conferenceDataVersion=1″“
Content type: “application/json”
Body:

{ “summary”: summary,

“start”: { “dateTime”: FORMAT_DATETIME(start_time) },

“end”: { “dateTime”: FORMAT_DATETIME(end_time) },

“attendees”: FROM a IN emails SELECT { “email”: a },

“description”: description}

Schedule Event Data Flow: Let’s build it now! This is the main Data Flow which brings all the necessary data together to create the Google Calendar Event. The Input data variables are the following: selected_time, name, email, list_guest_email, and preparation notes which all will come from a web page form built later in the Building Airkit Application section. See the screenshot below to see how the Data Flows are configured or continue to watch the Youtube Video to see how this app is built.

Building the Airkit Application

Now we have the integrations and Data Flows ready for use in Airkit Application, next we will need to build out the application for self-service appointment scheduling.
In Journey Builder, add a Visit a Link Trigger to start the application, and add a webflow in the first Journey step. Then in Web Builder, we will make three Web Pages. On the first page, a self-service appointment scheduler, we will add the following key controls: Label, Container, Date Picker and Container List with two Buttons. Make sure you label all the controls appropriately.

The Web Page Tree should look like the following example:

After you add these controls you can configure labels appropriately similar to what is shown in the Youtube Video or the screenshot below:

Next, we will configure the controls for the Date and Time Slot Selection. First we will configure the Date Picker control. You will configure the Control Properties as shown below to get a one month layout.

The selection of the date has a concurrent action of calling a Data Flow which gets all available time slots for that particular day. We use the “Get Free Slots” Data Flow, which will extract information from Google Calendar. See the screenshot for the variables to update.

The variable session.availability will have all the time slot data which will populate the buttons in the Container List control. The application will show a list of buttons with the available time slots.

Once a time slot is selected and confirmed via the Confirm Button control, the application will move to the next Web Page “Enter Details and Confirm”.

On the second page, “Enter Details and Confirm”, we will create a scheduled event form where a user can create a meeting, add guests to the email guest list, add any notes to the meeting and then schedule the appointment. We will be adding another set of controls: Container, Label, Text Input, Text Area Input and Button. Make sure you label all the controls appropriately.

The Schedule Event button action unifies all the inputs from the initial page and current page via the “Schedule Event Data Flow” in order to create a Google Calendar Event with a Zoom Meeting. See the screenshot below:

After the event is scheduled, the user is sent to the Thank You page.

On the final page, a Thank you page, add a label which thanks the user for scheduling an appointment.

Wrap Up

Hopefully this walkthrough has been a helpful guide on how to create a calendly clone on your own.

Even this build has room to add additional functionality! You could upload additional documents for the meeting to the calendar invite via the File Upload control. You could change the video conference link by creating a new API integration with Microsoft Teams or any other video conferencing service. Try adding new features of your own and let us know what you build!

Cat Trophy Kingdom: Building a video game with Airkit’s low-code platform

Chandra — Tue, 11 Oct 2022 22:09:51 +0000

Cat Trophy Kingdom: Building a video game with Airkit’s low-code platform

A few weeks ago, in preparation for releasing version 18.1 of Airkit, some coworkers and I were stress-testing the new animation functionality. We started with the basics, things we imagined might be among the most common use cases: building out a customized progress bar, associating an animation with the appearance of a warning label so as to draw more attention to it. Then, with the cadence of a joke, someone asked, “Can we animate a chicken crossing the road?”

The answer, as it turned out, was that we could. Easily. It took less than ten minutes and required only two assets: a JPEG of a road at dusk, and a GIF of a dancing chicken.

I was in love. In the span of less than ten minutes, this road-crossing chicken had become my muse, for it made me realize two things:

Airkit’s animation functionality can be combined with GIFs to create the illusion of complex motion with very little effort.
If you can animate a chicken moving in one direction, you can apply the same principles to move any character in any direction.

And once I had realized those two things, the conclusion was inevitable. I would use Airkit to build a video game.

In around 48 hours, I had put together Cat Trophy Kingdom, a short CRPG (Computer Role-Playing Game) where you earn the crown of Cat King by knowing trivia about how to build in Airkit.

(Pictured: A brief snippet of Cat Trophy Kingdom. Click here to play!)

This is absolutely not the sort of thing Airkit was optimized to build, and so while I did have to implement a few hacky work-arounds, I was overall pleasantly surprised by how quickly I was able to throw together something so far beyond the scope of CX automation.

Let me tell you about how I did it.

Building the Castle

When I first started building, I had only a vague idea of how I wanted the game to go, and I wasn’t entirely sure what would be feasible to complete in the 48-hour period I had given myself. I started with the basics: the game needed a protagonist.

After considering the constraints I was working within, not least of which was time, I decided to make a GIF of a little yellow cat held up by balloons. Out-of-the box animation in Airkit is smooth thanks to the automatic incorporation of easing, which looks good in combination with gentle bobbing. A floating means of transportation also meant that I didn’t need to worry about timing and configuring a complex walking cycle.

Almost immediately, I began to mentally refer to this cat as the “PC,” which stood simultaneously for “Player Character” and “Player Cat.”

Now that I had my PC, I needed to create a space for them to explore. I’d already decided that I wanted to set the game in a castle, so I found a picture of some masonry that could pass as a castle floor. This, I set as the background for the Container that would hold all the furniture and characters that would exist in my digital castle, starting with my PC. For the sake of organization and scalability, I put the Image Web Control containing the GIF of my PC in its own Container, which nested under the broader Container encompassing the whole castle floor. It was to this sub-Container that I would apply animations. I was kicking around the idea of having visible objects float alongside the PC under certain circumstances, and I didn’t want to have to animate them individually.

The PC needed a way to move about the castle floor, not in a single direction, but four: up, down, left, and right. These would dictate movement along two dimensions: the vertical and the horizontal. I defined two variables to keep track of the cat’s placement along these dimensions: x, to track distance in pixels from the leftmost border, and y, to track distance in pixels from the upper border. So that their values could be easily changed by simple addition and subtraction, both of these variables were Numbers. (This whole setup was based off of the standard Cartesian plane, with the orientation of the y axis reversed to avoid having to work with negative margin values.)

Upon updating the Airkit platform to v18.1, animations are incorporated into the preexisting UI of the platform by tying them to the styling properties of Web Controls. While styling properties are defined statically by default, they can also be defined in terms of variables, and changes to the values of such variables are reflected as changes in the appearance of the Web Control. Applying animations to the variable styling properties smoothens the transition. The Container that held my PC, then, would have varying values of the left and top margins, which would change according to the values of x and y respectively. (Because I had defined x and y as Numbers, I needed to use the FORMAT_NUMBER function to convert them into a string the margin expression could parse. The left margin was defined as “{{FORMAT_NUMBER(x, “”)}}px”, and the upper margin was defined as “{{FORMAT_NUMBER(y, “”)}}px”.)

I then animated changes to the margin so that the transition between different margin values would take place over the span of a second:

The values of x and y would be changed by pressing Buttons, which would trigger the Set Variable Action to change the value of x or y as appropriate.

The values of x and y would change by adding or subtracting numbers to or from their initial value, so once the Buttons were configured, I set up the initialization of x and y. Upon navigating to the Web Page on which I was building my castle, two Set Variable Actions would be fired, setting first x to 0 and then y to 0.

(Pictured: A fancy cat doing a fancy dance.)

By this point, I had built out something only marginally more complicated than the chicken crossing the road, and it was becoming clear that I was going to have to find ways around Airkit’s core assumptions if I wanted to get much further.

Airkit apps are designed to be easily accessible on screens of any size, browser or mobile. Out of the box, Web Controls don’t have a set pixel size; they scale automatically to account for the size of each user’s screen. When defining dimensions within styling properties, Airkit parses input given in either pixels or percentages. “50px” means fifty pixels, and “50%” means fifty percent of the Container the Web Control is nested under, which by default depends on the size of the screen being used to view the app. In most of the common use cases, the things Airkit was optimized to build – form digitization, call deflection – it’s considered best practice to define lengths in terms of percentages when possible, allowing the UI to appear standardized regardless of screen size.

As you may have already noticed, I was not doing this. I was already defining my PC’s movement in terms of pixels, not percentages. To better create the illusion of various images interacting with each other, I wanted fine control of each image’s location down to the pixel.

So I redefined the size of the castle floor Container, overwriting the defaults that would adjust the size to fit the screen it was displayed on. This meant I had to pick, then and there, what sort of screen ought to be used to play the game, and I decided to make a computer game, not a mobile-friendly experience. I set the size of my castle floor Container to exactly 1200 pixels by 900 pixels and tinkered around with the Page Layout so that the layout would remain the same regardless of screen size. This would render the game effectively unplayable if someone tried to access it from their phone, but that was a sacrifice I was willing to make.

This also meant I had to put the Up, Down, Left, and Right Buttons in a Container and adjust their placement so that they were more obviously visible on a computer screen.

(This was my first time changing the position of a Container from Relative to Absolute, but it would not be my last.)

My PC now had a defined and finite castle floor to explore. Pressing the Up, Down, Left, and Right Buttons would move the PC some number of pixels in the desired direction. How far each Button would move the PC was entirely arbitrary, but as long as the size of the change stayed consistent, it imposed a conceptual grid structure on occupiable spaces. The PC would only be able to reach spaces divisible by the number of pixels it could move at a time.

Here is the convention I settled on. The PC itself would occupy a 100 pixel by 100 pixel Container, which would move in 100-pixel steps. The coordinates “defining” the position of the PC would be defined by the pixel at the upper left of the 100 pixel by 100 pixel Container. For instance, given x = 0 and y = 0, the PC would appear at the upper left corner, apparently filling up the space defined by all values of x between 0 and 99, and all values of y between 0 and 99.

(Pictured: The grid as it exists in my imagination.)

Upon saving and previewing my progress, I was delighted to see my PC move about as intended. However, the lack of limitations surrounding the castle floor quickly became apparent: pressing the Up Button too many times sent my PC floating up and away into the limitless void, never to be seen again.

(Unless I pressed the Down Button an equally ludicrous number of times.)

I needed to impose further restrictions on the spaces my PC could occupy: I did not want them to be able to leave the castle floor, so I decided to create a new UDF (“User Defined Function”) to check if a proposed destination was within the established parameter. The UDF, designated ISINSIDE#USER_FUNCTION, took two Numbers, x and y, as input, used the out-of-box IF function to return the boolean TRUE if x and y described a position inside the castle, and returned FALSE if otherwise:

By making this a UDF, I was able to reuse it easily, and I incorporated it into the Action Chains associated with the Up, Down, Left, and Right Buttons. Now, before resetting the value of either x or y (as appropriate), each would run a Conditional Action to check if the new coordinates were inside of the castle. If they were, the cat would move as asked. If not, the cat would stay still.

This accomplished the illusion of the cat being unable to pass through the implied walls.

So now I had my PC, and the PC had a room to explore. Now was time to fill the room with characters and furniture for my PC to interact with.

Interacting with Characters and Furniture

The process of building my castle floor had solidified two key ideas:

My 1200 pixel by 900 pixel castle floor was also a 12 by 9 grid, in which my PC could occupy exactly one square at a time (and each square was defined by the coordinates of the pixel in the top left corner). The same principles could be applied to define the locations of furniture and other characters.
Keeping track of the location of each character or piece of furniture could be done via UDF, and each UDF could be used in an additional IF ELSE statement associated with the Conditionals tied to the Up, Down, Left, and Right Buttons.

The first character I wanted to establish was the Cat King, as the PC’s interactions with him would make up a core part of the game. I whipped up a sprite for him, which I confined to its own 100 pixel by 100 pixel Container. His placement on the board was defined using the same conventions as I had applied to my PC, only no variables were required:

This placed the Cat King in the location described by x = 800 and y = 100.

(Pictured: The placement of the Cat King in my imagination.)

I didn’t want my PC to be able to enter this occupied space, so I applied a similar strategy to the one I had used to prevent my PC from leaving the castle floor.

First, I created a new UDF, called ONCATKING:

Then, in the Action Chains associated with each of my Up, Down, Left, and Right Buttons, I added an IF ELSE branch and used my new UDF to trigger different behavior in cases where the PC tried to occupy the same space as the Cat King. Now, before resetting the value of either x or y (as appropriate), it would not only check to see if the new coordinates would be inside the castle, if they were, it would also check to see if the new coordinates would put the PC in the same square as the Cat King.

And if so, I wanted to open a modal.

Up until this point, I’d been working within a single Web Page, but now I needed to make a new Web Flow, which I would open as a modal in order to bring up the Cat King’s dialogue and allow the player to select how they wanted to reply. In my early iterations, the Cat King’s dialogue was a simple Label, and the dialogue options were simple Buttons, which might close the modal or navigate to another Web Page depending on the nature of the reply. For a bit of polish, I shortly after incorporated additional styling components, such as a drawing of the Cat King’s face, and a talk balloon gif from Giphy. After nesting some additional Containers and playing around with Airkit’s out-of-the-box styling properties, I found a layout I liked, which I would later re-use (by copying and pasting) when creating additional character interactions.

As I added more possible character (and furniture!) interactions to my game, I repeated this process in at least a dozen different forms. For each new interaction, I would place the sprite, make a UDF to test if the space was occupied by the sprite in question, and then I would incorporate the UDF into new IF ELSE statements in the Conditionals associated with the Up, Down, Left, and Right Buttons.

And yes, these Action Chains did grow very, very long, very, very quickly.

(Image Caption: This Action Chain is too long for my computer screen to even display all at once.)

Key insight: Using UDFs to keep track of occupied spaces was an even better idea than I first thought.

When I first made a UDF to keep track of whether a proposed location was inside the castle, I had originally only been thinking to save myself from writing x < 0 OR x >= 1200 OR y < 0 OR y >= 900 four separate times (one for the Conditional associated with each of the Up, Down, Left, and Right Buttons). I made UDFs to keep track of each occupied space for the same reason.

But as I placed more and more characters and pieces of furniture on the castle floor, I was sometimes struck by the urge to rearrange them, often for aesthetic purposes, more rarely to place the obstacles so that the way around them seemed less ambiguous. Regardless of why, moving the furniture meant both redefining the margins on the Container holding the furniture in question, and redefining the Conditional that managed the PC’s interaction with the furniture.

And when I needed to do that, I was glad I had a UDF that served as the single source of truth for the location of an interaction. Changing the UDF so that it referenced the new location of the occupied space was all it took to update every relevant Conditional, across every Button.

Tracking Progress and Interactions

Now I had built my castle and filled it with characters and furniture for my PC to interact with. There was one last key component of the game to work out: tracking the PC’s progress.

Game-play-wise, the flow I had in mind was not complicated: the PC would talk to the Cat King, who would tell them to bring him a Cat Trophy. Then the PC would talk to the Court Mage, who would give them a riddle, and once the PC answered it correctly, they would get the Cat Trophy. Then the PC would bring the Cat Trophy to the King, winning the game.

The same modal could not be opened every time the PC went to the location of the Cat King. One modal needed to open when the PC did not have the trophy, and a different modal needed to open when the PC did.

I wound up tracking these sorts of interactions with Booleans. For instance, I created a Boolean variable called have_trophy, which was initialized as FALSE at the start of the Journey but reset to TRUE when the correct Button was pressed to answer the court mage’s riddle.

More IF ELSE statements were added to the Conditionals associated with the Up, Down, Left, and Right Buttons, and some of the IF ELSE statements that I had already made grew more complicated. For instance, the Condition that needed to be met by the Left Button in order to open the Cat King’s initial modal, where he told the PC to bring him a Cat Trophy, used to look only like this:

and now it looked like this:

(The variable have_trophy is written as session.have_trophy here because it is a global variable. I made most of the progress-tracking Booleans global variables because changing their values was typically done in modals, and the modals, as separate Web Flows, are different Activity Groups from the Web Page that held my castle floor.)

Once my PC had earned their trophy, in addition to opening a different modal when interacting with the Cat King, I also wanted to have a little trophy float next to the PC’s sprite as they moved about the castle floor. As you may recall, I’d been kicking this idea around for a while, and I was prepared for it. The image of my PC was already inside a Container, and I could easily add the image of my trophy to the same Container. After a bit of resizing and tinkering with the margins of the trophy image until I was satisfied with its placement in relation to my PC, I toggled to the Advanced tab of the Inspector, and set the Is Visible field so that it was equal to session.have_trophy.

Now the trophy would only appear visibly next to the PC if session.have_trophy was equal to TRUE. And, because the movement animation had been applied to the Container both the PC and the trophy shared, I did not need to define any more animations to account for it.

(Pictured: A fancy cat doing a fancy dance with their new Cat Trophy. By this point, I had changed the colors of the buttons for aesthetic purposes.)

Key Insight: There’s a lot you can do when you track interactions with Booleans

Once I started tracking whether or not my PC had earned their trophy with the simple Boolean have_trophy, I realized I could do two extremely powerful things:

Interact differently with objects or other characters based on the variable’s value.
Render images visible or invisible based on the variable’s value.

These two things applied no matter what variable I made or what interaction I used it to track. I used these principles to create new ways for the PC to interact with their environment. Soon, my PC could do all of the things real cats can do: destroy a plant, hide in a box, and cast spells. Some of the Airscript expressions grew lengthy, but the underlying logic was always the same.

Conclusion

By this point, the 48-hour period I had given myself to build out this game was drawing to a close. I added a little more polish – an opening Web Page so that each player could name their PC something different, a Web Page that allowed players to crown their PC upon becoming Cat King – and then my work was done.

Given that Airkit isn’t a video game creation platform, I was quite happy with the end result. The tools Airkit provides might be structured with particular use cases in mind, but they’re also versatile enough that I was able to work around any out-of-the-box functionality that didn’t fit my use case, and I made much more progress in this 48-hour period using Airkit than I would have if I had tried to construct the same game from scratch.

While the gameplay was relatively short and simple, in a way, this worked to my advantage: after my 48-hour flurry of artistic verve, I was excited to show of my creation, and the fact that a single playthrough didn’t require much time commitment meant that it was easy to coax everyone into giving it a try.

(Pictured: My cat, after having been forced to sit through the dozenth playthrough of Cat Trophy Kingdom. He just became Cat King again!)

30 Minute Builds: Google Lens Rebuild with Airkit

Brooks Naylor — Thu, 25 Aug 2022 20:14:00 +0000

A standard mental exercise that all software engineers and web developers inevitably participate in is looking at a piece of software or an application, and thinking to themselves: “How would I make that?” It can come from either a stylistic interest, wanting to see what their take or spin on the product could be, but it could also come from a place of intellectual curiosity, wanting to walk through their own steps on developing a product they see in front of them.

As a web developer, I have started to try my hand at this more and more with low code tools, and wanting to see just how much faster building an application with them can be in the hands of an engineer. So I decided to take a stab at recreating a specific feature of Google Lens, which is to create an application that takes in an image with text present in it in a foreign language, and to translate that for the user into english.

Feel free to follow along with this tutorial, or, if you would prefer, follow along with the Youtube version of this build below!

Application Overview

The application itself is deceptively simple to create. The front end is a simple page with a file upload control, and a few variable dependent controls that would display the results of the returned data from Google.

It requires an integration with a Google Cloud application, however, with both the Google Cloud Vision and the Google Cloud Translation APIs enabled. The Data Flows would then use the Google Vision OCR capabilities to detect text in an image, and would then send that text to the Google Translation API.

Prerequisites

To build along with this tutorial, you will need a few things to get started:

Access to the Airkit Studio
A Google Cloud Platform Account

Creating the Google Cloud Application

The first step in building out this application is to create the Google Cloud Project we will be integrating with. First, create the project in the organization that you have access to. Once it is created, you first need to build the OAuth Consent Screen. The app type is “External,” and from there you’ll need to fill out the application information you’ll be displaying to users. No need to fill out any test users or scopes for the moment, we’ll be finishing those portions later in the build.

Next, type either “translation” or “vision” into the search bar at the top of the cloud console. You’ll then navigate to either the Cloud Translation API or the Cloud Vision API, depending on what you searched, and click the Enable button on both. Fair warning, Google Cloud Services may require you to input a credit card at this time. For the purposes of this build, we won’t be exceeding the basic tier version of these API endpoints, but feel free to watch the youtube video linked above to follow along if you would like to avoid storing your credit card.

Once both API’s have been enabled, we’re navigate back to the console using the hamburger menu in the top left, and click on the API’s and Services section. From here, we are going to be creating the authorization credentials for our integration. Click the Credentials option on the left, and click “Create Credentials” at the top of this page, and choose “OAuth Client ID” from the list of options. The application type is going to be “Web Application.” This will populate the fields we need to fill out for our OAuth Integration with Airkit.

The only required inputs here, other than naming your application at the top of the page, are the specific Airkit Authorized Redirect URI’s for this application. You’re going to add both “https://app.airkit.com/internal/session-gateway/v1/oauth/callback” and “https://us.api.prod.airkit.com/internal/sessions/v1/auth/callback” as redirect URI’s here, and then you’ll click create. This will generate a Client ID and a Client Secret for your application! Be sure to copy and paste them somewhere, because we will be using them in our custom Airkit integration.

Creating the Custom Integration

Back in the Airkit console, It's time to actually create the custom integration we're going to be using to connect to our Google application. In the integrations section of the console, create a new Custom Integration, and create a name and custom key for the integration. For authentication type, select OAuth 2.0. Then add two Integration Parameters, “client_id” and “client_secret”. Beneath those, select Authorization Code under the grant type. The token verb will be POST, and the token endpoint will be “https://oauth2.googleapis.com/token”. For Authorization Endpoint, put “https://accounts.google.com/o/oauth2/v2/auth?access_type=offline&prompt=consent”.

Now under scopes, we need to put two different scope URLs here, since we are accessing two differently scoped APIs within the same Google application, so separating them with a single space, put “https://www.googleapis.com/auth/cloud-vision https://www.googleapis.com/auth/cloud-translation”. The next two fields should be “Client Id” and “Client Secret”, and in these fields you will paste in those values you received from Google Cloud.

Finally, set up your Auth Token parameters using the example below.

Click Create, and our custom integration is ready for use! We’ll next establish a connection with our Google application. In the Airkit Console, under Connected Accounts, click Create New and select the integration we just made after naming the account. The integration parameters we added should now appear here as fields to fill out. These will also be the Client ID and Client Secret that were generated for us by Google. Once you click create, the OAuth Consent screen you made in the cloud console should appear. Accept the request, and the integration is ready for use!

Building the Airkit Application

Create a blank application and go to the Airkit Studio. Nn Settings, ddd the Google Integration we created in the Integrations section of the Builder, and select the Connected Account in the available dropdown. This allows our Airkit application to now interact with the Box application we created.

Next, add a Visit a Link Trigger in the Journey Builder, and in the first Step of the Journey add a blank Web Flow. From there, go to the web flows builder, and add a Title and some instructions for the user using Label controls. Then, add a File Upload Control, and inside the control add a Button Control. Underneath this, add a Media Control, and below that two different label controls. Change the top label control to say “Translated Text.”

In the Variable Tree, create two Activity level variables. One will be an asset variable called “uploaded_image,” and the other will be a text variable called “result.” Change the value of the URL in the Media Control to “activity.uploaded_image.downloadUrl,” and change the value of the last Label to “activity.result.” Your application should look something like this:

Functionality through Data Flows

The last step is to build the Data Flows we will be using to hit the two different Google API endpoints. Create two different blank Data Flows in the Connections Builder. In the first one, which will be the Data Flow that uses the Google Vision endpoint, add an Asset Input called “uploaded_image.” Add an HTTP Request Data Operation, and under service make sure the Google Integration you’ve added has been selected. The method for this operation is POST, and the URL is "https://vision.googleapis.com/v1/images:annotate", according to the Google API documentation. Under Body, follow the example below:

Add a new Transform Data Operation underneath this one, and in the expression follow this example below:

This will return a List, or an Array, of all the words found in the image we sent to the Google Vision API. The last step is to add the Run Data Flow Data Operation, and here is where we will be running the second Data Flow we created, which will hit the Google Translate API. Pass in the transform result, which should be a list of text.

In the Translate Data Flow, let’s add an input called “words” that is a List of Text (feel free to paste the transform result from the previous page so we have something to work with here). Next, add a Transform Data Operation, and in the expression write JOIN(words, “ “). This will give us a single string of text to send to the Translate API. Next, add an HTTP Request Data Operation, which will look very similar to the operation from the previous Data Flow, except the URL will be "https://translation.googleapis.com/language/translate/v2". For the body, follow the example below:

Next, add another Transform operation, following this example to extract the results we need from the Translate API.

Finally, make this most recent transform the return value at the bottom of this second Data Flow. Back on the first Data Flow, make the return value here the connectionOutput variable, which will contain the results of the second Data Flow.

To wrap it all up, return to the Web Flows Builder and select the File Upload control on the left. Click the Actions tab in the inspector, and on the On Upload Finished Event, add first a Set Variable Action to assign a value to the variable bound to the Media Control URL value, and add a Run Data Flow Action to run the Google Vision Data Flow, and make the output binding the “activity.result” variable.

Wrap Up

Once building out the application, a few thoughts initially came to mind. The first was to stress test the application as is without much tweaking to see how well this first iteration performs. The answer ended up being: fine? I went around my house with my phone with the app on screen and tested its ability to translate ingredients in my pantry. At its base level, the OCR we’re using still captures special characters, and has a hard time organizing text that isn’t laid out in an organized way, so the full text string it detects can be a bit disorganized depending on the image it analyzes. In the next iteration, I’m going to dive more into the Cloud Vision API documentation, and see if there are preventative measures against this, and I’m going to tweak the conditional logic in the Transformations I have in my Data Flows, to see if I can prevent this from happening.

The second thought was just the vision of potential here. I instantly thought about new layouts for the front end, adding selectors for language result options, and better ways to more effectively lay out the information being taken in and being spit out by the application. I can’t wait to keep tinkering with this app and more like it!