Let’s first define our method signature…

using System.Windows.Media;
using System.Windows.Media.Imaging;
void CreateThumbnail(string sourceImage, string outputImage, int width, int height)

The next thing to do is to get our source image into a BitmapSource…

BitmapSource imageSource = BitmapFrame.Create(new Uri(sourceImage));

The class that defines the transformation to be applied to the image is ScaleTransform. We need to create one of these and set the scaling factor to be applied to the width and height…

ScaleTransform st = new ScaleTransform();
st.ScaleX = (double)width / (double)imageSource.PixelWidth;
st.ScaleY = (double)height / (double)imageSource.PixelHeight;

With the transform defined, we need a TransformedBitmap to apply it to…

TransformedBitmap tb = new TransformedBitmap(imageSource, st);

The TransformedBitmap now contains the bitmap after the scaling transform has been applied. The only thing left to do now is write it to disk. In the process we’ll add some metadata just to show how that is done as well…

BitmapMetadata thumbMeta = new BitmapMetadata("jpg");
thumbMeta.Title = "thumbnail";
JpegBitmapEncoder encoder = new JpegBitmapEncoder();
encoder.QualityLevel = 100;
encoder.Frames.Add(BitmapFrame.Create(tb, null, thumbMeta, null));
using (FileStream stream = new FileStream(outputImage, FileMode.Create))
{
    encoder.Save(stream);
    stream.Close();
}

And that’s pretty much all there is to it. As I mentioned above you can use this exact same approach to apply any of the other transform classes in the System.Windows.Media namespace. These are all derived from System.Windows.Media.Transform, and in addition to ScaleTransform they include: RotateTransform, SkewTransform, TranslateTransform, and MatrixTransform.

There’s nothing wrong with the built-in media library, as far as it goes, but it isn’t really suited for managing large numbers of images sorted into categories, i.e. 30 images for one slideshow, 20 for another, etc. There are some plugins that improve on it, but this was all more complicated than I wanted it to be. All I wanted was to be able to prepare a folder of images and have the slideshow drive off of that. Fortunately I discovered exactly what I needed in JonDesign’s SmoothGallery 2.0.

SmoothGallery is a MooTools-based slideshow driver that works off of an HTML document or fragment that describes all the images in the slideshow, as well as the metadata associated with each image (title, description, etc.). The nice thing about this is that it is search engine friendly, and self-contained. The downside is that you have to prepare the HTML document that describes the slideshow. I’m pretty lazy, and didn’t relish the idea of manually adding image elements for 50 slideshow images. So I wrote a tool to do it for me.

SmoothGen is a simple console program that takes as input a folder of images, and outputs a complete HTML document describing the slideshow. It supports all of the options available in SmoothGallery, as well as some additional features such as alternative thumbnail sizes, changing the height of the info pane, and importing title/description fields from image metadata. It was written to work with SmoothGallery 2.0, and requires the .Net framework version 4 to run. The source is included, so you should be able to rebuild it for earlier versions of the framework if you need to. If you have any questions that aren’t answered in the documentation, feel free to drop a comment here.

Download SmoothGen 0.9

Config transformations are essentially a set of rules, similar to an XSLT in intent, if not in syntax, that replace or transform the content of specific nodes in the .config XML when the site is published. The full capability is quite powerful, but I am going to ignore 90% of it here. If you want to understand the whole thing there is a useful post on the Visual Web Team Developer blog. It’s very interesting stuff, but my favorite line was the one that began, “Simplest Approach: If you do not mind replicating the entire web.config file in web.staging.config then you can certainly do so…” Bingo! I may take advantage of all the neato matching rules later. For now I’m happy if I can achieve what we do now without requiring script to be created and maintained in a pre-build event.

Fortunately this is dead simple to do. The first step will be to create the transforms. The idea is that you have a base configuration named web.config, and one or more transforms that are applied to it when publishing under specific configurations. If you’re starting with a new web app then transforms for the default “Debug” and “Release” configurations will be created for you. You will find them as file nodes under web.config in the Solution Explorer, similar to the way code behind and designer files are handled. If, like us, you have a solution that predates VS2010 and want to start using config transforms, here’s what you do:

