Programming Mobile

Design Patterns - Abstract Factory

2013-06-05T09:50:00.002-04:00

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.

Resources

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

Wikipedia: http://en.wikipedia.org/wiki/Abstract_factory_pattern
The classic Design Patterns book: Design Patterns: Elements of Reusable Object-Oriented Software
Why use a Abstract Factory? http://stackoverflow.com/questions/2280170/why-do-we-need-abstract-factory-design-pattern

Next - The Factory Method

Android Tutorial: Using the ViewPager

2013-04-09T13:07:00.001-04:00

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="http://schemas.android.com/apk/res/android"

 xmlns:tools="http://schemas.android.com/tools"

 android:layout_width="match_parent"

 android:layout_height="match_parent" >

   <android.support.v4.view.ViewPager

     android:id="@+id/viewpager"

     android:layout_width="fill_parent"

     android:layout_height="fill_parent" />

</RelativeLayout>

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;

  @Override

  public void onCreate(Bundle savedInstanceState) {

    super.onCreate(savedInstanceState);

    setContentView(R.layout.activity_page_view);

    List<Fragment> fragments = getFragments();

    pageAdapter = new MyPageAdapter(getSupportFragmentManager(), fragments);

    ViewPager pager = (ViewPager)findViewById(R.id.viewpager);

    pager.setAdapter(pageAdapter);

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) {

    super(fm);

    this.fragments = fragments;

  @Override

  public Fragment getItem(int position) {

    return this.fragments.get(position);

  @Override

  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:

The getFragment method in the PageViewActivity
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="http://schemas.android.com/apk/res/android"

  android:layout_width="match_parent"

  android:layout_height="match_parent"

  android:orientation="vertical" >

  <TextView

    android:id="@+id/textView"

    android:layout_width="wrap_content"

    android:layout_height="wrap_content"

    android:layout_centerHorizontal="true"

    android:layout_centerVertical="true"

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

</RelativeLayout>

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);

   f.setArguments(bdl);

   return f;

 @Override

 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(R.id.textView);

   messageTextView.setText(message);

   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.

Reading Logs Disabled in Jelly Bean

2013-03-04T17:27:00.001-05:00

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:

Memory Management For Android Apps (Google IO)

2013-02-14T16:41:00.001-05:00

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.

Hardware Acceleration in Android - Are You Using It?

2013-02-04T16:58:00.000-05:00

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.

Android Library: Drag to Sort and Swipe to Delete List View

2013-01-21T16:01:00.000-05:00

Here's a pretty nice custom list view that allows the user to sort the items in the list view by dragging rows up and down, or removing a row dynamically with a side swipe.

The source can be found on Github here. The list view runs very smoothly. Carl has also thrown up a simple demo app to show it off, too. Even if you don't need a list view with this type of functionality at the moment, it's a good custom widget to keep in mind for when you do need it.

The repo is fairly active as well. If you have any suggestions or requests, now would be the time to get your comments up there.

Loaders versus AsyncTask

2013-01-13T15:57:00.001-05:00

One of the biggest pieces of Android that I have neglected to learn about would be Loaders. Seeing as it's time for me to learn it, perhaps I can help you out a bit with it as well. My main interest with the Loader concept is how it melds with the tried and true AsyncTask, and if it's really better or not.

AsyncTask

Before getting into the Loader concept, it's important to have a good idea of what the AsyncTask is and what it's used for within Android. If you have written any sort of application for Android, chances are you have played with the AsyncTask, or at the very least heard of it. In Android, the AsyncTask class is one of the core development tools that most apps use. It gives the developer an easy way to do processing on a thread that isn't the UI thread. This keeps the UI thread focused on the UI instead of other time-intensive tasks, such as disk or server calls. There are a few issues with using AsyncTasks, though:

Configuration changes can mess things up
Pausing an activity doesn't pause the AsyncTask
A fair amount of boilerplate code (which means more possible errors)

Loaders

The AsyncTask isn't the only way to do background processing in Android, though. The Loader class is a much newer construct in Android (although now it's getting a bit dated). It was released with Honeycomb(3.0) and is now included in the Support Library. The beauty of the Loader is that it handles some of the "gotchas" that usually are missed when using the AsyncTask. Mainly, it handles activity configuration changes (IE when the user rotates the screen).
Loaders (specifically the CursorLoader) really shine when using Cursors within Android to pull data. The Loader class does an excellent job of updating the Cursor information (and in turn, the UI) whenever the underlying data changes. This is immensely helpful when information changes often and you don't want to interrupt the UI, and whatever the user is currently doing, just to display some new information.
One particular subclass of Loaders is of interest: the AsyncTaskLoader. This class performs the same function as the AsyncTask, but a bit better. It can handle Activity configuration changes more easily, and it behaves within the life cycles of Fragments and Activities. The nice thing is that the AsyncTaskLoader can be used in any situation that the AsyncTask is being used. Anytime data needs to be loaded into memory for the Activity/Fragment to handle, The AsyncTaskLoader can do the job better.
To really get into the details of how to actually implement a AsyncTaskLoader, check out these sources:

