Book Image

Android High Performance Programming

By : Emil Atanasov, Enrique López Mañas, Diego Grancini
Book Image

Android High Performance Programming

By: Emil Atanasov, Enrique López Mañas, Diego Grancini

Overview of this book

Performant applications are one of the key drivers of success in the mobile world. Users may abandon an app if it runs slowly. Learning how to build applications that balance speed and performance with functionality and UX can be a challenge; however, it's now more important than ever to get that balance right. Android High Performance will start you thinking about how to wring the most from any hardware your app is installed on, so you can increase your reach and engagement. The book begins by providing an introduction to state–of-the-art Android techniques and the importance of performance in an Android application. Then, we will explain the Android SDK tools regularly used to debug and profile Android applications. We will also learn about some advanced topics such as building layouts, multithreading, networking, and security. Battery life is one of the biggest bottlenecks in applications; and this book will show typical examples of code that exhausts battery life, how to prevent this, and how to measure battery consumption from an application in every kind of situation to ensure your apps don’t drain more than they should. This book explains techniques for building optimized and efficient systems that do not drain the battery, cause memory leaks, or slow down with time.
Table of Contents (17 chapters)
Android High Performance Programming
Credits
About the Authors
About the Reviewer
www.PacktPub.com
Preface
Index

Business value of software quality


Developers often need to justify to non-technical peers why some decisions are taken that do not bring immediate value (think about refactoring an old module or developing some test coverage). There is a clear gap between the business and engineer departments that needs to be reconciled.

When we have to discuss with other departments the business value of decisions that have been made for the sake of software quality, I always like to mention the word "money". Making some decisions, in the long run, is equivalent to saving money and providing direct value to the software. They might not generate an immediate output, or a corporeal item (as much as software can be corporeal), but they certainly will come back in the future with some benefits. I can remember a few situations when refactoring a piece of software at the right moment made the difference between having a sustainable artifact that could be extended and having a monolith, as the result of many bad design decisions, that nobody was able to maintain and in the end meant money and financial costs. The following figure reveals the losses and consequences for companies over time due to bad software quality:

This graph has been taken from a document by David Chappell, and it explains some examples of when bad software quality incurs financial loss. Losing value from lost business might remind us of when Sony closed the PlayStation network due to a network attack. If the software had been properly designed and protected, the network might have been able to keep operating, but poor design led to the company losing a considerable amount of money. A financial loss due to customer reparations happens every time a company needs to compensate clients for a problem happening as a consequence of a poor software system. The obvious financial loss from lost customers will happen when customers do not want to acquire any more services provided by an infamous company! Financial loss from lawsuits is inevitable in many cases, especially when privacy issues or stolen data are involved (and they can be very expensive!).