First, make sure you have your configurations set up. We usually have local (Dev), Test, and Production configurations on web apps. Right-click the existing web.config file in Solution Explorer and click “Add Config Transforms.”

Visual Studio will add transforms for any existing configuration that doesn’t already have one. In this simple example the result is two new files: Web.Debug.config and Web.Release.config. Here’s what it should look like after you finish:

The next step is to delete one of them. Why? Well, recall that these are transforms. They change the base .config so that it will work in another environment. Which config doesn’t need to be transformed? The web.config that you use to run locally. What I like to do is modify the existing, or default Web.config so that it is set up to work in local debug situations, and then use transforms to modify it when the app runs in other environments. So in the example above you would get rid of Web.Debug.config, modify Web.config for local debugging, and modify the transform in Web.Release.config to work in the production environment. Here’s a simple Web.config that I will use to illustrate the rest of the example:

<?xml version="1.0"?>
<configuration>
	<appSettings>
		<add key="baseUrl" value="http://localhost:32767" />
	</appSettings>
	<connectionStrings>
		<add name="SiteDB" connectionString="server=localhost;database=SiteDB;uid=user;pwd=password"/>
	</connectionStrings>
</configuration>

As you can see this is set up for local debugging. Now for the release config. If you open up one of the transform files in the editor you’ll notice that it just contains an empty configuration node, along with some additional namespace information. Since we’re taking the simple route and swapping the entire file, the next thing to do is copy the contents of the configuration node from Web.Config to Web.Release.Config and modify it to work in the release environment. We also have to add the attribute that tells the transform tool to swap out the entire configuration node. Here”s what the completed file looks like:

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform" xdt:Transform="Replace">
	<appSettings>
		<add key="baseUrl" value="http://www.mysite.com" />
	</appSettings>
	<connectionStrings>
		<add name="SiteDB" connectionString="server=proddbserver;database=SiteDB;uid=user;pwd=password"/>
	</connectionStrings>
</configuration>

Note the additional namespace attribute on the configuration node. That namespace contains the element and attribute definitions used to define the transformation rules. The template will add this for you when it creates the files. The second attribute on the configuration node is one we need to add manually. The attribute xdt:Transform=”replace” tells the tool to replace the entire contents of a node in the base config with the contents of the same node in the transform. Since we placed this rule on the root configuration node, the entire contents of the config will get pasted in when we publish.

And that’s pretty much it. Once you have this set up the transform will be applied when you publish the site under a named configuration for which a transform exists. One thing to note, which confused me for a couple of minutes, is that the transforms are not applied on a simple local build. If you want the transform to run without publishing you apparently have to add a custom task to your project file and then call it from an event. This decision doesn’t really make sense to me, but I haven’t taken the time to research it and see why they did it this way. Fortunately all my local builds are under my “Dev” configuration, which is handled by the base Web.config, so this doesn’t really cause me an issue. When I publish to test or production the transforms run, and everything works great.

I still have a prejudice in favor of strongly-typed, compiled languages, but I also think scripting is the future of the bulk of development. And it’s still fun. Working with javascript or php today is the equivalent, for me, of loading up the BASIC interpreter and making stuff happen. It’s relaxing after spending my professional day wrangling huge .net solutions across multiple servers and staring at .configs until my eyes water. And just as I did back in the day, I still turn to games when I want to learn something new. They’re fun to program and they cover pretty much every aspect of a language. When I wanted to learn Silverlight I wrote GMemory, a deservedly unheralded accomplishment, but still fun to do. Recently I desired to get up to speed on JQuery, so once again I created a dumb game.

The sliding number puzzle has been around since the mid-nineteenth century. I remember my parents bought them for us to play with on long family car trips, which probably explains a lot about me. They come in various sizes, with the most standard being the fifteen-puzzle, so named because it is a 4 x 4 grid of sliding tiles with one empty spot. I didn’t know this when I started working on mine, so mine is a 35-puzzle, implemented entirely in javascript using JQuery. JQuery is brilliant, for a lot of reasons, but that’s another post. Suffice it to say that it was a lot of fun to work with, and the puzzle itself is interesting. It turns out that the mathematics of the sliding number puzzle have been studied for a long time, and it has proven to be an interesting problem for computer scientists as well, in terms of its inherent properties and the challenges of solving it.