Google has a pretty good example directly in the API Docs.
Android Design Patterns provides some more detail and the reasoning behind Loaders.

Finding and Fixing Overdraw in Android

2012-12-16T08:53:00.001-05:00

I just ran across an excellent article about new performance analysis tools in Android (adding in 4.1), and how to improve list scrolling beyond the standard ViewHolder pattern (which may fade away soon) and other tweaks.

Check it out here on curious-creature! I plan on testing my applications for overdraw in the next few days. One step closer to really smooth lists.

Enabling Developer Options on Jelly Bean

2012-12-03T16:42:00.003-05:00

If you have recently updated to 4.2 on one of your Nexus devices, you may have noticed that Developer Options is mysteriously missing from the setting menu. After frantically trying to it with no luck, you probably went to the web to find out where it went (just like I did).

To enable Developer Options in Android 4.2, go to Settings->About Phone. Once there click on Build number 7 times.

I'm not sure if this is just the Android team playing a prank on all the developers, or pretty cool Easter Egg. Hats off to the guys over at XDA for finding this.

Coding for the Changes You'll Have to Make Next Month

2012-11-27T16:22:00.000-05:00

One of the most difficult parts of software development is adapting to change. It's a guarantee that the concepts, ideas, and possibly the point of the program that you are writing will change several times before it's actually done.

If you have ever heard the buzzwords like Agile, Scrum, Extreme Programming, or anything similar, then you have put some time into writing software that adapts to change. Any programmer serious about the craft has at least heard about it, but few have actually mastered it (and neither have I). Designing a program that easily adapts to change is a very difficult task. However, there are a few good ideas I have found that help create this kind of software at a team level:

Spend more time on design! Seriously, spend a few days or weeks on it. Time put into simply designing the software and not touching the code itself is time well spent. The better your design, the less pain will come your way down the road when the product is getting ready to ship.
Think about what type of changes could come in the future. What would need to change in the system to let these new features exists? The smaller the effect on the entire system, the better.
Step back from the requirements of the system for a moment and ask yourself why the system is designed in a particular way.
What is going to happen when you run out of time (which you will)? Where do you think shortcuts will be made?

After designing a system, spend a few days (yes, days) thinking about possible additions to the system. Don't just rush into coding up the system after you have one working solution. With these ideas, think about how the system would have to change to accommodate this new idea. It really doesn't matter if these additions are realistic, feasible, or something that no one would really want in the program. If it's difficult to add to the current system, then maybe the system should be redesigned to accommodate it.

The other trick is really just refactoring-- but taking it to the extreme. Any and every chance to refactor some code to make it more readable, useable, and simpler, should be taken. Don't let confusing, complicated code stick around in the code base just because you have more important things to do, or you didn't code it yourself. If the code doesn't make sense or is difficult to understand, get with the programmer who wrote it, and make it simpler. At the very least, understand what caused the code to become so complex and avoid that path next time. You'll save yourself a ton of time in the long run of the project, and by making the code simpler, it will be much easier to change later on.

"Anytime you find yourself looking at a class's implementation to figure out how to use the class, you're not programming to the interface, you're programming through the interface to the implementation. If you're programming through the interface, encapsulation is broken, and once encapsulation starts to break down, abstraction won't be too far behind."[1]

Basically, this quote says if you have to look how a class/method/function works to figure it out, you're doing it wrong. Proper design hides this information well so that once it's written, it can be taken for granted. This is an excellent time to refactor and think about how the code really should be structured.

