Which proves my point. It's incredibly bloated and doesn't do much as an OS.
The underlying OS kernel and high-level application management rules are completely different things. Given that it takes very little code check if the app should to continue running in the background or terminate, I don't see how this results in an "incredibly bloated" operating system. And, unlike the NT kernel, the XNU kernel can be run on both mobile devices and the desktop.
That makes no sense. If it's pre-emptively multitasking (which, I know, it is), then they can do it right now but they don't. They may enable it in the future, but only because they know that Apple fanboys will swoon immediately and spend another eleventy gazillion dollars to upgrade. It won't have anything to do with the CPU. It will be a marketing move.
First, pre-emptive multitasking means the kernel preempts a task (removes it as the active thread) rather than have the task relinquishing execution on it's own. This improves performance and makes the system more responsive and stable, as the kernel decides when to switch between threads based on priorities.
However, if you only have one core, you can't actually run more than one thread concurrently. You must preempt all threads but one and serialize their execution, which merely gives the illusion of actually doing more than one thing at once. However, If you have more than one core, you can actually run two threads concurrently, as long as the OS supports it at the kernel and runtime level. Given that the iPhone OS is based on the same XNU kernel as Mac OS X on the desktop, it's likely no changes to existing iPhone apps would be needed to support true concurrent multi-threading on multi-core hardware.
Furthermore, you wouldn't need to run more than one app at the same time to greatly benefit from true concurrent execution. Even a single app, along with the OS itself, can spin off IO, networking, etc. to multiple threads - which could concurrently run on multiple cores. Add Apple's applications running in the background and the advantage would be even greater.
The same can be said for C as long as you follow the well defined malloc / free conventions. But we still have apps with memory leaks. Not to mention the far worse memory mangement bug known as the buffer overflow.
Objective-C uses retain counts to make managing memory significantly easier. For example:
Code:
- (void)addImageView:(id) self
{
UIImageView *imageView = [[[UIImageView alloc] initWithImage: [UIImage imageNamed:@"myimage.png"]] autorelease];
[self.view addSubview: imageView];
}
The retain count of the allocated object imageView will automatically be decremented at the end of the method call. And since the source UIImage was created with a class method, it is returned autoreleased as well. I don't have to remember to release or dealloc either of them. However, since the parent view retain the view when added to the view hierarchy, neither will be freed until they are removed from the parent view. I don't need to worry about when this will occur beyond knowing this convention. In addition, I could manually decrement the retain count for the image view by calling [imageView release] and omit the call to autorelase, if finer grained control was desired.
Objective-C is not a RAD language.
While it's true that Objective-C alone does not a RAD development environment make, when combined with Obj-C 2.0 properties, the Cocoa framework and, optionally, Interface Builder, development time can be significantly faster than C and comparable to Java. You can even add delegate Action methods for UI events in Interface Builder if you like.
A simple, yet functional, web browser can be built without writing any code at all. Everything can be wired up with Interface Builder.
www youtube com/watch?v=3MCkSoAPS5o
Wow, that code snipit was so intuitive.
What your not seeing is code you'd have to write to get the functionality received "for free" with Core Animation. This includes implicitly setting up the animation to run asynchronously on a separate thread in the background. It's also illustrates the ability to create multiple animations which can run in the one or more transactions and can span multiple views or layers. You can even redefine an animation while it's in progress or even start to independently animate a different set of properties on the same UI object, without worrying about coalescing active threads, re-interpolationg new timing and start values based on the current animation progress, etc. Core Animation handles all of the details for you behind the scenes.
