Archive for August, 2012

Windows Phone – Performance Best Practices

Performance issues is where we usually spend most effort in finding, so it is very important to understand how you find them, and how you prevent them in the first place.

This post will be fairly long containing some basic info about performance in apps and at the end go through some of the more common occasions where I usually see performance issues and how to fix them.

Let’s start with looking at the threading model.

Silverlight for Windows Phone has two threads that handle all the presentation related work. One UI Thread and one Composition/Render thread.

UI Thread

The UI thread is the main thread in Silverlight for Windows Phone and functions very similar to the UI thread for the Silverlight browser plug-in.

The UI thread handles all input, which includes touch, parse and create objects from XAML, layout calculations, data binding, draw all visuals (at least the first time they are drawn), rendering/rastering, process per-frame callbacks and execute other user code and event handlers.

Composition Thread

The composition thread is new for SL on WP7, it’s actually the only platform that has it (as far as I know) and is created to talk directly to the graphics processor, GPU. It basically feeds the GPU with textures to draw and handles transform (scale, rotate, translate) animations and plane projections.

The composition thread handles some work that the UI thread would normally handle, and therefore improves performance of Silverlight applications for Windows Phone. The composition thread combines textures and passes them to the GPU for drawing. Also storyboard-driven animations that run on the composition thread are automatically cached and handled by the GPU on the device in a process called auto-caching.

Note: To use the composition thread, scale transforms must be less than 50 percent of the original size.

In addition, opacity and clip property settings are handled by the composition thread. However, if an Opacity mask or non-rectangular clip is used on the animated object, these operations will be passed to the UI Thread. This means that even if the clip region is a rectangular shape but uses the PathGeometry the operations will be passed to the UI thread. So make sure to always use the RectangleGeometry for clipping paths if possible.

Animations and Threads

As mentioned previously, storyboard-driven animations are handled by the composition thread. This is ideal because the composition thread passes these to the GPU for processing. In addition, the composition thread can run more frequently than the UI thread if the CPU is overloaded.

Translate animation will run on the Composition Thread

There are times, however, when storyboard animations do not satisfy the requirements of your application. In this case, you may choose to drive animations in code. These animations are handled on a per-frame basis. In many cases, this is fine, but you should be aware of the implications of running animations on a per-frame callback.

Per-frame callbacks are handled strictly on the UI thread. Animations will update only as fast as the UI thread can process them, and depending on what else is happening in your application, the animations may appear less smooth than if they were running on the composition thread. Also, when you update animations in code, the elements are not automatically cached as they would be if they were updated in a storyboard. If you manually place a bitmap cache on these elements, the transformation and blending is passed to the GPU, but the animation is still being updated on a per-frame callback and processed by the UI thread. In these cases, the animation will update only as fast as the frame rate of the UI thread.

Color animations will run on the UI Thread and if blocked it will miss changing color


It is extremely important to think about threading and have a solid understanding of how critical the UI thread is, it already does a lot as it is, so extremely important not to do to much work on the UI thread then necessary .

Progress bar

One of the most common controls used to show an indication that something is taking time to process is the ProgressBar. Although not everyone knows that the progress bar that is shipped with the SDK is lacking performance, it is running all the animations on the UI thread and is not really a valid option for a progress indicator. If you need to place a progress bar somewhere in the application that is not at the top of the page, then you should use the PerformanceProgressBar that is shipped with the Silverlight Toolkit for WP7. But, that progress bar is not perfect either, it will actually continue executing the animations even if the progress bar is invisible. Toggle visible on and off is often how we show/hide the progress bar, but setting it to indeterminate will make the animation to continue even when it is hidden. So in this case you should also toggle the IsIndeterminate property using the same data binding you use to toggle it’s visibility.


<ProgressBar IsIndeterminate="{Binding IsProgressBarVisible}" Visibility="{Binding IsProgressBarVisible, Converter={StaticResource VisibilityConverter}}" >

The best option with respect to performance is to use the ProgressIndicator on the system tray on an application page. It performs very well and I have never had any issues with it, even when totally blocking the UI thread and have really advanced animations handled by the composition thread.

I often hear that we don’t want to use the ProgressIndicator since that requires the system tray to be visible and it will make the app look bad. But remember that you can set colors, opacity etc. on the system tray so it should not be to hard to design it to fit to the overall design. Changing the opacity on the system tray to something less than 1.0 will make the system tray hover over the page and let the page take the entire area, so you could also toggle the visibility of the system tray in the same way you toggle the progress indication.

