ISIS-3510

3.0
EVENTUAL
CONNECTIVITY
Should we handle offline
scenarios in mobile
apps?
Mobile apps are expected to run on
an environment with high
computational capabilities, local
storage, and access to a diverse set
of on-device hardware components
and sensors
How different are
web apps from
mobile apps?
Web apps are executed in a browser
that limits the access to hardware
components and computational
capabilities
Web apps are highly dependent
(often) on code that is executed at the
server side
Why do we need
apps with offline
capabilities and local
storage?
CASE STUDY 1:
Dairo is a maintenance operator for boilers. Every day,
before starting his shift, he downloads his working plan to
his tablet. Today, his first visit was at the Maliott hotel
(according to the plan)

At 8:00 am, Dairo was at the boilers room of the hotel (-2
floor). His report included photos and descriptions of the
situation. When he came back to the lobby, he taped on
the “Send report” button, at his tickets app, but the app
displayed an error dialog with the message “Wrong id
for the boilers room”
CASE STUDY 1:
This is a list of events that can help you to find
the issue:
- 8:00 am: Dairo gets into the boilers room (-2 floor)
- 8:01 am: Dairo's tablet lost connectivity
- 8:45 am: Dairo’s supervisor (Carlos) realized that the working plan
had an error, and there was a typo on the name of the hotel for the
first visit. The right name is “Marriott”
- 8:46: Carlos updated the hotel name at the centralized DB
- 9:05: Dairo left the room, and as soon as he got to the lobby the
tablet had connectivity again
- 9:06: There is an error when submitting the report data to the server
CASE STUDY 2:
Luisa is a maintenance operator for boilers. Every day,
before starting her shift, she downloads her working plan
to her tablet. Today, her first visit was at the W hotel
(according to the plan)

At 8:00 am, Luisa was at the boilers room of the hotel (-2
floor). Her report included photos and descriptions of the
situation. The report form has about 20 input fields. Before
leaving the room, the tablet turned off because the battery
was without juice. She went up stairs to plug the tablet to
an energy outlet. But, when she launched the app, all the
information was lost.
CASE STUDY 3:
Pierre is a maintenance operator for boilers. Every day,
before starting his shift, he downloads his working plan to
his tablet. Today, his first visit was at the Kapital hotel
(according to the plan)

At 8:30 am, Pierre was at the boilers room of the hotel (-2
floor). His report included photos and descriptions of the
situation. The report form has about 20 input fields. Before
leaving the room, he got a call from his supervisor, via
Skype. Carlos told him that there was a typo at the hotel’s
name. When the call was over, Pierre went back to the
tickets app, but it crashed and the report data was lost
How to enable
offline
experiences?
Apps need to combine
local storage strategies
with data retrieving and
fetching strategies
Cache: data stored locally with the
purpose of avoiding long computations/
invocations required get the requested
data
Cache (permanent): the data is always
available in the device, unless the user
deletes it or there is an over-the-air data
update

Cache (temporal): transient data that is

periodically deleted by the user, the app,
or the operating system
DATA CACHING
+RETRIEVING
STRATEGIES
Always offline: content is never requested from
internet

Offline first: content is queried first locally,

and then from internet if not available locally

Online first: content is queried first from internet,

and then from local cache if not available via internet

Always online: content is always requested from

internet
1. Cache, falling back to network:

This is the offline-first most used strategy. You

always retrieve data from cache/local storage,
but if there is a miss, then you ask the data to the
backend services
X Cache
Content
Manager
1. Cache, falling back to network:

This is the offline.first most used strategy. You

always retrieve data from cache/local storage,
but if there is a miss, then you ask the data to the
backend services
Cache
Content
Manager

2
2. Network only:

Data is always requested to the network because

the requests are not idempotent, or it is so
expensive to keep local storage

Cache
Content
Manager

1
3. Network falling back to cache:

The app is provided with the most up-to-date

content, but in the case of offline scenarios you
provide an older cached version

Cache
Content
Manager

X
3. Network falling back to cache:

The app is provided with the most up-to-date

content, but in the case of offline scenarios you
provide an older cached version
2
Cache
Content
Manager

X
4. Cached on network response:

The data is retrieved from the network and

duplicated locally on the cache/local storage

2
Cache
Content
Manager

1
5. Cache then network:

Cached data is shown first, then the data is

updated in both cache and UI when the data
from the network arrives
1
Cache
Content
Manager
5. Cache then network:

Cached data is shown first, then the data is

updated in both cache and UI when the data
from the network arrives

Cache
Content
Manager

2
5. Cache then network:

Cached data is shown first, then the data is

updated in both cache and UI when the data
from the network arrives
3
4 Content
Cache

Manager

2
6. Generic fallback:

If you fail to serve something from the cache and/

or network you may want to provide a generic
fallback.

X Cache
Content
Manager

X
6. Generic fallback:

If you fail to serve something from the cache and/

