The Not Do's In Your SmartWatch Application

Introduction and Background

This one is another article in the category of "Android Wear" application development, but with a slightly 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 devices may provide you with! The devices comprise,

Just enough battery power to run the device.
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.
Enough secondary 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 a battery. So you have to keep those things in mind while writing the applications for a smartwatch. It is a smartwatch, but, has very fewer 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 perform 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,

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 the same amount of capabilities and services provided to developers for application development. Android Wear has the API features and specifications for:

The native wearable executables.
Companion application handler objects.
Input/output services and managers.
Managing the views of your applications.
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 as 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,

Get to know what time it is along with the date (Great invention in human history?).
Find out the details about the weather, whether it is rainy or should you consider wearing cotton. (Sure you can look outside the sky and determine what is would be like).
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.

Don't waste the CPU

Wasting the CPU means to waste the cycles that the 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:

Performing too many (unnecessary) calculations.

Arithmetic and other required ones.
Generating graphics at fast refresh rates; 60Hz doesn't make sense.
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 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

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

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 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

publicfinalstaticint 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 they 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 requires 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

You may consider having fewer variables and try to avoid having unnecessary variables.
Avoid immutable types; for example, updating the String values.

Each time your variable is updated, the previous object is deleted (removed from the references that virtual machine holds) and a new object is created and referenced by that variable.

Avoid larger bitmaps and consider the refresh rates, again

SmartWatch has graphics capabilities and allows you to build the applications with graphics, with ease. But graphics must not waste either CPU or RAM. The common problems are 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 a 30Hz rate, using 60Hz doesn't make any sense. Also, if the animation requires a 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

Use smaller drawable, bitmaps.

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

SmartWatch is not yet ready for network-based requests

The wireless connections that the 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 the 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 the 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 the 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.

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 for 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 as 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:

Time
Date
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, the battery is used.

For enabling CPU to execute.
To enable RAM to save or provide the data.
To make the screen able to show the graphics.
To make the connections to the device; using Bluetooth or Wi-Fi.

Everything else...

The battery is needed, for the 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, the 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

The battery is going to be drained, even if you use the smart-device or not; on a standby mode.
CPU, RAM, I/O, Connectivity, Screen, Touch input and other hardware components run on battery!
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.
Try to trigger the functions when the 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:

CPU consumption.
RAM usage.
Graphics rendering and screen pixels content.
Hardware component battery usage.
Connectivity setups 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.

Allow CPU to sleep.

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

30Hz is enough!

Summary

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 SmartWatch.

9 Comments

Join the conversation! Your thoughts help the community grow.

Santhakumar Munuswamy11y ago
Good article
Priyaranjan K S11y ago
Thanks for the share ...
Harshad Pansuriya11y ago
Nice one
Nilesh Jadav11y ago
Great work sir !!
Mukesh Kumar11y ago
Keep it up sir
Afzaal Ahmad Zeeshan11y ago
Ranjan Dailata thank you for your kind and nice words. Exactly, and as having a little experience with SmartWatches and platforms, I must share the experience for building "good applications" to the beginners.
- Ranjan Dailata11y ago
  Keep it up and continue your good work. The more we share, the more we and others will learn.
Ranjan Dailata11y ago
Great! I really like the way you explained.. It's a must for smart watch programmers :)
Yashwant Vishwakarma11y ago
Awesome information !!!