Lenguajes estructurados en bloques

All the API calls to the backend for the app has the common prefix: http://dyamo.se/?rest route=/dyamo-app/

for the API token/validate:

http://dyamo.se/?rest route=/dyamo-app/token/validate

All the APIs requires data sent as JSON objects, and most API calls also require a Bearer Authorization header to be set with the generated token for the user. Before going into all the API endpoints we will go through all the different JSON keys that exist and what kind of data they expect.

• username: takes a username of a registered user. • password: takes a password.

• sid: takes the session token to validate the user. • uuid: takes an ID (integer) of a registered user. • cuid: takes an ID (integer) of a conversation. • muid: takes an ID (integer) of a message.

• suid: takes an ID (integer) of a registered school.

• users: takes multiple IDs (integers) of registered users, separated by a comma sign ”,”.

• gchat: takes exactly one of the two values ”true” or ”false”, is used to tell the server if a conversation should be a group chat or not.

• attachment: takes an integer from 1 - 3 (inclusive), which tells the API what kind of message is sent. For plain text messages use 1, for messages with file attachments use 2, for stickers use 3.

• text: takes a string of text with no special format.

• json: takes a JSON object, exact parameters depends on the API end- point used.

Now that we have gone through all the different JSON keys requested by the API endpoints we can start going through all the endpoints available.

• token: [username, password] - returns user info and generates a new session token if correct username and password is supplied.

• token/validate: [sid] - verifies the user session.

• user/self/info: [sid] - returns information about users own account. • user/info: [sid, uuid] - returns information about another user. • user/poll: [sid, muid] - returns an integer 1 if there are new messages

available since the message with ID muid and 0 if there are no new mes- sages.

• conversation/create: [sid, gchat, users] - creates a conversation containing the specified users, if the conversation should support more than two users gchat needs to be set to ”true”, otherwise it should be set to ”false”

• conversation/self/list: [sid] - returns the list of conversations as- signed to the users account.

• conversation/id/list: [sid, uuid] - returns the list of conversations assigned to the specified users account.

• conversation/send: [sid, cuid, attachment, text] - only applies when attachment=[1, 3], if set to 1 it posts a message containing the given text, if set to 3 it posts a message with the specified sticker id.

• conversation/send: [sid, cuid, attachment, text, file upload] - only applies when attachment=[2], posts a message with the specified text, and also takes a file that will be attached to the message.

• conversation/name: [sid, cuid] - returns the name of the specified con- versation.

• conversation/view/all: [sid, cuid] - returns a list of all messages in a conversation.

• conversation/view/new: [sid, cuid, muid] - returns a list of all mes- sages newer than the message with id muid.

• conversation/view/old: [sid, cuid, muid] - returns a list of all mes- sages older than the message with id muid.

• conversation/modify/add: [sid, cuid, users] - adds the specified users to a group chat conversation.

• conversation/modify/user/remove: [sid, cuid, users] - removes the specified users from a group chat conversation.

• conversation/modify/delete: [sid, cuid] - marks a conversation as deleted, also marks all user accounts messages as deleted exept adept accounts, whose messages are permanently deleted.

• conversation/modify/rename: [sid, cuid, text] - sets the name of a conversation, if a name already exists it replaces the old name with the new one.

• conversation/view/users: [sid, cuid] - returns a list of users assigned to the conversation.

• conversation/delete: [sid, cuid, muid] - removes a message from a conversation. Deletes messages sent by adepts and simply marks other users messages as deleted.

• conversation/status/get: [sid, cuid] - returns a 1 if the conversation has been read by anyone else than the last sender, returns a 0 otherwise. • get/file/data: [sid, cuid, muid] - returns the requested file.

• get/file/info: [sid, cuid, muid] - returns information about the re- quested file.

• school/info: [sid, suid] - returns the school code and name. • school/list: [sid] - returns a list of all registered schools.

• school/user/set: [sid, uuid, suid] - assigns the given user to the given school.

• school/user/list: [sid, suid] - returns a list of users that are assigned to the given school.

• school/add: [sid, json: [school code, school name]] - registers a new school.

• school/rename: [sid, suid, text] - changes the name of the given school.

• school/delete: [sid, suid] - deletes the given school, if there are no users assigned to it.

5

Discussion

When discussing how the app compares to expectations, one has to look at it in a few different ways. If we look at the initial expectations, set before development of the app even started, it is fair to say that the expectations were exceeded by quite some distance. However, the reality is that the expectations and goals that we had did not remain what they were from the beginning throughout the entire development process. In fact, they changed, more or less, on a weekly basis. Ideas for things to implement and different ways to implement things

First of all, we need to talk about the fact that an entirely new account type came to be. It was decided that an account type between admins and other account types was needed with some admin features, but not all, ultimately to facilitate the work that would have to be done by the admins.