Performance Counters


These counters are really important to use and understand, they are in great help when you try to find what the actual performance issue is. You enable/disable the performance counters by toggling EnableFrameRateCounter property in the App constructor.


Composite Thread – Aim for 60 FPS, it becomes red when under 30. 30 FPS doesn’t sound to bad, but MSFT has seen that the experience is not perfect when you come under that threshold, it just doesn’t look and feel good. So try to get at least 45 but aim for 60!

UI Thread – Becomes red when counter is under 15

Video Ram – the number of textures that has been created for all objects, for example a button that has been rasterized to a texture and drawn on the screen.

Internmediate textures – textures that SL has created for us to improve performance. If two or more textures are placed on the same layer, then SL will create one large texture of it so that we do not have to send one texture for each object, instead SL will just send one large.

Fill rate – fill rate tells us how many pixels that we send to the screen in each frame. A fill rate of 1 means that 800×400 pixels are drawn in each frame. There will be performance implications if the fill rate comes larger than 3, to much pixels to process and we get a drop in frame rate.

Redraw Regions

Objects that are animated but does not change, that is, pixels in the image looks identical in each frame but the object is moving, then SL will not have to send all the pixels over and over again to the GPU to calculate what is to be drawn. Instead the composition thread will just animate the object and render the same texture over and over, just in new positions.

By enabling Redraw Regions, then each time SL need to re-calculated and send pixels to the GPU it will be shown by a color tint on the texture with different colors. If we see a lot of flickering then we now something might be wrong.

You enable redraw regions in the same way you enable performance counters, but by toggling the EnableRedrawRegions property.


If we have a lot of flickering and want to remove that due to performance hit, then what we want is to cache the texture on GPU and only tell it to move the object and draw it again, we do not want to send the same pixels over and over again when they are not changing.

Recall in the section above about performance counters and intermediate textures, these sound really good but there might be times when intermediate textures means performance issues. If we have one or more moving objects on the same layer as for example a button, then SL will try to be smart and create an intermediate texture out of these, but since we are animating the objects the intermediate texture needs to be recalculated in each frame and sent to the GPU, so we get a performance drop due to that.

In this case we want to do two things, first of all make sure that pixels for an object that is not changing is not sent to the GPU in each frame and also prevent an intermediate texture from being created since it doesn’t add anything, just gives us worse performance.

The solution to this is setting cache mode. SL is smart and does this for us, but not in all types of animations. If we use a per-frame callback for animations then SL will not cache the texture for us. You set the cache mode manually by setting


for each object you want to cache.


Look at the left part, a lot of redrawing is done while the rectangle is animating to the right

Fill Rate

So fill rate tells us how many pixels we send to be processed in each frame. It’s important to understand that fill rate will increase by 1 if you explicitly set background color on the page. So setting background color on pivots, panels etc. is something you should avoid unless you really need to.

Bitmap Cache sounds like a “silver bullet” if you look at the above example about redraw regions. So shouldn’t we just set cache mode on all objects?

It sounds like a good idea, but the answer is NO! Caching an object means that we increase fill rate since each object becomes its own object that needs to be rendered. And an increased fill rate means a drop in UI thread FPS. For example, if we have an application with a background image of a sky, then several of other images that builds up the scene like trees, hills, bushes, birds etc. If we then set explicit caching on all objects then we will have several layers that the GPU needs to render, even if the texture for one object is not even visible since some other object is drawn in front of it. But if we do not set cache mode explicitly then SL will be smart and create one intermediate texture for us and cache just ONE texture instead of one for each object.

So it really depends on your app, and you have to be smart on when to use and not use bitmap cache, be ware of fill rate. So USE performance counters, use redraw regions etc. to figure out if your app is performing well or not.

Data serialization/deserialization

A Windows Phone app has the possibility to store data on “disc” where all I/O operations are working through Isolated Storage. WP7 works in a sandboxed environment separated from all the other apps on your phone, so it is “safe” to store application specific data on the phone without worrying about other apps accessing your data.

There is a specific API that makes it possible to save application settings as objects in isolated storage really easy, which facilitates storing simple objects a lot.

