developing network friendly applications

8/22/2019 Developing Network Friendly Applications

1/21

Developing Network-Friendly Applications

Tips on improving and optimising the user experience when

developing applications that connect via a mobile network.

Edited by: Paul Golding, Chief Disruptor, BlueVia Labs & James Parton, BlueVia Marketing

Developing Network-Friendly Applications by bluevia.com is licensed under aCreative Commons Attribution-NoDerivs 3.0 Unported License.

CC

BY ND
http://creativecommons.org/licenses/by-nd/3.0/http://creativecommons.org/licenses/by-nd/3.0/http://creativecommons.org/licenses/by-nd/3.0/http://creativecommons.org/licenses/by-nd/3.0/http://creativecommons.org/licenses/by-nd/3.0/http://bluevia.com/


2/21


The great news is that the boom in mobile apps development and smartphone proliferation has brought

a whole new generation of developers into the mobile world. The choice of applications has never been

better. The downside is that the dramatic increase in network usage can have a negative impact on the user

experience of connected applications. This document will outline strategies and techniques for trying to

improve the user experience through the best use of network resources and network friendly development

approaches at both the application and OS level.


3/21


Introducing Network Friendliness

Think UX, Think Network!

A good user experience is essential to the success

of any application, mobile or otherwise. Mobility

introduces additional challenges. For example, making

a user wait for a connection whilst one isnt available

would be a poor experience. On the other hand,

giving the user other options whilst the connection is

unavailable might improve the experience. As another

example; frequent updating, even when theres no

new data to download, can cause excessive battery

drain, resulting in a poor experience. Moreover, the

constant hammering of the network with new data

requests might hinder other users from getting the

best performance from the network.

With increasingly faster networks and faster devices,

it is common to see developers assuming that

anything goes, in terms of development, as if the

power of the network and device were unlimited, or

approaching that of desktop environments. This isnt

the case.

Your users are a lot more sensitive to a poorexperience on mobile devices and are a lot less

forgiving. You should pay attention to all aspects

of the application design that will have a positive

or negative impact on the user experience, which

includes thinking about the network connection.

Making a user wait for a

connection whilst one is not

available would be a poor

experience.


4/21


Network Friendliness

BlueVia encourages network friendly application

design. Connected applications share the same

network resources as other connected applications

in a given geographical area (i.e. within the coverage

area of a mobile cell). The behavior of one connected

application can impact other connected apps within

the same geographic area.

Network-friendly design is a principle of being a good

network citizen, which is something we want to

encourage at BlueVia. Network-friendly design is

about improving the mobile experience for all network

users, not just your applications users. Collectively,

you and your fellow developers can improve the

overall user experience of all connected applications

on the network. In this document, we focus on

approaches towards network-friendly application

design, taking into account the connection to the

network and how it inuences the user experience.

Network-friendly design is

a principle of being a good

network citizen.


5/21


More Than Just a Pipe

For the inexperienced mobile developer, it is easy to

assume that the network connection is just a pipe

its there and it works! This view is over-simplistic.

Network connections can exhibit a range of behaviors

that might affect application performance, as shown

in the illustration above.

Whether you are using a DSL, bre, LAN or mobile

networks, each of these networks has different

characteristics for maximum throughput, end-to-end

delay (latency), signaling overheads and available

capacity.

We could just ignore these characteristics and hope

for the best, but delivering an optimum experience for

your users (the people that matter the most) requires

that we understand these characteristics and build

the intelligence into our applications to accommodate

them.

You should also keep in mind that mobile operators

across the world are gradually switching to data

caps - i.e. maximum MBytes per day or month. This

places a responsibility on you to optimise application

trafc volumes. Every MB saved is a direct saving from

the customers usage bundle. And theyll love you for

it, especially if they choose to roam abroad.

Network connections can

exhibit a range of behaviors

that might affect application

performance.


6/21


Being Network-Friendly The Headlines

Heres a summary oftips for Application Developers that we will cover in more detail in this document.

Tips include:

Making as few connections as possible to the

network, both concurrently and temporally

Concatenating data transmissions in order to

lower connection chattiness

Closing open connections when they are nolonger being used

Where possible using a single TCP session for all

communications

Ensuring that all TCP sessions are torn down

correctly (i.e. with FINs)

Using light-weight protocols where possible (e.g.

REST instead of SOAP)

Enabling compression where possible

Supporting asynchronous messaging, (e.g. using

preferred PUSH mechanisms)

Caching frequently used assets

Using compressed image formats as much as

possible

Utilising optimised codecs to transmit audio and

video over mobile networks

Transmitting only information that a device is

subsequently able to process

Taking various measures to conserve battery life


7/21


Achieving Efcient Network Connections

Overview of Mobile Networks

