Eficiencia de σt con respecto a otras variables oceanográficas para

One thing that was causing issues for the beginning part of development was that if you tell Flutter to re-render the screen, from an element that is no longer in the tree, it will cause the app to crash, so we had to go around to every place were we called setState (which is the function to tell Flutter to re-render the screen) and check if the element is still in the tree or not and only proceed if the element is in fact in the tree. This is moreso an issue when you are using

asynchronous operations, as these are not synced with the rest of the executions, so it could happen that once this operation is finished, the user has already gone to a different page, one which either removes or replaces the element in which the operation was executed.

Another thing that affected almost every aspect of the app handling users, including the login page, was when a variable name of a variable in the response from the http post-request sent to the server changed name, which meant that we had to rename the variable name on the frontend in every place where we referred to this variable.

4.5

Backend

The development of the backend started a bit later than the development of the frontend. Mainly so that we would have an idea of what was wanted from DYAMO but also so that we could more easily map out what we needed from the backend. The backend stands for all the data processing on the server, for instance if the app needs a list of a users conversations the backend will look up those conversations and compile a list of them, then attach the last message to each conversation as well and send the data back to the app. The app can then format this data nicely to present it to the user. This section is going to go through the development of the backend and bring up problems stumbled upon along the way and how we went about solving them. We developed the backend on an isolated server and planned to move it to DYAMOs server once the backend was done.

4.5.1 Getting started

In the first week of development of the backend we started developing a base so that it would be easy to add different API (application programming inter- face) calls to it and started planning out authentication. However, during the development of the authentication it came to our understanding that DYAMO was using WordPress as the backend for their website. So we started over and studied ways of integrating with WordPress and came to the conclusion that making our backend into a WordPress plugin seemed like the best way to go. We studied ways of how we would communicate with our plugin from the app and found out that we could register hooks to POST requests from our plugin. We felt like this was a good way to go so we settled for this method and then started looking for solutions to integrate with WordPress login system.

REST API [11]) for WordPress that added the functionality that we needed - creating a session through an API call. This solution, however, did have some shortcomings compared to the standard way of signing in, we realized later. After adding the plugin to WordPress we wanted to find a way to integrate our plugin with their plugin so that our plugin would be aware of what user is signed in. It was hard to find documentation for this on the plugin page so we read through the plugin code to try to find a way. It seemed hard to get what we wanted without changing the plugin code so we started looking elsewhere and found a solution. Our plugin could send its own internal API call to the authentication plugin and by doing so, we also knew what user we authenticated as. We later extended this functionality by making our plugin check that there is only one active session per user and invalidating old sessions when a new one is created.

4.5.3 Database design

After implementing the authentication we could start working on the other features required on the backend. But to develop these features we first needed to design the database to get a better picture of what needed to be developed. We drew some models and examples and tried to make the database tables easily extendable by for instance taking inspiration from WordPress and implementing a generic table which could store custom keys and values for users.

4.5.4 Conversations

With the database designed we could move on to developing the backend func- tionality for the core of the app, messages. The first thing we worked on was the API to create conversations and assign users to them. There are two types of conversations, group chats and normal chats. All account types except adepts can be a part of group chats, while the normal chats can only have exactly one adept and one mentor, so two users in total. In both kinds of conversations there are three supported message types, plain text messages, file attachment messages, and sticker messages (for sending keys). Another API that was added was the conversation list API, which returned a list of conversations the user is part of and a preview of the last message inside each conversation.

4.5.5 File attachments

Sending a text message is trivial since the communication between the server and client is already in text format. However, file attachments are a lot of times not stored as text, so we had to do some research on how to get files sent to the server. What we found out was that we could use PHPs built in file upload functions, which is what we did. It took some time to get working correctly but we managed to get it to work finally. When sending the file attachments to the client one big problem was that WordPress wanted to keep sending other data after our plugin was done sending the file, which made it not work properly. We

fixed this by telling PHP to terminate when the file was done sending instead of letting WordPress take back control.

4.5.6 User Info

To display the conversations properly in the app, the app needs a way to trans- late the identifiers for the users to readable text (usernames etc). So then, a few APIs for different ways of getting user data was created. Another API was also created, with a bit more restricted access - user list. This API call returns a full list of users in the app.

4.5.7 Polling

For the app to detect new messages on the server without wasting too much bandwidth and CPU time on both the users device and on the servers resources we added a polling API. What this API does is that the client device sends the identifier of the last message they have received and the API responds with if there is a newer message, in any of the users conversations, on the server or not. The server does not specify what is new, just that the app should send another API request to refresh the conversations.

4.5.8 User Roles

To be able to give different privileges to users in a simple way a role system was decided to be used. Fortunately, WordPress has roles built into it, so what we did was create new roles on WordPress and simply checked the WordPress database what role each account had when asked. This let us control, on the backend, what roles where allowed to do what things, and if a role was put on a user that was not allowed in the app the backend simply denies access for that user.

4.5.9 Validation

At this point we felt like we should improve our approach to validate the data and user sessions and made one big generic check, instead of writing custom checks for each new function introduced. Now the new functions would simply ask this validation if all the data received from the user is valid and specify what data the function requires. If any of this data is malformed or missing the validation, it automatically cancels the API call and sends back a message with a reason why it failed. Implementing this required a lot of reworking of all