In this sprint we focused on making our app performance aware and making all of our features aware of eventual connectivity issues. The goal in this sprint was to make sure all our features included functionality for supporting eventual connectivity and avoiding anti-patterns. Additionally we implemented caching, local storage and multi-threading / concurrency strategies. As per the last sprint, all of our repositories were managed using the following Git Workflow Guidelines. Finally, we underscore the ethical implications guiding our actions in the ethics video.

1. Eventual Connectivity Scenarios
2. Selected Business Questions
   1. Type 2: Direct User Improvement
   2. Type 3: New or Deprecated/Updated Features
   3. Type 4: Benefits from Data
   4. Type *: Combination of Types
3. List of Implemented Features
   1. Eventual Connectivity Strategies
   2. Caching Strategies
   3. Multi-Threading/Concurrency Strategies
   4. Local Storage Strategies
4. Ethics Video
5. Application Releases & APKs
   1. Flutter
   2. Swift

Eventual connectivity refers to handling connectivity issues in mobile apps, where users may experience intermittent or lost connections. This is an important topic because it is crucial to prevent users from abandoning our mobile apps due to poor performance or functionality when the connection is lost.

In this section we detail eventual connectivity scenarios, which are possible situations a user can experiment in which the connection is lost. Following the guidelines on how to present eventual connectivity scenarios given in MS10, the following section details every scenario that we implemented on our apps, with screenshots on both Swift and Flutter applications.

Title/ID	Trying to login with google without connection
Event Description	User must login (with Google) but has no connection.
System Response	System should verify device connection before redirecting the user to the google login, block the sign in button and show a message.
Possible Antipatterns	Redirecting without connectivity check (RWPC)
Caching and retrieving strategy	N/A
Storage type	N/A
Stored data type	N/A
Screenshots	Note: if you click on the images you can view a larger version of them.

Title/ID	Alert when app loses connection
Event Description	User is using the app and connection is lost
System Response	System sends an alert to the user and continuously displays an offline indicator.
Possible Antipatterns	Lost content (Lost text), stuck progress notification, Blocked Application
Caching and retrieving strategy	N/A
Storage type	N/A
Stored data type	N/A
Screenshots	Note: if you click on the images you can view a larger version of them.

Title/ID	Timeout while completing sign in
Event Description	While the user is completing the sign in flow in the in-app modal connection is lost. The Google UI is left loading without any progress or shows an empty screen
System Response	The system should detect when users are taking too long to sign and signal if too much time has passed.
Possible Antipatterns	Stuck progress notification
Caching and retrieving strategy	N/A
Storage type	N/A
Stored data type	N/A
Screenshots	Note: if you click on the images you can view a larger version of it.
Notes	This scenario was implemented as part of a multi-threading strategy only in Swift

Title/ID	Losing connection when trying to post a review
Event Description	The user is creating a review and loses connection when attempting to post it.
System Response	System should verify device connection before attempting to post a review. When there isn’t the review is saved locally and the user is notified that it will be uploaded later.
Possible Antipatterns	Stuck progress notification (NNPPA), Blocked Application
Caching and retrieving strategy	N/A
Storage type	Local > Private > DB
Stored data type	SQLite row in table [Swift] Image file
Screenshots	Note: if you click on the images you can view a larger version of them.

Title/ID	Losing connection when navigating from browse to detail
Event Description	Before or while the user is navigating from the list view of spots (ie. Browse, ForYou or Bookmarks) they lose connection and the data from spots detail (reviews, stats, etc.) cannot be fetched
System Response	The system continues to show the offline indicator at the top of the spot detail and hides the blank information. Instead of the information a message is shown regarding the fact that the spot's detail cannot be fetched.
Possible Antipatterns	Lost content (blank map, lost text), Blocked Application
Caching and retrieving strategy	N/A
Storage type	N/A
Stored data type	N/A
Screenshots	Note: if you click on the images you can view a larger version of them.

Title/ID	User loses connection at any point in the app and sees indicator
Event Description	When using the app and after getting an alert that the application is offline, the user should be reminded at all times.
System Response	System is notified, by a network manager, that the connection is not available and displays an icon that indicates it
Possible Antipatterns	Blocked Application
Caching and retrieving strategy	N/A
Storage type	N/A
Stored data type	N/A
Screenshots	Note: if you click on the images you can view a larger version of them.

Title/ID	User loses connection at any point in the app, but won’t lose content
Event Description	When using the app and after getting an alert that the application is offline, the information displayed should not get lost
System Response	System will cache all of the spots on a network response, so when it is offline the app can easily fallback to cache when needed.
Possible Antipatterns	Lost content (lost text), Blocked Application
Caching and retrieving strategy	Cached on a network response
Storage type	Local > Private > Storage > Cache
Stored data type	Array of Spots
Screenshots	Note: if you click on the images you can view a larger version of them.

