Fix: Set the startup object on the app project’s properties page

In the .csproj file, this corresponds to the SilverlightAppEntry element:

<SilverlightAppEntry>PhotoDiary.App</SilverlightAppEntry>

I would call it a bug, that you cannot rename a project and have the SilverlightAppEntry update accordingly. But luckily, the work-around is simple.

Have a nice day!

This category has served me well, and even got traction in the iOS developer community, so I never bothered to stop and think if there exist an even better solution.

Especially now that GDC exists, and doing an inline block to invoke on the main thread or a background queue is easier than ever before.

Until Today

Traveling home by bus as usual I got a flash of genius; Why not use proxy objects? Calling a method on the main thread should be no harder then this;

[[self.slider mainThreadProxy] setValue:0.5f animated:YES];

The old NSInvocation solutions have a few drawbacks. First of all there is no code completion for the arguments, secondly there is not even basic type checking, and lastly the implementation is quite ABI specific.

The NSObject class already has support for method forwarding, and wrapping method calls up into NSInvocation instances. Why not use seriously battle proven code that Apple provides.

The Skeleton

The implementation for -[NSObject mainThreadProxy] will be childishly simple:

-(id)mainThreadProxy;
{
    // Return self directly if already on main thread.
    if ([NSThread isMainThread]) {
        return self;
    } else {
        return [CWMainProxy proxyWithTarget:self];
    }
}

The CWMainProxy class is a simple private helper, that will perform all of the heavy lifting. The interface and life time code is very small:

@interface CWMainProxy : NSObject {
    id _target;
}
+(id)proxyWithTarget:(id)target;
@end

@implementation CWMainProxy

+(id)proxyWithTarget:(id)target;
{
    CWMainProxy* proxy = [[[self alloc] init] autorelease];
    proxy->_target = [target retain];
    return proxy;
}

-(void)dealloc;
{
    [_target release];
    [super dealloc];
}
@end

The Meaty Parts

Now comes the tricky parts; actually act like a proxy. The proxy is a simple NSObject subclass, first it needs to be able to fake to any caller that it can respond to everything that the proxies target responds to.

-(BOOL)respondsToSelector:(SEL)sel;
{
    return [super respondsToSelector:sel] ||
           [_target respondsToSelector:sel];
}

Next up if the object claims it responds to a selector but do not have an actual implementation, then we must provide a NSMethodSignature so the run-time can create a proper NSInvocation for us.