IsolatedStorageSettings.ApplicationSettings[yourKey] = yourObject;

Even though it is simple to store objects in application settings, you will probably need to serialize and deserialize more advanced/complex objects in isolated storage throughout the application lifecycle. Below are some common occasions when you need to serialize and deserialize data.

  • App Launch – Deserialize
  • App being dormant/tombstoned – Serialize
  • App being reactivated – Deserialize
  • App being terminated – Serialize

So what do we have to think about when serializing data? The most important thing is how long it takes to serialize/deserialize data and when you do it.

First of all there are certification requirements that could be jeopardized and eventually hinder your app from being accepted to marketplace.

Launch Time, your main screen of the app needs to be rendered and shown within 5 seconds and the user needs to be able to interact with your app within 20 seconds.

Activation Time, if an app is deactivated (for example the user clicks the hardware Start button) and later activated, then the app needs to start with the same criteria as app launch time.

Most of our apps will have to save lists of object that you need to cache for quick access when the user returns to your application. This means that we need to serialize data to XML/JSON or some other format when the app is de-activated and when the user returns and the app is re-activated, data needs to be deserialized from isolated storage to a list of objects.

This serialization and deserialization can take time and if we do it in Application_Launching or Application_Activated event handlers then we could end up with performance issues at app startup. You need to think about where and when you need the data, make sure long running processing is done in background workers to prevent blocking the UI. For example, if you have a lot of data that you need to deserialize when starting your app, your app is useless without it, then think about other “dirty tricks” of how to fool the user into believing that your app is starting quickly. Perhaps use a second splash screen, you could even make the second splash screen look like your app (that is take a snapshot of your app en store it as a jpeg) and show that while you are deserializing data.

It is also important to select the correct serialization type, there are several options where some of them are shown in the table below with metrics showing how long it takes to serialize/deserialize 200 objects and 18 000 objects.

Isolated Storage Demo (executed on phone)

200 serialized 200 deserialized 18000 serialized 18000 deserialized
XML 76ms 174ms 6.1s 14.4s
DataC 149ms 191ms 12.9s 16.3s
DataCJSON 131ms 98ms 11.1s 8.4s
JSON.NET 63ms 147ms 5.2s 12.7s
Sharp 282ms 101ms 10.7s 9.6s

Note that this is just how it turned out in my sample app, the numbers could be totally different for your objects so you need to profile and try out different formats before you decide what format you should serialize data to. Most common is using JSON.NET in my experience.


As with serialization and deserialization to and from isolated storage, it is equally important to think about the size of messages that you send and receive over the wire. So use the above table to figure out what type of message to send when creating web services that are consumed from your Windows Phone application. It’s really simple to create a RESTful web service that provides JSON formatted output, so start with that unless you need a specific format.

Below is a screen shot of the message size for different types of message formats. (the sample app fetches all the suppliers that exists in the Northwind database)