However, before you spend much time trying to solve mine, I should mention that half the puzzles it generates cannot be solved. This is some mathematical property of the puzzle itself which was discovered by some guys named Johnson and Story back in 1879. Unfortunately you can’t tell if you are working on an unsolvable puzzle unto you get to the last number. Muwaahahahahaha. There’s a test to detect an unsolvable configuration, but I haven’t implemented it yet. I also haven’t implemented a solver. There are both search-based and pattern-based approaches to solving the sliding number puzzle, and I wanted to implement one and animate the solution, but I haven’t had the time. If you feel like trying, there’s a link to download the source files on the demo page.

So you want to do some iOS development, but you’ve heard that memory management is a chore? Have no fear. All you have to do is keep track of a reference count on every object in your application, making sure that when the last live pointer to each dies, the object has a ref count of 0 so that it can be deallocated. Ok, so maybe it does suck. If you’re used to modern tools like C# or Java then this world is a real throwback. Fortunately Apple provides some awesome tools for tracking down problems with leaks, and if you follow the right conventions you too can keep your objects from lying around and growing moldy. Since I just went through my first iOS project, and am now an expert, here are five things I’ve learned about iOS memory management:

1. Know the difference between alloc/init and with/by/from/of methods.

The alloc and init methods are the standard means for creating an object on the heap. Some common forms are:

MyObject *anObject = [[MyObject alloc] init];
MyObject *anObject = [[MyObject alloc] initWithSomeText:text];
MyObject *anObject = [[MyObject alloc] initWithColor:[UIColor blueColor]];

One thing that is true about all forms of alloc/init is that they return an object with a reference count of 1. You own that object, and are responsible for releasing it. By contrast what I called the with/by/from/of methods are factory methods that you call to get an object. A few examples you might have seen:

NSString *myString = [NSString stringWithFormat:@"%@", someObject];
NSString *myString = [anotherString stringByAppendingString:aThirdString];
UIFont* aFont = [UIFont boldSystemFontOfSize:17];

Most methods of this form return an autoreleased object. Unless you retain the result then it’s going to be released and deallocated when the next event loop runs. So when do you want to own an object, and when do you want one that is autoreleased? Consider a scenario where you’re passed a string in a callback, and are going to assign it to a property and keep it around. By convention, when you are passed an object in an argument to a method call you don’t own it. You don’t know what the caller is going to do to that object after the method returns. So you want to copy it to your property. Here is one way I’ve seen that done:

@interface MyClass {
}
@property (nonatomic, retain) NSString *myProperty;
@end

@implementation MyClass
@synthesize myProperty;

-(void)somethingSureMessedUp:(NSString *)reason {
    self.myProperty = [[NSString alloc] initWithString:reason];
}
@end

The question is: will that code leak? The answer is yes, it will. The initWithString method returns a new object with a reference count of 1. It is then assigned to a retained property. When an object is assigned to a retained property two things happen: the existing value is released, and the new value is retained. So the string now has a reference count of 2, and even if you follow my tip on releasing retained properties it will still leak. The alternative is the factory method:

-(void)somethingSureMessedUp:(NSString *)reason {
    self.myProperty = [NSString stringWithString:reason];
}

The stringWithString method also returns an object with a reference count of 1, so when we assign it to the retained property it still has a reference count of 2. But before the method returned our shiny new string it called autorelease on it. So when we return from this method and the autorelease pool gets processed this sting is getting a release call, and the reference count will be back to 1. Result: no leak.

So, when do you use init/alloc? Sometimes there isn’t a convenient factory method and you don’t have a choice. In those cases you may want to follow the pattern in Tip 2. In other scenarios you may have an interface component, or a collection, whose lifetime is the same as the containing class. In those cases feel free to call init/alloc and then release the reference in your container’s dealloc.

2. Autorelease what you don’t retain

