Skip to content

Android Handler – The handler class should be static or leak might occur

With the standard implementation pattern for a inner class Handler in an activity, the following is common:

public class MainActivity extends Activity { 

        private class CHandler extends Handler { 
                public void handleMessage(Message msg) { 
                    //handle message

While valid most of the time, this produce the warning “The handler class should be static or leak might occur”. More information of the error can be found here (search on page for HandlerLeak)

The reason why this warning is showing up lies with how inner class works. The handler class will implicitly hold a copy of the activity, making it ineligible for gc and thus the resources of the whole activity cannot be freed even when all references to the activity disappears. See the quote below from Romain Guy:

a Message has a reference to the Handler which, when it’s inner and non-static, has a reference to the outer this (an Activity for instance.) If the Message lives in the queue for a long time, which happens fairly easily when posting a delayed message for instance, you keep a reference to the Activity and “leak” all the views and resources. It gets even worse when you obtain a Message and don’t post it right away but keep it somewhere (for instance in a static structure) for later use.

Simply making the Handler static does not help, because once it is static, to access the activity you still have to pass a reference to the static Handler class. This reference is a strong reference and thus the same problem is still there. The solution lies with WeakReference and/or static Handler. Below is an example setup I have (this works for updating the fragment):

        private static class WeakRefHandler extends Handler {
	    private WeakReference<Fragment> ref;
	    public WeakRefHandler(Fragment ref) {
	        this.ref = new WeakReference<Fragment>(ref);
	    public void handleMessage(Message msg) {
	        Fragment f = ref.get();
                // handle message and update fragment
	private WeakRefHandler mHandler = new WeakRefHandler(this);

Posted in Android, Java. Tagged with , , , , , .

Strong, Soft, Weak and Phantom references – Java

A summarized notes on less known Java garbage collection and the different types of references in Java.

There are four types of references in Java, in order of their “strong-ness”: strong, soft, weak, phantom. Strong references are all the normal references you see in code all the time. All the others are from java.lang.ref.* and require extra code.

An object is

  • strongly reachable if at least one of the chain of references is all strong reference
  • weakly reachable if it is not strongly reachable but is reachable through a chain with at least one weak reference
  • softly reachable if it is not strongly or softly reachable, but is reachable through a chain with at least one soft reference
  • phantomly reachable if the object cannot be reached through the above chains, but can through a chain with at least one phantom reference
  • unreachable otherwise

Garbage Collection

  • GC will not claim any object that is strongly reachable
  • GC will claim at its discretion any object that is softly reachable, but generally this is done only when its running out of resources. This means that softly reachable objects may stay in memory for a while
  • GC will reclaim an object that only has weak reference left
  • Phantom reachable objects have been garbage collected (finalized). This is the only way to know when an object has been freed by GC

More on Phantom references
Generally, an object is not guaranteed to be gc-ed when finalize is called, for an resurrection example, refer to this

The only way to be sure that an object has been reclaimed is through the use of Phantom references and a reference queue. See here

Posted in Java. Tagged with , , , , , , , .

Java, Inner Class

I was going through various online sources on Java inner classes, and thought I’d summarize the notes here. This blog post does assume that the reader is familiar with what a local and anonymous inner class is, and will instead talk about some of the interesting properties.

Inner class contains a implicit reference of the Outer class instance it belongs to.

public class A {
    public class B {
        private int var = 0;

        private A refParent() {
            return A.this;

We see that the implicit reference to parent can actually be obtained through [InstanceNameOfParentClass].this

This property means that an instance of an inner class is attached to the instance of the outer class. A significant implication here is that the outer class cannot be garbage collected for as long as a strong reference to the inner class exists somewhere, because the inner class implicitly references the parent.

Creating an instance to a inner class
If the inner class is not private (or protected if you are out of package), then you can instance the inner class through a special new operator

A a = new A();
A.B b = B();

Notice that a instance of the outer class must be created first before generating the instance of the inner class (due to the required implicit reference)

You cannot declare static members in a non-static inner class
This happens because an inner class is linked to a parent instance, thus it cannot contain any static members itself. However if the inner class is static, then it is allowed to have static members and it will not contain a reference to the outer class.

Only nested classes can be declared static (Why use it?)
Why do we use static inner classes? Simple, you can use the inner class without a reference to the outer class (since it doesnt contain any reference to it, and can be instanced through [ClassName].[NestedClassName]

Private methods and variables in the inner class are accessible to parent (vice versa)

Noting that since inner class is treated as a member of the outer class, they have access to each other’s private members

Posted in Java. Tagged with , , , .

Setup SVN for an Android workspace

** This article assumes you have Subversive or other subversion integration installed with your Eclipse

Every android workspace has /bin/ and /gen/ directories. These are generated on the host machine from the project and should not be checked into SVN. Otherwise you will see that they change after every build (or auto build) of the project.

To exclude them, go to Eclipse’s Window Menu -> Preference -> Team -> Ignored Resources, add bin and gen.

Posted in Uncategorized. Tagged with , , .

Using Google Map Android API v2

I outlined how to build a Tab based interface with Swiping that included a Google MapFragment (in the form of SupportMapFragment from the Android Support library)

Turns out that there are a number of steps to get Google Maps API working for your app. The developer page here does a pretty good job of explaining how to set up the API.

Just two quick notes to augment what they said:

  1. keytool is in your jdk’s bin
  2. If you use multiple machines for development, you can use the same debug.keystore for all the machines. Preference -> Android -> Build -> Custom debug keystore

Posted in Android, Java. Tagged with , , , , , , .

How to Build a Debugger Mini Series #3 – Break Point

There are a number of requirements for a break point

Logical vs Physical break points

Logical break points correspond to the ones set by the user somewhere in the source code. Physical break point correspond to the point in the text data area of a application where the physical trap instruction is written into.

A logical break point may be resolved (meaning it has a mapping from symbol to physical address), or it can be unresolved, where the required module has yet to be loaded (thus may not have address). Usually this means two lookup tables, the first maps logical bp to physical and is used when settings, removing a bp. The second is a backward lookup from physical to logical, used when triggering bp.

In general there is no restrictions on how many bps can point to the same physical address


Steps to creating a breakpoint

  1. Given filename and line number, look up symbol table to find physical address of the instruction
  2. Validate that the breakpoint can be set. The symbol may not yet be in memory because the library has not yet loaded, the symbol may not be valid due to old symbol files etc.
  3. Create logical and physical break point objects
  4. There can be temporary breakpoints that are used only once (for example stop at main() so we can begin running)
  5. Debugger may need to create internal breakpoints to service certain user requests. Internal bp should not be visible to users when viewing the CPU view (but a memory dump should review the breakpoint)


Steps to service a break point

  1. OS notifies debugger that the application has stopped at a certain address due to breakpoint
  2. Look up logical bp list to see if this is a breakpoint we have created
  3. Stop and get user input
  4. Note that step-over on the source level is not the same as step-over at instruction level. There could be manyof instructions for a single logic statement. The debugger should use internal bps at a source level to achieve step-over in source

Posted in Debugger. Tagged with .

How to Build a Debugger Mini Series #2 – Operating System support for debuggers

Operating System support for debuggers

Debuggers are user mode applications which means that they cannot execute privileged code. Interactions between debugger and the debugged application goes through the OS.

Different operating systems have different support for debuggers.

  • Linux has ptrace() and wait(). pstrace can be called with different requests such as step, R/W of text or data blocks. The call is nonblocking as many requests can be fulfilled immediately by the OS (as it already has the information) without having to look into the application being debugged. For requests that take time to complete, wait() can be issued to wait for the next event notification
  • Linux also has the /proc device driver interface that exposes running processes like files and directories. Standard APIs like open(), close(), read(), write(), ioctl() can be used on these to achieve debugging purposes. This allow debuggers to attach to processes already running instead of opening a new instance as is needed with ptrace()
    • ioctl() can be used to register events of interest.
    • While breakpoint is not a event for ioctl, we can register a notification to wait for a process to stop, and then modify the text section of the code to induce a stop (illegal op)
    • The process will stop, and the debugger will be notified because it asked for notification
  • Windows has the Win32 debug API
  • Java has its own platform debugging architecture

Posted in Debugger. Tagged with , .

How to Build a Debugger Mini Series #1 – Introductions

At work I am working on a semi-basic (breakpoints, stepping, watch, query for symbols, handling optimized code etc.) debugger for a new chip, since this is the first time that I actually worked on a debugger, I’m reading through some resources.

The series of posts will be documenting some aspects of writing a debugger and personal understandings of them. Some of the information here will be pretty basic, but none the less included for completeness. This series will be posted *after* I have actually written the debugger, to ensure correctness of the posts.

I guess this post does assume that you know at least how to debug programs….

So the first in the series if going to be the information from the book How Debuggers Work by Johnathan Rosenberg. The book is dated (1996, talks about Visual Basic 3.0….) and the reviews arent exactly high, but none the less its a start.


Symbolic (source-level) vs Machine level debugging

  • Machine level debugging inspects and steps through the machine instructions actually being run on a system
  • Symbolic (source-level) debugging maps the instructions back to the source code and provides more intuitive use cases


Application vs In-circuit

  • Application debuggers are high level debuggers
  • In circuit debuggers are sits between OS and bare hardware and monitor all interactions between OS and hardware


Various views offered by a typical debugger

Current debuggers more or less shows the information listed in the bullet points below, sometimes under different names.

  • Source view: pretty basic, shows the source code
  • Stack view (Stack trace): a stack trace made up of a number of stack frames (each one a function call).
  • Breakpoint view: shows the breakpoints currently set
  • CPU view: machine level view showing the actual instruction (disassembly) being executed as well as the current state of hardware registers
    • Disassembly are machine instructions (assembly) translated back into textual assembly language representation (so they are human readable)
  • Variable view: At the symbolic level, variables can be listed
  • Inspector and Evaluator: variables can be inspected for value, additional code can be evaluated at the breakpoint


Debugger, Operating Systems

The debugger is a collection of these views and abilities above into a package.

For debugging applications on an operating system, there needs to be API support from the OS that allows the debugger to attach to an application, have R/W access to the process’s memory and have control over the execution of instructions in the process. The OS APIs also provide ways to notify the debugger when anything important happens (for example segfault).

The debugger is implemented with a main loop that basically waits for user commands to launch one of the above views.


Hardware requirements for debugging

At minimum, hardware must provide the following:

  1. A way to specify breakpoints (bp). These are specific locations in the executing code that when the processor reaches them, the execution will stop
  2. Notification (interrupt or trap) that would notify the OS (thus debugger) that an event has occurred (such as hitting a bp)
  3. The ability to R/W hardware registers

These requirements allow for the following:

  1. Break point
  2. Single stepping
  3. Fault detection
  4. Watch point

Break point

Usually implemented by  the processor as a special instruction that causes trap to the OS, which in turn notifies the debugger.

The debugger has access to application’s text space (source code), so when a bp is placed, it knows what location that instruction is. It saves the original instruction, and places the bp instruction in. Once the bp is hit, the hardware produces a trap which then tells the debugger where the trap was (which instruction) and why. From there, it is up to the debugger to proceed.

To continue after the breakpoint, the debugger must first restore the original instruction into the bp location, single step that, and put the bp back into the location before letting application continue. The last step is to ensure that the next time execution gets to the bp it still traps.

Single Step

This is where the processor is instructed to execute a single machine instruction and trap to OS again. Some hardware provides flags for this operation. In case this is not provided in hardware, it can be emulated by the debugger by break pointing the next instruction (read the instruction at the current program counter, save next instruction down and set bp at the next). Careful that the next instruction (or the current) may be a jump which requires solving what the correct “next” instruction is.

Fault Detection

Some faults are detected by hardware (such as division by 0, memory access violation etc.) while others are detected by the OS. In all cases, the debugger is notified before the application being debugged is allowed to run again.

Watch Point

Watch points (data breakpoint) are triggers for the debugger when some parts of the debugged application’s address is modified. There are a few ways for the hardware to implement this:

  • Have a set of registers that specifies the starting address and the runlength. Any write to any of the addresses will cause a trap
  • Mark specific memories as read only, which causes a trap to be generated on write

As a summary point, different processor architectures implement the above differently, and some have implications on debugger design. For example, MIPS have delay slots after branch instructions that can be filled by instructions that were supposed to run before a branch (since a branch takes a while to be fetch from memory, so if we do not want to stall the pipeline, then we can do a few more instruction while waiting for the branch). This means that a debugger seeing a branch must also see if the delay slots after it has been filled, and execute those before branching.

Posted in Debugger. Tagged with , .

Quick guide to enabling Tab + Swipe using Fragments and Android Support library

Before you start, if you want a systematic view (abeit a long one) to creating lateral navigation, refer to the Android Developer patterns:

I will go through a step-by-step (condensed version of the various google dev docs pages) on how to implement 3 tabs + swipe using 3 fragments. 2 fragments have xml layout files, and one fragment is a Google MapFragment.

*Important* – All the packages that you will see below such as ViewPager, FragmentActivity etc are available natively to Android 3.0+ APIs, however Android has provided a support library that allow the creation of everything described here all the way down to Android 2.2. This is important, because if you are developing on a high API level you will see that many classes can be important from either native API, or from*. You will have to stick with one of them as they are not interchangeable.

Example below will be using android support, as this provide greater backward compatibility.

Step 1 – Set up the tabs on the main activity
In Android 3.0+, tabs can be built into the ActionBar on any application. The code below is all that is required:

private void setupABar() {
		// obtain the action bar
		final ActionBar aBar = getActionBar();
                // set it to tab mode
		// add a tab listeners to handle changing the current fragment
		ActionBar.TabListener tabListener = new ActionBar.TabListener() {
			public void onTabUnselected(Tab tab, FragmentTransaction ft) {


			public void onTabSelected(Tab tab, FragmentTransaction ft) {

			public void onTabReselected(Tab tab, FragmentTransaction ft) {

		// add the tabs, register the event handler for the tabs

and in onCreate, call:


Most of the code here is self-explanatory, except for the mViewPager variable. This will become clear in the next section, just remember that the code above just sets up the tabs and registers a handler. It is rather detached from the whole fragment and swipe process.

Step 2 – Fragments
We now want to build 2 fragments (the 3rd Google Map fragment will be constructed in code at runtime). Here we will show the creation of only 1 fragment called ControlFragment (for the control panel of the app I was building):

public class ControlFragment extends Fragment {
	public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
		// inflat and return the layout
		return inflater.inflate(R.layout.controls_fragment, container, false);

and the layout:

controls_fragment.xml (simplified):

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android=""
    android:orientation="vertical" >

        android:text="@string/controls_btn_turnon" />
        android:text="@string/controls_btn_turnoff" />


Step 3 – ViewPager on the MainActivity and swipe
To support multiple views (called fragments), you generally:

  • Add a ViewPager to the layout (through either the XML or by code), it is responsible for displaying different fragments
  • If you need to control how the ViewPager functions such as disabling swiping on certain fragments, then you need to inherit the default ViewPager
  • Register a bunch of fragments to the ViewPager

Step 2 shows the construction of list items 1 and 2. We are building a custom ViewPager as we want to disable scrolling later on a Google MapFragment (so that when you swipe on the map it doesnt jump to the next tab).

MainActivity.xml (Layout XML):

    android:layout_height="match_parent" />

        vertCollectionPagerAdapter mVCollectionPageAdapter;
	ViewPagerMapNoScroll mViewPager;
	private void setupPager() {
                // the page adapter contains all the fragment registrations
		mVCollectionPageAdapter = new vertCollectionPagerAdapter(getSupportFragmentManager());
		mViewPager = (ViewPagerMapNoScroll) findViewById(;
                // set the contents of the ViewPager
		// add a on page change listener to change the actionBar's selected tab # (fragment will then be changed by actionBar's code)
                // the change listener is called on swiping
		mViewPager.setOnPageChangeListener(new ViewPager.SimpleOnPageChangeListener() {
				public void onPageSelected(int pos) {

and in onCreate of MainActivity:


*Swiping* – We see that we can enable swiping very easily by implementing a ViewPager’s setOnPageChangeListener, this is triggered whenever a ViewPager detects enough side scrolling, and also has determined that the current fragment can be scrolled (see below).

public class vertCollectionPagerAdapter extends FragmentPagerAdapter {
	private static final int FRAGMENT_COUNT = 3;
	private List<Fragment> mFragments = new ArrayList<Fragment>();
        // Google's Android MAP API 2 has MapFragment and the Android Support library's equivalent, SupportMapFragment
	private SupportMapFragment mMapFragment;
	private FragmentManager mFM;
	public boolean disableSwipe = false; 
	public vertCollectionPagerAdapter(FragmentManager fm) {
		mFM = fm;
		// add fragments
		mMapFragment = SupportMapFragment.newInstance();
		mFragments.add(new ControlFragment());
		mFragments.add(new StatsFragment());

	public int getCount() {
        // This is called by the ViewPager to get the fragment at tab position pos
        // ViewPager calls this when the Tab handler handles a tab change
	public Fragment getItem(int pos) {
		Fragment f = mFragments.get(pos);
                // we want to disable swiping on the map fragment
		if (f instanceof SupportMapFragment)
			disableSwipe = true;
			disableSwipe = false;
		return f;
	public Fragment getActiveFragment(ViewPager container, int pos) {
		String name = "android:switcher:" + container.getId() + ":" + pos;
		return  mFM.findFragmentByTag(name);


public class ViewPagerMapNoScroll extends ViewPager {
	public ViewPagerMapNoScroll(Context context) {
	public ViewPagerMapNoScroll(Context context, AttributeSet attrs) {
		super(context, attrs);
	protected boolean canScroll(View v, boolean checkV, int dx, int x, int y) {
		if (v instanceof ViewPagerMapNoScroll) {
                        // the vertCollectionPagerAdapter has logic on getItem that determines if the next fragment should have swipe disabled
			vertCollectionPagerAdapter a = (vertCollectionPagerAdapter) ((ViewPagerMapNoScroll)v).getAdapter();
			if (a.disableSwipe)
				return false;
				return true;
		return super.canScroll(v, checkV, dx, x, y);

This completes a really fast, code-centric tutorial on how to build Tab + Swipe using fragments and Android Support library.

As of now, the MapFragment would not work because that require additional setup, see the next blog post on that

Posted in Android, Java. Tagged with , , , , , , , .

MySQL cli import sql files

A note for myself since I keep forgetting it and have to dig for it everytime…

To open a sql file within the mysql client for import, use:

\. file.sql

Posted in Database. Tagged with , , .