JSON data sent: {“Address”:”49 Gilbert St.”,”City”:”London”,”CompanyName”:”Exotic Liquids”,”ContactName”:”Charlotte Cooper”,”ContactTitle”:”Purchasing Manager”,”Country”:”UK”,”Phone”:”(71) 555-2222″,”PostalCode”:”EC1 4SD”,”SupplierID”:1},{“Address”:”P.O. Box 78934″,”City”:”New Orleans”,”CompanyName”:”New Orleans Cajun Delights”,”ContactName”:”Shelley Burke”,”ContactTitle”:”Order Administrator”,”Country”:”USA”,”Phone”:”(100) 555-4822″,”PostalCode”:”70117″,”Region”:”LA”,”SupplierID”:2},{“Address”:”707 Oxford Rd.”,”City”:”Ann Arbor”,”CompanyName”:”Grandma Kelly’s Hom… and so on…

WebClient vs HttpWebRequest

WebClient is a wrapper class around the HttpWebRequest class that is used to perform Web service requests. WebClient can be easier to use because it returns result data to your application on the UI thread, and therefore your application does not need to manage the marshaling of data to the UI thread itself. However, if your application processes the web service data on the UI thread, the UI will be unresponsive until the processing is complete, causing a poor user experience, especially if the set of data being processed is large.

My suggestion is to use HttpWebRequest instead of WebClient and process the resulting data on the asynchronous request thread and then use BeginInvoke to marshal the data to the UI thread.

Making Large Numbers of Requests for Small Amounts of Data

To preserve battery life, the operating system will turn off the device’s radio after a preconfigured timeout interval. If an application is going to make a large number of requests for small amounts of data, I recommend that these requests be executed in parallel instead of serially. This helps to ensure that the device’s radio stack will not go to sleep, avoiding the lag incurred when the radio is powered on and off for each request and also saving battery life. Although there is a limit on maximum outbound network calls the rest will be queued and processed as soon as possible.

Where does it usually go wrong?

Below I’ll try to summarize some of the common performance issues that I have encountered and how to fix them.


Performance issues at startup is probably the most common problem I encounter when helping customer with their apps and causes everything from failed marketplace submissions to users giving up on your app since it takes to long to load and you end up with bad reviews and in worst case no one using your app.

Imagine that you start an app, see the splash screen and eventually the app is shown quickly, but it is really jerky, doesn’t seem to respond to user input and so on. These are the performance issues you really need to think about to fix. So what is actually going on at startup?

Assemblies are loaded and jittered, objects are instantiated and loaded and so on. Although the problem usually doesn’t reside here but it could. More common is what happens after that and all processing that needs to be completed before the app is “done” and fully ready for usage, deserialization of state (tombstone), loading UI (which means XAML parsing, element creation, layout calculations, redering etc).

So what can we do and what should we do to increase app startup time?

1. use a Splash screen and load data during startup. But if the app loads really quickly then you should perhaps remove the splash screen, only use if you need it. Don’t spend time designing the super cool and awesome looking splash screen since it could be so that the app starts really quickly and the user will not really see it to long. I have actually heard about cases when developers has put a Thread.Sleep() during startup to make sure the splash screen is visible longer. Not a good approach :) When the app is loaded you continue loading data that should be shown in background threads and when done publish/display it on UI using the dispatcher.

2. Use a second copy of the splash screen and show that as the first thing in your app with a progress bar if you need to load data from a web service or do something that takes time. But try to avoid this since the user wants to get into your app quickly and immediately start interacting with it. And even if you use a second splash screen with a progress bar you cannot take all the time you want, a max of 3-4 seconds, after that the user will start loosing his/her patience.

3. Keep the assembly size small of all the assemblies that are being loaded at startup. If your assemblies contains complex and demanding constructors, make sure to refactor and move the code to separate assemblies. If the app contains a lot of media like images, videos etc. then think about if you can set “build mode” as Content. If build mode is set to “embedded resources” then they will be loaded each time and make the loading of assemblies heavier, as build mode “Content” then assemblies will be loaded a lot quicker and content will be loaded “on demand”.

4. Keep your XAML clean and as simple as possible, try creating a small visual tree as possible to optimize layout calculations and rendering. Delay creation of controls to a later time when they are really needed and shown. For example in a Panorama all items will be loaded and kept in memory, which means that if you have 5 panorama pages, then all pages will be parsed, loaded and rendered (measure, arrange, bind etc.) on all UI if you do not create a custom page/control virtualization. You could optimize this by only loading the first and +/- one page and when the user pans load adjacent panorama pages and controls.

The Pivot control is using virtualization by default. 3 pages are loaded and kept in memory, current, previous and next pivot page.

One way is to set page visibility as Collapsed until they are needed (this means that they will not even be in the visual tree). But remember that even if you set visibility as Collapsed calculations and processing will still happen before they are eventually hidden from UI. A better approach is to remove XAML and manually add it when needed.

5. A somewhat strange but pretty cool solution is to take a screen shot of the app where you have hidden all dynamic data and then use that as a “second splash screen” while the app warms up loading data etc. and then do a nice fade from “splash screen” to the actual app with live data. In this way we are tricking the user to think that the app starts really quickly, loads some data and shows it. But be aware, this solution could give the wrong feedback to the user since the users cannot interact with the app directly if not done correctly.


When we now have followed all the advices above and the app starts really quickly we often hit the next common performance issue and that is with lists. It often feels like lists are not scrolling fast enough and are a bit jerky, they simply doesn’t perform good enough.

The problem is probably not that the lists doesn’t scroll fast enough, more common is that the phone doesn’t have time to render the UI while you are scrolling quickly.