-(NSMethodSignature*)methodSignatureForSelector:(SEL)sel;
{
    if ([_target respondsToSelector:self) {
        return [_target methodSignatureForSelector:sel];
    } else {
        return [super methodSignatureForSelector:sel];
    }
}

And finally we need to actually forward the NSInvocation call to the main thread, as per the callers request:

-(void)forwardInvocation:(NSInvocation*)invocation;
{
    [invocation performSelectorOnMainThread:@selector(invokeWithTarget:)
                                 withObject:_target
                              waitUntilDone:YES];
}

Conclusions

Given some thought I regard this solution to be much more elegant than my old solution. And it even yields less and more readable code than using GCD on iOS 4 and later:

[[self.slider mainThreadProxy] setValue:0.5f animated:YES];
    // vs
dispatch_async(dispatch_get_main_queue(),
               ^{
                   [self.slider setValue:0.5f animated:YES];
               });

• The implementation is much smaller, and relies on the Foundation framework functionality, not my own Objective-C ABI hacks.
• It is less code to write to use the functionality.
• Xcode can do proper code completion and basic type checking.
• It is compatible all the way back to iPhone OS 2, or Mac OS X 10.0, if you should care.

The CWFoundation project on Github has a more complete implementation. With more support for optional blocking, delays, and more proxies not only for the main thread but also for background threads and operations queue.

You are seldom alone with great ideas, so a nod to Joachim Bengtsson who has written about an invocation grabber before.

Why am I writing this?

As always when face with a very specific unusual problem – Internet is your friend. So I could just have left it there and allowed you to find the answer the same way I did. The thing is that the solution to my problem was a mashup of several standalone solutions presented on the web. So my idea is to summarize what I did hoping that it will help anyone facing the same problem.

What I did

So here are the steps that I took in order to get everything working. Quite a few steps but I wanted it detailed enough so that anyone could follow.

1. Right click the Dropbox icon in your system tray and select Preferences
2. Deselect Show desktop notifications
3. Deselect Start Dropbox on system startup
4. Download and install Windows Server 2003 Resource Kit Tools. It will warn you about incompatibility, but you can safely ignore this (or at least I did).
5. Open the Command Console (Run –> cmd).
6. Enter sc create DropboxService binPath= C:\Program Files (x86)\Windows Resource Kits\Tools\srvany.exe DisplayName= "Dropbox Service"
7. Open RegEdit and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DropboxService\
8. Create a new key named Parameters
9. Create a string value called Application and enter the full path to your Dropbox executable. Typically C:\Users\****\AppData\Roaming\Dropbox\bin\Dropbox.exe
10. Open Services (Start Menu –> Administrative Tools –> Services)
11. Locate your Dropbox Service, right click and select properties.
12. Set the service to Autostart
13. Under the Log on tab, check Allow service to interact with desktop.
14. Press Apply
15. Start the service
16. You will get a popup asking for permissions to display the Dropbox configuration - Accept.
17. Add your user info

Done!

Thoughts…

Well yes, I realize that this is not how Dropbox was intended to be used. But it surprised me that the only way, at least that I could find, was to hack away with toolkits, console applications and the registry. I’m not really counting on that there will be an easier way in the future. So this post is as much for me to remember how I did it, so that I won’t have to figure it out again, as for helping anyone else in a similar situation.

So what is a Chaos Monkey?

Before I continue, we should perhaps clarify what a chaos monkey is. I think that it all started 1983 during the development of MacPaint and MacPrint (the full story can be found here). What basically happened was that Steve Capps created a helper application that fed events to the other applications under development. The events represented things such as the keyboard being pressed and mouse clicks. While the application was running it kind of looked like a really frantic monkey was slapping the keyboard and playing with the mouse. Hence, it was named “The Monkey”.

The monkey was then used to test the applications and make sure that it did not crash whatever you threw at it. Much like when you sit down next to user that tries out your application for the first time and you know… he/she “uses it wrong” so that it provokes a crash. You could argue that it’s their own fault, but deep inside, you know that you probably should have handled those characters in the number field a little better. (Authors note: Neither I nor Jayway as a company compare end users to monkeys, this was just an example…)

Now, fast forward a couple of years and we have Netflix that started move onto Amazon Web Services (you can read more about their experience here). One of their tasks was to build a robust system that should be able to handle any unexpected problems, Rambo style (yes, they actually called it their “Rambo Architecture”). Unexpected problems typically includes servers going down or processes getting killed.

In order to build this resilient system, Netflix created a service that had as its sole task to randomly attack and kill other services and processes. The service was called the Chaos Monkey. Since the Netflix servers was now under constant attack it forced them to build robust and resilient services that could cope with the unleashed monkey. To prove the worth of the Chaos Monkey, Jeff mentions that

AWS had a huge multi-day outage last week, which took several major websites down, along with a constellation of smaller sites.

Notably absent from that list of affected AWS sites? Netflix.

I guess the monkey did its job, eh?

How does it work?

I think that a good metaphor for the monkey is a vaccine. A vaccine is defined as

Any preparation used as a preventive inoculation to confer immunity against a specific disease, usually employing an innocuous form of the disease agent, as killed or weakened bacteria or viruses, to stimulate antibody production.

Well that kind of sounds the same as our monkey, doesn’t it? We introduce a disease into our system in order to prepare it for the real thing. The disease agent in our case is the monkey and the antibodies is our own code written to cope with unstable system. Our role as developers suddenly become the same as our own bodies immune system. We find and protect all the weak spots in our system and when we are faced with the real deal we are prepared. Neat.

My very own monkey

I’m currently working with a project where we, some time ago, involuntary faced our own monkey. Our system is connected with several services and different hardware, such as barcode scanners, printers and card readers. All of which has a tendency to go offline or jam when you least expect it. Especially the printer, a device which reliability has generally not improved since Windows 95, gave us problems in the beginning.

It would stop working when you least expected it and it would certainly not inform anyone that it was now useless. Since we couldn’t figure out the root cause right away we started to implement a robust system that would verify that the printer was operational at, and before, critical moments and then inform the user in a friendly way (instead of just crashing or refusing to print). When we finally found and fixed the root cause of the problem we were well prepared for failures that we could not control, such as paper jam.

If the printer wouldn’t have failed so frequently in the beginning we never would have spent the effort to inoculate our system against it. Now, since the printer disease is gone we have an immune system that can cope with any unsuspected printer failures.

Important to note is that we, compared to the Netflix team, didn’t implement our own chaos monkey, we got one without asking for it. When we wrote the code to make our system more resilient, if anyone would have asked us if we where glad for the faulty printer we would most definitively say no. But now we’re reaping the harvest from our hard work and it would not be possible without the help of our very own little chaos monkey.

The problem

Today in our project a colleague was cussing over the fact that he kept writing the same block of code over and over again when null checking a property with a backing field.

Given the class Foo:

private Foo oldFooProp;
public Foo OldFooProp
{
    get
    {
        if (oldFooProp == null)
        {
            oldFooProp = new Foo();
        }
        return oldFooProp;
    }
}

Have any of you written something like this before? It’s a bunch of lines of code that you tend to write (in small variations) over and over again. Sure you can compact it a little but it in the order of 5 – 10 lines of annoying repetitive code.

Some use the null coalescing operator (??) version that looks like this:

public Foo OldAlternativeFooProp
{
    get
    {
        return oldFooProp ?? (oldFooProp = new Foo());
    }
}

This version is a little easier to compact down to even a single line.

But we (my colleague and I) can do you one better:

Here is an optional approach

private Lazy<Foo> foo = new Lazy<Foo>();

public Foo Foo
{
    get
    {
        return foo;
    }
}

Actually I’d prefer to do that like this but then you have to know the solution below and be comfortable with it:

public readonly Lazy<Foo> Foo = new Lazy<Foo>();

But wait a minute: That doesn’t work you say, right? You can’t return a Lazy<Foo> as a Foo you have to write theFoo.Value.

The Trick

The secret trick is to inherit Lazy<T> and implement an implicit operator for T on it!

namespace Jayway.com.Sys
{
    /// <summary>
    /// A version of <see cref="Sys.Lazy{T}"/> with the twist of being implicitly castable to <typeparamref name="T"/>.
    /// </summary>
    /// <typeparam name="T">The type of lazy instance we are creating.</typeparam>
    public class Lazy<T> : System.Lazy<T>
    {

        // Ctors removed for brevity

        /// <summary>
        /// Cast the <see cref="Lazy{T}"/> to it's contained <typeparamref name="T"/>
        /// </summary>
        /// <param name="lazyT">The lazy to cast.</param>
        /// <returns>The instance of <see cref="Lazy{T}.Value"/></returns>
        public static implicit operator T(Lazy<T> lazyT)
        {
            return lazyT.Value;
        }
    }
}

Now you can implicitly cast a Lazy<T> to it’s contained type T.

A few alternative constructions for it might look like this:

public LazyTests()
{
    // With parameter
    theFoo = new Lazy<Foo>(() => new Foo("bar"));

    // With Inversion Of Control
    IServiceLocator serviceLocator = GetServiceLocator();
    theFoo = new Lazy<Foo>(() => serviceLocator.GetInstance());
}

I kind of like this code. It’s compact. It’s easy to read. It’s pretty!

Hope you like it too – HTH!

Cheers,

M.

Up front I want to show what I am aiming for so you can evaluate if this is a worth while read: Using the more advanced features of MEF suddenly I find I use these pretty gruesome variable and parameter declarations: Lazy<IWorkItem, IWorkItemView>. After applying the fix in this post I am left with the exact same behavior and this much improved declaration: IEnumerable<IWork>.

Background on MEF

Using MEF you can easily juggle the concept of lazily (using System.Lazy<T>) importing an open ended set of instances of a given contract. This is built into the library for you. It takes some getting used to the concept but it is quite powerful. As if this wasn’t enough you can also add metadata to the contracts (with the MEF version of Lazy<T> – System.Lazy<T, TMetadata>) to enable you to select which of the - potentially many - implementations of the contract that you want to lazily load into your app domain and instantiate. Does this all sound like geek speech? Well it sure is but as I said this is a very powerful concept. Given that you have a good requirement for this scenario you never have to code extensibility code yourself ever again. I would go so far as to say that MEF makes the extensibility scenario a solved problem!

My Scenario

Working with improving the Worker role concept in Windows AzureI I recently had a use for an open ended set of implementations of what I called “work methods”. I wound up making my work methods implementations of IWorkItem. The metadata I added to my work method classes I decorated with IWorkItemView metadata contract. This is what the two contracts look like:

public interface IWorkItem{
    bool HasWork { get; }
    void DoWork();
}
public interface IWorkItemView
{
    string Name { get; }
    int Order { get; }
}

When using these contracts lazily in MEF I get the ugly instances of Lazy<IWorkItem, IWorkItemView>. There is some really cool functionality here for sure but I just can’t bare the ugliness of the statement as I begin to pass these instances around in method calls etc. The cool thing with MEF is that I don’t know beforehand how many implementations I have. All I need to know is that I can get them all:

[ImportMany]
IEnumerable<Lazy<IWorkItem, IWorkItemView>> Work { get; set; }

This gives me a whole enumeration of lazy instances that are combined with the metadata of the metadata contract. On each instance of the lazy works you call .Metadata to access the IWorkItemView contract and .Value to instantiate and return the instance of the IWorkItem. Now I don’t know about you but this is beginning to look kind of hairy to me. After all in my code I am not really concerned with any laziness or metadata contracts. Not only that – provided you are a coder that believes in separation of concerns there is one more issue. To explain the last statement let’s go back to my Windows Azure scenario:

I import my many lazy instances with metadata into my code. Then I’d like to begin to use those instances. I wrote some code to filter out which instance I wanted to use. I wrote code to execute the selected instance. I wanted to separate these two code blocks from each other and I also wanted to be able to exchange filtering methods on the fly. I could continue but some of you have certainly begun to see the problem here. I was now passing around parameters of type Lazy<IWorkItem, IWorkItemView>. That’s not exactly pretty! What I found that I was conceptually doing was rather using an instance of something that had the combined contract of my two work-method, and work-metadata contracts:

public interface IWork : IWorkItem, IWorkItemView { }

Passing around parameters of type IWork is a lot better than Lazy<IWorkItem, IWorkItemView>. You have to all agree to that, right?

So now – finally – the issue becomes that of transforming one instance into the other. I also want to keep the Lazy capability. The transformation technique is mostly built into an abstract base class I’ve written which you can download here:

I have also put the code in the MEF Contrib project at Github.

Using the base class comes with a little bit of custom implementation per conversion you want to do from from “lazy with metadata” to “other domain object”. The alternative would have been for me to use a dynamic code generation approach for the implementation but I felt that dynamic code in this instance is a serious overkill. Besides we also need to make sure MEF picks up our implementation which in this case means we have to apply an attribute to our implementation.

The solution

To re-iterate: We had the ImportMany statement above which is a bit cumbersome. Instead we are aiming for this:

[Import]

IEnumerable<IWork> Work { get; set; }

Please notice the two different attributes ImportMany and Import. There is an important difference. The first one will find a lot of implementations of the contract (zero to many) while the latter will find only one exact match to the contract. In the first case we want MEF to find all IWorkItem implementations that are decorated with the IWorkItemView metadata. In the second case we want to find one single collection of IWork.

The trick is to collect all the instances (ImportManyAttribute) and hand them back out (ExportAttribute) as a single collection. What we do in the base class is import the many lazy with metadata instances and then immediately export a whole collection of the new contract to be picked up somewhere in the code as needed.

Details

public abstract class ValueMetadataCompactorBase<TValue, TMetadata, TValueMetadata> :
    IEnumerable<TValueMetadata>
    where TValueMetadata : TValue, TMetadata
{
    protected abstract TValueMetadata Compact(Lazy<TValue, TMetadata> lazyValueMetadata);

    [ImportMany(AllowRecomposition = true)]
    internal IEnumerable<Lazy<TValueMetadata>> ValueMetadatas { get; set; }

    [ImportMany(AllowRecomposition = true)]
    internal IEnumerable<Lazy<TValue, TMetadata>> ValuesWithMetadata { get; set; }

     // Cliped IEnumerable implementation for brevity [...]
}

There are a few things to notice here:

• We ImportMany instances of the Lazy<TValue, TMetadata> and also for good measure we ImportMany istances of Lazy<TValueMetadata>. The reason for the latter is that since we offer the contract IWork for any developer to pick up an implement we can’t be 100% certain some one doesn’t use it in a direct implementation. It is no crime to do so even though the intent is to implement IWorkItem and decorate it with the metadata IWorkItemView. The real reason for not implementing the IWork direct is because we can remain lazy with the metadata if it is real metadata. If we want to start looking at the members of an implementation that does not have metadata we need to load that implementations assembly into the AppDomain.
• The class implements IEnumerable<TValueMetadata>. This is used in the derived classes to Export the behavior and make the transformation accessible to our needy develoeprs. ;~)

