1. Use the phone's microphone to listen the users voice to fill the search field with their words when searching for restaurants in the search screen.

2. In the map screen, the map shows with a special icon the location of a restaurant that is within a radius of the user if it is new, if the user hasn't liked it yet and if any of the restaurant's categories is within the user's liked categories.

3. Depending on the location of the user and the established search radius, it will automatically adapt and show the restaurants near the user.

4. Section in the home screen that recommends the user restaurants he/she might like and improve their experience through the highlighting of restaurants that match their registered likings in the app.

5. Login and register screen for the users to enter or create an account that stores their liked restaurants and authentication details.

6. Use the google maps code API and the google play map services to show the user the locations of restaurants near them, in addition to their surroundings and points of interests.

7. Firebase database for persisting the user's, information, restaurant's information, analytics events and information needed for the functioning of the application. This service is used to track the users likes, liked categories, list the restaurants, filter them and find their location.

8. Firebase storage to store image files for the images that belong to restaurants and the images that are assigned to represent the users.

9. List of currently opened restaurants that uses the phone's time and compares this value with the schedules of the restaurants.

10. List of all restaurants.

11. Screen that allows the user to find restaurants using keywords, see the restaurants he recently searched for and erase their history.

12. List of liked restaurants by the user.

1. Specialized restaurant screen that displays the restaurant's details

2. Review list for each restarant that shows a score and description left other users

3. The option to write a review for a restaurant, leaving a description and a star rating

4. A random restaurant screen, that displays the details of one of the restaurants in the database

Type 1: What is the number of users per device model?

Type 2: What restaurant(s) have been the most liked or positively reviewed this week?

Type 2: What percentage of the restaurants has the user left a review in?

Type 3: How often does a user leave a review after using the "randomize restaurant" feature?

Type 4: What common qualities are shared by the restaurants most frequently added to users' favorites?

Type 5: In what area are the restaurants that are the most liked?

In RestaU, DataStore is used as a local storage strategy to save recently visited restaurants. DataStore is ideal for handling small datasets asynchronously and securely, improving concurrency and access compared to alternatives like SharedPreferences.

The implementation centers around the RecentsRepository interface, which defines two main methods: saveRecentsEntry, to store a set of restaurants, and readRecentsEntry, which returns a reactive data flow (Flow) of these entries. Since DataStore only supports key-value pairs, the Restaurant objects are serialized to JSON with Gson before storing and deserialized when reading. This approach efficiently manages complex objects like Restaurant.

override suspend fun saveRecentsEntry(recents: Set<Restaurant>) {
    val json = gson.toJson(recents)
    context.datastore.edit { settings ->
        settings[PreferenceKeys.RECENTS_ENTRY] = json
    }
}

override fun readRecentsEntry(): Flow<Set<Restaurant>> {
        return context.datastore.data.map { preferences ->
            val json = preferences[PreferenceKeys.RECENTS_ENTRY] ?: ""
            if (json.isNotEmpty()) {
                val type = object : TypeToken<Set<Restaurant>>() {}.type
                gson.fromJson(json, type)
            } else {
                emptySet()
            }
        }
    }

A unique key (RECENTS_ENTRY) is defined in PreferenceKeys to identify recent restaurant data. This key ensures unique storage in DataStore, avoiding access conflicts. The Context.datastore extension enables DataStore to be accessible throughout the app via context, standardizing usage and simplifying data management.

private object PreferenceKeys {
    val RECENTS_ENTRY = stringPreferencesKey(Constants.RECENTS_ENTRY)
}

DataStore was chosen over a local database like Room due to its lightweight nature and efficiency for handling small, key-value-based datasets, such as recently visited restaurants. Unlike Room, which is better suited for more complex, relational data structures, DataStore offers simpler setup and faster access for small data without the need for complex querying. Additionally, DataStore integrates seamlessly with Kotlin coroutines and flows, making it ideal for reactive and asynchronous data handling, which enhances performance and responsiveness in the app's user experience.

In the Flutter implementation of RestaU the local storage strategy is applied through the shared preferences APIS. SharedPreferences is a simple key-value storage for saving small amounts of data locally on the user's device. It's commonly used for storing user preferences, settings, and other small pieces of persistent data that should be retained across app sessions.

The main application of this strategy is in the Search feature for saving the recent searches for restaurants of the user. To do so, the search_viewmodel class define a couple of functions that manage this local storing mechanism. The first one this saveLastSearchResults() that after loading and parsing the [SharedPreferences] for the app from disk. Saves a list of strings, represented a list of each id from the lasSearched restaurants by the user to persistent storage in the background. We can appreciate the implementation as following:

