Developing network-friendly-applications

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 a CC
Creative Commons Attribution-NoDerivs 3.0 Unported License. BY ND


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.


Making a user wait for a
connection whilst one is not
available would be a poor
experience.

Introducing Network Friendliness
Think UX, Think Network!

A good user experience is essential to the success With increasingly faster networks and faster devices,
of any application, mobile or otherwise. Mobility it is common to see developers assuming that
introduces additional challenges. For example, making “anything goes,” in terms of development, as if the
a user wait for a connection whilst one isn’t available power of the network and device were “unlimited,” or
would be a poor experience. On the other hand, approaching that of desktop environments. This isn’t
giving the user other options whilst the connection is the case.
unavailable might improve the experience. As another
Your users are a lot more sensitive to a poor
example; frequent updating, even when there’s no
experience on mobile devices and are a lot less
new data to download, can cause excessive battery
forgiving. You should pay attention to all aspects
drain, resulting in a poor experience. Moreover, the
of the application design that will have a positive
constant “hammering” of the network with new data
or negative impact on the user experience, which
requests might hinder other users from getting the
includes thinking about the network connection.
best performance from the network.


Network Friendliness

BlueVia encourages “network friendly” application Network-friendly design is a principle of being a good
design. Connected applications share the same “network citizen,” which is something we want to
network resources as other connected applications encourage at BlueVia. Network-friendly design is
in a given geographical area (i.e. within the coverage about improving the mobile experience for all network
area of a mobile cell). The behavior of one connected users, not just your application’s users. Collectively,
application can impact other connected apps within you and your fellow developers can improve the
the same geographic area. overall user experience of all connected applications
on the network. In this document, we focus on
approaches towards network-friendly application

Network-friendly design is design, taking into account the connection to the
a principle of being a good network and how it influences the user experience.
“network citizen”.


Network connections can
exhibit a range of behaviors
that might affect application
performance.

More Than Just a Pipe

For the inexperienced mobile developer, it is easy to We could just ignore these characteristics and hope
assume that the network connection is just a pipe for the best, but delivering an optimum experience for
– it’s there and it works! This view is over-simplistic. your users (the people that matter the most) requires
Network connections can exhibit a range of behaviors that we understand these characteristics and build
that might affect application performance, as shown the intelligence into our applications to accommodate
in the illustration above. them.

Whether you are using a DSL, fibre, LAN or mobile You should also keep in mind that mobile operators
networks, each of these networks has different across the world are gradually switching to “data
characteristics for maximum throughput, end-to-end caps” - i.e. maximum MBytes per day or month. This
delay (latency), signaling overheads and available places a responsibility on you to optimise application
capacity. traffic volumes. Every MB saved is a direct saving from
the customer’s usage bundle. And they’ll love you for
it, especially if they choose to roam abroad.


Being Network-Friendly – The Headlines

Here’s a summary of tips for Application Developers that we will cover in more detail in this document.

Tips include:

• Making as few connections as possible to the • Enabling compression where possible
network, both concurrently and temporally
• Supporting asynchronous messaging, (e.g. using
• Concatenating data transmissions in order to preferred PUSH mechanisms)
lower connection “chattiness”
• Caching frequently used assets
• Closing open connections when they are no
• Using compressed image formats as much as
longer being used
possible
• Where possible using a single TCP session for all
• Utilising optimised codecs to transmit audio and
communications
video over mobile networks
• Ensuring that all TCP sessions are torn down
• Transmitting only information that a device is
correctly (i.e. with FINs)
subsequently able to process
• Using light-weight protocols where possible (e.g.
REST instead of SOAP) • Taking various measures to conserve battery life


Achieving Efficient Network Connections
Overview of Mobile Networks

Before getting into the details of how to achieve However, once resources are allocated to a mobile,
efficient connections, a brief exploration of the nature it is inefficient to release them immediately in case
of cellular connections will highlight the fundamental the mobile needs them again a short while later.
limitations. Otherwise, the overhead of reserving and releasing
resources can overload the signaling channels on
Cellular networks optimise the available capacity
the network, even though there might be enough
to allow many users to share the same physical
capacity to send the actual data. This results in
resource, namely the finite radio spectrum. In sharing
mobiles being “blocked” from the network. Indeed,
the same resources, mobiles essentially “take
this is exactly what happened when the iPhone
turns” whenever there are more mobiles than radio
became so successful and popular so quickly.
bandwidth available. This process involves reserving
resources on the network before a mobile can
transmit or receive data.


