Same paradigm : .NET and Cocoa

When people say, “Windows copied Mac”, they talk only about how they look, or their GUI. However, from the early days of Mac and Windows, I have said, “It is not about GUI. The more and obvious proof that MS copied Apple’s is their API.”

Why did the first Windows have many function call style in pascal type rather than C native? Why similar API functions had almost identical list of parameters and orders? If they designed those APIs for themselves, most of those APIs would have MS’s own pattern although there are possibility that some of them can be similar.

Even nowadays, I noticed such thing. The .NET methods and their patterns are very similar to Cocoa.

One of the weakest part of the Cocoa is that thread methods/functions can’t change GUI widgets like moving knobs of a slider, updating progress indicator in its context. It should ask a main thread to do so by calling “performSelectorOnMainThread” or something like that. ( The name of the method is very clear about what it does and in what context it performs. )

With Win32/MFC, MS platform didn’t have this restriction. Sure, those widgets or controls should be protected with locks. However, you can access and update widgets/controls from a thread other than a main thread.
However, this is changed in .NET. Although it is still possible to do so in unmanaged context, but in managed context, you need to ask underlying system to call an access method for the caller’s sake.

Example is :

private void SetText(string text)
{
    // InvokeRequired required compares the thread ID of the
    // calling thread to the thread ID of the creating thread.
    // If these threads are different, it returns true.

    if (this.textBox1.InvokeRequired)
    {
        SetTextCallback d = new SetTextCallback(SetText);  // 1. This "SetText" is this method itself
        this.Invoke(d, new object[] { text });    // 2. "this" is a WinForm form that contains "textBox1"
    }
    else
    {
        this.textBox1.Text = text;
    }
}

Why did MS change their mechanism similar to that of Cocoa? ( which is restricted. )
Also, it is not as clear as that of Cocoa.
The SetText() above is called inside of a thread. So, when “invokeRequired” is reached, it is still called from a thread, and when its “Invoke” ( actually its form’s Invoke, not the thread’s ) rather than the textBox1’s Invoke is called, it visit the same SetText again ( that is why there is no parameter to set “on which object the Invoke() is called” ), but this time, it is called in main thread’s context. So, the “else” part is called.

This shows the difference of elegance between Apple style and MS style.
Apple people implement things thinking “how to use it”, “What design is better.”, while MS people just implement without or minimally thinking about those.

What is even worse is, “why don’t MS people enhance Apple’s weak implementation?”. Just like Columbus’ egg, when you think an original idea, it takes time and your energy to squeeze the idea from your brain. So, for the first implementer, what is more important is that they did it, not how well they did it. However, in the case of MS, they borrowed that idea. Then they should have more time to think about how to enhance it. But they didn’t.
Probably this way of changing UI widgets are better approach and more systematic approach, but at least, style-wise they could enhance it. But they are uglier than Apple’s.

So, if you write in Cocoa, it is just one shot call. That is, you create methods which interact with GUI widgets on main thread, and in other threads, call performSelectorOnMainThread to let the main thread to call the method to modify GUI widget.

On the other hand, In .NET, it is like to implement your own performSelectorOnMainThread and that is visited twice.
Here,developers writing in Cocoa can get relaxed thinking that their favorite framework is not worse than .NET and rejoice because its simpler architecture.

Objective-C/Cocoa programmers can now justify the somewhat restricted architecture of interaction between threads and GUI widgets. :)

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: