The not-dos in your smartwatch application

Introduction and Background

This one is another article in the category of "Android Wear" application development, but with a slight different point-of-view. In the previous posts, I had been talking about the "how-to"s and "what-is" of the programming. In this short guide, I will talk about a few things that you may do to ruin the entire concept of "efficiency". You do get the point of "limited memory and battery power", don't you? 

If you do understand the platform of a smartwatch, then you will find it easier to understand the logic and reason of this article post. Almost every smartwatch has the same hardware and software features and services on it. So, whether it'd be Android Wear (generally) or any other smartwatch that you are having in mind, the hardware components and software services are (more or less) the same as to what other device may provide you with! The devices comprise of, 

1. Just enough battery power to run the device
2. Just enough memory to run a few components 
   • Showing time and date is one of them.
   • Handling the services, Android Wear may listen to users saying, "Ok Google...".
   • Just a few other things like drawing the Watch Faces; which is indeed another service.
3. Enough seconday storage to save a few things, which includes the operating system also. 

Due to these facts, most smartwatches do not have the services that most users might want to use, and the practices are always enforced because developers may want to go just above the curve and for the sake of "good service" may waste the resources, like battery. So you have to keep those things in mind while writing the applications for a smartwatch. It is a smartwatch, but, has very less resources and needs not to heat up. Do you expect to tie a heatball on your wrist?

In this post of mine, I will enlist a few of those practices that won't cost you much but will ensure that your applications performs better and also the user using your application won't have to burn the resources from both ends just to make sure the application runs!

You may want to read other articles that I have posted, 

1. The ABC of Android Wear applications
2. Creating the watch faces for Android Wear

This post will focus on tips to fine-tuning the applications that you develop! 

What does Android Wear API have?

Although my post is more directly related to Android Wear only, but generally almost all of these smartwatches have same amount of capabilities and services provided to developers for application development. Android Wear has the API features and specifications for:

1. The native wearable executables.
2. Companion application handler objects. 
3. Input/output services and managers.
4. Managing the views of your applications.
5. Generating the Watch Faces for your clients.

These services are the ones that are meant to be used and served to the clients. You can for sure use other services, like Wi-Fi, but that is not recommended as it would simply drain the battery life. The package index has a list for these services and APIs and also has the descriptions for you.

The "don't do"s

First of all, I will enlist the topics that may cause your application to burn the resources from both ends. I will point out a few of them, and I will point out how to avoid these conditions and problems in your code. 

