While UIAppearance isn’t a brand new topic, it seems to get less love than it should. UIAppearance is a protocol available since iOS 5 that allows a developer to quickly configure the appearance of user interface controls provided by Apple. The fact that that your custom controls can take part in UIAppearance is talked about even less. This post will cover the basics of using UIAppearance and will explore adding support to your custom interface components.

UIAppearance Basics

You’ll be glad to know that UIAppearance is a straightforward API with almost no learning curve. To use it you need only know three things.

• Properties and methods exposed to UIAppearance are decorated with the UI_APPEARANCE_SELECTOR attribute.
• The class method +[UIControl appearance] will set the UIAppearance system to apply the specified properties when the control is created.
• The class method +[UIControl appearanceWhenContainedIn:] will set the UIAppearance system to apply the specified properties when the control is created, but only when it is created in the specified containers.

That is all there is to it. UI_APPEARANCE_SELECTOR, + appearance, + appearanceWhenContainedIn:

Adding some style to UINavigationBar

Let’s see how this works. Say you want to style your UINavigationBar to be something a little different than the standard iOS style. First, look at the header file for UINavigationBar (you can find this by right-clicking on the symbol and choosing ‘Jump to Definition’ on it in Xcode).

Search for UI_APPEARANCE_SELECTOR. You’ll see it attached to many of the properties and methods, but not all. This is your guide to what is available by UIAppearance. In our case, the first time we see the attribute is with:

1

@property(nonatomic,retain) UIColor *tintColor UI_APPEARANCE_SELECTOR;

This means that the tintColor property is available for UIAppearance. This means I can now apply a global style affecting the tint to all UINavigationBar objects by telling the appearance proxy:

1

[[UINavigationBar appearance] setTintColor:[UIColor redColor]];

Now, no matter where a UINavigationBar is displayed within my app, it will be tinted red. Classy.

You can make this even more specific by telling the style to only apply when it is inside your own YOURCustomViewController. Consider the code:

1
2

[[UINavigationBar appearanceWhenContainedIn:[YOURCustomViewController class], nil]
                               setTintColor:[UIColor redColor]];

You’ve now told it to only apply the red tint color when a UINavigationBar is displayed inside a YOURCustomViewController. However, if I add a UINavigationBar to another view controller, it will not be tinted red. Only in the case that an instance of a UINavigationBar is in the hierarchy below an instance of a YOURCustomViewController will it be tinted red. Still classy.

All of these appearance styles can be applied as early as you like in your application. For example, you can set all your styles in -[UIApplicationDelegate application:didFinishLaunchingWithOptions:].

Supporting different iOS versions

As can often occur when working with any API, certain versions of can provide different functionality. How can we build an application level style when the available methods and properties on Apple’s controls are changing?

Thankfully, Objective-C is a dynamic language that allows runtime introspection on your objects. In a similar style to how you would ask your object if it -respondsToSelector:, you can ask a class if it’s instances respond to a method as well.

Consider this sample:

1
2
3

if ([UINavigationBar instancesRespondToSelector:@selector(setShadowImage:)]) {
    [[UINavigationBar appearance] setShadowImage:awesomeShadow];
}