To use this base class you have to do two things:

1) Implement the base class which constitutes implementing one method for compacting together a TValue and TMetadata into a TValueMetadata.

2) Apply the ExportAttribute with the parameter typeof(<your type>).

Let me show you my implementation of the compactor for compacting IWorkItems with IWorkItemView into instances of IWork:

[Export(typeof(IEnumerable<IWork>))]
internal class WorkCompactor : ValueMetadataCompactorBase<IWorkItem, IWorkItemView, IWork>
{
    protected override IWork Compact(Lazy<IWorkItem, IWorkItemView> lazyValueMetadata)
    {
        return new WorkWrapper(lazyValueMetadata);
    }

    private class WorkWrapper : IWork
    {
        private readonly Lazy<IWorkItem, IWorkItemView> lazyWorkWithMetadata;

        public WorkWrapper(Lazy<IWorkItem, IWorkItemView> lazyWorkWithMetadata)
        {
            this.lazyWorkWithMetadata = lazyWorkWithMetadata;
        }

        public bool HasWork
        {
            get { return lazyWorkWithMetadata.Value.HasWork; }
        }

        public void DoWork()
        {
            lazyWorkWithMetadata.Value.DoWork();
        }

        public int Order
        {
            get { return lazyWorkWithMetadata.Metadata.Order; }
        }