Secondly, something that is not included compared to the expectations is change password in the settings, although this ought to come when the corre- sponding page is available in the app. However, changing password will not be done within the app, which we initially intended. We even made the whole form and everything, but it would be too much work to get it to work with the backend since it was not supported by the authentication method we are using. Another major difference compared to the expectations is that admins can be active members of conversations, whereas they were originally just going to be able to monitor conversations. This is because there was originally only going to be one type of conversation, which is between an adept and a mentor. However, it was decided that there should also be conversations for admins, moderators and mentors to discuss different things like how to conduct mentoring; how to coordinate mentors and how to match a mentor with an adept. Because of this it was essential that admins should be able to join such conversations.

Reinforcement stickers (referring to key and Congratulations-stickers) were another thing not included in the initial expectations. This was something that DYAMO asked us to add a few weeks into development, and it seemed like they had planned it for a while as they already had graphics made for it. The purpose of the reinforcement stickers is so that mentors can reward students for doing well. As the clients will likely be quite young, DYAMO hopes that the positive reinforcement can help motivate them to try and excel in their studies.

The expectations section mentions that admins should be able to create conversations, but it never goes into where it should be implemented. The truth is, that we didn’t have a clear idea of where it should be added when we first started out. However, once we started working on the app, we quite quickly decided the put it in the user view, so that it could easily be created with a user already in mind to add to the conversation. Another option would have been to have it in the conversation list view, but that intuitively feels like it would always be to add yourself to a conversation since it is where your conversations are, which you might not always want. It is something that we have considered to have as an option as well though, but never acted on.

Having schools as part of the app was not the plan from the beginning. The only way that schools would play a part was to generate a username for adepts. However, we decided to add schools so that users could be more easily managed in the app based on schools. In a meeting with DYAMO, they wanted users to be separated into groups based on what school they belonged to. In order to do this we needed to know what school users had been assigned to, and that is ultimately why we decided to include schools and assigning of users to schools, in the app.

The create account function also differs from the initial expectations. Ini- tially the account creation would be done in the app, but a long way into development we found that it would be very hard to register users from the app

with the authentication method we were using and decided it would be best to simply create a link to the website where the functionality to create accounts already existed.

5.1

Company Feedback

Overall, DYAMO are satisfied with how the app turned out and very happy to have their own platform to work more closely with their clients. They are very passionate about their idea, and having their own app is a big milestone in the evolution of their company. The app exceeded (almost) all the expectations that they had (both in terms of the initial expectations and the ones that came later). However, there is one significant aspect of the app that fell short of expectations, which is that background notifications do not work on all devices, meaning that some users will not receive notifications from the app unless they are actively using it.

6

Future Work

In this section we will discuss what could be improved with our work and explain some of our workflow to help with future development of either the backend or the app.

6.1

Ideas for Future Development and Improvement

For future improvements there are multiple aspects to think of, for easier main- tainability the code base should be improved. Looking back, a lot of code could be abstracted further than what we have done currently which would make the code easier to navigate, update and keep building on. We did rewrite a big por- tion of the app in the last months to improve the way we stored global values across the app and also abstracted away calls to the API endpoints to eliminate bugs from when requests failed (by including more comprehensive checks in the abstracted function). But this could be improved further. A good idea for fu- ture work on this aspect would be to write one function for each API endpoint which takes care of data translation for that specific endpoint. Right now we take care of this every time we use an endpoint which makes it harder to keep the app up to date with the server, if any of the two would change; since we might have to change the API and translation in multiple places rather than just in one place.

believe that if enough time was put into trying to find a solution, it should be able to get it to perform polling every 15 minutes. If that would be successfully implemented, I think the background fetch [10] could be the key to getting it to work. Another problem is the notifications on Android, theoretically the notifications works as long as you do not completely exit the app. I.e. you can minimize it and use other apps and the notifications should work just fine. In practice however, this is not true for all devices and will not work forever, because the Android system can terminate the app if it needs the resources occupied by it. Another problem is the fact that the app has to be minimized, and not fully shut down for it to even have a chance to work. A typical user is probably not aware of this and therefore they do not know the consequences of exiting the app completely.

Another solution to many of the issues, but also potentially the biggest change, would be to change the type of backend used. The current backend does not support pushing data to clients. This means that the server does not have support for push notifications, it does not support pushing new messages to the users etc. If we would have had this feature there are many more options for plugins handling these kinds of notifications, messages etc. It would also remove the limit of how fast we can receive messages. As of now the app can not know if the server has any new messages without asking (i.e. polling), but we can not let the app ask the server for updates constantly since this would take up a lot of resources from both the clients phones and from the server. So this means that the frequency of getting new messages is limited, and to find out if there are any new notifications our app has to be ”awake” to be able to ask the server if there are any new messages to notify the user about rather than just having the server report back when there has been an update. However changing the backend would mean redesigning a huge part of the app since it is built to use the stateless server we have today. There would also be the problem of connecting their website to this backend, right now this is no problem since the website and backend is running on the same server.