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.






What is Android Architecture?

What is Android Architecture?

Let’s talk software but take a break from code. Many of the components in this model grant developers the super-human powers to build some clever and innovative applications on a wide variety of devices, but, what is Android architecture?


Application Framework

The top layer of Android architecture is called the application framework. This is the layer of abstraction that developers work within. This is where the applications live, a customized software layer just below where front-end users see. In this layer, developers are free to take advantage of the device hardware and some operating systems protocols, such as accessing location information, running background services, setting alarms, adding notifications to the status bar, etc.

Here is a run down of key services included within the Application Framework:

  • Activity Manager – Controls aspects of the application lifecycle and activity stack.
  • Content Providers – Allows applications to publish and share data with other applications.
  • Resource Manager – Provides access to non-code embedded resources such as strings, color settings and user interface layouts.
  • Notifications Manager – Allows applications to display alerts and notifications to the user.
  • View System – An extensible set of views used to create application user interfaces.
  • Package Manager – The system by which applications are able to find out information about other applications currently installed on the device.
  • Telephony Manager – Provides information to the application about the telephony services available on the device such as status and subscriber information.
  • Location Manager – Provides access to the location services allowing an application to receive updates about location changes.


Our next layer down is the language library layer itself. Android includes a set of core libraries which provide access to all of the Android components to build an application. As a developer, you will probably only ever use the first two libraries: the standard Java SDK and the Java-based core Android SDK, but the other libraries deserve mention.


Java developers will be happy to know that almost all of the standard Java functions are here and updated to the most current Java SDK version.
The other vital set of Java libraries are the Android Libraries themselves. These contain the functions for interfacing with the Android hardware. Here you will find graphics rendering, local database access, device network stack access, XML manipulation, dates and times, camera access, GPS access, phone/contacts access, etc; all of the features that were being customized in the Application Framework layer.


As a subset of these libraries, there are the Java Interoperability Libraries which handle the special virtual machine that Android uses and how Java interacts within it. Developers don’t go here.

Android also includes a set of C/C++ libraries. These are used behind-the-scenes by the Java code and Virtual Machine to interact with various components of the Android system. For example, the OpenGL ES library works with the Android OS to deliver graphics. Developers rarely need to access these and in Android Studio they are purposely hidden from direct editing.

Finally, the virtual machine specific libraries, of which no developer should ever access. Let’s enjoy this black box.


Android Runtime

Each Android application does not run as a process directly on the operating system. Instead, during runtime, application instances run though a virtual machine called the Dalvik Virtual Machine, which is similar to the Java Virtual Machine (JVM). The DVM was developed by Google to compile Java using 50% efficiency in memory footprint, compared to Oracle’s JVM.

To create a distribution ready app, most of the Java class files are transformed into .dex (Dalvik Executable Format) files by the developer using the dx tool found inside of the Android Software Development Kit. When the end user starts the application,  their DVM executes the .dex files, and the C/C++ libraries; runtime begins.


Significantly, during runtime each application actually runs within its own instance of the DVM. This creates a sandbox effect. Applications cannot directly access other applications or the operating system. Using a virtual machine also has the big-picture effect of working within a variety of vendor-specific versions of the OS on a countless number of devices.

Linux Kernel

Finally, Android relies on the Linux version 2.6 for core system services which actually means little to us developers. This layer is the lowest abstraction layer and supports all of the higher layers in their interactions with device hardware. But, an important distinction between Linux desktop and Android mobile is that Android uses the Dalvik virtual machine to run every application. The VM communicates with the kernel as separate instances, and is totally different than applications running on a typical Linux OS which run directly on the system.

The kernel provides multi-tasking for running system processes concurrently. It also provides the required system management and core services such as security, memory, power, and process management. It also deals with the network stack, like wifi, and the device drivers for hardware components.

Remember that while based on the  Linux version 2.6 at its core, Android is an operating system for mobile, and many traditional desktop/server ideas simply don’t exist in this environment. For example, applications cannot be controlled via generic GNU/Linux shell commands. They are “locked” from the developer. The only interfaces available are those of which Google has made available via the Application Framework. The terminal environment in Android is not available without “rooting” the device to gain access, and once you are in, it is restricting and underwhelming compared to what you would find with Linux desktop.

That being said, it is refreshing for computer geeks, especially Linux die-hards, to see their favorite operating system core being used inside of the heart of the world’s most popular mobile OS.



Android Architecture is made of four key components:

  1. Application Framework
  2. Libraries
  3. Runtime
  4. Linux Kernel(Just remember “ALAL”.)
    You will also hear the Android Architecture called the Android Stack or the Android Framework.

Pretty sweet, right?

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