Slashdot Mirror
Analyzing Apple's iPhone Strategy
Galen Gruman submitted infoworld's summary of Apple's grand strategy for the iPhone. He points out that the real important part of the new iPhone is the software, not the hardware. He talks about the new SDK stuff, the ad-hoc app distribution, and other stuff. It's a reasonable read if you have been ignoring the iPhone and want to know what the hype is about over this release, but doesn't break any new ground if you've been paying attention.
However, even the ad hoc license is not the wide-open solution that the open source community ultimately desires. An iPhone user should be able to opt into installing and running unsigned applications, a capability offered by all competing mobile platforms. This is the showstopper for me. A smartphone without a real freeware ecosystem will never truly thrive, for the same reasons that that open source development and commercial s/w development drive each other on standard platforms.
Obj-C is often considered what C++ would have been, if C++ were done right. However, for a right while only NeXT really used it. GNUStep, which was trying to copy NeXT Step, started supporting it as well.
When Jobs came back to Apple (he also formed NeXT), Apple acquired NeXT and all their technology. This is when OS X was born and why it uses Obj-C.
So, basically only MacOS X and GNUStep really use Obj-C in any significant way (at least that I'm aware of).
The syntax is a little weird, and the targeted platforms are somewhat limited, so not many people know it or bother to learn (unless they want to develop for Mac or GNUStep).
Its a turn off because people like familiar things and would rather use C++ or Java rather than Obj-C, I suppose -- and Obj-C is sort of the barrier to entry to Cocoa and Carbon.
And many have said that about C vs Assembler. The difference is that you'd have to add a zero or so to the end of the price of the app. Java's substantially easier to write apps for, in certain domains, in certain sizes of applications.
C doesn't have features which make it reasonable to write very large applications (namespaces come to mind). You can do it (e.g. Unix kernels, etc), but you have to be much more disciplined without those features. That discipline costs in terms of additional expertise required, (higher programmer salaries) and project management (more overhead for managers, documentation, etc).
Also, Java has features which make writing tools for it substantially easier than C. Better available tools also reduce the cost of software production.
For the most part, Java sacrifices starting performance for long-term performance. Letting a Java app 'warm up' for a while will show substantially better performance than when it first started running.
Care about electronic freedom? Consider donating to the EFF!
Hmm - I have to assume you've not used ObjC much or at all - you have to take it with its class library (Cocoa), similar to Java, but it's ridiculously easy to use once you've spent a week or so learning it. Literally, it took me a week to be proficient in this "new" language.
Applications don't need namespaces - frameworks do, but applications should be perfectly happy being run in their own (default) namespace. I think most people will be writing applications on the iPhone, not frameworks.
As for tools, XCode comes with data-modelling tools to create entity relationship diagrams/models that integrate with your code, it comes with fantastic dtrace-driven graphical performance monitoring tools, and an excellent integrated gdb-based debugger which does things like fix-and-continue, step back, etc.
Just putting some context into place,
Simon
Physicists get Hadrons!
Yes, you can write generic programs in Obj-C. What are you doing to do with it without the library framework, though?
If you want to actually **DO** anything with it, then you need GNUStep or Cocoa. Sort of like, you can write C programs on any system with libc and the header files available, but without all the fancy extras, like gtk or whatever, you're severely limited in what you can do without having to start from scratch.
I don't program in Obj-C. I don't use Mac. I don't want to do either of those things. Its not FUD as much as an explanation.
If you want to program Mac apps, you pretty much have to use it (or java) from what I can tell. If you want to use it without GNUStep or Cocoa, then you need bindings for your toolkits, same as anything else.
Just because you *CAN* do something, doesn't mean people really do. Yes, there are Obj-C bindings for GTK. I don't know how many people use them, but I would venture to guess its not that many. GNUStep software is written in Obj-C, same as Cocoa-using OS X software is.
That is the point I am trying to make. And I don't "prentend" to use bsd.
dick.
"While Linux likewise has the fanatical user base... they just have no way of monetizing it. Linux users like being locked into that platform, but not enough to actually pay for anything. They are happy to use hardware two generations out of date, happy with being completely locked into FOSS (since extremely few companies will write for Linux), etc, but not happy enough to actually spend any money supporting what they supposedly believe in. Look at Red Hat- they've been doing poorly for years now, and that's not going to change (although their dropping the failed "Linux on the Desktop" project will undoubtedly help them a great deal).
:)
While Apple has been gaining market share (up to 4-5%)... Linux's has remained flat for the past ten years (always around 0.65%, even as the size of the market has virtually exploded). Meaning... every Apple sold is coming from Linux's share of the market (either actual or potential). Which is good, since Linux has no chance of succeeding in competition with Microsoft, while Apple can do quite well with a tiny market share."
Sigh. You're wrong on so many points that I don't know where to start. The Linux vendors in the server OS and application space have been making money hand over fist for that same ten years, you know.
We just needed to see the desktop environment catch up, that's all. We needed the OS itself to get responsive enough in the face of no vendor support (and sometimes downright hostile responses to queries about drivers), we needed the applications to get good enough, and we needed some market force to get people to look at Linux as a desktop appliance. That'll settle the lack of vendor support all by itself.
We've seen the OS get very responsive indeed, to the point that running some games under wine are actually faster than running them in Windows XP on the same hardware. Applications are out there to meet the basic needs of most consumers, while other options are becoming at least tolerable. Driver problems are largely resolved with only a few holdouts refusing to either release binary drivers (not ideal) or provide any help at all to the people writing FOSS drivers.
Finally, the fact is that your information about marketshare is a bit out of date. Every Website tracking company that publishes its global stats, from Hitslink to W3 Counter to Xiti to TheCounter, all show that Linux began increasing its market share a while back. Depending on how far back a given site lets you see, you can argue that it started in early 2006. Certainly, every tracking site that goes back to December 2006 shows that when Vista was released, Linux began growing. That's market force number one.
The second is the release of the eee. All of a sudden, the hardware vendors realized that they could make a pot full of money selling a device without having to include Microsoft Windows or OS/X and people would buy it. Not just buy it, stand in line all night to get one!
Micrsoft's response? A warmed over, extremely limited version of Windows XP Home with a drop dead date that's only 2 years out, and even then they want the hardware restricted. It has the hardware vendors so unimpressed that they seem to be flat out ignoring it.
Asus stated that they expected to sell 40% of their eee line as Linux. Asus has also decided to include a small Linux distribution in the BIOS of every motherboard that they manufacture.
MSI figures 50% of the Winds that they sell will be Linux. Acer has publicly stated that they're moving their entire laptop line over to Linux. Dell is still adding desktops and laptops to the pool of preinstalled Linux boxes (including the mini-Inspiron). HP is offering the Mini-Note with Linux side by side with the Vista versions.
2008/2009 is the start of Linux moving into the mainstream. It's going to be fun to see how far it gets!
You don't necessarily need Mac OS X or GNUstep to use Obj-C in any significant way.
Debian Etch (and many other distros) has both the gcc-objc compiler and libFoundation libraries in the stable repository. I use them all the time to write GUI-less server applications. The Foundation library (the non-GUI toolkit for Objective C) makes it trivially easy (much like Java) to write a little piece of multi-threaded code that sits around waiting for input on a socket - WITHOUT all the overhead of launching yet another JVM instance.
http://en.wikipedia.org/wiki/T-Mobile#United_States
https://support.t-mobile.com/knowbase/root/public/tm22037.htm T-Mobile's domestic roaming partners all operate on the GSM 1900 band.
Okay, ready to learn Objective-C? Class names normally begin with capital letters and instances of classes begin with lowercase, just like Java.
/* of @interface */
/* private variables go here */
You call a procedure from an object with the syntax [object function:argument], similar to lisp. If there are multiple arguments, it looks like [object function:argument arg2Name:argument2 arg3Name:argument3].
You declare classes as follows:
@interface :
{
float aFloat;
NSString *string;
}
- (NSString * ) string;
- (void) setString:(NSString *)newString;
- (NSString *) theFloat;
- (void) setFloat:(float)value;
+ (NSArray *) someArray;
@end
Obj-C objects are always pointers. Methods (functions) that begin with a '-' are instance methods; they would be called by an instance of the object (i.e. [instance method]. Those beginning with a '+' are class methods; they are called with [Class method].
Use #import instead of #include. #import always checks to make sure it doesn't include a file twice, so you don't need to bother with #ifndef's.
Here's an implementation file
@implementation
{
}
- (id) init
{
if (self=[super init])
{
string = [[NSString alloc] initWithString:@"This is a string.";
}
returm self;
}
- (void) setString:(NSString *)newString
{
string=newString;
}
- (void) setFloat:(float)value
{
aFloat=value;
}
- (NSString *) string
{
return string;
}
- (float) theFloat
{
return aFloat;
}
+ (NSArray *) someArray
{
return [[NSArray alloc] initWithObjects:
}
You can see that, as in Java, variables are in-scope within member functions.
The method alloc is implemented in the ObjC base class, NSObject, and allocates memory for the instance. It will always be followed up with an init method of some kind.
The keyword 'id' is a macro for any instance of NSObject or any of its subclasses.
The variable 'self' refers to the current object. The variable 'super' refers to the current object, interpreted as it it were its parent class. Since every object but NSObject begins with self=[super init], only NSObject needs to know precisely how the Objective-C runtime is implemented.
Not shown here is how flags are handled, which is usually of the form [object shouldDoSomething], which then returns YES or NO. To set behavior, it's [object shouldDoSomething:YES].
In Objective-C, NSStrings are denoted like C strings, but with an @ before the open quote marks: @"This is an NSString." [object description] will return an NSString that tells you something about object, usually for classes within the core frameworks it is a text representation of the data.
The null pointer as an object is called nil. nil, or indeed any object, will accept any method call and fail silently, so make sure you properly alloc and init your objects, and double-check that they actually respond to the methods you send them.
Write to the console with NSLog(NSString*).
There. Now you know Objective-C. How the fuck hard was that?
NB: I wrote this off the top of my head, and it's been a while, so there are probably a ton of bugs in it. But, you get the idea.