What ideas and concepts do you use to create adaptable software?

1. Code Complete: A Practical Handbook of Software Construction, Second Edition - Chapter 6 - page 19

RBRecorder Redesigned

2012-11-21T08:00:00.000-05:00

After a fair amount of feedback from users, RBRecorder has been redesigned from the ground up and is now available on Google Play! RBRecorder makes refereeing a Racquetball match much easier and simpler. The new app includes:

A completely revamped UI
Historical match tracking
Doubles support
Comment support for matches and games
Support for Matches longer or shorter than 3 games
Support for games with any score or timeout limit

This release also comes with a promise of many new features in the near future, such as:

More detailed stat information
Match summery statics with the ability to email match info

Go check it out!

App Starters for Android - Worth the Effort?

2012-11-05T15:22:00.001-05:00

Over the last month or so I've seen a few simple projects pop up on Hacker News that help with creating an Android App.

Android KickStartr: http://androidkickstartr.com/
Android Bootstrap: http://www.androidbootstrap.com/

Both projects allow you to punch some basic info. in about your application, and they output a formatted project file that's tuned to your application. The nice thing about these projects is that they contain many of the most commonly used libraries out there today.

Both projects add the ActionBarSherlock library, which allows you to have a nice Android-like Title Bar in apps well below 4.0. They both also add the Support Library, which gives a pre-3.0 app access to some of the new constructs like Fragments. KickStartr gives you a bit more of customization ability by selecting which libraries you would like to include, while AndroidBootstrap gives no choices, but a deeper list of libraries.

Both projects can get the job done, and they save you a bit of time by setting up all the annoying libraries for you. If you're starting a new project soon, they are certainly worth considering.

Bloom Filter Implementation in Java on GitHub

2012-10-30T14:40:00.001-04:00

A Bloom Filter is a type of Set Data Structure. For those unaware, a Set Data Structure only has one main method, contains. It's only used to determine if a specific element is included in a group of elements or not. Most Data Structures (like a Hash Map, Linked List, or Array) can create this function fairly easily. You simply need to search the data structure for the specific element.

However, these types of Data Structures can pose a problem when the number of elements in the set exceeds the amount of memory available, as these types of data structures store all of the elements in memory.

This is where the Bloom Filter becomes interesting. As the Bloom Filter doesn't actually store all of the elements of the set in memory.

Instead of placing each element into a the Data Structure, the Bloom Filter only stores an array of bytes. For each element added to the Bloom Filter, k bits are set in its array. These bits are typically determined by a hashing function.

To check if an element is within the set, you simply check if the bits that would normally be one for this item are actually one. If they all are one (instead of zero), then the item is within the set. If any of the bits are not one, then the item is not within the set.

With every Data Structure there is definitely a draw back to the Bloom Filter. By using the method above, the Bloom Filter can say an element is within the set when it actually isn't. False positives are possible in the set, and they depend on several factors, such as:

The size of the byte array
The number of bits (k) set per element
The number of items in the set

By tweaking the above values, you can easily get the false positive probability to respectable levels while still saving a large amount of space.

After I discovered the Bloom Filter, I went looking for an implementation in Java. Sadly, a standard implementation doesn't exist! So, I wrote a quick and simple version of the Bloom Filter for Java. You can find the source code on GitHub.

My implementation uses:

MD5 Hash
- To add an Object, the set takes the value of the hashCode() method to compute the MD5 hash. For subsequent values of k, the filter uses the previously computed MD5 hash (converted to an int) to generate the new MD5 hash.
Backed by a simple byte array
Implements the Set<Object> interface, although some of the methods in the interface will not work properly.

Note that the project also used the SizeOf Library to get the number of byte used in memory.
I also did a few quick expirements to compare the filter to a standard ArrayList in Java and a few performance checks.

Time required to add an element to the set using different k values
Size of the set versus the array list at different levels

As to be expected, the larger the number of elements required to be in the set, the more useful the Bloom Filter becomes. It does get a bit tricky when determining how large the Bloom Filter should be and what the optimal k value is for a given set, especially if the set is continually growing.

For the tests, I simply added Objects (which have a size of 16 bytes) to each data structure, and I then use the SizeOf library to get the true amount of space used.

