What is Android? and its Data Structures Development Guide
Android is an operating system intended for utilization in some smart cell phones and different devices like tabs, iPod and tablets. This innovation, which is possessed by Google, Inc., incorporates an operating system, software, applications and e-readers, and many other advanced applications. Android is a Linux-based operating system designed basically for touch screen handsets; such as smartphones and tablet computers.
To develop a new application, SDK (Software development kit) is used to develop the application for the android platform and it is available on the internet.
The Android SDK incorporates inspect projects or applications with source code, different development tools, an emulator, and obliged libraries to construct Android apps. Applications are composed utilizing the Java language and run on Dalvik, a custom virtual machine intended for installed utilization which runs on top of a Linux kernel.
In the development of the android application, there is no need for any development tools like another development process; it just needs Eclipse, the Android SDK, and the ADT Plugins. Android development can be done on any machine computer, mac, windows, etc.
Practical Data Structures Guide for Android developers
Until a few months ago, while developing an android application, I never thought a lot about data structures. This is partly because there are many more difficulties to solve while developing for android as related to competitive programming were only running time matters. And partly because I started android developing before going to college, studying data structures and algorithms. Many of the habits and thought processes that I have established in the early days have been stuck.
I might reject data structures thinking that it would be trading code consistency for a little bit of efficiency and since we usually don’t have to handle a lot of data in apps, it would create sense to stick to the very basic data structures and keep code maintainable. But this view was wrong.
The reasons why now I think choosing the right data structure is important:
1. Every data structure place restriction on how you can access your data.
2. Choosing a more constrained data structure makes it more clear how you are going to access the data and it decreases the chances of surprising your fellow programmers.
3. Programming abstractions (interfaces, abstract classes, inheritance) place restrictions on what you can and cannot do. All programming constraints minimize the chances of you shooting your foot.
4. Choosing the right data structure will lead you to the right algorithm which will also improve efficiency as a side effect.
5. And finally, it’s disturbing how much resort to Array List no matter the task. I was also guilty of this.
Use an array instead of the array List when the number of elements is fixed. The most essential reason to do this is that this changes your fixed-length constrain from words to code. The  syntax indicates that this is a normal, fixed-length array for your fellow developers. Another reason that is a bit subjective is that the  syntax is more compact than the get (), add () functions.
Array List itself uses Array to store the data. So how can they magically change lengths? Documentation says that
As elements are added to an array List so its ability increases automatically. The specifics growth policy is not stated beyond the fact that adding an element has constant amortized time cost.
Constant amortized time is just a clever way of saying that it is fixed in most situations. When looking at the source code, it turns out array List begins with default length 10 and increases by 50 percent every time it reaches full capacity So, if you declare a new array List and proceed to fill 100 elements. It would create arrays of lengths 10, 15, 22, 33, 50, 75, 113!! And every time the capacity is surpassed it would copy over all the elements in the last array to the new one.
Inserting and removing an element are also expensive operations. Say you remove element 10 from an array List of length 100. All the elements from place 11 onwards would have to be shifted left! Similarly, adding will move all the elements to the right.
Enter Linked List, you do not need to move all the elements of the list to insert or remove an element in between. Adding an element is always constant time because it has a dynamic capacity. Other operations such as the index have the same cost in both list implementations. And sort costs the equal for all Collections because the sort technique first dumps everything into an array. But the linked List comes with an added constraint of not being able to access elements randomly. You can do get (index) but it would be an expensive operation.
This is the only place where the array List is better than a linked list. And I believe an array List should only be preferred over a linked List if random access is a necessity. More frequently, I find that my code is using this feature due to my laziness. Not because it was the best method.
To counter this array List addiction starts with initializing all your lists as linked List and only switch to an array List if you can’t live without random access. If you are going to make a list of posts from a server and then iterate over them, using a linked List would make your code more elegant. Since, instead of a list, get (I) you would write a list. Next () list. Previous () which is much easier to understand when you see a list. Get (I) and then trying to figure out how i is changing. Using an array List is justified for a music app where the user might hit the random button and so I have to be randomly changed.
The second most widely used data structure in android dev is HashMap. Like the Array vs. array List argument. Use an EnumMap over a HashMap if the keys are already identified. They offer similar advantages in the maintenance code by being more constrained. And as a side effect, the app is going to be a little quicker.
Iterating over a HashMap provides no guarantee of the order in which elements will be crossed. Say you are developing a shopping cart and store the orders in a map of product quantity. The user now desires to see all the product items in his cart. Since a HashMap is being used, the card would display all the items but the order would be random. Instead of using a Linked HashMap is much better here, since you can iterate over it like a normal linked list. It would be nice to use the Linked HashMap here to show the product in the order they were added,
Other valuable HashMap variants are TreeMap and Weak HashMap. Weak HashMap stores only a weak reference to its keys which can help stop memory leak. For example, you are storing View references in a HashMap that is shared among Activity and background Services. You’d like the View references to be garbage collected when the Activity finishes. If you use a regular HashMap in this situation it would hold a strong reference that would cause memory leakage. TreeMap is useful when you want the key to sorting the entries.
Infrequently used Data Structures
If you know that a list will only have unique features, use a HashSet instead of an Array List. As with Array vs. array List, EnumMap vs. HashMap we also have HashSet vs. EnumSet. For example, if you have a list of configuration keys, you can use EnumSet to represent the “selected” keys. If an order is important, similar to Linked HashMap, here we have Linked HashSet that preserves the insertion order and TreeSet that keeps the elements sorted.
Your data would hardly ever be of the form of a Tree but one very common use case is that of nested comments. I simply implemented nested comments using an array List once. As a result, all processes on the data (removing, adding, and editing a comment) become extremely complex. For example, removing a comment would be simply removing the comment node from the tree data structure, but since it was stored in an array List I had to repeat forward from the index of the comment to remove all its children too. Unfortunately, java does not have a common tree implementation.
Stacks and Queues:
To be honest I’ve never used a Stack during android development. However, they are used in Android itself (e.g. the activity back stack). I used Queue, once in the background Intent Service, to buffer requests for work. Stack and Queue have very rare uses during android development. But it’s still important to know just in case the user ever comes up. Have you used all of these during development?
Concurrency is a significant issue too while selecting the data structure which is very much ignored. When a similar data structure is modified and used in two different threads they should be synchronized. Concurrency problems rarely happen but when they do its very problematic to point it out since they are hard to reproduce. I have mostly encountered multi-threading using sync Tasks, Run able, Executor, Handlers, Service or using java. As a thumb rule, when using these classes only check if you are modifying a data structure from any thread aside from the UI thread. You must use a concurrency compatible version of your data structure, even if you are not modifying the data structure but modifying the elements in it.
Inheriting from these data structures
Finally, if you have some special limitations on the data, it’s better to have a separate class to encapsulate it by extending it from the built data structures. Say for example you want to have a file object list array, but you are constraining it to store only the files that exist. You should check each time before you add a file to the list. Or you could have a new class Existing File List that extends from array List and wraps the add function.