The smartwatch, in my humble opinion, is not yet ready as a framework or a platform to be used like you may use any other watch or any other Smart device. First of those things is, the resources available in a smartwatch device. The smartwatch, may or may not have (depending on your application's complexity) enough support for you to even continue using it (as its name claims it to be) for a day! Your average watch, can tell you the date and time, plus if you just try to look above in the sky, you will be able to determine what weather it is, cloudy, sunny etc. Plus, if you simply just remember what your wife or boss told you to do later today, you won't have to carry another application or device to remind you later about events. 

Smartwatch, claims to take care of all of them. Smartwatches provide you with options to:

1. Get to know what time it is along with the date (Great invention in human history?)
2. Find out the details about weather, whether it is rainy or should you consider wearin cotton. (Sure you can look outside the sky and determine what is would be like)
3. What you want to do later this day, events are managed and shown as you expect them to happen. (I'll leave this to the SmartWatch to handle)

But, what most developers do is they try to move beyond the verge, and try to force it to do what it is not intended to. Also, if you have read the article (that I suggested above), you will find the conversation that I had with OriginalGriff a lot compelling! The base for this post and a few sections in it are also having their core basis on those words that he used back in that conversion. 

1. Don't waste the CPU

Wasting the CPU means to waste the cycles that CPU generates for working with different processes and instructions. Each instruction requires a bunch of cycles, more the cycles, more CPU has to work. Consequently, more CPU has to work, more it conserves the battery. 

CPU can be wasted in many ways:

1. Performing too many (unnecessary) calculations.
   Arithmetic and other required ones.
2. Generating graphics at fast refresh rates; 60Hz doesn't make sense.
3. Performing network-based requests and actions
   SmartWatch must not perform network based requests, instead consider performing those actions on the connected handheld device. 

There are many other factors, like a bad code, bad software design, bad implementation etc. all of these factors cause your application to waste the CPU. In the next sections, such as network, RAM and other similar ones, CPU is again used. So, the most important factor is the CPU. Always try to save the CPU cycles and allow CPU to rest, when your application or user doesn't want to interact.

Tips

1. Avoid using CPU all the time!
2. Wait for user to interact with the device to continue another function.
3. Avoid running another function all the time, in the background.
4. Consider running such background tasks in the handheld device!
5. Perform the time consuming, network requests and mathematical operations on the handheld and then transmit the results to the device using the companion application.

2. Don't waste the RAM

Coming down the waterfall, after CPU, RAM is another major factor that may cause your users to go madly in love with your application to mad about the application's bad UX. Each variable that you create in your application consumes RAM. Although RAM is a random-access memory, it doesn't mean that you can fill it with every garbage value that you may have. The variables in your applications like

public final static int PI = 3.14; 
// You can memorize that value, can't you? And use it as a literal in the code

// Or at worse
int add(int a) {
   int b = 5;
   int c = a + b;
   return c;
}

That was just hypothetical, most of developers do not do this, and those who do, don't, just don't do it. 

Hint: If you didn't get the point for what is going wrong up there, 

int add(int a) {
   return a + 5;
}

Avoid making variables where you can use the literals, or already available data. 

In SmartWatch, the graphics that you create for the canvas are also calculated and stored in the RAM. The graphics, bitmaps and other resources are available in the RAM so that can be used later. Also, if you manipulate the graphics objects they also use the CPU. As mentioned, CPU is a core factor that is used in almost every process, so updating the contents of the RAM also require a few CPU cycles. It is not just the RAM you are wasting but the CPU cycles also!

Each time RAM is updated, CPU has to update the content by sending them to RAM and RAM then updates the addresses, then CPU has to be notified that content is updated and so on. So it again requires a lot of CPU cycles. Each time you run an animation, graphics objects are updated (based on the matrices and other data that you provide) and so CPU has to run the cycles to complete the request and then update the screen. 

Tips

1. You may consider having less variables, and try to avoid having unnecessary variables. 
2. Avoid immutable types; for example updating the String values. 
   Each time your variable is updated, previous object is deleted (removed from the references that virtual machine holds) and a new object is created and referenced by that variable.

3. Avoid larger bitmaps and consider the refresh rates, again

SmartWatchs have graphics capabilities and allow you to build the applicatins with graphics, with ease. But graphics must not waste either CPU or RAM. The common problems is that you may use a single graphics object or drawable resource. Consider using a size that doesn't require a lot of CPU processing, RAM space and so on. The graphics that you generate, need to be rendered and CPU cycles are at stake here again. 

You can trim the sides of the bitmaps and drawable resources, to make them fit as to what you need. If your image has white spaces, removed them, trim the corners, remove additional empty areas in the drawable resource. Smaller drawable would require less CPU to be computed, less RAM to be stored and less time to be rendered on the screen. 

The device can also render the animations with a 30Hz refresh rates. Most of the graphics, for your SmartWatch can be rendered with a full crisp view with 30Hz rate, using 60Hz doesn't make any sense. Also, if the animation requires 60Hz refresh rate, then it is not efficient for the SmartWatch, re-consider the design and approach for that animation and make it appropriate for the SmartWatch. 

Tips

1. Use smaller drawables, bitmaps. 
   They save, CPU and RAM plus the time required to render them.
2. Use 30Hz refresh rate for animations that you run.
3. Use a different bitmap for separate devices which is fine-tuned to work perfectly for that device's size and screen's pixel density. 

4. SmartWatch is not yet ready for network-based requests

The wireless connections that Android team has provided are just to connect the device with your handhelds. They are not meant for network based communications with the world around you! Initially, only bluetooth was supported for communications. Now, Wi-Fi has also been added to the library. It can still make requests to HTTP servers. But, that is not a good approach!

You must never build applications that send HTTP requests using Wi-Fi on device, as it will consume the battery life on the device. Although Wi-Fi, would send the requests to the HTTP servers, you can download the content from Web API in JSON format, but that is not guaranteed to work because Wi-Fi is turned off as soon as companion app is connected using Bluetooth. So, Wi-Fi will be turned off and battery life used will be wasted (in sending that HTTP requests and waiting for a response). 

Android Team recently pushed another update, Always-on and Wi-Fi with the latest Android Wear update. The update explains that although software support for Wi-Fi has been added, you must rely on Data Layer in Android Wear and companion wear to communicate with external world. The Wi-Fi must not be used for HTTP requests, that is what the handheld device is there for. Use that device to download the data and then send it to your watch. 

5. Save battery! 

It is not a humanitarian cause that I am going to write here, but a good UX one, users are not fond of caring their device chargers with them to make sure they charge the device every 12-24 hours. Samsung's Gear devices have this problem, if the devices are used like a user may use a SmartWatch, the devices need to be charged regularly. 

If you have to charge a device regularly, then an analog watch may suffice to show you:

1. Time
2. Date
3. Events (if you can remember the where and when of them)

... And it comes with a 30-days of battery life! Even more in most watches. 

In all of the above cases, battery is used.

1. For enabling CPU to execute.
2. To enable RAM to save or provide the data
3. To make the screen able to show the graphics
4. To make the connections to the device; using Bluetooth or Wi-Fi.
5. Everything else...

Battery is needed, for very basic execution of the Android itself. No matter how hard they try to work, in making the devices keep themselves alive with a constant use, max time is 2 days (or a week on standby). The problem is again battery, and your application is not keeping the battery usage in mind, may drain the battery power it has in an hour. Never do that. 

That was the most common idea of wasting the battery, battery is used by other devices and hardware components attached too. For example, the vibrators and other sensors also use battery life to function. The vibrators in your SmartWatch must not be used for a long time as it would consume battery life. By default in Android, vibrator is turned off after 6 seconds. The sensors, would consume the battery life if they need to be run continuously. 

Tips

1. Battery is going to be drained, even if you use the smart-device or not; on a standby mode.
2. CPU, RAM, I/O, Connectivity, Screen, Touch input and other hardware components run on battery! 
3. Hardware components need to be fine-tuned and the APIs need to be re-configured to make sure they are using the battery life that is sufficient and are not wasting it. 
4. Try to trigger the functions when user wants them to. Don't always continue to execute functions and force the CPU to work. Allow CPU to rest!

Points of Interest

In the above post, I have mentioned a few of the factors that cause your application to drain the resources and tips that you may use to make the application better for your users. The tips are based on software engineering practices to make sure that the design of the application is implemented to make the application efficient. 

The tips have been given based on:

1. The CPU consumption.
2. RAM usage.
3. Graphics rendering and the screen pixels content. 
4. Hardware component battery usage.
5. Connectivity set ups and so on.

Plus, the tasks that require a background thread, need to be pushed and kept on the handheld, where battery, CPU and RAM resource is much higher. You should consider performing complex tasks there, and then send the response or the result over to the SmartWatch to display! 

1. Allow CPU to sleep.
   Only trigger the CPU to wake up and perform calculations when user wants to. Do not start the activities on your own, programmatically. 
2. Keep the RAM free of garbage variables, try to save most of the data on handheld and transmit it to the device when needed!
3. Do not use hardware components (e.g. vibrators and sensors) for a long time. It is annoying (vibrating the device on wrist) and also wastes the battery life.
4. Use small drawable resources. Smaller resources use less CPU cycles, less RAM space, less time for rendering and are better. 
5. Use a lesser frame refresh rate
   30Hz is enough!

Finally, keep the resources in mind before creating anything for Android Wear! It is not yet ready as a platform to do smart things. The same thing was said when laptops originated, the battery, CPU and RAM were problems. Now that is not much of a problem. SmartWatches will soon get enough resources and power to run for a week performing the tasks that we need them to. But until that time, let us try avoiding wasting the resources. 

Have a great time building the applications for Smart Watch! :-)