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 Creative Commons Attribution-NoDerivs 3.0 Unported License.
CC
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 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 poor experience 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.
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
Network-friendly design is a principle of being a good network citizen.
design, taking into account the connection to the network and how it influences the user experience.
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 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, fibre, 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 traffic 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.
Being Network-Friendly The Headlines

Heres 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 network, both concurrently and temporally Concatenating data transmissions in order to lower connection chattiness Closing open connections when they are no longer 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) Taking various measures to conserve battery life 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
Achieving Efficient Network Connections

Overview of Mobile Networks
Before getting into the details of how to achieve efficient 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 finite 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 inefficient 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.
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 benefit 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 significant 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 reconnecting 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 issues and 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 efficient connections:
If an application polls for data too often, it might never achieve the less active state.
Recommendations for achieving efficient 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 not crucial for the user The installation or removal of a connected application should not cause any modification to the device/OS network connectivity settings common to the platform and all connected apps. If user intervention is needed to configure connection settings, then the application developer should offer 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 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 efficiently. 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 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 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
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 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 off bundling 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 flow 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 finding your monthly data bundle has been consumed or your battery life reduced to minutes because an application has a bug and keeps interacting with a server.
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 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.
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

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 traffic profiles. Here at Telefonic, weve seen a huge difference between good 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. 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.
Here are some guidelines that might apply to IM and Chatty clients (including social 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 some devices 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 up sessions as part of initialization only to find 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
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.
Advice about Content Handling and Format:

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 <canvas> 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 device characteristics. 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 best practises in terms of protecting sensitive data, especially if a SIM-swap is detected.
Protocols and Data Formats:

Use light-weight protocols and data formats where possible (e.g. YAML instead of XML)
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 do not 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, stating the 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 preferred PUSH mechanisms instead of polling, or at least put this under the users control.
Use e-MN (e-Mail Notification, 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 serverside 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 wed offer is: Dont 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 cant 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 Cceres 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 Creative Commons Attribution-NoDerivs 3.0 Unported License.
CC
BY ND

Developing Network Friendly Applications

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Developing Network Friendly Applications

Diunggah oleh

Hak Cipta:

Format Tersedia

Developing Network-Friendly Applications