This is the corollary to Tip 1: if you write a method that produces an object, and you don’t specifically keep a reference to that object and ensure that it is released on dealloc, then autorelease it before letting the reference go. In the context of the example above, if there was no convenient factory method that returned an autoreleased object you could follow another common pattern:

-(void)yourDaughterTookTheCar:(NSString *)reason {
    self.myProperty = [[[NSString alloc] initWithString:reason] autorelease];
}

In this case you’re doing the same thing that the factory method does internally. Your autorelease will balance out the retain that the property setter will do, and nothing will leak, assuming you follow Tip 5.

3. Use properties

Sure, everyone uses properties when they want to make something available to another class, but what about when you just have some internal objects to keep track of? In general, unless a reference has exactly the same lifetime as its container class, i.e. the object it points to is created when the container is created, and deallocated when the container is deallocated, then it makes more sense to keep it in a property than to use an ivar. This is especially true if the reference is going to point to different objects over the lifecycle of the program.

Retained properties retain and release their objects, so assigning a new value to one automatically releases the previous value. This behavior makes it much easier to keep the reference counts of objects with transient lifetimes balanced. The follow-up rule to this one is Tip 4.

4. Always use property access syntax to access properties

I wrote a short post on this one a few weeks ago. Properties are backed up by ivars, and ivars are accessible within the implementation of the class that declares them. It’s all too easy to do this:

-(void)sheBetterBringItBack:(NSString *)reason {
    myProperty = [NSString stringWithString:reason];
}

Outside callers can’t do this, because they can’t see the ivar (unless its public, and it shouldn’t be) and have to use property access syntax. Although you can get away with this inside the declaring class, its either a leak or a crash waiting to happen. The problem is that this notation (leaving out “self.”) bypasses the property setter completely. There is no operator overloading in C, and C is all Objective-C is in the end. The only way to make sure that you call the setter and properly retain the object is to use . syntax to reference the name. Of course you could do this:

-(void)somethingSureMessedUp:(NSString *)reason {
    myProperty = [[NSString stringWithString:reason] retain];
}

But why would you? You’re just doing an end-run around the property mechanism, and you might as well work with it rather than against it. Declaring and using properties correctly can help a lot with the management of object reference counts. My last tip involves what to do with properties at the end of the world.

5. Release retained properties in dealloc

This one might seem like a no-brainer, but it has caught me a couple of times (which doesn’t prove that it isn’t a no-brainer), especially when adding new retained properties to an existing class. The property mechanism only comes into play when a property is set. At the end of the world, when your container object’s dealloc method is called, remember to go through your retained properties and release any that aren’t nil. You can either release them explicitly, or by setting them to nil, but either way they remain your responsibility.

And that’s it, except for one last bonus tip: learn to use the Instruments framework in XCode to profile your memory usage. Apple is pretty strict about app behavior, and leaks can get your work rejected. The leak and allocations analysis tools are really very impressive, and remind me of using Bounds Checker back in the day. They are too big a topic to tack onto the end of this post, but Apple’s developer site has some great overviews. Check them out.

When I finally got around to the hunt-it-down part things weren’t so obvious. As far as I could tell we were doing all the right things to the resources assigned to the tab bar controller. The fact that it only happened after dismissing the application with the home button and then bringing it back had to be meaningful. In fact I had been wondering for some time just what happened when the user hit the home button on an iPhod running iOS 4.x. It was obvious from application behavior that the app wasn’t exiting and restarting. At least, not every time. I started reading up on how iOS manages the application lifecycle, and some lights began going on. Apparently the home button didn’t cause an app to exit, at least not always. If the app didn’t exit it went into a background limbo state, and in that state the operating system might do things. It might, for example, “release unused views.” Oh, really? Lots of lights popped on all at once.

If you were used to writing applications for iOS 3.x (and the guys who started this app were), then you had birth and death to think about, just like any program. When your app started you got a call to application:didFinishLaunching in the app delegate, and when the app exited you got a call to applicationWillTerminate. Typically you allocated your resources at startup, deallocated them in the app delegate’s dealloc method, and life was simple. Enter iOS 4 and “fast task switching.” This facility is a component of Apple’s answer to multi-tasking in iOS 4, the entirety of which includes actual background processing, something I’m not going into now. The piece of it that is relevant here is the switching part. Task switching is what takes place when the user taps the home button, or uses something like Springboard.

