this is undefined
index-7896a516.js:1 TypeError: Cannot read properties of undefined (reading 'isManaging')
    at index-7896a516.js:1611:43125
    at wC (index-7896a516.js:1:25984)
    at Proxy.<anonymous> (index-7896a516.js:1611:43005)
    at xu (index-7896a516.js:1:15746)
    at Ef.W [as fn] (index-7896a516.js:1:40924)
    at Ef.run (index-7896a516.js:1:4878)
    at P.S.update (index-7896a516.js:1:41205)
    at P (index-7896a516.js:1:41231)
    at b (index-7896a516.js:1:40022)
    at y (index-7896a516.js:1:39819)

>>LATEST: The website application is successfully deployed and hosted via Netlify at https://terminarium.netlify.app 🚀. The root case of this issue was: an improper use of this keyword in some of the components and an improper path specifications for the images used in the web-application. Now, the web-application is fully functional and can be used as intended.

Having learned an enormous amount on web app development using Vue.js since the start of Sprint 2, the team members that started with no prior knowledge have come a long way. However, CSS styling still posed a challenge, two issues in particular: First, dynamically adjusting the UI elements to varying screen sizes has continued to be inconsistent for some pages. Even when seemingly following best practices learned from the considerable educational resources available online, the elements behave in a fickle way from screen to screen. Secondly, styling the background image has also mystified us, especially when it comes to making it repeat vertically on the Y axis. It has been a challenge to make scrolling intuitive when the size of the elements on the page exceeds the viewport of a particular screen. Both issues are of course a consequence of the very short time which was allocated to the Frontend team to acquire and apply the necessary Vue.js and CSS knowledge to develop the application. Ultimately, we have addressed them to a level that is satisfactory and that meets the standard of quality we aim to deliver in the allotted time frame. In the process, we have importantly obtained a new level of understanding of the underlying frameworks.

A core focus of the team was to deliver a product that is above all useful by virtue of its practicality. It became apparent throughout development that the Wio Terminal was a very limited device that hindered this quality goal. Specifically, it was realized that to modify any aspect of the network credentials used for establishing an MQTT connection, the user would have to modify the program sketch's source code, recompile and reupload it to the terminal. This severely impacted the portability of the product, making changing WiFi networks exceedingly tedious. Given the hardware limitations, the only possible solution was to allow users to modify these values using the interface of the Wio Terminal itself. Consequently, a deeper challenge arose: how?

The solution we devised was comprised of two stages: The first was a screen that accepted user input by drawing an onscreen keyboard that could be navigated using the 5-Way Thumbstick Switch. Creating this keyboard required a culmination of all previously gained knowledge, both from using the terminal's drawing functions and from learning about memory allocation in C++. This solution eased the problem of inflexible changing of WiFi networks.

The user input screen did not, however, erase the problem. Due again to the hardware limitations, the modified network details would not be saved after powering the Wio Terminal; the hardcoded default values would need to be remodified. This still did not meet the quality of life standard we aimed to provide. It was therefore decided that the second stage of tackling the problem was enabling data values to persist after powering off. The easiest method was to save the data to an SD card, however it was deemed unsuitable to require users to insert an SD card for this basic functionality. Therefore, after much research we found it possible to save data to flash storage using a further external library. Due to the limited number of write cycles permitted by the hardware, a compromise needed to be struck, and therefore the user is encouraged to use it but warned of it and given the option to opt-out of it during the program installation procedure.

As of Sprint 3, the complexity of the Wio Terminal's program sketch had peaked, and when the introduction of new features necessitated some structural changes in the existing code, this would often lead to new bugs. While syntax errors pointed out by the compiler were no problem to fix, more often these bugs were hidden unintended behaviors. A big challenge therefore was debugging in these instances. The beginner-friendly design of Arduino IDE, a quality that made it an attractive choice to us (as explained in the Technical Stack and Tools section), means that the IDE does not have a built-in debugger. This, in turn, meant that we had to rely primarily on more primitive methods: leaving trace code throughout, and of course raw mental debugging, keeping track of the program’s control flow in our heads. It was attempted to switch to VSCode with appropriate Arduino extensions installed, but swapping back and forth was also considered more tedious than it was worth. We eventually persevered through this arduous process, and certainly grew from the experience of tackling the issue in this manner, but it did cost time and energy that could have been saved by a basic debugger built into Arduino IDE.

During this sprint, the team members have experienced some time overdue in the development of the project. This is mainly attributed to an illness of one of the team members whose work consisted of the development of the front-end of the application. This has caused a delay in the development of the project, which has been solved by the rest of the team members, who have taken over the tasks of the sick member. Nevertheless, the team has managed to meet the deadlines set for the completion of the project within the scope of Sprint #3.

What have we learnt? Indeed, some risks are inevitable and can not be avoided. However, the team has learnt that it is important to plan the project in such a way that it can be completed even if some of the team members are not able to work on the project for a certain period of time. This can be achieved by distributing the tasks in such a way that the knowledge of the team members is shared among the team members. This way, the team members can take over the tasks of the sick member and continue the development of the project without any major problems.

The team members have experienced an onset of stress during the last days of the sprint. For most of the team members, this has been the first intensive experience of working in a team on a project of this scale in a Git Workflow oriented environment. This has resulted in a lack of communication between the team members, which has caused some confusion and misunderstandings. This has been solved by the team members by communicating with each other and clarifying the misunderstandings, particularly as part of the daily stand-up meetings.

Furthermore, some team members continuously insisted on adding additional features to the project, which, indeed, is an initiative of good nature. However, due to the time constraints of the project, the team members have decided to focus on the core features of the project and postpone the development of the additional features (that were not part of the initial project scope) to a later stage of the project, for instance, as a hobby project.

What have we learnt? The team members have learnt that it is important to communicate with each other and clarify any misunderstandings that may arise during the development of the project. Furthermore, the team members have learnt that it is important to focus on the core features of the project and postpone the development of the additional features to a later stage of the project. This way, the team members can focus on the core features of the project and complete the project within the set time constraints without having to experience an onset of stress or inconvenience.