Title/ID	Losing connection when using the Bookmarks View
Event Description	The user navigates to the Bookmarks View or is using it when they lose connection.
System Response	The system continues showing the information which is already in cache.
Possible Antipatterns	Lost content (lost text), Blocked Application
Caching and retrieving strategy	Cache falling back to network
Storage type	Local > Private > Storage > Cache & Preferences
Stored data type	Array of Spots
Screenshots	Note: if you click on the images you can view a larger version of them.

Title/ID	Losing connection when using the Spot Detail View
Event Description	The user navigates to the Spot Detail View or is using it when they lose connection.
System Response	The system displays a text informing the user that they are offline. If the spot detail information hasn’t been loaded then it encourages them get back online, and if it has then an offline indicator is shown.
Possible Antipatterns	Lost content (Lost text), stuck progress notification, Blocked Application
Caching and retrieving strategy	N/A
Storage type	N/A
Stored data type	N/A
Screenshots	Note: if you click on the images you can view a larger version of them.

Title/ID	Opening the for you page without connection
Event Description	The user opens the for you tab for the first time while having no connection.
System Response	The system displays a text informing the user that they are offline and a message that requires them to connect again if possible.
Possible Antipatterns	Lost content (Lost text), stuck progress notification, Blocked Application
Caching and retrieving strategy	N/A
Storage type	N/A
Stored data type	N/A
Screenshots	Note: if you click on the images you can view a larger version of them.

Title/ID	Losing connection when using the Reviews View
Event Description	The user opens the Reviews View when the reviews have been loaded but there is no connection.
System Response	The system displays a text informing the user that they are offline and the images have a placeholder. When connection is recovered, the image loads once again.
Possible Antipatterns	Lost content (Lost text), stuck progress notification, Blocked Application
Caching and retrieving strategy	N/A
Storage type	N/A
Stored data type	N/A
Screenshots	Note: if you click on the images you can view a larger version of them.

The storage type is defined from this diagram, presented on the lectures:

Back to top

This sprint expands on the last one by implementing specific business questions within our analytics system through an interactive Power BI dashboard. You can access the analytics dashboard through the next link:

• Analytics Dashboard in Power BI

Each question is aimed at enhancing our understanding of customer behavior and business operations. New questions will be marked with this emoji: 🆕

Check sprint 2 wiki page

To enhance the search bar functionality and simplify the process of users finding places they have previously visited, we have decided to incorporate the five most recent searches conducted by the user. Whenever the user searches for a specific restaurant by name, the application will automatically save the search to a list of spots that the user has previously searched for.

Moreover, if the user has conducted prior searches, the search history will be displayed, as illustrated in the following images:

Note: if you click on the images you can view a larger version of them.

This feature aims to streamline the search experience, allowing users to conveniently access places they have recently looked up.

Check sprint 2 wiki page

Check sprint 2 wiki page

• Visualization: Dashboard Card
• Description: Shows the percentage of users that have saved restaurants in bookmarks.
• Utility: This visualization is incredibly helpful for the team in order to analyze the way our app is being used. Understanding the proportion of users interacting with a feature, allows us to focus the development direction we want to give to our app. For example, on one hand, if there is a small amount of the user base using a certain feature, we may reduce development efforts on said feature. On the other hand, if a large part of our user base is using a feature, we could focus on improving it and the user's experience.

Check sprint 2 wiki page

Check sprint 2 wiki page

• Visualization: Bar graph (restaurant vs. Amount of unfinished reviews)
• Description: On the x-axis we are able to see the restaurants available in our app, while the y-axis shows the amount of unfinished reviews per restaurant.
• Utility: being able to see how many unfinished reviews each restaurant can also help us provide our analytics persona (a business person that wants to open a restaurant) a more complete insight on which are the most popular restaurants of our community. Having unfinished reviews is a metric that can be combined with the ratings of each restaurant and the amount of finished reviews in order to have different metrics to understand which spots are more popular.

(This question was originally How often does a user begin a review and leave it unfinished, i.e they close the app or return to home before submitting?)

Check sprint 2 wiki page

Check sprint 2 wiki page

Back to top

This section shows a comprehensive list on all of the features implemented in both applications, including the ones developed in the last sprint. All of the new features are marked with this emoji: 🆕

• Location between user and spot on the Browse View (GPS Sensor)
• Notification reminding the user to leave a review if they haven’t done so in a while.
• Answers the following type 2 business question: How many days have passed since the user last left a review? (e.g. 4 days, then it is suitable to suggest the user to write a new review)
• Notification when the user is on campus and it is lunchtime suggesting to find a spot for lunch on the app. (Context-aware, GPS usage)
• For You page of recommended spots (Smart feature)
• Authentication with Google
• External Service Connection: Firebase Firestore, Cloud Storage. Backend Endpoints
• 🆕 Drafting of spot reviews: users can leave a review unfinished and choose to save it in local storage. This draft can be used to re-fill in data if they chose to make a new review.
• 🆕 Bookmarks View + Functionality. Users can now bookmark their favorite spots and see them in the Bookmarks Tab. The chosen ones are saved in local storage (just the IDs). The details are saved in cache.
• 🆕 Dedicated view for showing profile related data + sign out button

