Unity Trello Form
Trello has risen as an often used tool in project management, facilitating Kanban-style organization. It helps teams track tasks and their progress, allowing for robust communication during a sprint. Its API is public and well-documented, facilitating its use in backend projects that seek to leverage it to connect to Trello from external applications.
Result
The Unity Trello Form is a downloadable Unity program that allows users to connect to a Trello account and report a bug by filling out the fields, including specifying a board and a list on the selected board. A card is then generated at the specified destination with a description generated by the provided data and other salient information that can be pulled using Unity.
Timeline: August 2022
Role: Designer and Developer
Tools: C#, Unity, Trello
Content
- Problem Statement
- Ideation
- Development
- Accomplishments
Problem Statement
Trello has been a pivotal tool alongside Notion in how I organized myself in college, being used in several projects I was involved in to track tasks. It wasn't until I was browsing the Work With Indies Discord server that the topic of experimenting with its API through UnityWebRequest came up as a good way to explore backend programming. Knowing how integral Trello has been to keeping a project organized, I realized something - a lot of my projects were going into playtesting and documenting those bugs has been a constant challenge. Integrating the generation of Trello cards directly into the playtest build would reduce the friction of documentation immensely.
Thus, the problem statement became:
How do we build a form in Unity that can create a card on a Trello board that can help document a bug?
Ideation
The focus on the Unity project would be on the Trello API and the Unity Web Request system. For the code architecture, I relied on scriptable objects to keep the system as modular as possible. My project was also heavily inspired by Àdam Carballo's Unity Trello system, which itself was heavily based on Ben Follington's implementation.
Development
With existing projects leading the way on how the syntax for WebRequests and the Trello API documentation being well-written, grabbing the data was actually one of the most straightforward parts of the project. Because of this, I wanted to be a little more ambitious with the project than simply showing that I could make a call to an API - I wanted a fully-fledged system that could also use GET requests in order to create selectable elements on the form, which could then be used to formulate the POST requests. This made figuring out how I could coordinate my calls for information and how to distribute the information throughout the system my primary focus.
Because of this large responsibility, I put a heavy emphasis in dividing responsibilities. I was able to use the information from the Trello API to populate my UI and then have the UI elements write to scriptable objects to store selections. At first, I had a single file that did all the communicating with the Trello API. However, I felt like having UI population code in a script that also handled the sending of cards was making the script handle too much. Ideally, I wanted the script that sent a card to Trello only receive information from whatever was selected in the forms - it should not have to hold the information of all of the boards and the lists.
This made me think about having two scripts that used the API - one that processed all the GETrequests in order to distribute them into scriptable objects, and one that pulled from the scriptable objects to create a POST request - I designated these as the "model" and "sender". Since these both needed to use the Trello API, it made more sense to me to set the key and token as scriptable objects that the scripts could pull from. This also meant less hassle if I had any other scripts that needed to use the API in the future.
One major hiccup I ran into with the scriptable object design is the retaining of information between submissions. This was because the scriptable objects still retained information across scenes; being stored on the asset-level. This was actually a challenge that stumped me for a bit because changing the value is what triggered functions in the system - this would happen if we set them to null values as well. What I did to get around the value change response was to add a reset method, which would write to the underlying protected (previously private) variable underlying the public property.
A minor issue I ran into was a warning I was getting that read "A Native Collection has not been disposed, resulting in a memory leak. Enable Full StackTraces to get more details." Initially, I thought it could be something related to all of the lists I was creating - however, these were all handled by Unity's automatic garbage collector. Research on the matter introduced me to the Dispose function, which was used to clean up resources. This thread revealed to me that the cause of the issue was the failure to dispose of the web requests at the end of their use. To fix it, I just made sure to save the data I needed in a variable before disposing of the web request, returning that variable at the end of the function. This seemed to stop the error from popping up.
Working with scriptable object events, I ran into a funny challenge due to their modularity. I found that my functions were so disconnected as to make communicating errors to the front-end difficult: Information had a one-way pipeline as none of the scripts have references to each other. The solution I came up with was to log all the errors to a scriptable object. At the end of any function that could throw an error, a function was run that checked if any errors existed and would trigger an event in response . This event then instantiated the error panel at the active screen. Checking which screen was active could be ignored because if we disable the inactive one, it will not matter that they're both listening to the signal.
Accomplishments
- Learned the basics of making web requests in Unity
- Used the Trello API to read board / list information and create cards
- Used Scriptable Objects to transfer data between components