Impactos del futuro sobre la educación superior

The Android application made frequent use of SQLite foreign keys to ensure data consistency and referential integrity. Unfortunately, the capabilities of this particular implementation of SQLite did not allow for foreign key functionality. Even with the usage of foreign keys, the order in which data enters the application is not guaranteed. Therefore, foreign keys were removed to make the data more flexible. Yet this approach came with the added complexity of ensuring data at the application level.

With the absence of foreign keys, facilities were added to manually ensure data consistency throughout the application. When a parent record is removed from the cache, any child records from other tables relying on that record have to be removed themselves. For instance, if a tag was removed from the local cache, the cache would

155

also have to remove any comment records with a TagID field corresponding to the removed tag. Data consistency problems arise when a record is modified by a user. In this way, much of this functionality was consigned to the action cache which would be able to update ancillary cache records when needed.

Another change from the Android schema is the addition of a RoomID column on the Adventure table. In implementing the social enhancements outlined in the proposal for this thesis, a social space was created for adventure members to discuss the adventure itself. This took the form a “chat” tab which includes a real-time chat feature. A JavaScript library called “socket.io” was used to implement this feature. Socket.io uses the concept of “rooms” to organize the messages being sent to the socket.io server.

Users can enter any number of rooms in order to receive messages sent in that room. Each adventure acts as its own “room”. Retroactive changes were made to both the remote and local databases to accommodate this feature, ensuring that every row in the adventure table would be given its own room. A room is a unique identifier which allows the socket.io client to connect to the server as soon as the adventure is entered. While the user is present in that adventure, they will receive any messages sent within that adventure’s room. The number of received messages will display on the badge icon on the “chat” tab.

One of the planned social enhancements called for making tag comments more prevalent. The previous version of the application required users to navigate to the tag’s detail view, then the comment view. This enhancement allowed users to view comments on tags with a single button press. A secondary goal was to provide the user with added context as to the activity on each tag. A user could see which tags had more comments by looking at the tag list view, rather than navigating to the

comments each time. Even displaying the comments with a single button press could be a tedious process as the user could find themselves frequently opening the tag comments.

To provide the user with instantaneous information about comment activity, a small badge icon was added to the “comment” button. This badge tracks the number of comments relating to that tag. This enhancement was integrated into the card representation so that users could scroll through available tags, aware of the number of comments on each tag. To achieve this result, a new field was added to all tag related API responses. When the API receives a request for a list of tags, the number of comments that reference those tags is calculated and returned with the rest of the HTTP response. A new field called “NumberOfComments” was added to the local cache database. Rather than having to make an API call each time, a previously accurate representation of the number of comments on a tag is stored. This is updated each time the page is refreshed.

The final change from the Android application was to the action cache. While the application developed in this thesis relies on the same principles of the action cache designed by Cushman [9], there were significant changes in the implementation of the action cache. The previous action cache implemented the following fields.

• CacheTime: DATETIME - Time of cache, used in ordering records.

• ActionString: TEXT- Action to perform on the database.

• ActionHandler: TEXT - Identifies a handler to perform the action.

• Url: TEXT - A remote resource location to which the data should be sent.

157

The algorithm for registering and resolving applications has been overhauled. As before, actions are serviced in the order that they are inserted in the action cache. Though the data required to service and propagate these changes to the API has changed. The action schema is as follows:

• Operation: TEXT - The type of operation performed by this action (e.g., Post, Put, or Del).

• EntityType: TEXT- The type of object being operated on (e.g., Tag, Comment, Adventure).

• EntityID: INTEGER- Row identifier for the object being operated on.

• ParentID:INTEGER- Used in place of EntityID for referring to junction records (e.g., AdventureTag, AdventureMember).

• ChildID:INTEGER- Used in place of EntityID and in conjunction with ParentID.

• Created: INTEGER - Millisecond value representing when the row was inserted into the action cache.

Note that there are similarities between the two implementations as both keep track of the type of action being propagated and the time at which the action was registered. This work’s implementation removes URL strings as API routes could change, leading to unresolved action records being invalidated. Additionally, “handlers” have been replaced by local resolver functions in the ActionService. The ActionService will resolve any data inconsistencies that might arise when side-effecting data in the local cache, thereby removing the need for the PostActions. More information about how actions are handled and resolved can be found in section A.3.