Before getting into the details of how to achieve

efcient connections, a brief exploration of the nature

of cellular connections will highlight the fundamental

limitations.

Cellular networks optimise the available capacity

to allow many users to share the same physical

resource, namely the nite radio spectrum. In sharing

the same resources, mobiles essentially take

turns whenever there are more mobiles than radio

bandwidth available. This process involves reserving

resources on the network before a mobile can

transmit or receive data.

However, once resources are allocated to a mobile,

it is inefcient to release them immediately in case

the mobile needs them again a short while later.

Otherwise, the overhead of reserving and releasing

resources can overload the signaling channels on

the network, even though there might be enough

capacity to send the actual data. This results in

mobiles being blocked from the network. Indeed,

this is exactly what happened when the iPhone

became so successful and popular so quickly.


8/21

ZZ

ZZ

Z


When there is a period of inactivity in the

transmission of data (e.g. whilst reading a web page),

the radio network will detect this and move the

connection to a less active and less power hungry

state. The benet of this requirement is longer

battery life for the device. You can imagine how your

application design might affect these state changes.

For example, if an application polls for data too often,it might never achieve the less active state, even

though there is no data to transmit. In other words,

the business of constantly checking for data, even

when there isnt any, will still drain the battery and

hog network resources, thereby degrading the user

experience (including those in the cell who might be

blocked from getting network resources).

The process of moving between active and less active

states also consumes power in itself. However, there

is a potentially more pressing issue to consider, which

is that reconnecting to a more active state can also

take a few seconds (depending on the number of

users) so if the application is going to transmit and

receive data on a frequent basis its better to keep

the connection in an active state in order to avoid

delays in the user experience. This contradicts the

earlier advice of letting your application move to an

idle state in order to save power, so what should you

do? The answer is to avoid unnecessary polling or

communication that is not adding signicant value

to the user experience (e.g. polling too often for data

that doesnt change as often as the polling interval).

But, when you do need to use network resources,

try to concatenate sessions, but know that theres a

point at which keeping the session active versus re-

connecting will work against your users battery life.

The trick is to use a variable timer that you can easily

change if you start to hear about battery problems

from your users!

Most developers are unaware of these issuesand simply assume that the connection

behaves like a wired connection. As you can

see, this is not the case. So, lets now explore

some recommendations for achieving efcient

connections:

If an application polls for

data too often, it might never

achieve the less active state.


9/21


Recommendations for achieving efcient connections:

Make as few connections as possible to the network,

trying to concatenate communications in order

to lower the frequency of transmission instead of

sending data as and when it becomes available.

Automatically turning off applications during low

activity periods for those applications that are notcrucial for the user

The installation or removal of a connected

application should not cause any modication to the

device/OS network connectivity settings common to

the platform and all connected apps.

If user intervention is needed to congure connection

settings, then the application developer should offera wizard-type tool to simplify the process in order

to avoid user error that could interfere with proper

connection performance.

Make as few connections

as possible to the network,

trying to concatenate

communications.


10/21


Any open connections that are no longer being used should be closed properly You should use delay tolerant

techniques. For example, consider putting network access on a different (i.e. background) execution process

to the main user-interface process. In this way, if the network process becomes blocked or sluggish, it wont

necessarily have an impact on the user interface process. Your app should break content into small pieces that

can be downloaded separately and coded more efciently. Again, dont assume that the network will give the

application constant and consistent network performance for the duration of a download or session. Perhaps

a software update, for example, could be carried out in stages rather than one big download. You should