If your app is running in the foreground, and the user switches tasks (or a phone call arrives, or anything else happens that would force the app to give up control of the screen) what happens depends on whether the app is compliant with fast task switching. By default all apps built against the 4.0 SDK are. If you want your app to exhibit the old behavior then you have to say so by putting the UIApplicationExitsOnSuspend key in info.plist and setting the value to true. If you do, then the app will simply exit, and applicationWillTerminate gets called as it used to.

If you don’t add that key to info.plist, then the behavior is entirely different. Oliver Drobnik has a great flowchart of the events and accompanying explanation on his Dr. Touch blog. Basically it goes like this: the app starts up fresh and application:didFinishLaunchingWithOptions is called (the replacement for application:didFinishLaunching), followed by applicationDidBecomeActive; the app is now running in foreground and gets switched; applicationWillResignActive is called, followed by applicationDidEnterBackground. After that last call the application is suspended. Unless it is actually doing background processing as alluded to above, nothing is happening, but the image is still in memory. In this stage the OS may, as mentioned, prune the app’s memory usage by releasing invisible graphics objects, and ultimately it may also dump the app from memory if it needs to. If that happens applicationWillTerminate will not be called. Something to keep in mind.

Now what happens going the other way? If the app is suspended in ram and the user taps its icon, then it first gets a call to applicationWillEnterForeground, followed by  applicationDidBecomeActive. In order to avoid the problems we were having you need to at least tear down any invisible/unused views as the app is heading for the background, and then restore these when the app is summoned to the front again, or as needed. So, does applicationWillTerminate ever get called? The answer is pretty much “no.” If you’re building against the 4.0 SDK that method is essentially deprecated. Except… well comments on the Dr. Touch blog indicate that maybe it still does get called if your app is running on earlier devices such as the iPhone 3. I don’ t have one of those to test on, so I’ve decided they don’t exist and my app will never run on them. Solved!

By the way, if you want to see which apps are currently running/suspended on your iOS 4 device double-tap the Home button. The UI will slide up as it does for the Utility app, and a side-scrollable list of app icons will be displayed. When I did this for the first time I was surprised at how many apps were still resident in memory. There is a red badge on each icon that will let you kill the app, and as with a preemptive strike from the OS the app’s applicationWillTerminate method is not called when a user does this. In general I would ignore this list and let the OS manage the app pool, but as a developer it’s nice to know you can force an app out of ram for a restart if you need to.

I’ve only been developing for iOS for a couple of weeks now, but it’s already obvious how ubiquitous the UITableView is in user interfaces. This makes sense. iPhone/Pad/Pod apps are often of the “list info and drill” variety, and the UITableView brings a lot of utility to the, um, table for lists, and even for constructing static dialogs. UITableViews automatically scroll if your content is too long for the vertical screen space, and they give you a lot of control over how individual cells and rows are styled. In the app I recently worked on we used a UITableView to list some stuff that was fetched as XML from a REST webservice. The webservice was taking about 4-5 seconds to retrieve the data over a wifi connection, and I knew it would likely be slower over 3G data connections. To let the user know what was going on I wanted to display an animated activity spinner while the transaction was enroute. If you’ve used the YouTube app for iOS then you’ve seen one of these in action.

The spinner is displayed over the contents of the table view, without obstructing the tab bar control. You can freely switch to another tab while the spinner is displayed over the current tab. It’s a nice, clean way to show that one tab is busy, while allowing the other tabs in the application to remain available. When I tried to replicate this behavior in our app, however, I quickly ran into some quirks. UITableView might be a useful control, but it isn’t all that lenient about how its views are managed. More on that below. First, let’s make the spinner itself.

Fortunately the iOS UIKit contains a view called UIActivityIndicatorView that makes this a pretty easy task. Basically the indicator view provides the little animated spinner. You set up its properties and provide a container. Here’s what the declaration of a reusable spinner overlay might look like. The syntax highlighter doesn’t deal with Objective-C, so I am just using the C filter. Apologies if it doesn’t look right.