When there is a period of inactivity in the try to concatenate sessions, but know that there’s a
transmission of data (e.g. whilst reading a web page), point at which keeping the session active versus re-
the radio network will detect this and move the connecting will work against your user’s battery life.
connection to a less active and less power hungry The trick is to use a variable timer that you can easily
state. The benefit of this requirement is longer change if you start to hear about battery problems
battery life for the device. You can imagine how your from your users!
application design might affect these state changes.
For example, if an application polls for data too often, Most developers are unaware of these issues
it might never achieve the less active state, even and simply assume that the connection
though there is no data to transmit. In other words, behaves like a wired connection. As you can
the business of constantly checking for data, even see, this is not the case. So, let’s now explore
when there isn’t any, will still drain the battery and some recommendations for achieving efficient
hog network resources, thereby degrading the user connections:
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
If an application polls for
take a few seconds (depending on the number of data too often, it might never
achieve the less active state.
users) so if the application is going to transmit and
Z

Z
receive data on a frequent basis it’s better to keep
Z

Z
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
Z

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 significant value
to the user experience (e.g. polling too often for data
that doesn’t change as often as the polling interval).
But, when you do need to use network resources,


Recommendations for achieving efficient connections:

Make as few connections as possible to the network, The installation or removal of a “connected
trying to concatenate communications in order application” should not cause any modification to the
to lower the frequency of transmission instead of device/OS network connectivity settings common to
sending data as and when it becomes available. the platform and all connected apps.

Automatically turning off applications during low If user intervention is needed to configure connection
activity periods for those applications that are not settings, then the application developer should offer
crucial for the user a 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.


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 won’t
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 efficiently. Again, don’t 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 as
soon 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 that’s 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


Configure 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 specific APN. Instead, use the information contained within the platform
APIs for the device to pick up the active data configuration, allowing the device platform to manage API
configurations where possible. This will ensure that more efficient APN settings can be applied globally for
all applications. However, for best flexibility, the user should still be able to edit APN data associated with a
particular application.

Consider putting network
access on a different
execution process to the
main user-interface process.

Roaming users might want to enable data-roaming, but would like to be sure that only essential applications
start 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).


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 the
address book with active presence, then every status update for these users is going to flow 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 benefit 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 first few and display these in the client before waiting to
download 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 benefit
to the user.


Application/widget updates and “Network
Hammering”
All applications require updates to improve or correct Does the network support data voice and data calls
bugs and some widgets are designed to collect and simultaneously? Many 2G networks don’t allow
receive data. In both cases developers can help users both to happen at the same time so if there is a
by considering the frequency of interactions. Key flow of data (automatically or otherwise) this can
things developers should ask are: result in voice calls being missed or failing. Nothing
worse than missing that important call, especially
When’s the best time to do the updates? Off peak
if you’re working for yourself!
times means the user is likely to get a higher speed
and therefore faster update meaning less battery
Has the application and widget been thoroughly
consumption.
tested? Nothing worse than finding your
How often should updates occur? Frequent updates monthly data bundle has been consumed or
could use more data so you might be better off your battery life reduced to minutes because
bundling a number of updates and pushing these an application has a bug and keeps interacting
out at the same time. with a server.

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?


We’ve seen applications that have been poorly A user’s subscription to a service has ended but no
designed and behave unexpectedly in the real world. one told the app that so it keeps retrying. This is
These applications get into an unplanned state and a frequent problem with mobile clients, so ensure
then continuously set up and tear down connections that you have a proper mechanism for disabling
and consume battery. Runaway apps can potentially clients as part of the user deactivation process.
deplete the battery in minutes! Grrrrr! Examples of Users (whom you should always assume are
this include: impatient) will repeatedly hit the button because
“nothing happened”.

A fault or condition develops that stops the
app communicating to the origin server so it
keeps trying.

Runaway apps can potentially
deplete the battery in minutes!


Instant Messaging and other “Chatty” Apps
Isn’t IM just so yesterday? Well no, lots of people
still rely on IM and now the use of “group chat” Some of the best clients we’ve seen use

applications is growing. Moreover, many social a co-ordination server, which the mobile

networking apps, or “socially-enabled” apps device connects for a single TCP/IP session.

increasingly exhibit “chat-like” traffic profiles. Here at The co-ordination server then handles
multiple IM sessions (conversations) via a
Telefonic, we’ve seen a huge difference between good
single TCP/IP socket.
and 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.


Here are some guidelines that might apply to IM and “Chatty” clients (including
social networks):

