Enums in Android

Ounces equal pounds, pounds equal pain

I’ve recently been interviewing around for Android Developer positions, and something that surprised me was how frequently my interviewer would ask language specific questions. I had ( wrongly ) assumed that most questions would focus on the Android platform, as that’s what most of the Glassdoor interview questions seemed to focus on. Since then I’ve started devoting a little more time to researching and learning about ways to use Java’s unique properties to make my applications more efficient and bug free.

I think that for a number of developers working on something as specific as Android, there can be an almost blind focus on learning the newest and hottest libraries, instead of really nailing down their fundamentals. As such, I’m going to cover a little topic I’ve been researching and playing around with, and hopefully you’ll take it into consideration next time you open up Android Studios.

I was about to use an Enum class for an application I’ve been working on, and in my research I came across this fragment on Stack Overflow. So much love for that site. Coming straight from from the Google Developers training site is this quote about using Enums in apps:

Be aware of memory overhead

Be knowledgeable about the cost and overhead of the language and libraries you are using, and keep this information in mind when you design your app, from start to finish. Often, things on the surface that look innocuous may in fact have a large amount of overhead. Examples include:

  • Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.
  • Every class in Java (including anonymous inner classes) uses about 500 bytes of code.
  • Every class instance has 12-16 bytes of RAM overhead.
  • Putting a single entry into a HashMap requires the allocation of an additional entry object that takes 32 bytes (see the previous section about optimized data containers).

A few bytes here and there quickly add up—app designs that are class- or object-heavy will suffer from this overhead. That can leave you in the difficult position of looking at a heap analysis and realizing your problem is a lot of small objects using up your RAM.

Full page here: https://developer.android.com/topic/performance/memory.html#Overhead

Little things like this are what I live for. Maintaining the mindset that ounces equal pounds and cents equal dollars has made me a more attentive and efficient person, and I think we could all use more of this mindset when developing for fun and on the job.

Thanks for reading, and happy coding.

Sieve of Eratosthenes

I have seen a LOT of algorithms since diving into Computer Science, but the Sieve of Eratosthenes model for generating prime numbers has so far been my favorite. I think most of us have been in a situation where learning a new algorithm that only slightly boosts amortized run time or space complexity while adding a hundred lines of code, but for me, the Sieve of Eratosthenes was such a mind boggling improvement I had to write about it. There are likely hundreds of ways to generate prime numbers, and check if a number is prime. One of the first programs I ever wrote was a JavaScript program that checked if a number was prime by iterating through all the numbers less than the input value, and checking if all numbers below THAT were divisible by the earlier iterative. Not such a program. At least I can admit it happened, right?

The Sieve of Eratosthenes works by generating a list of boolean values for each number less than our input, and setting them all to true. We then start at 2, and since it is marked as true, we know it is prime. We then mark off all numbers in our boolean set that are divisible by two as False, since any number divisible by a prime is obviously not prime. We then move to 3, and since it is marked as True, we know it is prime. We then mark off all multiples of 3, and repeat this process. We terminate the program when the square of a prime number is greater than our input value, and return our list of prime numbers. If we want a list of integers returned instead of an array of boolean values, we could just iterate through our list, appending the index of each cell still marked as true.

My code on GitHub can be found here if you want to check it out:

https://github.com/n8sters/Sieve-of-Eratosthenes/blob/master/SieveOfEratosthenes.java

While it may not be the most interesting, the simplicity and efficiency of this algorithm compared to the naive approach makes it worth mentioning. Additionally, it dates back to roughly 276 B.C., which is just cool.

Thanks for reading!

AsyncTask and the Mayfly

AsyncTask and the Mayfly

 

I was going to write this post exclusively on the AsyncTask loader in Android studio, but after reading a number of blog posts, YouTube comments and recalling a conversation I had at the Google Dev Group meeting a couple weeks ago, I think I want to touch on a slightly different subject; framework lifecycle and the hack’n’patch nature of the tech industry.

Multithreading is an important part of mobile development, more so than in a traditional computer program because of the limited RAM and internet connectivity. Moving network requests and other such tasks to a background thread allows for a more fluid and immersive experience. Using the AsyncTask loader is how Android was presented to me, so when I went to learn more on my own, that’s where I began my search. After watching a couple videos on the Android Developer YouTube channel and reading some posts on Stack Overflow, it seemed that while using AsyncTask isn’t that difficult, not many “professional developers” use it in a professional context. According to a number of users, most developers use multithreading libraries and dependency injectors like Needle and Dagger in their day-to-day activities. I don’t know about you, but trying to learn something while concurrently being told I will never use the skill I am trying to master is terribly demoralizing. I am going to have to trust that the folks over at Udacity and Google are asking me to learn this for a good reason. I suspect it is one of those things that every Android developer has to understand at a fundamental level, so that if a library or dependency injector is not longer supported, the developer can still use the basic AsyncTask loader.

