Eventual Connectivity Scenarios

Scenario 1: No network in authentication process

• ID: 1

• Event description: The user is filling the signup or login screens with the personal data. When the user decided to sent the petition to authenticate, but the petition fail because the user has no network.

• System response: Cancel the petition and show to user an informative message explain that he needs network to authenticate.

• Possible Anti-patterns: Non-Informative Message: Inconsistent Message or Generic Messsage; Stuck progress notification

• Caching and retrieving strategy: Network Only. But if the app has information about last authentication in preferences, the application don´t need to authenticate the user.

• Storage type: Local data manager to preferences, and cache to save information typing in the text fields.

• Stored data type: The user email could be saved to avoid rewriting, in preferences we save the user id of last use.

Scenario 2: Offline waiting turn

• ID: 2

• Event description: The user is waiting their turn, but the connection is lost

• System response: Store the last information about the user turn and show a message indicating the connectivity problem and ask the user to arrive at the place or recover the connection.

• Possible Anti-patterns: #3 Non-Informative Message, #1 Blocked Application

• Caching and retrieving strategy: Network falling back to cache

• Storage type: Cache manager

• Stored data type: Information related to the turn like single value turn number and single value current turn number of the queue.

Scenario 3: No network in recommended places

• ID: 3

• Event description: The user wants to go to recommended screen, but he has not network connectivity.

• System response: System need to alert that user hasn't connection and retrieve information saved in local storage, if user hasn´t data in local storage the application must shown only the message of no network connectivity.

• Possible Anti-patterns: Non-existent result notification, Lost Content, Non-informative message.

• Caching and retrieving strategy: Cached on network response.

• Storage type: Local Storage data manager.

• Stored data type: We will save information about the last recommended places.

Scenario 4: Lost connectivity while joining a queue.

• ID: 4

• Event description: The user is about to join into a queue of a restaurant. It processes the petition retreiving the place data to send a request to the server, but the connection was lost and it could not be sended.

• System response: The application blocks the botton and shows a message explaining that the connection was lost.

• Possible Anti-patterns: #3 Non-Informative Message. #7 Unavailable functionality after connection recovery.

• Caching and retrieving strategy: Network Only.

• Storage type: Local Storage

• Stored data type: The loaded places by the user is a List of ObjectPlaces that contains information about the place, such as id, name, and address. In this way, when the connectivity is back, the application could send the request after connvection recovery.

Scenario 5: Offline active turn

• ID: 5

• Event description: It is the turn of the user, but it lost the connection

• System response: Notify and inform the user through a message about the connectivity problem and caching the last information about the turn state

• Possible Anti-patterns: #3 Non-Informative Message, #1 Blocked Application

• Caching and retrieving strategy: Network falling back to cache

• Storage type: Cache manager

• Stored data type: Turn state. In our application the turn can have a fourth state: cancelled, waiting, active and ended. In this case the state single value about the active state turn.

Scenario 6: Offline profile data

• ID: 6

• Event description: The user is about to see his app profile with his stats. When he enters the screen, the connection was lost and the app can't retrieve data about the user.

• System response: Cancel the retrive operation and get the information stored in the local storage.

• Possible Anti-patterns: #3 Blocked Application #4 Lost Content

• Caching and retrieving strategy: Network falling back to cache

• Storage type: Local Storage

• Stored data type: The app saves information about the user in preferences, and the information in local storage about the common places of an user.

Scenario 7: No network in common places

• ID: 7

• Event description: The user goes to home screen to see their common places, but the connection is lost

• System response: A message indicating the network problem appears and the last list of common places is stored in cache

• Possible Anti-patterns: #3 Non-Informative Message, #1 Blocked Application, #8 Unclear behavior, #4 Lost of content

• Caching and retrieving strategy: Network falling back to cache

• Storage type: Cache manager

• Stored data type: Map of common places. Every place has information like address, name, city, count of visit.