// MyActivityOverlayViewController.h
#import <UIKit/UIKit.h>

@interface MyActivityOverlayController : UIViewController {
    UILabel *activityLabel;
    UIActivityIndicatorView *activityIndicator;
    UIView *container;
    CGRect frame;
}
-(id)initWithFrame:(CGRect) theFrame;

As you can see, not much to it. We have an interface derived from UIViewController, with ivars to hold pointers to a label, the spinner, and a container to hold them both. There is also an init method that takes a frame. I’ll talk more about this below, but essentially I found it useful to establish the size I wanted the view to be at initialization. That gets stored in the frame ivar.

So that’s the controller interface. Next let’s look at some key aspects of the implementation. First the init method:

// MyActivityOverlayViewController.m
#import "MyActivityOverlayViewController.h"

-(id)initWithFrame:(CGRect)theFrame {
    if (self = [super init]) {
        frame = theFrame;
        self.view.frame = theFrame;
    }
    return self;
}

This is a pretty simple init method. First it saves the frame, because it will be used later to size and center the nested controls, and then it sets the size of the default view created by the UIViewController. Next we need to create the controls and build our simple view hierarchy. The overridden loadView method is where that gets done:

-(void)loadView {
    [super loadView];
    container = [[UIView alloc] initWithFrame:CGRectMake(0, 0, 110, 30)];
    activityLabel = [[UILabel alloc] init];
    activityLabel.text = NSLocalizedString(@"Loading", @"string1");
    activityLabel.textColor = [UIColor lightGrayColor];
    activityLabel.font = [UIFont boldSystemFontOfSize:17];
    [container addSubview:activityLabel];
    activityLabel.frame = CGRectMake(0, 3, 70, 25);

    activityIndicator = [[UIActivityIndicatorView alloc] initWithActivityIndicatorStyle:UIActivityIndicatorViewStyleGray];
    [container addSubview:activityIndicator];
    activityIndicator.frame = CGRectMake(80, 0, 30, 30);

    [self.view addSubview:container];
    container.center = CGPointMake(frame.size.width/2, frame.size.height/2);
    self.view.backgroundColor = [UIColor whiteColor];
}

This method does a bit more work. After calling the superclass loadView it creates a container to hold the label and activity spinner. Having them inside a container makes it easy to center the group in the owning view. It then creates the label, sets a few style properties, and adds it to the container’s view as a subview. You can set these properties any way you want. I was shooting for essentially the same look as the YouTube app. The last thing that happens to the label is that its frame is set. The size of the rectangle used was figured out based on the font size and relative positioning I wanted, but what’s important is that the size was set after the label was added to its owning view (i.e. the container). I’m not sure why this was important, but it was. Hey, I’ve only been at this a couple of weeks.

The next thing that happens is that the activity indicator itself is created. You’ll note that I’m not autoreleasing any of these objects, so I have to make sure to release them in the dealloc override. I know that UITableView retains its added views, and if that is also true of UIView I could autorelease the controls here and let the view manage them, but as I wasn’t sure of the behavior I opted to play it safe. After the indicator is created it is added to the container view and its frame is also set. Lastly the container itself is added to the UIViewController’s view, it’s center is set to the center of the frame we saved in the init method, and its background color is set to white.

Just a few additional things to finish off the implementation. First we need to start the indicator spinning. The indicator view provides methods called startAnimating and stopAnimating for just this purpose, and you could provide pass-through methods on your overlay controller. That would be the way to go if, for example, you wanted to display the overlay and then start and stop the animation and alter the label as different actions occur. In my case I’m going to have it start spinning whenever its displayed, and stop when it goes away. For that purpose you can override viewWillAppear, and viewWillDisappear:

-(void)viewWillAppear:(BOOL) animated {
    [super viewWillAppear:animated];
    [activityIndicator startAnimating];
}

-(void)viewWillDisappear:(BOOL) animated {
    [super viewWillDisappear:animated];
    [activityIndicator stopAnimating];
}

The only other thing we need to do is clean up after ourselves:

-(void)dealloc {
    if (container != nil) [container release];
    if (activityLabel != nil) [activityLabel release];
    if (activityIndicator != nil) [activityIndicator release];
    [super dealloc]
}

And that does it for a simple implementation of a UIView that can be initialized with a frame size, and that will create a centered combination of a light gray activity spinner and light gray label on a white background. Now all we have to do is display it somewhere. That, as it turns out, is the tricky bit.

To get something on the screen we have a couple of choices. We could tell the tab bar controller to present it as a modal, or to push it as a page. Neither is a very good choice in this instance. Pushed controllers are not modal; they come with a back button by default. Modal controllers take up the whole screen and prevent access to the tab bar. So that’s not what we’re after. The other alternative is to play with views. To do this we would create an instance of the ActivityOverlayViewController, and then pass its view to the addSubView method of our UITableView’s view.

None of my attempts at doing this worked. I tried different combinations of methods to insert the view and then bring it to the top, but whatever I did things got screwed up one way or another. Toward the end I actually got it to display, but the table view drew the cell border lines over it, and that I was not able to work around. Instead, what I had to do was insert the activity spinner view as a subview in the view that owned the table view. In other words, it had to be a sibling view of the table view, not a child, and it had to be on top. Here’s what I came up with:

-(void)showActivityView {
    if (overlayController == nil) {
        overlayController = [[ActivityOverlayViewController alloc] initWithFrame:self.view.superview.bounds];
    }
    [self.view.superview insertSubview:overlayController.view aboveSubview:self.view];
}

So the first thing to note here is that my activity controller is initialized with a rectangle representing the bounds, or inside dimension, of my table view’s superview. The second thing is that it is explicitly added to that view using the method that let’s you specify a view over which it should be placed in the view stack. In this case I want it inserted above the table view.

And that pretty much does it. Add that method, and an ivar to hold the pointer to the ActivityOverlayViewController, to the controller for your table view and you’re all set. To get rid of it when your background action is done, call:

-(void)hideActivityView {
    [overlayController.view removeFromSuperView];
}

And of course remember to clean up after yourself in your dealloc method. Here’s what the result looks like…

The final caveat is that as I mentioned above I am quite new to all this, so if somebody knows a better way to get this done then I hope to hear of it. Meanwhile this works and achieves the desired behavior.

The answer is that it ain’t much handled at all. The scheme relies on manual reference counting using messages like retain, release, and autorelease, and there are a number of rules for when you should send these messages to a given object. One blog post I read called this a “convention-based” regime, which is a good term for it. The important thing when adhering to a convention is to understand what the rules are. Fortunately the rules for Objective-C aren’t numerous or difficult to understand. In a nutshell: if you own an object you must release it. The corollary might be: if you release an object it better be one you created, or one you have taken ownership of by sending it a retain message. The whole thing rests on knowing whether or not you own an object. One of the places where this gets tricky, as old C++ hands will have no difficulty believing, is in property sets and gets.

Fortunately the rules here aren’t all that obtuse either, and they boil down to: when you set a property release the current value, and retain the new value. There are some variations, but in general that’s what you’re going to want to do. Code that gets the value of a property should adhere to another rule: when you receive an object from a method not prefixed with alloc, init, or copy, or when you are passed an object as an argument to a method call, you don’t own it. You don’t release it unless you have first called retain on it. If everybody plays by those rules then everything works fine, but of course that’s always been the rub with primitive languages: voluntary compliance.

In any case, our code did appear to play by those rules, and yet it was still crashing. The scenario was a simple one…

@interface SomeClass
    int someProperty;
@end
@property (retain, nonatomic) int someProperty;

The @property syntax tells the compiler to generate accessor methods named ‘someProperty’ and ‘setSomeProperty’ that adhere to the rules for setting and returning properties. The ‘retain’ and ‘nonatomic’ attributes are instructions to the compiler on how to generate those accessors, in this case adding code to release/retain in the setter, and not adding code to guarantee transactional atomicity. Based on what I could see we were adhering to best practices in using the @property syntax to implement our properties. And yet… it was still crashing.

The line that was faulting looked like this…