Do not generate separate sessions for every Hence:
connection.
Do not open lots of TCP sessions if they are not going
Do not use push for keep-alives (as this creates to be actively used. This is a case of being careful
unnecessary paging in the network). in your code design, avoiding things like setting up
sessions as part of initialization only to find that
Do not create a context for every keep- alive and tear
the code pathways later on don’t make use of the
it down again.
initialized resources.
If periodic keep-alives are necessary from the mobile,
Close unwanted sessions elegantly, thus allowing the
current thinking is that the optimum is just under 30
network to keep valid (required) sessions open longer.
mins.
Avoid leaving server applications with hung sessions.
Multiple sessions are often produced because some
devices do not close sessions, either because sessions Always close sessions that are no longer in use or
are intended to be used long term or an application needed.
closed without properly ending the session.

Do not open lots of TCP
connections if they are not going to
be actively used


TCP Session Guidelines: Advice about Content Handling and
Format:
Where possible, use a single TCP session for all
communications. Connected applications should utilize embedded
viewer capabilities on the device for displaying videos.
Ensure all TCP sessions are torn down correctly with
The app should use the mechanism (API) supplied by
FINs etc.
the device to connect with the appropriate viewer.
If TCP sessions exceed an hour, a push service is
Use compressed image formats as much as possible.
recommended.
Consider the use of <canvas> element or SVG for
If a TCP keep alive mechanism is used outside of a
dynamic graphics.
push environment the minimum duration should be
10 minutes. Use cookies sparingly.

Give preference to UDP over TCP. Use optimised codecs to transmit audio and
video over the mobile network, adjusting as much
With multiple application sessions, avoid opening
as possible to the network quality and device
lots of TCP sessions. Instead, consider sharing a
characteristics.
single TCP connection between multiple application
sessions. Make assets as lightweight as possible.

Sessions should be closed elegantly, closing all Ensure errors are handled properly and gracefully,
unused or terminated TCP sessions. Please ensure including appropriate display of user messages.
that your application logic manages connections
If an application is going to reference sensitive
gracefully and carefully.
user information, then it is worth considering best
practises in terms of protecting sensitive data,
Protocols and Data Formats:
especially if a SIM-swap is detected.
Use light-weight protocols and data formats where
possible (e.g. YAML instead of XML)


Processing Power Considerations: Asynchronous and Push Messaging:
Transmit only the information the device is able to
When supporting asynchronous messaging (i.e.
handle and process in a timely fashion.
asynchronous method invocation and asynchronous
Use circular buffering to reuse the RAM at the method dispatching), consider the following:
beginning when memory runs out, notwithstanding
the possibilities of overwriting other data.

Stating the obvious, but do not do work that you do
not need to do, or until you need to do it. For example,
if a translation application downloads text to be Use preferred PUSH mechanisms
translated into another language, then don’t do this instead of polling, or at least put
this under the user’s control.
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.)
Use e-MN (e-Mail Notification, which is an OMA
Be careful with memory allocation. Again, stating
recommendation) so that whenever there is a new
the obvious: do not allocate memory unnecessarily,
e-Mail, the network sends a message (WAP push)
perhaps as part of an overly zealous initialisation
to the device. If the device is “alive”, it will connect
procedure.
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.


Remember that users move between networks
and tariff
Users often now move between different networks and propositions on those networks. Some advice we’d
offer is:

Don’t hardcode the APN settings into your app. Rely on the device APIs to pick up the specific network settings.
As a last resort if you can’t use the native device API then let the user manually change this in the application.

Respect your users’ confidentiality – 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 figure out some other way of protecting the
information.


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 Arellanoo
Head of Mobile Devices

Mr. Harald Heckmann
Technical Devices Vendor Manager

Mr. Javier Lorente
Head of Customer User Interface

Mr. Manuel Cáceres
Job Title: NAS Competence Centre Engineer

Mr. Miguel Lira
New technologies manager

Mr. Neil Warren
Device Technology Manager


For Press and Media Enquiries:

33 Digital
BlueVia@33-digital.com
+44 (0)20 7608 2500

Developing Network-Friendly Applications by bluevia.com is licensed under a CC
Creative Commons Attribution-NoDerivs 3.0 Unported License. BY ND

Developing network-friendly-applications

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (17)

En vedette

En vedette (9)

Similaire à Developing network-friendly-applications

Similaire à Developing network-friendly-applications (20)

Plus de BlueVia

Plus de BlueVia (13)

Dernier

Dernier (20)

Developing network-friendly-applications