This bring me to my second point, the lifespan of frameworks and libraries. I haven’t been in this industry long enough to experience it much myself, but a discussion topic I see mentioned very frequently revolves around the short lifespan of frameworks. From what I have read, most experienced programmers use them if the company they work for uses that framework, but when they aren’t required to do so they use only well established and well maintained libraries and frameworks. While most of my reading has revolved around JavaScript, the same principle applies to Android development.

I understand if this isn’t news to most professional developers, but this revelation comes as somewhat of a surprise to a newcomer like myself. For now, I think the best course of action is to stick with what my instructors tell me to learn, and if I find myself struggling in a personal project, learning a new framework isn’t the worst use of a free day.

Cheers!

Android Audio

I have been using Udacity for the past six months now, and for those who have never heard of them, I encourage you to check them out. Udacity has a number of excellent courses on a broad range of topics, and the programs built by Google are particularly well done. The ability to interact with the content through quizzes and activities is much more engaging than a traditional YouTube video, and there are forums for students who want to talk about the subject at hand with peers. I am currently working through the second level Android developer course, and I wanted to take a break and write about audio in mobile applications.

While to some it may seem mundane, a LOT of care and attention goes into adding audio to an application, and while many of these practices are not exactly necessary for an application’s function, providing a seamless and cohesive experience while being a “good mobile citizen” is a marker of a well designed piece of software.

For the full list of Android AudioManager constants, click here.

https://developer.android.com/reference/android/media/AudioManager.html

If we have continuous audio playing in our app, whether that be the main function, like in a music player app, or a side feature, say a background song in a game, we can be very unkind to our user and their device if we aren’t careful. You might not have noticed, but when you’re listening to a song on Spotify or Soundcloud, and someone texts you, the volume will briefly lower, allowing you to hear the notification.

This can be called with the constant:

AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK

This allows or application to release audio focus for a brief time, and allows the user to feel connected and informed. If we had not accounted for such an occurrence, the user would exit our application and see a missed text, call or other notification. I don’t know about you, but I wouldn’t feel particularly kindly towards any app that behaved like this.

Another way we can be good Android citizens is by releasing memory allocated for our application as soon as we are finished with it. If you are not familiar with application lifecycles, I highly suggest reading this documentation:

https://developer.android.com/training/basics/activity-lifecycle/starting.html

Whenever an audio file has finished playing, or if another non-concurrent file is started, that memory should be released back to the device. There are a number of other ways to tune audio playback in Android applications, and if you have any specific questions about best practices or how to add different features to your application, feel free to ask me!

Cheers.

The two-sum problem

While reading about all the different ways in which someone can better their understanding of a problem, I consistently came upon one piece of advice: write about what you are learning.

The two sum problem is a variation of the subset sum problem, in which the goal of a function is to return the sets of numbers that add to a given sum. The  two-sum challenge is similar, where the goal is to find all the pairs of two integers in an unsorted array that sum up to a given integer. For example, if the array is [1, 5, 3 9, 11, -3 ] and the sum is 6, your program should return [[9, -3], [1, 5]] because 9 + -3 = 6 and 1 + 5 = 6.

 

The simpler, albeit slower solution is to loop through the array for each element in the array, logging a pair if they sum to our given integer. While this will work, it runs in O(n^2), as we loop through n time, checking n elements. Thankfully, there is a faster solution, using the glory that be; hash tables.

 

To achieve a faster running time, we want to create an empty hash table, and for each “i” element in our array, we check to see if the i element minus our sum, S, exists in our table. If it doesn’t, we add it to our table, and if it does, we have found a pair. Let’s demonstrate how that works:

def two_sum(arr, S)

sums = []

hastable = {}

for i in range (0, len[arr]): //for as many elements as are in out array

sum_minus_element = S -arr[i]

if sum_minus_element in hashtable: //if sum_minus_element is in our has table:

sum.append([arr[i], sum_minus_element]) //add and our current index in arr to it

hashtable[arr[i]] = arr[i] //otherwise add sum_minus_element to our hash table

return sums //returns an array of sum arrays

 

Using the same array and sum as last time,  ( [1, 5, 3 9, 11, -3 ], summing to 6 ) we begin by placing the first element in the array, 1, into our hash table. We then move to the next element, and check if 6 – 5 = 1 is in our hash table, and it is! This means we have found a pair! We then check if 6-3 = 3 is in our table, and since it isn’t we add 3 to our hash table. We only have to loop through our array once, so our time complexity is roughly O(n).

While researching this post I found two explanations of the run time, another being O(sum*n), which I thought was slightly odd. 

http://algorithms.tutorialhorizon.com/dynamic-programming-subset-sum-problem/

While I really like their visuals, I personally think visualizing the time complexity as a linear function of the number of elements in our array emphasizes how useful this algorithm is. Hash tables are a vitally important part of software development, and knowing how to use them effectively is necessary skill for all successful programmers and computer scientists.

 

Cheers!