From the above graph, its easy to see that the Bloom Filter is much more efficient on size once the array becomes larger than 100 objects. That trend continues at 1500 objects, with the Bloom Filter requiring 22808 bytes less than the ArrayList to store the same amount of elements.

The above graph shows the time in seconds (on an early 2012 iMac) to add an element to the list with different numbers of bits set (k). As k increases, the time increases fairly slowly up to 10 bits. However, anything past 10 becomes very costly, with 100 bits set requiring a full second to complete.

Feel free to check out the source code for the tests and the Bloom Filter implementation itself on GitHub.

A Reason to Write Android Apps First

2012-10-23T16:34:00.001-04:00

If you work on a mobile app and you're planning on developing it on Android and iOS, it may be less work for you to write it on Android first. Google recently released a new tool that makes porting Java code to iOS much easier.
The project (j2objc) can be found here.

To give the program a quick test run, I ran it using this Java file:

public class hello {

public static void main(String[] args) {

System.out.println("To Objective C we go!");

}

}

After running the above code using j2objc, I received two files (as expected): the header file, hello.h, and the source file, hello.m. The source file looks like this:

//

// Generated by the J2ObjC translator. DO NOT EDIT!

// source: hello.java

//

// Created by Isaac on 10/18/12.

//

#import "IOSObjectArray.h"

#import "hello.h"

@implementation hello

@end

int main( int argc, const char *argv[] ) {

int exitCode = 0;

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

IOSObjectArray *args = J reEmulationMainArguments(argc, argv);

NSLog(@"%@", @"To Objective C we go!");

[pool release];

return exitCode;

}

J2Objc certainly has to make a few decisions when converting between the two languages. One is seen above, as System.out.printLn is converted to NSLog. Currently J2Objc can convert much of Java, including things like reflection and anonymous classes in Java. I imagine these kinds of decisions are made through the program.

Although the library can't touch any specific Java code related to the Android APIs, it can handle anything written in pure Java. The tool certainly has potential, especially for converting standard java classes directly to their Objective C equivalent.

Advance Data Structures from MIT

2012-10-16T19:23:00.001-04:00

Up for learning about some new Data Structures? MIT just released some vidoes from their Spring 2012 Advanced Data Structures class.

The first lecture goes on about the Pointer Machine style, as well as Temoral Data Structures (sounds interesting, right?). I'm sure there are some really interesting things hidden in these videos, which can be found here.

I imagine I'll be posting a few more articles as I run through the lectures.

Android Tutorial: Finding the SD Card Path

2012-10-09T15:12:00.001-04:00

Finding the SD Card path in Android is easy right? All you have to do is use Environment.getExternalStorageDirectory(), and you’re good to go!
Well, not quite.
After all, that’s what StackOverflow says. If you actually try the above method on a Samsung device, life won’t be fun for you. Environment.getExternalStoreDirectory() actually returns the incorrect path on most Samsung devices. That’s how I came across the issue. It turns out, the above method doesn’t actually guarantee that it will return the SD Card directory. According to Android’s API documentation,
“In devices with multiple ‘external’ storage directories (such as both secure app storage and mountable shared storage), this directory represents the ‘primary’ external storage that the user will interact with.”
So the call doesn’t guarantee that the path returned truly points SD Card. There are a few other ways to get an “external” path on the device where files can be stored, though, like the getExternalFilesDir().
There are also a few other tricks to actually get the path of the SD Card directory. The below code works on most Android devices (Samsung included). It’s a pretty hacky solution, though, and who knows how long this trick will actually work (source). Instead of using the code below, it may be better to ask the question, “do I really need the SD Card directory, or just a path that I can store files to?”

File file = new File("/system/etc/vold.fstab");

  FileReader fr = null;

  BufferedReader br = null;

  

  try {

      fr = new FileReader(file);

  } catch (FileNotFoundException e) {

      e.printStackTrace();

  } 

  

  try {

      if (fr != null) {

          br = new BufferedReader(fr);

          String s = br.readLine();

          while (s != null) {

              if (s.startsWith("dev_mount")) {

                  String[] tokens = s.split("\\s");

                  path = tokens[2]; //mount_point

                  if (!Environment.getExternalStorageDirectory().getAbsolutePath().equals(path)) {

                      break;

                  }

              }

              s = br.readLine();

          }

      }            

  } catch (IOException e) {

      e.printStackTrace();

  } finally {

      try {

          if (fr != null) {

              fr.close();

          }            

          if (br != null) {

              br.close();

          }

      } catch (IOException e) {

          e.printStackTrace();

      }

  }