        public string Name
        {
            get { return lazyWorkWithMetadata.Metadata.Name; }
        }
    }
}

Notice:

• The annoyance here is that I have to custom implement a boring IWork wrapper ourselves since I am not using a dynamic code approach.
• The implementation of said IWork retains the lazy behavior in my implementation since I only forward calls to the members to the contained lazy instance.
• The [Export(typeof(IEnumerable<IWork>))] attribute on the implementation is that which makes my IEnumerable<IWork> available to the rest of my code through MEF.
• The implementation is marked as internal. MEF doesn’t care – it finds internal, protected and private implementations as well as public.. This means that user coders do not even know that this conversion exists. All the handling of lazy etc. is removed from the “subscribing” code.

Summary

Note to self: Write less epic blog posts. ;~)

I hope this post gives you some insight into how MEF works as well as a neat trick to simplify some of your MEF-Import code and lazy-metadata craziness. The functionality is very good to have but I really do not want library specific concerns to affect my code too much. Do you?

Cheers,

M. (the NoOpMan)

[someTextField performSelectorOnMainThread:@selector(setText:)
                              	withObject:@"A new text"
                             waitUntilDone:YES];

But not everything is an object

Since Objective-C is a superset of C, there are still all the types from C available. Such as all the primitives, including enums, and more complex struct types. Cocoa Touch is pragmatic and will use the most proper type for the use-case, not forcing everything into a square OOP hole.

