Developing Network-Friendly ApplicationsTips on improving and optimising the user experience whendeveloping applications that connect via a mobile network.Edited by: Paul Golding, Chief Disruptor, BlueVia Labs & James Parton, BlueVia MarketingDeveloping Network-Friendly Applications by bluevia.com is licensed under a CCCreative Commons Attribution-NoDerivs 3.0 Unported License. BY ND
Developing Network-Friendly ApplicationsThe great news is that the boom in mobile apps development and smartphone proliferation has broughta whole new generation of developers into the mobile world. The choice of applications has never beenbetter. The downside is that the dramatic increase in network usage can have a negative impact on the userexperience of connected applications. This document will outline strategies and techniques for trying toimprove the user experience through the best use of network resources and “network friendly” developmentapproaches at both the application and OS level.
Developing Network-Friendly ApplicationsMaking a user wait for aconnection whilst one is notavailable would be a poorexperience.Introducing Network FriendlinessThink 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 thatintroduces additional challenges. For example, making “anything goes,” in terms of development, as if thea user wait for a connection whilst one isn’t available power of the network and device were “unlimited,” orwould be a poor experience. On the other hand, approaching that of desktop environments. This isn’tgiving 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 poorexample; frequent updating, even when there’s no experience on mobile devices and are a lot lessnew data to download, can cause excessive battery forgiving. You should pay attention to all aspectsdrain, resulting in a poor experience. Moreover, the of the application design that will have a positiveconstant “hammering” of the network with new data or negative impact on the user experience, whichrequests might hinder other users from getting the includes thinking about the network connection.best performance from the network.
Developing Network-Friendly ApplicationsNetwork FriendlinessBlueVia encourages “network friendly” application Network-friendly design is a principle of being a gooddesign. Connected applications share the same “network citizen,” which is something we want tonetwork resources as other connected applications encourage at BlueVia. Network-friendly design isin a given geographical area (i.e. within the coverage about improving the mobile experience for all networkarea 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 thethe same geographic area. overall user experience of all connected applications on the network. In this document, we focus on approaches towards network-friendly applicationNetwork-friendly design is design, taking into account the connection to thea principle of being a good network and how it influences the user experience.“network citizen”.
Developing Network-Friendly Applications Network connections can exhibit a range of behaviors that might affect application performance.More Than Just a PipeFor the inexperienced mobile developer, it is easy to We could just ignore these characteristics and hopeassume 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) requiresNetwork connections can exhibit a range of behaviors that we understand these characteristics and buildthat might affect application performance, as shown the intelligence into our applications to accommodatein the illustration above. them.Whether you are using a DSL, fibre, LAN or mobile You should also keep in mind that mobile operatorsnetworks, each of these networks has different across the world are gradually switching to “datacharacteristics for maximum throughput, end-to-end caps” - i.e. maximum MBytes per day or month. Thisdelay (latency), signaling overheads and available places a responsibility on you to optimise applicationcapacity. 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.
Developing Network-Friendly ApplicationsBeing Network-Friendly – The HeadlinesHere’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
Developing Network-Friendly ApplicationsAchieving Efficient Network ConnectionsOverview of Mobile NetworksBefore 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 caseof 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 onCellular networks optimise the available capacity the network, even though there might be enoughto allow many users to share the same physical capacity to send the actual data. This results inresource, 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 iPhoneturns” whenever there are more mobiles than radio became so successful and popular so quickly.bandwidth available. This process involves reservingresources on the network before a mobile cantransmit or receive data.
Developing Network-Friendly ApplicationsWhen there is a period of inactivity in the try to concatenate sessions, but know that there’s atransmission 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 easilystate. The benefit of this requirement is longer change if you start to hear about battery problemsbattery 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 issuesit might never achieve the less active state, even and simply assume that the connectionthough there is no data to transmit. In other words, behaves like a wired connection. As you canthe business of constantly checking for data, even see, this is not the case. So, let’s now explorewhen there isn’t any, will still drain the battery and some recommendations for achieving efficienthog network resources, thereby degrading the user connections:experience (including those in the cell who might beblocked from getting network resources).The process of moving between active and less activestates also consumes power in itself. However, thereis a potentially more pressing issue to consider, whichis that reconnecting to a more active state can also If an application polls fortake 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 Zreceive data on a frequent basis it’s better to keep Z Zthe connection in an active state in order to avoiddelays in the user experience. This contradicts theearlier advice of letting your application move to an Zidle state in order to save power, so what should youdo? The answer is to avoid unnecessary polling orcommunication that is not adding significant valueto the user experience (e.g. polling too often for datathat doesn’t change as often as the polling interval).But, when you do need to use network resources,
Developing Network-Friendly ApplicationsRecommendations for achieving efficient connections:Make as few connections as possible to the network, The installation or removal of a “connectedtrying to concatenate communications in order application” should not cause any modification to theto lower the frequency of transmission instead of device/OS network connectivity settings common tosending 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 connectionactivity periods for those applications that are not settings, then the application developer should offercrucial 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.
Developing Network-Friendly ApplicationsAny 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 processto the main user-interface process. In this way, if the network process becomes blocked or sluggish, it won’tnecessarily have an impact on the user interface process. Your app should break content into small pieces thatcan be downloaded separately and coded more efficiently. Again, don’t assume that the network will give theapplication constant and consistent network performance for the duration of a download or session. Perhapsa software update, for example, could be carried out in “stages” rather than one big download. You shouldprogram 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 “FastDormancy” - 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/availableconnection, which might a 3G connection, just because that’s the state the device is currently in even though aWiFi connection might be available. Applications with heavy data requirements could remind the user to switchback to WiFi (if possible). Use mobile network connection only when there are no others available
Developing Network-Friendly ApplicationsConfigure widgets or “active icons” so that they are updated on an infrequent basis in background. Althoughthe update frequency might be selectable by the user, it is down to the application developer to suggestsensible settings and adopt friendly defaults.Avoid coding an application to use a specific APN. Instead, use the information contained within the platformAPIs for the device to pick up the active data configuration, allowing the device platform to manage APIconfigurations where possible. This will ensure that more efficient APN settings can be applied globally forall applications. However, for best flexibility, the user should still be able to edit APN data associated with aparticular 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 applicationsstart consuming network resources. Many devices can allow an application to check the roaming status ofthe device. If so, you should take advantage of this in your design and adopt the default setting to avoidconnections whilst roaming unless granted by the user.Radio connections and associated Data Context sessions can take several seconds to set up. Short delays donot necessary mean failure. It could be that the session has been queued for resource allocation and will stillbe serviced, or that the device is busy with another transaction. Remember that your application does nothave exclusive access to the device resources, sessions or bandwidth (e.g. be prepared to wait while othertransactions complete).
Developing Network-Friendly ApplicationsWhen a data session is set up, the radio system has a number of controlled states that should be observed. Forexample, do ensure that timeout states are long enough - tearing down the session and retrying will just usemore 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 offduring periods of inactivity. Instant-message presence updates are a classic example where throttling can havea 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 flow from the IM serverto the client, even though the client might not be active in the foreground. Slowly, these updates will drain thebattery 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 updatesto the display before waiting for all of the data to be downloaded. A classic example is an e-mail client thatneeds to download 50 e-mails. Why not download the first 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 benefit to the user.
Developing Network-Friendly ApplicationsApplication/widget updates and “NetworkHammering”All applications require updates to improve or correct Does the network support data voice and data callsbugs and some widgets are designed to collect and simultaneously? Many 2G networks don’t allowreceive data. In both cases developers can help users both to happen at the same time so if there is aby considering the frequency of interactions. Key flow of data (automatically or otherwise) this canthings 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?
Developing Network-Friendly ApplicationsWe’ve seen applications that have been poorly A user’s subscription to a service has ended but nodesigned and behave unexpectedly in the real world. one told the app that so it keeps retrying. This isThese applications get into an unplanned state and a frequent problem with mobile clients, so ensurethen continuously set up and tear down connections that you have a proper mechanism for disablingand 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 arethis 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!
Developing Network-Friendly ApplicationsInstant Messaging and other “Chatty” AppsIsn’t IM just so yesterday? Well no, lots of peoplestill rely on IM and now the use of “group chat” Some of the best clients we’ve seen useapplications is growing. Moreover, many social a co-ordination server, which the mobilenetworking 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 aTelefonic, we’ve seen a huge difference between good single TCP/IP socket.and bad IM client applications. These are probablysome of the toughest apps to optimise and it willalways be a judgement call on the right trade-offbetween the messaging performance and battery life.
Developing Network-Friendly ApplicationsHere are some guidelines that might apply to IM and “Chatty” clients (includingsocial networks):Do not generate separate sessions for every Hence:connection. Do not open lots of TCP sessions if they are not goingDo not use push for keep-alives (as this creates to be actively used. This is a case of being carefulunnecessary paging in the network). in your code design, avoiding things like setting up sessions as part of initialization only to find thatDo not create a context for every keep- alive and tear the code pathways later on don’t make use of theit down again. initialized resources.If periodic keep-alives are necessary from the mobile, Close unwanted sessions elegantly, thus allowing thecurrent 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 somedevices do not close sessions, either because sessions Always close sessions that are no longer in use orare 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
Developing Network-Friendly ApplicationsProcessing 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 asynchronousUse circular buffering to reuse the RAM at the method dispatching), consider the following:beginning when memory runs out, notwithstandingthe 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 Use preferred PUSH mechanismstranslated 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 partsthat he or she reads. (Also, consider off-loading thesetasks to the server anyway.) Use e-MN (e-Mail Notification, which is an OMABe careful with memory allocation. Again, stating recommendation) so that whenever there is a newthe 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 connectprocedure. 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.
Developing Network-Friendly ApplicationsRemember that users move between networksand tariffUsers often now move between different networks and propositions on those networks. Some advice we’doffer 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 considerdeleting this data if the SIM has been swapped in the device or figure out some other way of protecting theinformation.
Developing Network-Friendly ApplicationsContributorsMr. Eric RobothamHead of Network Architecture, End to End Design and Data Access at O2 UKMr. Athar MeoSenior Engineer – Test (Radio Networks)Ms. Esther ArellanooHead of Mobile DevicesMr. Harald HeckmannTechnical Devices Vendor ManagerMr. Javier LorenteHead of Customer User InterfaceMr. Manuel CáceresJob Title: NAS Competence Centre EngineerMr. Miguel LiraNew technologies managerMr. Neil WarrenDevice Technology Manager
Developing Network-Friendly Applications For Press and Media Enquiries: 33 Digital BlueVia@33-digital.com +44 (0)20 7608 2500Developing Network-Friendly Applications by bluevia.com is licensed under a CCCreative Commons Attribution-NoDerivs 3.0 Unported License. BY ND