Android and Jenkins: Continuous Integration

2012-09-04T07:23:00.001-04:00

By using Jenkins, it’s pretty easy to get a Continuous Integration server set up with an Android project. But before you dive into setting up the software itself, it’s very helpful to have some basic concepts on a few different types of software that you will run into.

For those unaware, Continuous Integration is a way to improve your code by following the “fail fast” concept. If any bug or problem crops up in your application, you want to find them as early as possible. By building and testing your application frequently, you can do just that. By finding the bug quickly, it will be easier to fix the problem, as the code was written recently.

What CI really does for you is two things:

Compiles the application when any new changes are checked in
Runs automated tests every time we recompile

So CI is really only helpful if you are growing your Unit Tests as well as your application. Without the tests to support your application, Continuous Integration quickly loses its usefulness.

Jenkins is really an automated build server for a number of different types of applications. Jenkins itself is written in Java, so it’s only natural for it to support Java projects at its core, which works out great for Android.

Jenkins Plugins

One of the really awesome things about Jenkins is it’s plugin capability. Jenkins alone can pull your software (from SVN) and build it, if you’re a Java project, but that’s really it. By adding a few plugins, you can add some more interesting and useful features. Without a handful of plugins, using Jenkins as a CI server wouldn’t be possible.

For Android, these two Jenkins plugins are incredibly useful:

Android Emulator
- Allows automated unit testing using the emulator
xUnit
- Improves the basic jUnit support of Jenkins

Ant

When using Jenkins, some basic knowledge of Ant is also necessary. If you’re building Android projects with Eclipse, you likely don’t ever deal with the configuration that is required to build your application. With Jenkins, you have to do a bit of work to get it building properly by creating an Ant script for your app.

I won’t go into the details of actually creating an Ant script. You can find more info. on Ant from the above link, and this blog post helps immensely when generating the script from scratch.

Unit Testing

Robodium is a framework that beefs up Android Unit Test capabilities. It allows much easier testing of UI elements within Android. If you are looking to write unit tests for your application, you should really check it out.

I hope this article helps you get the basics of what’s really needed for an Android CI server using Jenkins. To get into the details to truly set the server up, check out this blog article:http://blackriverweb.com/2012/02/android-continuous-integration-with-ant-and-jenkins-part-1/

How to Use Android's TextView as a Hyperlink

2012-08-27T16:44:00.000-04:00

With a few simple pieces of code, it's really easy to convert a TextView into a hyperlink, which opens the default browser outside your app.

Just follow these steps:

Set the text of the TextView with a bit of HTML (by using the Html.fromHTML method, or by using the strings.xml file)

"<a href=\"http://www.programmingmobile.com\">ProMobile</a>"

Set the MovementMethod of the TextView with LinkMovementMethod.getInstance()

That's it! It is important to note that this method does cause the link to open outside the control of your application. If you want the link to open within your app, you should open the link within a WebView instead.

Why Code Assumptions are Bad - Quarks with Android's CheckBoxes and ListViews

2012-08-14T18:15:00.000-04:00

Last week I spent a few hours with a pretty annoying problem. I was developing a simple List View that contained items with a Checkbox and a couple of TextViews. When a user would check a Checkbox on an item, that Checkbox state would be saved. The functionality should be that when the user scrolls away from a checked item, and they scroll back, the checked state should be refreshed.

To set this up, I used the View tags functionality to map Checkbox states to a specific item in the list view. Every time a new view was created with the List View Adapter's getView call, it checked the view's tag to get the Checkbox state. This part worked like a charm. But despite the View tag mapping, the Checkbox state was still being lost after scrolling.

After spending a few hours debugging the code, I finally figured out the problem. The problem involved yet another assumption that I had within the code.

For a Checkbox, in order to receive a callback anytime the user interacts with the Checkbox, you can supply a OnCheckedChangedListener. This listener gets call anytime the user clicks on the Checkbox.
The deadly assumption that I made was that this callback only is called when the user interacts with the Checkbox.

I had my code set up like this within the getView call:

Set the OnCheckedChangedListener
Set the Checked state of the Checkbox by using the setChecked method and using the View Tag functionality described above.
And so on

This ordering is what burned me. It turns out, the setChecked method also triggers the OnCheckedChangedListener to be called. So anytime I set the state of the Checkbox, the OnCheckedChangedListener would immediately call and wipe out the state I had just added.

The fix is really easy. All I needed to do was just switch the order of the two calls above. Now, by setting the state before I set the OnCheckedChangedListener, I have no problems.

It just goes to show you, assumptions in code always come back to haunt you down the road. I wish I could take credit for finding this silly mistake myself, but I did run across this StackOverflow post about it eventually.

Android WebView CSS Support

2012-08-07T17:02:00.000-04:00

Creating HTML applications can be a great way to cut down development time between two platforms. The trend today is to develop a web app for iOS (with varing amount of native code) and simply use the HTML, CSS, and Javascript on other platforms like Android.

The process can work well, and it can save you considerable time while still having a nice, polished app on multiple platforms. There are a few pitfalls with the approach, though. One of the main troubles is developing for iOS first.

You see, iOS has a great in-app brower. It has support for all of the latest HTML5 components, it fully supports CSS3, and it has great Javascript performance. The problem is, no other platform is near that level yet. This can create some issues when you are porting your HTML,CSS, and Javascript to other platforms, like Android.

When following the pattern above, you should really develop for the lower platform first and then port to iOS. This way, you will have less development time lost to solving compabability issues. Some of these issues could be: Javascript DOM differences, CSS3 syntactical differences, and Javascript performance differences. Also, keep in mind that the usage of third party libraries, that may work great on iOS, may not work on other platforms. It may not even have an equivalent verison available.

One thing to watch out for would be:

-webkit-linear-gradient... versus -webkit-gradient...

I'm sure that there are several other major differences between what is supported between Android and iOS. Once I find more, I'll let you know.

Want to Add a Navigation Drawer to Your Android App?

2012-07-25T15:54:00.000-04:00

Android's Navigation Drawer is one of the major features of an Android phone. The drawer gives the user access to things like notifications (someone just send you a text message), to system events (Wi-Fi has changed) to which apps are currently running (depending on what "skin" of Android is in use). The user can open the Nav Drawer by just swiping down from the Status Bar. The Nav bar also brings a unique animation to the device. The user can draw, hold, and flig the bar open or closed.
Wouldn't that kind of animation be cool to add to your own app? Many apps today are adding sliding menues (think Facebook, Steam, etc..). Although they don't completely have the "swipe and play with" feel to it, it would be really nice to have. However finding the details on the Sliding Drawer was a bit tougher than I thought. After some time, I did find exactly what I was looking for, so let me save you the trouble of looking for it. I found a great tutorial on the Sliding Drawer over on Android People (Android Sliding Drawer Tutorial).

Have fun playing with it! The author is also kind enough to give the full source for the example project. Its great for just pulling it open and using whatever you would like.

Android Performance Tweaking: ParseArray Versus Hashmap

2012-07-16T16:28:00.001-04:00

For the conclusion, just skip to the last section.

One of the more recent Android ADT updates added Android Lint. Lint will check your Android project for simples things that you can change to improve your app. Lint notifies you about things like:

Unused resources
Simple code changes to improve performance
Inefficiencies in XML layouts such as nested weights or unused layouts

And a few other things. When I ran Lint the other day, I found one other performance tweak that was suggested by Lint. I was told that “for maps where keys are of type integer, it’s typically more efficient to use the Android SparseArray API”.

But when should A SparseArray be Used?

After checking out the optimization a bit more, I couldn’t find a ton of data that says when a SpraseArray should be used over a Hashmap. Should it be used in every case where a Hashmap could have been used? What about if the array is small? How about if the range of values is under 500?

These are the kinds of questions I tried to answer with the experiment below. But before I jump right into the experiment details, it’s good to have some background information on Hashmaps and SparsArrays.

What is a Hashmap?

A Hashmap is a data structure that holds “key value” pairs. It has a constant time, or O(1) time requirement for retrieving an element from the array. This means that it takes the same time to pull any element from the array, regardless of the size. This is possible by using a hashing function, which generates the array indices, given the input key.