Long lists are using virtualization by default, which means that SL will keep 3 full “pages” of elements in UI and memory and while we are scrolling new “pages” will be loaded as needed, which means parsing XAML, generating new objects, inserting these into the visual tree, layout calculations, measure, arrange, bind and so on. So there is a lot that needs to be done and if SL doesn’t have time to process this then, bam, you get black “pages” that show up and it feels like the list doesn’t scroll fast enough.

So what should we and can we do to optimize lists?

1. If the list is short, less that 3 full pages, then you should try to use a regular stack panel instead of a virtualizing stack panel (easily accomplished with templates). Using a stack panel all objects will be loaded immediately and you get a perfect scrolling experience.

2. Try to delay loading and processing while you are scrolling, you might end up with scrolling past objects that you will not even see in the end and then it is useless to loaded and process these objects. For example, if you have a list of images that are downloaded from Internet and when you scroll past a lot of images quickly then you do not need to load the images since the user will not even seem them when he/she stops scrolling. Listening to the scroll event is trivial and easy to implement.

3. Another problem is XAML itself. Windows Phone will not cache Data Templates and Control Templates after they are parsed, so by making simpler XAML and binding to less properties you will increase performance. Make sure you do not set properties in XAML that are default values, since that only adds more processing and try to avoid having objects as Collapsed that you don’t even need, they will add processing and eventually a performance hit.

4. Try to avoid value converters in data bindings. Data binding is a low-level operation and if you need to call external code to calculate values then you will have to pay for that. Instead use a ViewModel approach and add convenience properties that gives you the value directly. It is often really easy and possible to add more properties to your ViewModels to contain all the values your UI needs to show, and in the end not use value converters in lists at all.

5. If you still need really advanced XAML and perhaps different XAML for different items in the list then there are some more advanced techniques to use.

A ListBox will by default recycle containers, which is good, we want that to keep our memory footprint low, but there are scenarios where Data Templates becomes really advanced and you might end up with several visuals that are Collapsed or a very complex UI. Again, this means a lot of parsing, object creating etc. that in the en will be hidden for the user. A common solution I usually try to follow is to create one simple base data template that only contains the parts that always will be visible on all items in the list and then manually in code behind decide what XAML should be in the item and manually add them to the visual tree.

The process is fairly simple:

a) start with a “dummy control” with a Control Template that shows elements that are always visible for all list items.

b) create an Attached Property for the control.

c) set the value for the attached property using regular data binding and in the implementation of the attached property and “Property Changed” event handler you generate/create the UI elements needed for the specific item and manually add them to the visual tree.

6. Use third party list controls. There are several developers that has tried to tackle the performance issues with lists, some are good some are not so good, they all seem to have good and bad “features”.

a) DeferredLoadListBox, by David Anson. This list uses a regular stack panel and delays loading of controls. But there is an issue with this control (unless that is fixed in later version then I have tested) and that is that items are not unloaded when they are not used/visible which means that if you have a really long list and scroll a lot, you will hit a memory problem.

b) LongListSelector is an ItemsControl in Silverlight Toolkit that virtualizes the list without using a VirtualizingStackPanel, you can even tweak some parameters like how many pages to keep in memory and how fast it should scroll.

c) LowProfileImageLoader is another awesome control by David Anson and this class helps us with preventing that we load images on the UI thread. This one I have used a lot and think it is a really great asset.

d) LazyListBox by Peter Torr, it basically delays work until we are not scrolling.

So try them out and pick one that suits your needs.


Problems that usually occur is that the UI doesn’t really feel like it responds to user interaction, it might be hard to pan in a panorama or change pivot, you might have to try several times before anything happens. These are really common in several apps I have used and is extremely frustrating every time.

Issues like this most likely is due to that the UI thread has to much to do, remember that the UI threads is responsible of handling touch, parsing and creating objects, rendering/rastering visuals, processing per-frame callbacks etc. so the UI thread has a lot to do as it is, and if we start to do to much work on it our app will have to pay for it. But it can also happen if we do to much work in background threads which also might result in UI thread gets to little time to process.

So what can we and should we do?

1. Simply stop processing to much work on the UI thread, make sure you move any heavy work to a background thread. If you still have issues since the work is to heavy anyway, then you can add artificial sleeps to give the UI thread some slack. Simply add a 1 ms second sleep, Thread.Sleep(1); , and the UI thread will perform a lot better. A 1 ms sleep is something that the users will most likely not see or know about.