The shadowImage property is new to iOS 6. Using +[NSObject instancesRespondToSelector:, we can inspect whether any instance of an object of this type will respond to this selector. Since you’ll be using the class type to apply an appearance, not an instance, this class method will tell you if this property can be used.

Using UIAppearance in your custom UI views

As stated earlier, you too can take advantage of UIAppearance in your custom views. Following the same pattern as seen above, let’s create a UIButton subclass that provides a property through UIAppearance.

I want to expose the font of the label on a UIButton. After subclassing, I’ll create a property that is decorated with `UI_APPEARANCE_SELECTOR called titleFont.

1
2
3
4
5

@interface TWTButton : UIButton

@property (nonatomic, strong) UIFont *titleFont UI_APPEARANCE_SELECTOR;

@end

Next, I create the setter implementation and set the title label’s font property.

1
2
3
4
5
6
7
8
9
10
11
12
13

#import "TWTButton.h"

@implementation TWTButton

- (void)setTitleFont:(UIFont *)titleFont
{
    if (_titleFont != titleFont) {
        _titleFont = titleFont;
        [self.titleLabel setFont:_titleFont];
    }
}

@end

Now, you can set its appearance as if it was always available via UIAppearance:

1

[[TWTButton appearance] setTitleFont:myFont];

For a more detailed example of this, check out TWTButton.

• Enforce framework requirements in a concise way.
• Wrap platform differences
• Keep your code DRY

First things first. Create a class with a private constructor. That will prevent accidental instantiation of the helper class. For our purposes, the helper class will simply be a collection of public static methods.

1
2
3

public class ExternalStorageHelper {
  private ExternalStorageHelper() {}
}

Enforce framework requirements

Let’s use Android’s external storage as an example for building a helper class. Before working with external storage, getExternalStorageState() should be called to check it’s availability. The call returns a String and checking the value can be a little ceremonial. It might be cleaner just to ask the boolean question you care about.

The method isExternalStorageMounted() shows that you can ask that simple question to test for the required availability.

1
2
3

public static boolean isExternalStorageMounted() {
  return Environment.getExternalStorageState().equals(Environment.MEDIA_MOUNTED);
}

In a recent tweet, Romain Guy reminded developers to put data in the right place on external storage. Your app might benefit from the media scanner by placing files in the correct location. A helper method can enforce this and you only have to remember the details once. Here, music files can be directed to appropriate directory.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public static File openMusicDirectory(Context context) {
  if (isExternalStorageMounted()) {
      return (Build.VERSION.SDK_INT >= Build.VERSION_CODES.FROYO) ?
          context.getExternalFilesDir(Environment.DIRECTORY_MUSIC) :
          openDirectory("music");
  }
  return null;
}

private static File openDirectory(String dirname) {
  File f = null;
  if (isExternalStorageMounted()) {
      File storageDir = Environment.getExternalStorageDirectory();
      f = new File(storageDir, dirname);
      if (f != null && !f.exists()) {
          f.mkdirs();
      }
  }
  return f;
}

Wrap platform differences

Prior to API 8, files were written using getExternalStorageDirectory(). Beginning with API 8, getExternalFilesDir() is used with a type parameter to enable the media scanner to properly categorize files.

You can make your application’s files available for sharing. In openPublicPicturesDirectory(), we use the required directory to share images that will not be deleted with the application. Despite the runtime API level, the files will be saved in a sharable, public directory.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public static File openPublicPicturesDirectory() {
  if (isExternalStorageMounted()) {
      return (Build.VERSION.SDK_INT >= Build.VERSION_CODES.FROYO) ?
          Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_PICTURES) :
          openPublicDirectory("Pictures");
  }
  return null;
}

private static File openPublicDirectory(String dirname) {
  File f = null;
  if (isExternalStorageMounted()) {
      File storageDir = Environment.getExternalStorageDirectory();
      f = new File(storageDir, dirname);
      if (f != null && !f.exists()) {
          f.mkdirs();
      }
  }
  return f;
}

Another example, getCacheDir(), also shows this ability to wrap platform differences. The cache directory is a useful location to temporarily persist files. If external storage is not mounted, we fallback to the device internal memory using Context.getCacheDir().

1
2
3
4
5
6
7
8
9
10
11
12
13

public static File getCacheDir(Context context) {
  return isExternalStorageMounted() ? getExternalCacheDir(context) : getCacheDirByContext(context);
}

private static File getExternalCacheDir(Context context) {
  return (Build.VERSION.SDK_INT >= Build.VERSION_CODES.FROYO) ?
          context.getExternalCacheDir() :
          context.getCacheDir();
}

private static File getCacheDirByContext(Context context) {
  return context.getCacheDir();
}

If external storage is available, it will use it, provided the device is running API 8 or higher. Otherwise, it will fallback to internal memory as before.

Keep your code DRY

These are small methods. Even so, copying and pasting little snippets throughout your app is a code smell. The helper is just enough context to wrap reusable functionality.

There are some legit objections to helper functions, especially when they are used as a dumping ground for unrelated functionality. They can resist refactoring since they aren’t in front of you all the time like the classes that call them. So keep it small and focus on your application’s needs. There’s no need to construct a generic library for everything. So, rewrite your helpers for each application if you want. That way you’re not locked into a strict library pattern of error or exception handling. Let your app be your guide.

It’s a little convenience that keeps your code clean and your head free of low level framework details.

Here is a talk I gave at a CocoaHeads Raleigh-Durham event earlier this year and at the latest CocoaConf Raleigh:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

- (void)viewDidLoad
{
    [super viewDidLoad];
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(someMethod:) name:kMyNotificationIdentifier object:nil];
}

- (void)dealloc
{
    [[NSNotificationCenter defaultCenter] removeObserver:self];
}

- (void)someMethod:(NSNotification *)note
{
    // Message received
}

Blocks!

As of iOS 4 and the introduction of blocks, Mac and iOS developers can now use blocks to subscribe to NSNotification broadcasts. This new method also allows you to specify an NSOperationQueue to perform the block action on.

1
2
3
4
5
6
7

- (void)viewDidLoad
{
    [super viewDidLoad];
    [[NSNotificationCenter defaultCenter] addObserverForName:kMyNotificationIdentifier object:nil queue:nil usingBlock:^(NSNotification *note) {
        // message received
    }];
}

Wait, what?

Not so fast! Who is the observer? What removes this observer? What if you load several view controllers that do this? This block based method is not as simple as it appears. Reading the docs, we learn that addObserverForName:object:queue:usingBlock: actually returns an opaque observer that you are meant to retain, and subsequently -removeObserver with. Let’s take a look at what this looks like.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@implementation MyViewController
{
    id _notificationObserver;
}

// ...

- (void)viewDidLoad
{
    [super viewDidLoad];
    _notificationObserver = [[NSNotificationCenter defaultCenter] addObserverForName:kMyNotificationIdentifier object:nil queue:nil usingBlock:^(NSNotification *note) {
        // message received
    }];
}

// dealloc, or potentially a method popping this view from the stack
- (void)dealloc
{
    [[NSNotificationCenter defaultCenter] removeObserver:_notificationObserver];
}

As you can see, you still need to track the observer of a notification and remove it. Similar to what you would do if you were using the selector-based notification listener. Oddly enough, this is an example of a block-based API not really improving things. For this API, the selector-based NSNotificationCenter listener is a much simpler option as you don’t have to maintain the observer seperately.

To find out more information visit the git bisect manual page.

Using TTAlertView

Using TTAlertView is simple. TTAlertView uses the familiar initWithTitle:​message:​delegate:​cancelButtonTitle:​otherButtonTitles: and show methods to create and display your alert view. From there TTAlertView handles laying out and animating the view.

Lets see some code:

1
2
3
4
5
6
7
8
9

- (void)simpleAlert
{
  TTAlertView *alert = [[TTAlertView alloc] initWithTitle:@"A Simple TTAlertView"
                                                  message:@"... with the default layout!"
                                                 delegate:self
                                        cancelButtonTitle:@"Dismiss"
                                        otherButtonTitles:nil];
  [alert show];
}

… which gives you this:

Of course, this alert hasn’t been customized at all, so it looks lame. Let’s see what adding in some custom images can do for us…

Customizing TTAlertView

To customize this alert view, we’re going to set the background image for containerView (the box containing the title, message, and buttons). Since TTAlertView handles the layout and, most importantly, the sizing of the containerView, using a resizable UIImage here is best practice – this guarantees that no matter the size of the containerView, the image will be stretched appropriately to fit.

We’re also going to add some button images using TTAlertView’s setButtonBackgroundImage:​forState:​atIndex: method. With this method we will set images for the button’s normal and highlighted states, again using resizable UIImages. (If you’re using textured button images or button images with text baked in, worry not – we’ll cover how to use these types of assets in a future blog post!)

Here’s some more code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

- (void)fancyAlert
{
    TTAlertView *alert = [[TTAlertView alloc] initWithTitle:@"A Fancy TTAlertView"
                                                  message:@"... with images and designs!"
                                                 delegate:self
                                        cancelButtonTitle:@"Dismiss"
                                        otherButtonTitles:nil];

    // we don't want the background peeking through
    [alert.containerView setBackgroundColor:[UIColor clearColor]];

    // resizable images work best
    UIImage *backgroundImage = [bgImage resizableImageWithCapInsets:bgCapInsets];
    UIImage *buttonOffImage = [btnOffImage resizableImageWithCapInsets:buttonCapInsets];
    UIImage *buttonOnImage = [btnOnImage resizableImageWithCapInsets:buttonCapInsets];

    [alert.containerView setImage:backgroundImage];
    [alert setButtonBackgroundImage:buttonOffImage
                           forState:UIControlStateNormal
                            atIndex:0];
    [alert setButtonBackgroundImage:buttonOnImage
                           forState:UIControlStateHighlighted
                            atIndex:0];

    [alert show];
  
}

… and voilá!

We’re done here

A quick shout-out to one of our favorite clients: Go Try It On. GTIO provided the assets used in the stylized alert example seen above – the assets were taken from the custom alert view in GTIO’s app, which is where TTAlertView was pioneered!

This is just a taste of TTAlertView’s potential. In future posts we will cover more ways to use TTAlertView – like using fixed-size images, tweaking the layout, and supplying custom view hierarchies. Stay tuned!

We wanted to include a horizontally-scrollable list of images so that many of them could be shown without much expense in smartphone screen real estate. Other information might need to be presented on the same screen as well, so our scroller would need to be hosted inside a vertical scroll view, and would have to play nice with its motion event handling. We also knew the images would need to be retrieved from a URL, and sometimes there would be many of them, so they would have to be lazy-loaded and cached locally.

HorizontalImageScroller-Android solves these problems, and makes it easy to implement in your own app. Imagine a scenario where you have a list of objects that contain URLs that correspond to photos, and you’d like to show those in a horizontally-scrollable list.

In the layout xml for your activity (or fragment, if that’s how you roll), just add the element:

1
2
3
4

<com.twotoasters.android.horizontalimagescroller.widget.HorizontalImageScroller
    android:id="@+id/my_horizontal_image_scroller"
    android:layout_width="match_parent"
    android:layout_height="wrap_content" />

Then, in your activity’s onCreate() (or your fragment’s onCreateView()), just set up the scroller’s adapter with a list of ImageToLoadUrl objects.

1
2
3
4
5
6

ArrayList<ImageToLoad> images = new ArrayList<ImageToLoad>();
for (YourObjectWithSomeImageUrlProperty myObject : myListOfObjectsWithSomeImageUrlProperty) {
    images.add(new ImageToLoadUrl(myObject.getTheUrlToTheImage())); // adapt as necessary
}
HorizontalImageScroller scroller = (HorizontalImageScroller) findViewById(R.id.my_horizontal_image_scroller);
scroller.setAdapter(new HorizontalImageScrollerAdapter(images));

For more detail, see the readme included with the HorizontalImageScroller-Android library. For even more detail, see the included sample app. The above should be enough to get you started though.

Here’s a talk I gave this summer about Foundation’s lesser-known collection classes.

If you found this valuable, consider a local meetup group. Ours is CocoaHeads RTP, and we’d love to see you. If you’re remote, antisocial, or allergic to pizza, you can watch more of these videos at cocoaheads.tv.

A quick review of AsyncTask

So we’re all on the same page, let’s provide a quick review of AsyncTask usage. AsyncTask has a flexible implementation that makes it possible to process any type of input, provide any type of progress, and return any type of final data. Let’s create a very simple – read: useless – example that counts some number of seconds down, providing some progress every second and creates a Toast when complete.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

package com.twotoasters.toastmo;

import android.app.Activity;
import android.content.Intent;
import android.os.AsyncTask;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.ProgressBar;
import android.widget.Toast;

public class DontUseAsyncTaskLikeThisActivity extends Activity {

  private ProgressBar _progressBar = null;

  
  /* (non-Javadoc)
  * @see android.app.Activity#onDestroy()
  */
  @Override
  protected void onDestroy() {
      super.onDestroy();
      _progressBar = null;
  }


  /* (non-Javadoc)
  * @see android.app.Activity#onCreate(android.os.Bundle)
  */
  @Override
  protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.main);
      _progressBar = (ProgressBar)findViewById(R.id.progressBar1);
      
      Button button = (Button)findViewById(R.id.switch_button);
      button.setText(R.string.switch_to_good);
      button.setOnClickListener(new OnClickListener() {
          
          @Override
          public void onClick(View v) {
              Intent i = new Intent(DontUseAsyncTaskLikeThisActivity.this, ListenerAwareAsyncTaskDemoActivity.class);
              startActivity(i);
              finish();
          }
      });
      
      AsyncTask<Integer, Integer, Void> asyncTask = new AsyncTask<Integer, Integer, Void>() {

          @Override
          protected Void doInBackground(Integer... params) {
              int totalTime = params[0];
              int count = 0;
              
              while(count <= totalTime && !isCancelled()) {
                  try {
                      Thread.sleep(1000);
                  } catch (InterruptedException e) {
                      // don't care!
                  }
                  
                  this.publishProgress((int)(((float)count++ / (float)totalTime) * 100f));
              }
              return null;
          }

          /* (non-Javadoc)
          * @see android.os.AsyncTask#onPostExecute(java.lang.Object)
          */
          @Override
          protected void onPostExecute(Void result) {
              Toast.makeText(DontUseAsyncTaskLikeThisActivity.this, "Done!", Toast.LENGTH_LONG).show();
          }

          /* (non-Javadoc)
          * @see android.os.AsyncTask#onProgressUpdate(Progress[])
          */
          @Override
          protected void onProgressUpdate(Integer... progress) {
              // oh dear
              _progressBar.setProgress(progress[0]);
          }
      };
      
      asyncTask.execute(120);
      
  }
}

All of this is reasonably okay and a common usage of the AsyncTask paradigm. Unfortunately, it also crashes horribly in certain circumstances. Why? Because the AsyncTask lifecycle is completely decoupled from the Activity lifecycle (technically it’s almost completely decoupled… but for this conversation, it may as well be). Unless cancelled, the AsyncTask lives on regardless what happens to the Activity that launched it.

So what’s wrong with this?

The easiest way to see the problem is to investigate what happens when we rotate the screen. There are other scenarios that might expose the issue, but the screen rotation configuration change is the most direct and easiest to exercise. By default, when Android processes a configuration change, the Activity is torn down and recreated from scratch.

In our case, we’re setting our ProgressBar to null in the onDestroy() method of our Activity. So on a configuration change, our Activity is torn down, our _progressBar field is set to null and our landmine is set. The next time our AsyncTask calls onProgressUpdate() a NullPointException will be thrown. This is rarely good.

Is this a contrived example? Of course! However, similar, less-contrived logic is often used in AsyncTask objects. “Wait a minute, why don’t you just not set the field to null!” Sure, that might avoid an NPE in this precise case, but it doesn’t address the underlying issue. Our problem, at its root, is that the reference to what we’re updating within our AsyncTask is stale.

How do we fix this?

An approach that we often use is extending the AsyncTask to use a listener that we can register with as needed and unregister with if desired. This allows a tighter coupling with the Activity so that AsyncTask can always operate with a fresh reference. Here’s our AsyncTask subclass.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97

package com.twotoasters.toastmo;

import android.app.Activity;
import android.os.AsyncTask;

public abstract class ListenerAwareAsyncTask<Params, Progress, Result> extends AsyncTask<Params, Progress, Result> {

  /**
  * Our completion and progress listener. This is the thing that we'll call when things get
  * completed.
  * 
  * @author bjdupuis
  *
  * @param <Progress>
  * @param <Result>
  */
  public interface OnCompleteListener<Progress, Result> {
      public void onComplete(Result result);
      
      public void onProgress(Progress... progress);
  }
  
  /**
  * Constructor that registers a listener.
  * 
  * @param the base <code>Activity</code> that the listener runs on
  * @param listener the listener to register.
  */
  public ListenerAwareAsyncTask(Activity activity, OnCompleteListener<Progress, Result> listener) {
      this();
      
      register(activity, listener);
  }
  
  /* (non-Javadoc)
  * @see android.os.AsyncTask#onPostExecute(java.lang.Object)
  */
  @Override
  final protected void onPostExecute(Result result) {
      if(_listener != null) {
          _listener.onComplete(result);
      } else {
          // save the result so we can defer calling the completion
          // listener when (and if) it re-registers
          _result = result;
      }
  }

  /* (non-Javadoc)
  * @see android.os.AsyncTask#onProgressUpdate(Progress[])
  */
  @Override
  final protected void onProgressUpdate(Progress... values) {
      if(_listener != null) {
          _listener.onProgress(values);
      }
  }

  /**
  * Register a listener to be notified when the task completes and updates progress.
  * 
  * @param listener the listener to call
  */
  public void register(Activity activity, OnCompleteListener<Progress, Result> listener) {
      _listener = listener;
      
      // see if we had a deferred result available
      if(_result != null) {
          activity.runOnUiThread(new Runnable() {
              
              @Override
              public void run() {
                  _listener.onComplete(_result);
                  _result = null;
              }
          });
      }
  }
  
  /**
  * Unregister the registered listener. If it's desirable for more than one listener 
  * to be notified, it's trivial to have a list of listeners.
  */
  public void unregister() {
      _listener = null;
  }
  
  // the completion listener we'll call.
  private OnCompleteListener<Progress, Result> _listener = null;
  
  // a temporary storage for the result.
  private Result _result = null;

  private ListenerAwareAsyncTask() {
  }
  
}

We can use this new class as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111

package com.twotoasters.toastmo;

import android.app.Activity;
import android.content.Intent;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.ProgressBar;
import android.widget.Toast;

import com.twotoasters.toastmo.ListenerAwareAsyncTask.OnCompleteListener;

public class ListenerAwareAsyncTaskDemoActivity extends Activity {

  static ListenerAwareAsyncTask<Integer, Integer, Void> _myTask = null;
  private ProgressBar _progressBar = null;
  
  private OnCompleteListener<Integer, Void> _myTaskListener = new OnCompleteListener<Integer, Void>() {

      @Override
      public void onComplete(Void result) {
          Toast.makeText(ListenerAwareAsyncTaskDemoActivity.this, "Done!", Toast.LENGTH_LONG).show();
      }

      @Override
      public void onProgress(Integer... progress) {
          _progressBar.setProgress(progress[0]);
      }
  };

  /* (non-Javadoc)
  * @see android.app.Activity#onDestroy()
  */
  @Override
  protected void onDestroy() {
      super.onDestroy();
      _progressBar = null;
  }

  @Override
  public void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.main);
      _progressBar = (ProgressBar)findViewById(R.id.progressBar1);

      Button button = (Button)findViewById(R.id.switch_button);
      button.setText(R.string.switch_to_bad);
      button.setOnClickListener(new OnClickListener() {
          
          @Override
          public void onClick(View v) {
              Intent i = new Intent(ListenerAwareAsyncTaskDemoActivity.this, DontUseAsyncTaskLikeThisActivity.class);
              startActivity(i);
              finish();
          }
      });
      

  }

  /*
  * (non-Javadoc)
  * 
  * @see android.app.Activity#onPause()
  */
  @Override
  protected void onPause() {
      super.onPause();
      
      if(_myTask != null) {
          _myTask.unregister();
      }
  }

  /*
  * (non-Javadoc)
  * 
  * @see android.app.Activity#onResume()
  */
  @Override
  protected void onResume() {
      super.onResume();

      if(_myTask == null) {
          _myTask = new ListenerAwareAsyncTask<Integer, Integer, Void>(this, _myTaskListener) {

              @Override
              protected Void doInBackground(Integer... params) {
                  int totalTime = params[0];
                  int count = 0;
                  
                  while(count <= totalTime && !isCancelled()) {
                      try {
                          Thread.sleep(1000);
                      } catch (InterruptedException e) {
                          // don't care!
                      }
                      
                      this.publishProgress((int)(((float)count++ / (float)totalTime) * 100f));
                  }
                  return null;
              }
          };
          _myTask.execute(120);
      } else {
          _myTask.register(this, _myTaskListener);
      }
  }

}

You’ll notice our doInBackground(), onProgress(), and onComplete() do precisely the same things at the Activity level as their less-safe alternatives. The biggest difference is that our references will always be fresh. Another benefit we derive is that if the background task completes while we’re away, we’ll be notified as soon as we register of the completed result. This is particularly nice for AsyncTask objects that perform networking operations, since we won’t have “wasted” an out-and-back request/response.

Example project

I’ve created a sample project showing the “bad” way of doing things and the “better” way of doing things. When run on the emulator or device, try rotating the screen a few times in each case. When on the “bad” case, you’ll NPE with great regularity.

Ternary Operations with Objective-C objects

Most people are familiar with ternary operations. For example:

1

NSString *myString = [self isHighlighted] ? @"Highlighted" : @"Not Highlighted";

Similar to this behavior in C:

1

int i = 1 ? : 0;

Objective-C supports omitting the true side of the ternary operator when working with objects. Consider a case where you need to set a string depending on whether another string is nil or not. You might try:

1
2
3
4
5
6

NSString *myString = nil;
if ([self otherString] != nil) {
  myString = [self otherString];
} else {
  myString = kSomeConstantString;
}

We can quickly clean this scenario up (down to one line, even). First, we remove the check against nil. When checking the state of an object ( if (obj != nil) { ... }), nil is a false statment and non-nil is a true statement. Therefore, we can update this to ( if (! obj) { ... } ). We can then expand that into a ternary operation.

1

NSString *myString = [self otherString] ? [self otherString] : kSomeConstantString;

We can go a bit further in this scenario, however. Since the object we are checking is also the true side of the ternary operation, we can omit it.

1

NSString *myString = [self otherString] ? : kSomeConstantString;

UPDATE: Another thing that makes this useful is that the message to self is only sent once. (Thanks to @bmf making this point.)

Who is Two Toasters?

Two Toasters is a growing, highly acclaimed mobile development company based out of Durham, NC and New York City. We love developing beautiful applications for our customers focused primarily on Android and iOS platforms. We’re pretty good at it, too, if we do say so ourselves. Since we’re growing, we’re always looking out for good young developers to turn into awesome veteran Android and iOS developers. We do a lot of teaching internally and decided as a company that it would be rewarding to extend that knowledge out the doors to the general mobile development community.

Why? Simply put, we like cool apps. More good mobile developers means more cool apps. And more good developers hopefully means fewer bad developers which leads to fewer bad apps. Bad apps make our souls bleed. We hate that.

What is ToastMo?

ToastMo is our repository of knowledge. It’s our place to post things we’ve learned, things we wish to teach, or things we think people should know. Some things on ToastMo will be basic, some will be advanced. Some things you might already know, some – hopefully most – you might not. We’ll be teaching things we teach our own junior developers, things that often aren’t necessarily obvious if you haven’t done it before. We’ll teach best practices we’ve developed over time based on our experience with our projects.

How can I get involved?

Thanks for joining us! Requests for future topics are always appreciated, so don’t hesitate to leave a comment.

• Want to develop with us? Email us at careers@twotoasters.com
• Need an app built? Email us at biz@twotoasters.com