A Hashmap is used (in this case) to map Integer keys to an object.

What is a SparseArray?

To understand what a SparseArray is, it is helpful to understand how a standard array works. An array is really just a continuous block of memory. The size of this block corresponds to how many elements the array can hold. For example, if a object requires 10 bytes of storage, and the array is created that can hold 5 of these objects, then the array has 50 byte memory block. Each of the objects in the array is given a 10 byte segment. By using the array index, you are actually moving through the array’s memory, 10 bytes at a time.

A problem comes into play when you want specific indices to map to specific objects, and they don’t cover every indices. For example, if you want an object at indices 4 and 5, but you don’t care about indices 1, 2, or 3, then you wind up wasting memory with an array.

Why use a SparseArray over a Hashmap?

It seems that the SparseArray is a more efficient solution than using a Hashmap to map Integers to objects. The theory is that the SparseArray can add and retrieve elements quicker than a HashMap, in this case, by removing the hashing function processing time.

As you can see from the SparseArray page, and the Lint warning, the statements here are pretty vague.

Is a SparseArray better than a Hashmap all the time? If not, when does a HashMap become more efficient than the SparseArray?

The Experiment

To compare the two data structures, I designed a quick and simple test (and app). The bench marks gauge how long it takes to:

Insert x random values (with a range from 0 to y)
Retrieve x random values (with a range from 0 to y)

To handle this experiment, I wrote a simple Android app that contains a basic UI, and a few Async Tasks to do the above experiment (available on Github soon).

For the experiment, I tested two different variables:

The array size from 1, 10, 100,…, to 1,000,000
The range of numbers within the array from 1, 10, 100, …, to 100,000,000

The app was run on a Samsung Galaxy 2 with Android version 2.3.4.

Results

SparseArray Results

The SparseArray is a very quick data structure for sizes of 10,000 and less. If you are pulling data from your array considerably more than adding to it, you can get away with a size of 100,000. It starts to slow down a bit with the jump to 1,000, but nothing too surprising.

Hashmap Results

The Executive Summary

The Hashmap and the SparseArray have very comparable performance up to the 10,000 size mark. The 100,000 size mark is where some interesting results are found. For retrieving elements within a 100,000 size array, performance deteriorates quickly once the range of integers exceeds 1,000.

So it seems the Hashmap and the SparseArray are very similar for data structure sizes under 1,000, with any range you would like. The performance gains at a size of 1,000 would likely be very small, if any.

Both data structures have difference performances when the size has been increased to the 10,000 mark. At this level (in yellow in the above graphs), the Hashmap has greater performance with adding objects, while the SparseArray has greater performance when retrieving objects.

At a size of 100,000 (in red in the above graphs), the Hashmap loses performance very quickly, at the 100 range mark. However the SpraseArray is still able to retrieve elements in this range with comparable efficiency. It also breaks down after the 1,000 range limit has been hit through.

So with all the fun stuff above, I walk away with a few new theories:

In Android (and mobile programming in general) having more than 10,000 objects in a data structure in memory seems to be an upper limit.
For smaller arrays (under 1,000) the performance of the SparseArray and the Hashmap are very comparable
For arrays larger than 10,000, if you are adding more than retrieving elements, try the SparseArray.
For arrays larger than 100,000, give the SparseArray a shot… or fix your application design so you don’t have any insanely large in-memory data structures.

Google IO 2012 Session Videos are Up

2012-07-12T09:54:00.001-04:00

Now that this year’s Google I/O is over, all of the sessions have be uploaded to YouTube. This year we have 28 videos, each of them about an hour long. I highly recommend checking out at least a few of them.

Time to start watching.

Python Is Out For IOS

2012-07-09T17:51:00.001-04:00

It looks like Python is the way to go if you want to use a scripting language in the mobile world. Python is out for iOS now, although its not free. It looks like it is a bit further along and more polished than the Android version Google has been working on for awhile now. Writing apps in Python over Java or Objective-C would make life much easier. I guess well see how bad the performance hit for using a scripting language in the mobile world is soon.

JSON versus XML: Is JSON Really Better than XML?–Here’s the Code

2012-06-25T16:01:00.001-04:00

The code used to test the performance of JSON and XML is now available on GitHub. For more info, check out my last post: JSON versus XML: is JSON Really Better Than XML?