2. Use PerformanceProgressBar or ProgressIndicator

3. Try not to use color animations since these will be executed on the UI thread. You can often accomplish the same effect by animating the opacity, but remember that animations with OpacityMasks will be executed on the UI thread so try to avoid using opacity masks on objects that are animated often. I’m not implying that you should never use opacity masks, but you need to think about the consequences. If you need an opacity mask then there is a simple trick that you can use. Place the object in a Canvas and set the CacheMode to BitmapCache and then animate the container instead of the object itself.

4. Use RectangularGeometry for clipping paths on objects that are animated or drawn often, all other types of paths will be sent to the UI thread for processing.

5. Popup is also rendered on the UI thread, might want to change this to a simple Panel where you set z-index and toggle it’s visibility instead, you will get a lot better performance and even support for orientation change in your app.

As I wrote in my previous post about the importance of UX, the perception of how the user thinks your app performs is key. UX is King! So all the “dirty tricks” your can think of are valid, as long as the users gets the impression that your app is performing really well, then all tricks are valid. So be creative and think about how can we trick the user into believing that your app is super fast.

Background Agents

You have the possibility to schedule one Background Agent per application which is executed while your app doesn’t have focus. Each background agent can execute one or both of the following:

Periodic Task – is executed approximately each 30 min or so and is allowed to execute for 25 seconds, use less than 6MB of memory and is automatically un-scheduled if it has more that two adjacent crashes.

Resource Intensive Task – executed if the phone is charging, has WiFi or USB pass through (connected to the computer), the screen is locked and the battery is over 90% charged. So this will most likely occur for example while you are charging your phone during night. A resource intensive task is allowed to execute for approx. 10 minutes and use a maximum of 6MB of memory.

In any of the tasks you can do/access the following

  • Titles
  • Toast
  • Location
  • Network
  • R/W ISO Store
  • Sockets
  • Most of the framework API

The following is not allowed

  • Display any UI
  • Use XNA
  • Access the microphone or camera
  • Sensors
  • Play media (only use background audio API)

I usually ask myself, do I really need a background agent?

If you do, then make sure you do not have any important functionality in them since there are several ways to disable them or prevent them from even being executed:

  • to many are already running, you cannot schedule any more
  • not available at all on 256MB devices
  • prevented by the user in settings
  • battery is to low


You should think about background agents like Batman and Robin, Batman does all the important stuff (your app) while Robin is there once now and then and helps out doing some really simple stuff (your background agent), but Batman is so awesome so he can always handle everything himself, not dependent on Robin at all. You should implement your app the same way, they have to function to a 100% without background agents. I usually try to avoid using background agents in the first place since there are so many cases that could prevent them from being executed in the first place and instead invest in a Push Notification solution.

Location in background agents

if you need to get hold of the geo location in a background task then you might end up not getting them in time. Since a periodic task only has a few seconds to execute them you might not have time to start the GeoCoordinationWatcher to get the exact position. What you can do is to create a GeoCoordinationWatcher object and them immediately get the location, you will then get a cached position that the phone caches for you automatically around each 15 minute or so. Not accurate but might be good enough.

ISO store is available for background agents and is the same used as for the app, so you can easily share information between the app and your background agent. Although there are cases where the agent may try to access the same file in isolated storage at the same time as your app. If you start to or could encounter these types of issues then you should use a Mutex.

Debug background agents using

ScheduleActionService.LaunchForTest(“task name”, TimeSpan);

In that way we can schedule our task to execute each minute or some other timespan that is suitable for testing instead of waiting for 30 minutes. If you start your app debugging and exit the app by pressing the hardware Start button then Visual Studio will not stop debugging so you can easily place break points in your OnInvoke method to debug your task.


Re-Schedule often, each time you start your app since a scheduled agent will be removed after 2 weeks by the phones OS.

Do NOT implement critical functionality in a background agents since it is not sure that your agent will even execute.

if you need a more secure functionality to execute some code now and then to update Tiles or show Toast notifications then evaluate if you cannot use Push Notifications

Well that’s it for now regarding Performance Best Practices for Silverlight Windows Phone apps. There is so much to think about when it comes to performance optimizations, but this post might have given you something to think about and at least gotten your attention on how important it is and that you should always think about it while developing apps for The phone.

Happy Coding!

%d bloggers like this: