Monday, September 2, 2013

Useful Regex Tools

Ever find yourself trying to figure out the right syntax for a Regex pattern? I've used these two sites a handful of times to generate some regex patterns:

For a quick overview of all of the special regex syntax, check this site out:

To test your pattern, this site works well:

Saturday, August 31, 2013

Back to Posting

Time to end the post drought! A few months ago I made a pretty big move for a new job. I'm now working at Amazon! So the last few months have been pretty busy while I try to get used to the new position and the new area. Things are slowly starting to cool down a bit. That means I'll have some time to start writing again.

Stay tuned for more articles soon.

Wednesday, June 5, 2013

Design Patterns - Abstract Factory

Design Pattern Review

Need a refresher on Design Patterns? There are plenty of Design Patterns out there. Over the next few months, I plan on writing a bit about most of the common design patterns that can make your life (and mine) as a developer much easier. My aim is to give you just enough of the idea to then be able to research the details from some other resources (some of which I have included).

To start off, I’ll be going through a bunch of Creational Patterns, patterns that are useful when you need to create objects.

Creational Patterns

To start off, let’s talk about the Abstract Factory pattern. The Abstract Factory pattern enables the creation of a set of common objects without having to know the concrete classes themselves.

Abstract Factory

In Java terms, this usually boils down to an abstract class. It is used to create a specific interface that all Factories will agree to. By agreeing to an interface up front, any class that uses one of these Factories doesn't need to know anything about what type of Factory it is really talking to.

What It Can Do for You

From the code, this allows you the ability to swap out Factory types with a single line change. All that is needed is to change the Abstract pointer’s concrete Factory instance. Nothing else needs to be changed.

What It Can’t Do for You

There are a few drawbacks with this design. If you find yourself having to add new types (via new methods) to the Abstract Factory class, you will have to add this same method to all concrete Factory classes as well. This effectively means that all Factories must be modified when any additions are needed.


For more information, including examples, check out these resources:

Next - The Factory Method

Tuesday, April 9, 2013

Android Tutorial: Using the ViewPager

Currently, one of the most popular Widgets in the Android library is the ViewPager.  It's implemented in several of the most-used Android apps, like the Google Play app and one of my own apps, RBRecorder:















The ViewPager is the widget that allows the user to swipe left or right to see an entirely new screen. In a sense, it's just a nicer way to show the user multiple tabs. It also has the ability to dynamically add and remove pages (or tabs) at anytime. Consider the idea of grouping search results by certain categories, and showing each category in a separate list. With the ViewPager, the user could then swipe left or right to see other categorized lists. Using the ViewPager requires some knowledge of both Fragments and PageAdapters. In this case, Fragments are "pages". Each screen that the ViewPager allows the user to scroll to is really a Fragment. By using Fragments instead of a View here, we're given a much wider range of possibilities to show in each page. We're not limited to just a List of items. This could be any collection of views and widgets we may need. You can think of PageAdapters in the same way that you think of ListAdapters. The Page Adapter's job is to supply Fragments (instead of views) to the UI for drawing.

I've put together a quick tutorial that gets a ViewPager up and running (with the Support Library), in just a few steps. This tutorial follows more of a top-down approach. It moves from the Application down to the Fragments. If you want to dive straight into the source code yourself, you can grab the project here.

At The Application Level

Before getting started, it's important to make sure the Support Library is updated from your SDK, and that the library itself is included in your project. Although the ViewPager and Fragments are newer constructs in Android, it's easy to port them back to older versions of Android by using the Support Library. To add the library to your project, you'll need to create a "libs" folder in your project and drop the JAR file in. For more information on this step, check out this page on the Support Library help page on the developer site.

Setting Up The Layout File

The next step is to add the ViewPager to your layout file for your Activity. This step requires you to dive into the XML of your layout file instead of using the GUI layout editor. Your layout file should look something like this:

<RelativeLayout xmlns:android=""
 android:layout_height="match_parent" >

     android:layout_height="fill_parent" />


Implementing The Activity

Now we'll put the main Activity together. The main takeaways from this activity are as follows:

  • The class inherits from FragmentActivity, not Activity
  • This Activity "has a" PageAdapter object and a Fragment object, which we will define a bit later
  • The Activity needs to initialize it's own PageAdapter
public class PageViewActivity extends FragmentActivity {
  MyPageAdapter pageAdapter;
  public void onCreate(Bundle savedInstanceState) {
    List<Fragment> fragments = getFragments();
    pageAdapter = new MyPageAdapter(getSupportFragmentManager(), fragments);
    ViewPager pager = (ViewPager)findViewById(;

Implementing The PageAdapter

Now that we have the FragmentActivity covered, we need to create our PageAdapter. This is a class that inherits from the FragmentPageAdapater class. In creating this class, we have two goals in mind:

  • Make sure the Adapter has our fragment list
  • Make sure it gives the Activity the correct fragment
class MyPageAdapter extends FragmentPagerAdapter {
  private List<Fragment> fragments;

  public MyPageAdapter(FragmentManager fm, List<Fragment> fragments) {
    this.fragments = fragments;
  public Fragment getItem(int position) {
    return this.fragments.get(position);

  public int getCount() {
    return this.fragments.size();

Getting The Fragments Set Up

With the PageAdapter complete, all that is now needed are the Fragments themselves. We need to implement two things:

  1. The getFragment method in the PageViewActivity
  2. The MyFragment class


1. The getFragment method is straightforward. The only question is how are the actual Fragments created. For now, we'll leave that logic to the MyFragment class.

private List<Fragment> getFragments(){
  List<Fragment> fList = new ArrayList<Fragment>();
  fList.add(MyFragment.newInstance("Fragment 1"));
  fList.add(MyFragment.newInstance("Fragment 2")); 
  fList.add(MyFragment.newInstance("Fragment 3"));
  return fList;

2. The MyFragment class also has it's own layout file. For this example, the layout file only consists of a simple TextView. We'll use this TextView to tell us which Fragment we are currently looking at (notice in the getFragments code, we are passing in a String in the newInstance method).

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

    android:textAppearance="?android:attr/textAppearanceLarge" />


And now the Fragment code itself: The only trick here is that we create the fragment using a static class method, and we use a Bundle to pass information to the Fragment object itself.

public class MyFragment extends Fragment {
 public static final String EXTRA_MESSAGE = "EXTRA_MESSAGE";
 public static final MyFragment newInstance(String message)
   MyFragment f = new MyFragment();
   Bundle bdl = new Bundle(1);
   bdl.putString(EXTRA_MESSAGE, message);
   return f;
 public View onCreateView(LayoutInflater inflater, ViewGroup container,
   Bundle savedInstanceState) {
   String message = getArguments().getString(EXTRA_MESSAGE);
   View v = inflater.inflate(R.layout.myfragment_layout, container, false);
   TextView messageTextView = (TextView)v.findViewById(;
   return v;

That's it! with the above code, you can easily get a simple page adapter up and running. You can also get the source code of the above tutorial from GitHub.

For More Advance Developers

There are actually a few different types of FragmentPageAdapters out there. It is important to know what they are and what they do, as knowing this bit of information could save you some time when creating complex applications with the ViewPager. The FragmentPagerAdapter is the more general PageAdapter to use. This version does not destroy Fragments it has as long as the user can potentially go back to that Fragment. The idea is that this PageAdapter is used for mainly "static" or unchanging Fragments. If you have Fragments that are more dynamic and change frequently, you may want to look into the FragmentStatePagerAdapter. This Adapter is a bit more friendly to dynamic Fragments and doesn't consume nearly as much memory as the FragmentPagerAdapter.


Monday, March 4, 2013

Reading Logs Disabled in Jelly Bean

Just a heads up for anyone looking to read the standard ADB logs directly within your application. From Jelly Bean and up, you won't be able to access them on a non-rooted device. Although you can still ask for the permission via the READ_LOGS tag, you won't be granted the permission.

For more information check out these links:

Thursday, February 14, 2013

Memory Management For Android Apps (Google IO)

In gearing up for this year's Google IO, I started looking over all of the sessions from the last few years to see what kind of gems are hidden there. I recently watched the latest Google IO session on Memory Management within Android. While I watched the video, I took some notes of what I thought were the more important and interesting points. At a high level, the video has some interesting info about how memory is allocated in Android (and really, Java itself).

Garbage Collection (GC) is the process of reclaiming old memory in your application. Or in other words, taking objects that are no longer in use and freeing the memory used by them so the memory can be used for new objects.

The most interesting points in the video were about the Android Heap. The Heap is where all applications are stored within Android. Each Android app has a limit that is specific to each device. To find that limit, use the method ActivityMonitor,getMemoryClass.

Sometimes that Heap size isn't enough. Luckily, there is a way to increase the Heap size for your app. To increase the size, add the tag bigHeap to your Application tag in the manifest file. However, increasing the Heap can be a double-edged sword. By having a large Heap, GC can take considerably longer because GC has to go through a larger Heap to check for objects that can be freed. So just using this tag to get away from memory leaks in your app is a pretty bad idea and will only make your app performance decrease.

This video also goes into memory leaks. To start off, a memory leak means you still have a reference to an unused object, which means GC can't remove an object. One common memory leak in Android involves keeping a reference to an Activity(or a context) for far too long. This is especially common when handling Activity rotation changes. Finding and fixing memory leaks is more of a dark art of software development. It's a very important skill to have in your pocket simply because the Garbage Collector won't save your memory in all cases. For example, if you happen to pass Context objects around frequently in your application, it's much more likely that a memory leak has crept into your app. By using the Eclipse Memory Analyzer, it's pretty simple to find a leak using a few tricks that are shown in the video (like using Dominator Trees) and to do a few changes to your code to fix it.

Monday, February 4, 2013

Hardware Acceleration in Android - Are You Using It?

Did you know Android has Hardware Acceleration? Did you also know you actually need to enable it for your app first? Suprisingly you do! It's not defaulted to on. Here's another little gem in Android that could have a major impact on your application.

If you allow your app to run on Android versions above 3.0, you should probably enable Hardware Acceleration. By enabling Hardware Acceleration, the performance of your application's UI may improve considerably. To enable Hardware Acceleration on an application, simply add the android:hardwareAccelerated tag to the manifest file.

After adding that tag to the application element, simply recompile and test your app. It is very important to fully test your app after you add this line. Although it's unlikely that Hardware Acceleration will negatively affect your app, it is certainly possible. It is a good idea to make sure all of the views and animations still work as you expect it to.

If you find that certain screens seem to have problems with Hardware Acceleration, you can disable it on a per Activity basis if needed as well. To do so, simply add the tag (set to false) to the activity tag within the manifest. This allows you to enable Hardware Acceleration for the entire application while removing it for certain parts. And this also works in the reverse. You can enable only specific Activities while leaving it off for the majority of the application.

One other interesting feature in the IO Session (linked below) is the concept of a View Layer. By using this new Layer method, you are able to use the GPU within the device to speed up animations (IE ListView scrolling). Check out View.setLayerType for some more information.

For more details about Hardware Acceleration--and really some interesting information on how views are actually drawn in Android--check out this Google IO Session. And like most things Android-related, Google has a detailed page here on Hardware Acceleration.