Questions Every Android Developer Should Know: Part 1

How well do you know Android?

Here are some common questions and answers regarding Android development. I compiled these questions and answers from posted interview questions, stack-overflow, trivia, documentation and other various sources. This is not a how-to, but a more general description of things I believe you should know to become a rockstar Android development. In the future I may expand on some of these topics as their own articles, but for now: enjoy!


Does Android include an internal database?

Yes! Android uses the open-source, stand-alone SQL database, SQLite. This is accessible via the command line of a connected device in developer debug mode. The access is limited to single instances of the app, but you can access remotely. Android studio contains a command-line interface called sqlite3 which can remote right in. The database can also be as large or as small as you wish.

The DB files are stored in the package manager …/projectName/databases. The Android java libraries include methods manipulate and query the database .


What is a ViewGroup?

“View: the most over-used word in the the Android development environment. Le Sigh.”

ViewGroup actually means two separate, but closely related things.

  1. In Java, the ViewGroup class is an abstract class that all Layouts extend. ViewGroup is an invisible container for all of the other Layouts.
  2. A ViewGroup is also an umbrella term to help categorize those layouts in XML. So, LinearLayout and RelativeLayout are examples of what we would call ViewGroups in the XML layout editor.


What is an Activity?

“A single, focused thing that the user can do.” – official Android documentation

An app cannot exist without at least one activity, even a WebView app is a single activity. In Android, an activity is represented by a single screen. Most applications have multiple activities to represent their various screens. Activities contain the UI elements of the application. More than one activity can be on the screen at the same time as a floating window or embedded within another activity. In java, Activity is a class. The official Android documentation provides an excellent overview of the lifecycle and states of an activity.

An activity has essentially four states:

  • If an activity is in the foreground of the screen (at the top of the stack), it is active or running.

  • If an activity has lost focus but is still visible (that is, a new non-full-sized or transparent activity has focus on top of your activity), it is paused. A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.

  • If an activity is completely obscured by another activity, it is stopped. It still retains all state and member information, however, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.

  • If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.


The lifecycle of an activity is based on 7 key methods. OnCreate

public class Activity extends ApplicationContext {
protected void onCreate(Bundle savedInstanceState);

protected void onStart();

protected void onRestart();

protected void onResume();

protected void onPause();

protected void onStop();

protected void onDestroy();



speaking of activities…

What is a Fragment?

A fragment represents a behavior or a portion of user interface within an Activity. You can combine multiple fragments in a single activity to build a multi-pane UI and reuse a fragment in multiple activities. You can think of a fragment as a modular section of an activity, which has its own life cycles, receives its own input events, and which you can add or remove while the activity is running.






(C++) Objects: Deep copy vs. Shallow Copy

“Ahhhhh, it’s time for C++,  and you know what that means,
A glass of wine, your favorite easy chair,  and of course Microsoft Visual Studio open in your Windows operating system.” -not the intro to “Smash” by the Offspring

What is the difference between a “deep copy” and a “shallow copy” in C++?

Is one better than the other, regarding copying objects?

I thought you would never ask. A shallow copy copies all the member values from one object to another. Great! But what if your member variables include pointers? You are going to run into some problems. To understand the difference between a shallow copy and a deep copy, let’s look at how and where issues can happen.

First, let me get my includes and namespace on:


Now some code:


This most basic C++ object, myObject. There is a single member variable, a pointer variable named ptr.

So let’s look at a shallow copy. Check out the following:


First, we created a method named shallowCopy, and then we pass in myObject as two separate reference parameters named src and dest(source and destination).  Two objects created.  All good, right?

Image result for NO meme

No. dest is pointing to src‘s location. This will lead to some problems with manipulating the data inside of shallow copies. When creating or deleting an object, a shallow copy may cause runtime errors. For example, if object src is deleted, runtime error. The best case for using shallow copies would be when the object is complex and you just need the state of the object at that instance in the program, basically something to reference and nothing more. If you start making changes to a copy of the object, you may be in for a runtime headache of epic proportions. So how can we get an accurate copy of an object, including references that don’t point to other objects?

So let’s look at making a deep copy:

Here is deepCopy with input parameters of references to myObject type named src and dest. The dest pointer is being casted as a char pointer in memory, with the same string length as src, but it exists on its own. Then copy the pointers using strcpy library function.

A deep copy does everything a shallow copy does, but also copies any pointer objects and dereferences them. So the dest and src pointers are no longer pointing to the same location in memory, but pointing at their own locations in memory. Deep copy should be used more often, especially when the size of the copied structure is large. Keep in mind they do cost a little more in memory, but deep copies are almost always the right way to go.

So, the main takeaway here: be sure your pointers are copied over when copying objects, make a deep copy.


Hello world!

So, we all start things. Blogs have been hit or miss for me. There are some days where I have all of the words for all the the things and other days, not so much. Starting a blog sets up an expectation. There is now pressure added to my life.

I recently heard a podcast from Recode Decode where the guest was Evan Williams, a founder of Blogger, Twitter, and now Medium. He made an argument that there are many people with good ideas who do not want to blog everyday. There are good writers who can articulate their thoughts well but not on a routine basis. Perhaps they have a moment of clarity. An ah-ha that must be captured. A blog is not necessarily going to appeal to casual writers.

I am keeping this blog focused on technology. My background includes music and books, but technology has been a lifelong fascination for me, so let me talk about that.

My mother worked in tech as a network specialist, so I heard all about computers growing up. Our home always had laptops floating around. We had internet early on. I never needed to leave the house to print a document. Some of my earliest memories were playing floppy disk games on our little IBM. My mother swears I first learned to program as a kid. I remember being one of the fastest typers in my school. I remember building websites and configuring a local server on our mac at age 14 (or was it the neighbors mac?). IRC chatrooms and pp message boards were all the rage. The internet was blossoming.

I don’t remember having a dream of working with computers. They just seemed like tools to me. Tools that made creations, but nothing relevant to who I was in the year 2000. I wasn’t eager to build the next CRUD app. I wanted to perform in my band. I wasn’t dreaming of the next best consumer application. I wanted to party with my friends and spend long nights staring into space, pondering existence. We did not have a startup culture in Connecticut.  No codecademy existed online yet. There were no hacker groups having meetups in Connecticut. Computers enabled very little of what I was doing. I just didn’t think I would enjoy working with them. I did not think I was intelligent enough anyway. This was the realm of super geeks!