This makes it quite hard to call for example -[UIView setHidden:], that takes a single BOOL argument. Same for -[UIView setFrame:], that takes a single CGRect struct argument, that in turn consists of one CGPoint and one CGSize struct.

Every type imaginable in C can be bundled in an NSValue instance. So we could bundle up the BOOL primitive, or the CGRect struct in a NSValue object. Then pass that object to the main thread, where it is unbundled and passed to the desired method. Quite cumbersome as it requires us to bundle, and unbundle types manually, and implement at least one extra method.

There must be an easier way

It turns out that NSInvocation can also handle any imaginable C type, or else it would not be able to invoke any imaginable Objective-C method. Making a NSInvocation invoke its method on the main thread is easy enough. Just add a category to the NSInvocation class, with a new method like this:

-(void)invokeOnMainThreadWaitUntilDone:(BOOL)wait;
{
  [self performSelectorOnMainThread:@selector(invoke)
                         withObject:nil
                      waitUntilDone:wait];
}

So now all you need to do is to create a NSInvocation object, fill it in with the primitive or struct types, and invoke it on the main thread. But creating and setting up a NSInvocation object is also a bit on the boring side...

There must be an even easier way!

We could use variable argument lists from plain old C. Too bad that they are untyped?
No despair, we know the target object for our invocation, and we know what method to call. So we have what we need to fetch the NSMethodSignature object for the call, that contains all the type information we need to safely process the va_list.