program your app to release connections as soon as possible, letting the radio layers of the software know assoon as possible that a connection resource can be released (for low-level device drive design, please see Fast

Dormancy - http://gsm.org/documents/TS18_v10_TSG_PRD_Fast_Dormancy_Best_Practices.pdf).

It hopefully goes without saying, but use mobile network connection only when there are no others available

(e.g. WiFi). This seems obvious, but an application might simply (and naively) use the current/available

connection, which might a 3G connection, just because thats the state the device is currently in even though a

WiFi connection might be available. Applications with heavy data requirements could remind the user to switch

back to WiFi (if possible).

Use mobile network

connection only when there

are no others available


11/21


Congure widgets or active icons so that they are updated on an infrequent basis in background. Although

the update frequency might be selectable by the user, it is down to the application developer to suggest

sensible settings and adopt friendly defaults.

Avoid coding an application to use a specic APN. Instead, use the information contained within the platform

APIs for the device to pick up the active data conguration, allowing the device platform to manage API

congurations where possible. This will ensure that more efcient APN settings can be applied globally for

all applications. However, for best exibility, the user should still be able to edit APN data associated with a

particular application.

Roaming users might want to enable data-roaming, but would like to be sure that only essential applicationsstart consuming network resources. Many devices can allow an application to check the roaming status of

the device. If so, you should take advantage of this in your design and adopt the default setting to avoid

connections whilst roaming unless granted by the user.

Radio connections and associated Data Context sessions can take several seconds to set up. Short delays do

not necessary mean failure. It could be that the session has been queued for resource allocation and will still

be serviced, or that the device is busy with another transaction. Remember that your application does not

have exclusive access to the device resources, sessions or bandwidth (e.g. be prepared to wait while other

transactions complete).

Consider putting network

access on a different

execution process to the

main user-interface process.


12/21


When a data session is set up, the radio system has a number of controlled states that should be observed. For

example, do ensure that timeout states are long enough - tearing down the session and retrying will just use

more power and take longer in the end.

If a session is going to transmit and receive data on a frequent basis, it is better to leave the session open.

Overall, try to optimise network requests by batching requests, throttling low-priority requests and backing off

during periods of inactivity. Instant-message presence updates are a classic example where throttling can have

a major impact on network performance and battery life. For example, if an IM client has 100 friends in theaddress book with active presence, then every status update for these users is going to ow from the IM server

to the client, even though the client might not be active in the foreground. Slowly, these updates will drain the

battery without offering any benet to the user.

Deploy design techniques at the application level to minimize the perceived latency due to network delays.

For example, when gathering data to update the application display, consider scheduling some partial updates

to the display before waiting for all of the data to be downloaded. A classic example is an e-mail client that

needs to download 50 e-mails. Why not download the rst few and display these in the client before waiting todownload the rest? In this way, even if the network is slow, the application itself can still seem responsive.

Too many IM updates will drain the

battery without offering any benet

to the user.


13/21


Application/widget updates and Network

Hammering

All applications require updates to improve or correct

bugs and some widgets are designed to collect and

receive data. In both cases developers can help users

by considering the frequency of interactions. Key

things developers should ask are:

Whens the best time to do the updates? Off peak

times means the user is likely to get a higher speed

and therefore faster update meaning less battery

consumption.

How often should updates occur? Frequent updates

could use more data so you might be better offbundling a number of updates and pushing these

out at the same time.

If the user has a monthly data allowance, is it

better to allow the user to decide when to do an

update rather than automatically updating?

Does the network support data voice and data calls

simultaneously? Many 2G networks dont allow

both to happen at the same time so if there is a

ow of data (automatically or otherwise) this can

result in voice calls being missed or failing. Nothing

worse than missing that important call, especially

if youre working for yourself!

Has the application and widget been thoroughly

tested? Nothing worse than nding your

monthly data bundle has been consumed or

your battery life reduced to minutes becausean application has a bug and keeps interacting

with a server.


14/21


Weve seen applications that have been poorly

designed and behave unexpectedly in the real world.

These applications get into an unplanned state and

then continuously set up and tear down connections

and consume battery. Runaway apps can potentially

deplete the battery in minutes! Grrrrr! Examples of

this include:

A fault or condition develops that stops the

app communicating to the origin server so it

keeps trying.

A users subscription to a service has ended but no

one told the app that so it keeps retrying. This is

a frequent problem with mobile clients, so ensure

that you have a proper mechanism for disabling

clients as part of the user deactivation process.

Users (whom you should always assume are

impatient) will repeatedly hit the button because

nothing happened.

Runaway apps can potentially

deplete the battery in minutes!


15/21


Instant Messaging and other Chatty Apps

Isnt IM just so yesterday? Well no, lots of people

still rely on IM and now the use of group chat

applications is growing. Moreover, many social

networking apps, or socially-enabled apps

increasingly exhibit chat-like trafc proles. Here at

Telefonic, weve seen a huge difference between goodand bad IM client applications. These are probably

some of the toughest apps to optimise and it will

always be a judgement call on the right trade-off

between the messaging performance and battery life.

Some of the best clients weve seen use

a co-ordination server, which the mobile

device connects for a single TCP/IP session.

The co-ordination server then handles

multiple IM sessions (conversations) via a

single TCP/IP socket.


16/21


Here are some guidelines that might apply to IM and Chatty clients (includingsocial networks):

Do not generate separate sessions for every

connection.

Do not use push for keep-alives (as this creates

unnecessary paging in the network).

Do not create a context for every keep- alive and tear

it down again.

If periodic keep-alives are necessary from the mobile,

current thinking is that the optimum is just under 30

mins.

Multiple sessions are often produced because somedevices do not close sessions, either because sessions

are intended to be used long term or an application

closed without properly ending the session.

Hence:

Do not open lots of TCP sessions if they are not going

to be actively used. This is a case of being careful

in your code design, avoiding things like setting upsessions as part of initialization only to nd that

the code pathways later on dont make use of the

initialized resources.

Close unwanted sessions elegantly, thus allowing the

network to keep valid (required) sessions open longer.

Avoid leaving server applications with hung sessions.

Always close sessions that are no longer in use or

needed.

Do not open lots of TCP

connections if they are not going to

be actively used


17/21


TCP Session Guidelines:

Where possible, use a single TCP session for all

communications.

Ensure all TCP sessions are torn down correctly with

FINs etc.

If TCP sessions exceed an hour, a push service is

recommended.

If a TCP keep alive mechanism is used outside of a

push environment the minimum duration should be

10 minutes.

Give preference to UDP over TCP.

With multiple application sessions, avoid opening

lots of TCP sessions. Instead, consider sharing a

single TCP connection between multiple application

sessions.

Sessions should be closed elegantly, closing all

unused or terminated TCP sessions. Please ensure

that your application logic manages connections

gracefully and carefully.

Protocols and Data Formats:

Use light-weight protocols and data formats where

possible (e.g. YAML instead of XML)

Advice about Content Handling andFormat:

Connected applications should utilize embedded

viewer capabilities on the device for displaying videos.

The app should use the mechanism (API) supplied by

the device to connect with the appropriate viewer.

Use compressed image formats as much as possible.

Consider the use of element or SVG for

dynamic graphics.

Use cookies sparingly.

Use optimised codecs to transmit audio and

video over the mobile network, adjusting as much

as possible to the network quality and devicecharacteristics.

Make assets as lightweight as possible.

Ensure errors are handled properly and gracefully,

including appropriate display of user messages.

If an application is going to reference sensitive

user information, then it is worth considering bestpractises in terms of protecting sensitive data,

especially if a SIM-swap is detected.


18/21


Processing Power Considerations:Transmit only the information the device is able to

handle and process in a timely fashion.

Use circular buffering to reuse the RAM at the

beginning when memory runs out, notwithstanding

the possibilities of overwriting other data.

Stating the obvious, but do not do work that you donot need to do, or until you need to do it. For example,

if a translation application downloads text to be

translated into another language, then dont do this

until the user needs it, and then only for the parts

that he or she reads. (Also, consider off-loading these

tasks to the server anyway.)

Be careful with memory allocation. Again, statingthe obvious: do not allocate memory unnecessarily,

perhaps as part of an overly zealous initialisation

procedure.

Asynchronous and Push Messaging:

When supporting asynchronous messaging (i.e.

asynchronous method invocation and asynchronous

method dispatching), consider the following:

Use e-MN (e-Mail Notication, which is an OMA

recommendation) so that whenever there is a new

e-Mail, the network sends a message (WAP push)

to the device. If the device is alive, it will connect

to get this new e-Mail. This way, the device is not

continuously sending messages to the network to

say: I am alive.

For clients that need to access a number of server-

side resources across different URIs, consider the use

of server-side aggregation, which co-ordinates access

to multiple TCP sessions in the network and presents

them as only one TCP session to the mobile client.

Use preferred PUSH mechanisms

instead of polling, or at least put

this under the users control.


19/21


Remember that users move between networks

and tariff

Users often now move between different networks and propositions on those networks. Some advice wed

offer is:

Dont hardcode the APN settings into your app. Rely on the device APIs to pick up the specic network settings.

As a last resort if you cant use the native device API then let the user manually change this in the application.

Respect your users condentiality If an application has information a user may deem sensitive then consider

deleting this data if the SIM has been swapped in the device or gure out some other way of protecting the

information.


20/21


Contributors

Mr. Eric Robotham

Head of Network Architecture, End to End Design and Data Access at O2 UK

Mr. Athar Meo

Senior Engineer Test (Radio Networks)

Ms. Esther ArellanooHead of Mobile Devices

Mr. Harald Heckmann

Technical Devices Vendor Manager

Mr. Javier Lorente

Head of Customer User Interface

Mr. Manuel CceresJob Title: NAS Competence Centre Engineer

Mr. Miguel Lira

New technologies manager

Mr. Neil Warren

Device Technology Manager


21/21


For Press and Media Enquiries:

33 Digital

[email protected]

+44 (0)20 7608 2500

Developing Network-Friendly Applications bybluevia.com is licensed under a CC
mailto:bluevia%4033-digital.com?subject=http://creativecommons.org/licenses/by-nd/3.0/http://creativecommons.org/licenses/by-nd/3.0/http://creativecommons.org/licenses/by-nd/3.0/http://creativecommons.org/licenses/by-nd/3.0/http://creativecommons.org/licenses/by-nd/3.0/http://creativecommons.org/licenses/by-nd/3.0/http://bluevia.com/mailto:bluevia%4033-digital.com?subject=

developing network friendly applications

Documents