or network you may want to provide a generic
fallback.

X Cache
Content
Manager

Fallback
local
resource
RECAP of data caching + retrieving
strategies

1. Cache, falling back to network - Email

2. Network only - Rappi, Zoom, Pokemon Go
3. Network falling back to cache - Translator
4. Cached on network response - Facebook,
Instagram
5. Cache then network - Facebook, Instagram
6. Generic fallback - Whatsapp
DATA
FETCHING
STRATEGIES
When would you update
cached data?
Data fetching strategies
At launch time: every time the app is launched
(e.g., Mario Kart Tour). Splash or download dialog is
displayed while the data is downloaded

At launch time (background fetch): the data is

updated by using a background worker

Pull (on user demand): the data is retrieved from

the network with a user command (e.g., Gmail)
Data fetching strategies
Expiration policy: every x secs/mins data is
updated; the expiration time can be set up by the
user

Via notification (push): a backend-server notifies

the app when new data must be retrieved
What aspects should be
considered when
designing the eventual
connectivity strategy?
1. Identify single points of failure
(SPoF) in your app

2. What is going the happen the first

time the user opens the app?

3. What features will require an offline

experience?

4. Storage limitations in the devices

5. Data expiration policy

6. The offline/fallback resources to be

used (e.g., images)

7. How are you going to detect eventual

connectivity events? On demand?
With a background service?
ANTI-
PATTERNS
EVENTUAL CONNECTIVITY
ANTI-PATTERN #1: BLOCKED APP
Event: The application finds a
connectivity problem.

Response: An app process fails and

the app gets blocked.

Problem: The app assumes there is

always connection and is not catching
an (un)expected exception
ANTI-PATTERN #2: STUCK PROGRESS NOTIFICATION

Event: The application finds a

connectivity problem while loading
elements.

Response: The progress bar gets stuck

until the users change to other view.

Problem: The progress bar is not hidden

because the app does not detect the
lack of connectivity
ANTI-PATTERN #3: NON-INFORMATIVE MESSAGE

Event: The device has a

connectivity problem.

Response: A message is shown

saying that there was an error.

Problem: The message is generic

and it doesn’t explain why there was
a connectivity error
 ANTI-PATTERN #3 (EXAMPLES)

https://drive.google.com/file/d/0B6rmz9iRQx89N0lLRlNKSnMzN2c/view

https://drive.google.com/file/d/0B6rmz9iRQx89cGkxVm42bWFXWVk/view

https://drive.google.com/file/d/0B6rmz9iRQx89SEFRNi0tS19wWTg/view

https://drive.google.com/file/d/0B6rmz9iRQx89M2VJaUtDTWZIZEU/view
ANTI-PATTERN #3
ANTI-PATTERN #4: LOST CONTENT

Event: The application finds a

connectivity problem.

Response: It shows empty,

incomplete, or blurred content

Problem: There is no content were

there is supposed to be.
 ANTI-PATTERN #4 (EXAMPLES)

https://drive.google.com/file/d/0B6rmz9iRQx89TVhoM09Zdm9YanM/view

https://drive.google.com/file/d/0Bxilg6hEwsQqdE11bVNiQjYzVUk/view

https://drive.google.com/file/d/0B6rmz9iRQx89Y3lmejdiMUlyTms/view
ANTI-PATTERN #5: NON-EXISTENT RESULT
NOTIFICATION

Event: The user invokes an action related

to a connectivity process

Response: There is no message

showing if the actions were carried out or
not

Problem: The user needs to do a refresh

or other action to verify the app behavior
ANTI-PATTERN #6 & 10: REDIRECTION W/O
CONNECTIVITY CHECK

Event: The application redirects you to

another view while it finds a connectivity
problem.

Response: The new view is empty or

shows problems

Problem: The app did not check the

connectivity before redirecting to the view
ANTI-PATTERN #7: UNAVAILABLE FUNCTIONALITY AFTER
CONNECTION RECOVERY

Event: The user invokes an action

related to a connectivity process while
not having good connection

Response: The action is unavailable

Problem: The action was disabled

when the connection was restored
ANTI-PATTERN #8:UNCLEAR BEHAVIOR

Event: The user invokes an action

related to a connectivity process.

Response: The behavior is unexpected

Problem: The reason for the behavior is

unclear
 ANTI-PATTERN #8

https://drive.google.com/file/d/0B1tqnYuNn8J7XzI2V0xtSmM4NVE/view

https://drive.google.com/file/d/0B1tqnYuNn8J7czRyaWhJRm43VWM/view

https://drive.google.com/file/d/0B6rmz9iRQx89WWdTa3dzM2pOYVk/view
ANTI-PATTERN #9:UNEXPECTED RESULT FROM
BACKGROUND PROCESS

Event: The user invokes an action

related to a connectivity process.

Response: There is no indication that

the action was performed or that it will
be executed later

Problem: The process is queued to be

executed later, but the user is not
notified