Our target machine is a Mac running 32- or 64-bit Intel CPU, or an iPhone OS device with a 32 bit ARM CPU. Turns out that on both platforms va_list is simply a void* pointer, to the stack frame. Even better va_start() will always flush any argument passed into the register on the stack frame. So we can skip most of the boring argument handling, by treating the arguments like a byte buffer, only advancing and aligning the buffer according to the information in the NSMethodSignature object.

A convenience method for creating a NSInvocation object for a particular target, selector, and list of variable arguments, would turn out like this:

+(NSInvocation*)invocationWithTarget:(id)target
                            selector:(SEL)aSelector
                     retainArguments:(BOOL)retainArguments, ...;
{
  va_list ap;
  va_start(ap, retainArguments);
  char* args = (char*)ap;
  NSMethodSignature* signature = [target methodSignatureForSelector:aSelector];
  NSInvocation* invocation = [NSInvocation invocationWithMethodSignature:signature];
  if (retainArguments) {
    [invocation retainArguments];
  }
  [invocation setTarget:target];
  [invocation setSelector:aSelector];
  for (int index = 2; index < [signature numberOfArguments]; index++) {
    const char *type = [signature getArgumentTypeAtIndex:index];
    NSUInteger size, align;
    NSGetSizeAndAlignment(type, &size, &align);
    NSUInteger mod = (NSUInteger)args % align;
    if (mod != 0) {
      args += (align - mod);
    }
    [invocation setArgument:args atIndex:index];
    args += size;
  }
  va_end(ap);
  return invocation;
}

Conclusion

And now we can easily call any method on the main UI thread.

An example where a CGRect struct is used to update the UI components frame;

// Set new frame of a label.
[[NSInvocation invocationWithTarget:someLabel
                           selector:@selector(setFrame:)
                    retainArguments:NO, CGRectMake(40, 40, 200, 100)]
 invokeOnMainThreadWaitUntilDone:NO];

A slightly more complex example, where we send a primitive int, and also waits for and fetches the result from the main thread:

// Query a UITableView for the number of rows in section 2.
NSInvocation* i = [NSInvocation invocationWithTarget:tableView
                                            selector:@selector(numberOfRowsInSection:)
                                     retainArguments:NO, (NSUInteger)2];
// Block this thread until method has been invoked and result is available.
[i invokeOnMainThreadWaitUntilDone:YES];
NSInteger numberOfRows;
[i getReturnValue:&numberOfRows];

Download full source code here: NSInvocation+CWVariableArguments.zip

Update: Example 2 was not 64-bit compatible as David Remahl pointed out to me. Added type cast to fix the error.

Update 2: A new version with some more features and small bug-fixes to BOOL, float and uint16_t types, plus proper unit tests can be downloaded here: CWFoundationAsyncAdditions.zip