In this section we detail eventual connectivity strategies, which are ways of solving the eventual connectivity scenarios detailed before.

• At launch time (background fetch): When the application starts, spots for the BrowseView and ForYouView are fetched from the backend to be stored in cache and be shown to the user as soon as they are retrieved.
• Pull (on user demand): the detailed data of spots (including reviews) is fetched once the user navigates to the spot detail view.
• Showing alerts and indicators while the user is in offline mode.
• We use both online-first strategies (in the Browse and ForYou views) and offline-first (in the Bookmarks view).

Caching improves performance, reduces energy use, and lowers backend load by storing frequently accessed data in faster temporary storage. And although caching is a useful strategy, it has limitations. Caching is more expensive than persistent storage, so the cache size is smaller and limited, often stored in RAM. Therefore, we had to carefully decide what data to cache in order to maximize the benefits. In this section, we will explain how we implemented these strategies following the concepts we saw in the lectures.

1. Network falling back to cache when fetching data from the Browse Feed and ForYou. In the first instance, the application will try to get the spots data from the backend service (Firebase), if there is no connection and this data cannot be fetched then the information is retrieved from the cache. This strategy is relevant here because we want to prioritize having up to date information about the spots the user is browsing.
2. Cache falling back to the network when fetching data for the Browse View, the application first checks if data is available in the cache, if so this the data that is fetched to be displayed. If there is no cached data then the information regarding the saved bookmarks is fetched from the backend service (Firebase). Here it is not as important to have the latest data but rather that it is available regardless of connection for the user.

All of these strategies use the following tools:

• Swift: NSCache
• Flutter: SharedPreferences

Concurrency is important to avoid overloading the main thread of execution. In Flutter, concurrency works only with asynchronous functions and futures, since it is a single threaded language. However, Swift does allow for multi-threading, which allows offloading long-running tasks to background threads, keeping the main thread responsive for a smooth user experience, while either executing in parallel or distributing the tasks. Taking these constraints into account, the following list details the strategies we use on each app for improving performance and user experience.

1. [SWIFT] Delegate fetches (of browse and for you data) to other threads so it is done only once (at launch) not each time the user changes tab. – Implemented on top of the existing Browse and For You features
2. [SWIFT] If more than 45 seconds have passed, dismiss the sign-in dialog that the GoogleSignIn package uses for showing its UI. (Since this component is not native to our application we couldn’t simply set a timeout, so the sign in flow executes on one thread and the timeout on another, if the latter finishes it first it synchronizes the UI to show the alert and dismiss the view, otherwise the flow continues as normal) – Implemented on top of the existing sign-in feature
3. [FLUTTER] Due to Flutter's nature we were unable to develop multithreading strategies. After speaking with our lecturer, we were informed that we could do asynchronous programming instead of multithreading. Most of our tasks utilize this type of programming, for example we fetch the Suggestions list for the search bar with Futures and Awaits.

Futures and async/await work together to handle asynchronous operations without blocking your program. Futures represent the eventual result of an asynchronous task, while async/await functions allow your code to continue running other tasks while waiting for the future to complete, making asynchronous programming more readable and efficient. Flutter uses asynchronous programming (Futures, async/await) to keep your app responsive during potentially slow tasks (network, files). This avoids blocking the UI thread, which would cause lag and a bad user experience. By using Asynchronous programming we allow these tasks to run in the background while the UI stays smooth and interactive.

Local storage, or installed data, allows mobile apps to have all the necessary data stored locally on the device. This enables the app to function mostly offline, without needing to constantly connect to the internet to retrieve data. The following list details the way we are using local storage in our apps.

1. DB: the application saves drafts of reviews to a local SQLite database and the images within App-Specific files. Implemented with the feature of drafting of spot reviews:
   • Swift: SQLite (Package to access local db) + FileManager (Image File)
   • Flutter: SQLite (Package to access local db)
2. Preference: the application saves the IDs of the spots that have been bookmarked by the user in the Preferences – Implemented with the Bookmarks feature
   • Swift: UserDefaults.shared
   • Flutter: SharedPreferences
3. File Manager: the application saves the recent searches made by the users to an app-specific file. – Implemented on top of the existing search feature in the Browse View.
   • Swift: FileManager (JSON)
   • Flutter: SharedPreferences

Back to top

You can watch our ethics video here or by clicking on the image.

Back to top

• Release: The release for sprint 3 is here.
• APK: The APK for sprint 3 is here.

• Release: The release for sprint 3 is here.
• APK: Pending instructions by lecturers or TAs.

Back to top