self.anotherProperty = someProperty;

Veteran Objective-C programmers will already see a problem here. The line above was faulting trying to read someProperty. The value of someProperty had been set earlier in a line that looked like this…

someProperty = aStringWeWerePassed;

Veteran Objective-C programmers may actually be laughing audibly at this stage of the discussion. The problem with these two lines of code is obvious to them, but it’s the kind of thing a C# programmer would blow right by without a second thought. Naturally, if you define a property and then assign to it, the setter method is going to be invoked. Right?

Uh, no. I’ve been learning as I proceed deeper into this thing that the best way to grok what is going on in Objective-C is to let the old C ethos flood back into your soul. If you never had a C ethos, because you never worked in C, may your deity of choice aid you. In ‘Old C’ the compiler knows diddly squat about properties, and it doesn’t know when to turn a simple and obvious assignment into a call to a method. It doesn’t know unless you tell it, and the way to tell it is like this…

self.someProperty = aStringWeWerePassed;
// or
[self setsomeProperty:aStringWeWerePassed];

Either of these will work, but what we were doing was a simple assignment of one pointer value to another, without going through the setter method, and without calling retain or release or any of that stuff. Specifically, the reason the program was crashing is that when you are passed an object in a method (in a callback from NSXmlParser in this case) the object is guaranteed to be around until the method that passed it to you returns. If you want to keep it longer than that you call retain on it. That’s what happens in the property setter, except that as you know now we weren’t going through the property setter when we set the value. By the time we read that value later the memory had been deallocated.

Objective-C, as I have grown fond of saying, actually is your father’s programming language.

I set up the services to run under the development server on localhost:35000. I then started Portforward.exe and set up a redirect from 192.168.0.100:8888 (the dev machine’s local address) to localhost:35000. The remote client is an iOS app running on an iPod Touch connected via wifi with the address 192.168.0.111. The request was received successfully, the service processed the request successfuly, the result was serialized successfully, but once I let the program run out of the service method the client would report a connection reset. This was tested from the iPod, as well as from a simple console client on another windows box, with the same result.

I fired up Wireshark and monitored the exchange. The inbound request was sent in two packets. The first contained the POST header, and the second contained the request body. After the service finished processing the response header packet was written (including 200 OK and the correct content length), and then RST was sent and the connection was dropped. So, given this scenario I am sort of suspicious that the problem lies with Portforward.exe, but I don’t have time to find a different forwarder, or write one, and test it again. Until I do I can’t really say that the technique will work. In the end I had to go ahead and install IIS to enable the full debugging scenario I needed.

If you Google around on this problem you’ll find a number of solutions. The actual code inside the server that rejects remote connections is just a couple of lines and not at all complicated. For this reason some people have suggested using ildasm to disassemble the web server assembly and comment out the relevant test. But there is a much easier and less intrusive way to get around this problem, and it just takes a couple of minutes to set up.

First, find and download a port forwarding utility for Windows. I use Portforward by Trent Waddington, because it is small, requires no installation, and is easy to use. His download link is to an exe file so I won’t post it here, but you can find it midway down this page. What you’re going to do with the port forwarding utility is make Visual Studio’s web server think your connection is coming from localhost, when in fact it is coming from a remote device.

Once you have the port forwarding utility, open up your VS application, and get into the project properties dialog. Click the ‘web’ tab and look for the ‘Servers’ section of the property page. The radio button next to ‘Use Visual Studio development server’ should be checked. Below it check the radio button next to ‘specific port’, and then type a port number into the edit box on the right. I usually use 35000. Save the project properties. Build and run. Your web application is now running on the dev server and listening for http connections on whatever port you chose.

Now start the port forwarding utility and set up a forwarding rule. You do this in various ways in different tools, but in Portforward you click “Redirections” and then “Add” and it pops a little dialog. Let’s say that the machine you’re running the web app on has an IP of 192.168.0.100, and your client is going to try to connect to port 8080. Set up a rule that forwards 192.168.0.100:8080 to localhost:35000 and you’re good to go. Now when your client connects the connection will be redirected to the development web server on localhost, which will make it happy, and make you happy at the same time.