Future<void> _saveLastSearchResults() async {
    SharedPreferences prefs = await SharedPreferences.getInstance();
    List<String> idList = _lastSearchResults.map((restaurant) {
      return restaurant.id.toString();
    }).toList();
    await prefs.setStringList('lastSearchResults', idList);
  }

The second function is the related to loading the last search results from the persistent storage, this instruction retrieves a list of ids belonging to the last searched restaurants and then passed as argument to the function that fetch a restaurant by its id to retrieve a Restaurant object.

// Cargar resultados recientes desde SharedPreferences
Future<void> _loadLastSearchResults() async {
  SharedPreferences prefs = await SharedPreferences.getInstance();
  List<String>? idList = prefs.getStringList('lastSearchResults');
  
  if (idList != null) {
    // Assuming you have a method to fetch restaurant by id
    _lastSearchResults = await Future.wait(idList.map((id) async {
      return await fetchRestaurantById(id);
    }).toList());
  } else {
    _lastSearchResults = [];
  }
  
  notifyListeners();
}

The kotlin app uses 2 concurrency strategies, multithreading and coroutines. Coroutines are blocks of code that run concurrently, which avoids blocking the main thread. However, they are also not bound to any thread, which allows developers to delegate them or parts of them to other threads and take advantage of the benefits of multithreading. Android/Kotlin has 3 threads where coroutines can be delegated, the Main thread which is in charge of painting the UI and managing user and external events, the IO thread which is optimized for actions such as network calls or retrieving information from the disk, and the Default thread which is a heavy thread for long running tasks. We can change coroutines from threads by using the Dispatchers class in the coroutine creator launch function. By using all this previously mentioned concepts, we can improve performance significantly and develop tasks concurrently.

In the following image, the sendEvent function creates a coroutine in the IO thread.

In the changeCircleRadius function, the method creates a coroutine in the Default thread.

In the following image, the launch function is changed for the async method. The async method is a coroutine that returns a defered object, that will adquire a success or failure value in a point forward in time like promises in javascript.

In all the examples, it can be seen the viewModelScope object which ties all the coroutines to the view model's lifecycle.

The Flutter application uses Futures as its multithreading/concurrency strategy. Futures allow the app to continue its main process while another process happens simultaneously.

In the example above, we use the FutureBuilder to build the list of all restaurants. As these are fetched from Firebase and this process takes time, the use of Futures allows the page to load while the restaurants are being retrieved, displaying them as soon as they become available.

The function for retrieving all restaurants returns a Future list of restaurants, which will be used to load the list.

As a cache strategy, we decided to use a hashmap to store the bitmaps that were retrieved from the network when showing a restaurant's card when clicking a pin in the map. When pressing a pin, if an image is not in the hashmap contained in the state, it is retrieved from the remote firebase storage, if it is, it is simply shown to the user. With this bitmap hashmap, the user will experience less delays when opening a card and observing the related image and resources for making network requests saved, instead of making constant calls to the remote server. This cache is persistent per session given that it is a memory cache stored in the map's view model, when the viewmodel is disposed, this cache will be cleared.

The previous image illustrates the process where in line 194, the cache is checked if the image is already stored, if it isn't, asynchronically (line 195 with the launch method) in line 196, the image is downloaded and saved in the state (lines 197-201) to be shown in the screen when the pin is clicked.

The caching strategy involves saving images of restaurants using the cached_network_image package, which leverages local storage to keep downloaded images accessible offline. When an image is requested, it checks for a local copy of the restaurant image; if available, it serves the cached version, reducing redundant network calls and enhancing load speeds. If a cached copy does not exist, the image is downloaded, displayed, and stored in cache for future use. This setup is optimized for offline accessibility and efficient loading, reducing network usage for frequently requested restaurant images.

This can be seen in the following code:

class CustomCacheManager extends BaseCacheManager {
  static const key = "customCache";

  CustomCacheManager()
      : super(
          key,
          maxAgeCacheObject: Duration(days: 7), 
          maxNrOfCacheObjects: 100,
        );
}

This class creates a cache manager that will store up to 100 images for a maximum of 7 days.

CachedNetworkImage(
  imageUrl: restaurant['imageUrl'],
  cacheManager: CustomCacheManager(),
  placeholder: (context, url) => CircularProgressIndicator(),
  errorWidget: (context, url, error) => Icon(Icons.error),
)

This code snippet displays the image, first checking if it’s in cache; if not, it retrieves the image from imageUrl or shows a circular progress indicator while loading.

This approach significantly improves restaurant image loading times, allowing the app to handle high-frequency image requests with reduced latency and less network dependency.