sprint4
Hive is the ultimate mobile app for the Uniandes community, seamlessly connecting students through engaging events and community initiatives.
Hive is a hand-crafted app for the Uniandes community, which has all the features expected on a events app, and even more interesting features. For example, the user can create a event specifying the date, the duration, the location, and more. For the perspective of a user, the app provides a lot off functionalities, like showing the number of people joined in an event, the users that has created more events, statistics like how many time has I used the app, and other features.
- The initial approach to micro-optimization involves eliminating any unused imports within the application files. The objective is to avoid loading unnecessary libraries or packages that won't be utilized later on the view. The reduction in consumption is modest, decreasing from just above 90MB to slightly less.
- The second aproach was to check the Memory use in the FlutterDevTools profiler. It was observed that our event filtering feature consistently exhibited memory leaks. Consequently, we undertook a code revision, shifting from the initial approach of concurrently maintaining events from five distinct categories. Instead, we implemented a more streamlined method wherein we retrieve event data only when necessary. Specifically, upon a user's selection of a filter type, we access stored events and present only those pertinent to the user's preference. This adjustment resulted in a substantial reduction in the frequency of Garbage Collector invocations, constituting a really good optimization.
This image captures a moment when the user opted to filter content based on categories. In this particular image, the user engaged in three distinct category filters within the Feed interface. (Before the micro-optimization)
This image captures the same scenario where the user actively chose to apply 3 category-based filters. (After the micro-optimization)
- The first micro-optimization strategy is to remove all unused imports in the application files with the purpose of not loading libraries or packages that will not be used later. Although the application already consumes a significant amount of memory, we can observe a minimal change when removing these imports, reducing the consumption from a little over 128MB to slightly less.
PRE and POST:
- Another strategy is to eliminate unused global variables. Similar to the previous one, the idea is to avoid generating more objects that will ultimately not be used, thus reducing memory consumption. Using the profiler, we can observe a constant expenditure greater than 128MB before making the changes. After making these changes, there is a lower and more prolonged initial memory consumption, albeit minor.
PRE and POST:
- On the other hand, we modified the adapters by implementing weak references in them to reduce memory costs when refreshing the view while filtering events for each category. Before the implementation, every time we filtered by a category, there was a growing trend in consumption towards 200MB. However, upon implementation, we can eliminate that growing trend and see that the view is being recycled between the categories of the filter.
PRE:
POST:
- Finally, one of the most important optimizations was related to the bee feature. Previously, we used an excessively heavy image for the bee, which was then resized, causing us to render a heavy object each time on the profile view. To optimize it, we changed the image resolution to reduce its weight and avoid generating complex rendering. With this implementation, we can see an almost 10 times improvement in the memory space occupied by the bee image.
PRE and POST:
We have 3 features implemented by Team Flutter:
- Filter events by category: In the first video we find the option on the home page to filter the events shown by the category to which they belong (Academic, sports, etc).
- Bee: This feature, although simple, is an implementation of multithreading with a graphical rendering update.
- Edit my event: In the third video we show how from the section my events we can modify the information previously placed.
We can find the 3 features implemented by the team in Kotlin:
- Filter events by category: In the first video we find the option on the home page to filter the events shown by the category to which they belong (Academic, sports, etc).
- Bee: This feature, although simple, is an implementation of multithreading with a graphical rendering update.
- Edit my event: In the third video we show how from the section my events we can modify the information previously placed.
The initial image showcases the "Top Creators" view, providing a visual representation of content creators' rankings. The subsequent image corresponds to the "Stats" view, presenting statistical insights. The third image captures the "Edit My Event" view, illustrating the interface for modifying a event I have previusly created.
- What are the top creators of the app?
This is a type 2 question because this question is made by the user for the user. This shows the user what are those creators that have the highest average of participants per event and have created more than 3 events. This can show the user what are those creators that might create a good and well-attended events.
- How many events of every category I have attended?
This is a type 2 question because this question answers a user question. This answer adds value to the user by helping them to show the percentage of events that the user has attended grouped by category. It takes into account all the events the user has attended and shows all the information required.
- What are the people that I share events with the most?
This is a type 2 question because it answers a user request. This BQ adds a valuable feature for the users, as they are now able to see who are those people that they share events with. It takes into account all users that the user has been in events with.
- Sensor feature - QR Lector for event's detail
The purpose of this feature is to give users the possibility to share an event quickly. For this, we use QR codes that automatically open the view of a specific event. This can be done by means of the device's camera. This functionality can be seen in the QR icon to the left of the logo and in the main part of the application (To read QR codes). In order to share an event, a code is generated when accessing the event details. This allows linking the QR with the event.
- Type 2 question (feature) - User history The type 2 question that we answer with this feature is: What are the last events I attended in the last month?
To answer this question, we show all past events that the user joined, sorted by date from the most recent to the oldest. In addition, we show the event detail to see the event information. However, the functionality of the "join" or "leave" button is removed since these are events that have already happened.
- Context Aware (feature) - Notification when the user is close to the University
For this feature, Hive app sends notifications when the user's device, with their explicit consent, enters a predefined geographical area around Uniandes, utilizing location services and geofencing technology. This feature tracks the user's proximity to Uniandes and triggers notifications accordingly, requiring responsible data handling, privacy protection, and battery optimization to ensure an accurate, user-friendly, and ethically sound experience. It is context-aware due to the fact that takes into account the surroundings and the user's location
- Smart feature
The smart feature is represented in the feed of the application; the displayed Events in the feed are based on the user's most inscribed events tags. It's developed based on the "most liked" tags of the user and returned by an endpoint of the backend, it corresponds to the "Home" page of the app.
- User authentication - Login
In this feature, we do a simple implementation of a login with a username and password to know which user is entering the application. Here we do checks for both empty and nonexistent user or incorrect information as you can see in the images. On the other hand, it allows an unregistered user to go to the account creation section.
- External services - User profile
In the profile view, we make requests to the backend of the application to access the user's information and display it. We obtain the user detail and show information related to the account with which the session started (name and email). On the other hand, we show the user's participation by means of the number of total events in which the user has participated.
- External services -User activities
In the activity view, closely related to the user's history, it allows to see the active events to which the user has subscribed sorted by date from the most recent event to the most distant event. In this feature we use 2 services from the application backend. Get active events of a user sorted by date and get the detail of an event. With this we can give the user an easy way to access the registered events to see their information, share it or simply decide not to participate in the previously registered event.
- SignUp
Allow the registration of a user
Previews the username of the user after signing up
- LogIn
Log in the user, with the credentials of the sign-up
- Feed
Feed of events created by all users
Smart feature: Events based on your most liked events
CAS Feature: Notification based on your location about the recent available events
QR Feature: Allows the user to scan a QR of an event
- Event Detail
See the detailed attributes of an event Join an event
Give up an event
See how many people have joined the event
QR Feature: Allows the user to show the QR of a created event for other users to join it
- Event Create
Create a new event
- List of your Events
See the list of your available events in the future
See the history of the events you have attended
See the list of the events you have created
- Profile
See your profile information
Sign out from the app
See the amount of time you have spent in the app
See the number of events that you have joined in total
- Stadistics
The statistics view provides the user with a detailed insight into their participation in various event categories and highlights the social relationships associated with their activities. The first section, "Events by category," features a pie chart illustrating the distribution of events across categories such as sports, academic, cultural, entertainment, and others. This chart visually represents the user's preferences regarding event participation. The second section, "People who attend events with me the most," unveils social connections by displaying a list of individuals with whom the user has attended the most events. This information offers a deeper understanding of social relationships and emphasizes the most active friendships or connections in terms of shared event experiences. Overall, the view aims to provide the user with a clear and structured overview of their experiences and relationships in the realm of events.
- Edit Event
The event editing view is an interface designed for users to make modifications to the information of a previously created event. This view is structured into two main sections. In the "Basic Information" section, essential elements of the event such as title, date, time, location, and category are presented. The second section, named "Additional Details," provides space for more specific information, including an event description, duration, guest list, and relevant links. To make edits, the user simply clicks on the field they want to modify and enters the new information. Additionally, navigation through available options is facilitated using directional arrows. Once all desired edits have been made, the user must confirm the changes by clicking the "Edit" button, ensuring that the updated information is effectively saved.
- Top Creators
The view of the top creators aims to provide the user with a prominent list of global creators who have organized more than 3 events and have achieved a noteworthy participation percentage. This perspective focuses on highlighting those creators who have demonstrated consistency in event organization, indicating a continuous commitment to the platform. Additionally, success in terms of participation is emphasized, suggesting not only the frequency of their activities but also the ability to attract and retain active participant attention. By presenting this view, users are offered an efficient way to identify and connect with the most influential and successful creators on the platform, thereby fostering an enriching experience for all involved.
b. Specify what are your BQs for this sprint (You should differentiate which BQs correspond to each sprint)
- How many times in a month do users encounter crashes or technical glitches while using the application?
This is a type 1 question because it gathers information related to the app's performance and reliability in a day to day use by users, it gives telemetry regarding the correct operation of the app
- What is the average loading time of our app based on a monthly average?
This question is directly related to monitoring the application's resources and its performance, which is one of the key aspects of application telemetry. Furthermore, the answer to this question would assist the development team in identifying potential performance and stability issues in the application.
- What are the last events I attended in the last month?
This question is intended to provide the user with a list of the events they attended in the last month. This information is directly useful to the user as it allows them to recall the events they recently attended easily. It can help the user keep track of their activities and plan their future schedule based on their past experiences.
- What are the events I would like the most on this app based on my interactions?
This question improves the user experience because it allows him to seek relevant events that serve his interests.
- How much attendance does a specific event have?
This question aims to provide the user with relevant information about how many persons will attend an event that the user is interested in. This can help the user decide if assisting an event can be fulfilling or not.
- Am I already registered for a specific event?
This is a type 2 question because this question is made by the user for the user. This could help the user know if he is already part of an event, this is valuable information because if the user is already registered he may want to cancel his registration, invite his friends, and more options. This is relevant for users because they may forget if they registered or not in some event while searching for nice events to participate in.
- How many events have I attended?
This is a type 2 question because this question answers a user question. This answer adds value to the user by helping them keep track of how many events they have attended, sharing this information with their friends, and having this record as relevant information for their user profile. We address this type 2 question by showing the user the events they have joined and have ended, as well as the events that will take place in the future.
- What are the events that I have created?
This is a type 2 question because it answers a user request. This BQ adds a valuable feature for the users, as they are now able to see in a certain place in the app, which are their own events, so they can see the activity they have had, even though the number of events that are in the feed, which could be a lot; also, the user is able to visualize how many attendants do their events have.
- Which are the most visited events?
This is a type 4 question as it intends to general purposes information, like the trending events and the most requested assets from users. This question can help the business to understand what the focus of users' attention is currently, and this information could be sold by the business to third-party companies to make a profit from it or create new events of that nature.
- What are the top creators of the app?
This is a type 2 question because this question is made by the user for the user. This shows the user what are those creators that have the highest average of participants per event and have created more than 3 events. This can show the user what are those creators that might create a good and well-attended events.
- How many events of every category I have attended?
This is a type 2 question because this question answers a user question. This answer adds value to the user by helping them to show the percentage of events that the user has attended grouped by category. It takes into account all the events the user has attended and shows all the information required.
- What are the people that I share events with the most?
This is a type 2 question because it answers a user request. This BQ adds a valuable feature for the users, as they are now able to see who are those people that they share events with. It takes into account all users that the user has been in events with.
Our eventual connectivity strategies are the followings:
Cache the network: this is our most used strategy. It is implemented in the Feed, Profile and Calendar views in order to show the cached data first (for not making the user wait) and then be updating the data in cache and UI when the data from network arrives.
Cache, falling back to network: this is the least used strategy, because it is only implemented in the Stadistics and in the TopCreators views. This strategy is based on first get the data from cache/local storage and if it miss, get the data from the server, which is really usefull in this views because it allows to get from local the necesary information for the graphs presented on this views.
Eventual Connectivity Scenarios
ECn 1
| Item | Scenario Description |
|---|---|
| Title/ID | Edit Event |
| Event Description | In this scenario, the user can modify fields deemed necessary within an event. Once the desired changes have been made, the user must click the "Edit" button to apply the modifications. |
| System Response | Upon clicking the "Edit" button, the system will generate a confirmation message, notifying the user that the changes have been successfully applied to the event. |
| Possible Anti-patterns | In the event of no available connection and a failure in attempting to send the edit, it is considered an anti-pattern. To address this scenario, preventive and descriptive measures will be implemented. |
| Storage and Retrieval Strategy | When the connection is unavailable, the submission button will be deactivated, and a message indicating the lack of connection will be displayed. This strategy aims to prevent failed submissions and provides clear information to the user about the situation. |
| Storage Type | In this context, no local storage type is implemented, as event editing cannot be carried out without a connection. However, a clear notification about the lack of connection is provided to inform the user and prevent undesired actions. |
ECn 2
| Item | Scenario Description |
|---|---|
| Title/ID | Statistics. |
| Event Description | The user accesses the application to view statistics on events by category and the top individuals who have attended events with them. |
| System Response | The application checks connectivity. If there is a connection, it retrieves real-time data. If there is no connection, it retrieves locally stored data in Room. |
| Possible Anti-patterns | The application does not inform whether it is retrieving real-time data or data from local storage. The user interface does not distinguish between real-time and locally stored data, confusing. |
| Storage and Retrieval Strategy | It uses Room to locally store relevant data, such as events by category and user participation. The application prioritizes the retrieval of real-time data, but if there is no connection, it resorts to locally stored data. |
| Storage Type | Room Database for local data storage. |
ECn 3
| Item | Scenario Description |
|---|---|
| Title/ID | Top Creators. |
| Event Description | The user accesses the application to view the top creators of events who have organized more than 3 events and have had many participants. |
| System Response | The application checks connectivity. If there is a connection, it retrieves real-time data. If there is no connection, it retrieves locally stored data in Room. |
| Possible Anti-patterns | The application takes a long time to switch from real-time data to locally stored data, causing frustration for the user. Locally retrieved data is not updated, leading to obsolete information. |
| Storage and Retrieval Strategy | It uses Room to locally store data about event creators, the number of events created, and participants. The application attempts to retrieve real-time data, but if the connection fails, it shows locally stored data with a last update indicator. |
| Storage Type | Room Database for local data storage. |
Team Flutter decided to keep the events information in local storage through the implementation of Encrypted SharedPreferences. This strategy aimed to maintain the integrity and security of event data at the local level, ensuring expeditious access to the information upon the application's launch subsequent to event retrieval. To optimize application responsiveness, the team collectively adopted a "Cache then Network" methodology. In various views where event data is presented, such as the Feed, Historic Activities, Future Activities, and Events Created, the team elected to store the event information in SharedPreferences during a single instance, subsequently extracting or modifying it as needed. This approach contributes to the enhanced efficiency of the application.
In kotlin Room is excellent for managing structured and complex data, such as lists of events, personal information, or any other type of data that needs to be stored in a structured manner in a local database. You can define entities and use SQL queries to perform operations on the database. For this reason, we use it to handle most structures that need to be saved to manage eventual connectivity, such as feed events, activities, history, or created events. On the other hand, SharedPreferences is useful for storing simple data and application configuration, such as the user ID or user settings like usage time or information status. We specifically encrypt this data since it is sensitive information (Encrypted SharedPreferences).
There were 3 strategies that were implemented in Kotlin and used for multithreading purposes. They were employed in 3 different cases.
- Coroutines with Dispatcher IO: This strategy utilizes the IO dispatcher to handle tasks involving input and output operations, such as network requests or file I/O. It ensures non-blocking execution of these operations, preventing thread blockages and maintaining application responsiveness during IO-bound tasks. In our case, the dispatcher IO was used to access the Room local database and make different operations.
- Coroutines with Dispatcher Main: Tailored for the main thread, this strategy prevents UI freezing by enabling asynchronous operations without compromising user interface responsiveness. It's particularly useful for handling tasks associated with user interactions and contributes to creating smooth and interactive applications. In our case, the dispatcher Main is used in the Bee feature, when the user drags or touches the screen when the feature is active, the bee will follow the touches and change its position accordingly.
- Suspend Functions: Suspend functions play a crucial role in the Kotlin multithreading model. Marked with "suspend," they execute long-running tasks asynchronously without blocking the calling thread. Suspend functions excel in scenarios like network requests and database queries, offering a seamless approach to writing responsive and efficient code. The suspend functions are used to be called inside the coroutines and have that multithreading aspect working properly.
| Strategy | Description |
|---|---|
| Async-await | Async-await functions are a crucial part of modern programming languages because they enable asynchronous concurrency. This is really useful for us, developers, to write code that can efficiently manage time-consuming and non-blocking operations. In the context of Flutter, these functions are used to handle tasks such as network requests, repetitive tasks in the background, complex calculations, and other operations that may take time to complete. To make the Hive application always responsive and non-blocking, we use a lot of async-await operations to manage time-consuming tasks, such as saving data to local storage, retrieving data from local storage, making login and sign-up requests, and handling time conversions. |
| Future | Future is really useful in Flutter because it handles asynchronous operations that take time to complete without blocking the main thread. In our implementation, we decided to use Future to declare lists of events, which retrieve the information of the events from local storage to show in the different views when the user does not have connectivity. This implementation is done three times: in the feed view to know all the available events, and in the Calendar view, which has a Future list to load the events from local storage that will occur in the future and those that have occurred in the past. |
The FormProgressCache class is used to manage and preserve the progress of forms in different states of the application lifecycle, such as pauses and resumptions. This class is responsible for storing and retrieving objects of the FormData type, which encapsulate the information entered by the user in any form within the application.
During the execution of the current form fragment, a check is performed each time it is paused (onPause) to determine if the form has been successfully completed using the resourceHasSucceeded function. If successful, the corresponding entry for the form is removed from the cache using formProgressCache.remove("formData"). If not completed, the form data is collected into a FormData object and stored in the cache using formProgressCache.put("formData", formData).
In the resume event (onResume), the form information is retrieved from the cache using formProgressCache.get("formData"). The form fields in the user interface are then populated with the retrieved data, allowing the user to continue completing the fields from where they left off.
Caching in Flutter was implemented with a global HashMap variable called "cache" which also provides a set of methods available in any place in the app, in order to allow its usage for general purposes along the app. This is the implementation of this variable and its service functions:
This variable is used on all the form views, which correspond to SignUp, LogIn, and EventCreate views, and it's used to both write and read information from Cache.
For example, the information from the cache is read when the forms are first rendered, for example:
On the other hand, the form field information is saved to the cache every time that something is typed on the field; for this, every form field has its own "onChanged" method that writes the current data to the cache, and also validates that the data typed is valid, as shown in this "description" field:
Finally, when the operation is successful (either for SignUp, LogIn, EventCreate or EditEvent), the cache is flushed in order to avoid overwriting future data.