It's really embarrassing hearing Apple fanbois talk like grade school males comparing whose daddy can beat whose daddy. You guys need to get a hold of yourselves and stop giving apple users a bad rap.
Thank you for reading my mind and pretty much posting what I was thinking point for point...
I think technology is on Google's site. Java is clearly better choice thanks to huge developer community, although Android does not use SWING or Java ME GUI framework. So there is something a developer has to learn. I have tried Google's SDK and it is incredibly easy to use for typical tasks. I personaly like the service-based architecture and permission system that does not have to rely on code signing to have applications under control.
If you don't like the icons or the home screen, remmember that is can be changed easily, just by creating an application that will tell Android "I'm capable of being homescreen". I'm sure iPhone-like home screens will come. Also remmeber that although Andoid is an open platform, every provider or developer can deviler it relatively closed with pre-selected set of applications.
I know that Apple is superior in usability, but technology is a great advantage for Google in a long-run and technology cannot be switched easily (sometimes sacrificing compatibility). However usability of Android apps will improve overtime time. Everything will depend on developers of applications on both sides.
Competition is always good, so let the fight begin. I'm joining Google's side this time.
I had similar thoughts, but the differentiator, I think, is that the iPhone is an iPod. Apple's done extremely well with the UI, and all the Android phones are going to look kind of similar and pedestrian. It will still be the iPhone users that have something special.
I do wish Apple had taken the iPhone opportunity to dump Objective-C and Cocoa and gone with a more modern API, and that's one area that Android will have a HUGE advantage over the iPhone in. You'll have droves of developers who have years of experience in the toolchains, languages, and systems involved.
you have that last part backwards - Cocoa Touch and Objective-C are the more modern API. That is a significant competitive advantage in Apple's favor, both for the mac and for the iPhone. And it certainly helps that you program both the same way - Cocoa and MacOS X.
The Cocoa Touch API's are actually quite easy to work with, and brilliantly helpful.
Apple did a lot of the groundwork here on a stable system and its written in a coding variety they know and love.
Its seems brilliant to me.
For example, with the tab bar interface and navigation controls at the top, I can program that entire interface (with exactly the same brilliant graphical look) in around 10 lines of code to set up for view controllers on it. That is pretty impressive. Its not much work to set up half the screen with a beautiful interface like that.
And the entire OS down to the OS X is designed for Cocoa APIs that work. Why change it?
I think technology is on Google's site. Java is clearly better choice thanks to huge developer community, although Android does not use SWING or Java ME GUI framework. So there is something a developer has to learn. I have tried Google's SDK and it is incredibly easy to use for typical tasks. I personaly like the service-based architecture and permission system that does not have to rely on code signing to have applications under control.
...
I know that Apple is superior in usability, but technology is a great advantage for Google in a long-run and technology cannot be switched easily (sometimes sacrificing compatibility). However usability of Android apps will improve overtime time. Everything will depend on developers of applications on both sides.
Competition is always good, so let the fight begin. I'm joining Google's side this time.
Ah, it brings tears of joy and sadness to my eyes. The naivety. You'll learn pragmatism and cynicism soon enough.
I think technology is on Google's site. Java is clearly better choice thanks to huge developer community, although Android does not use SWING or Java ME GUI framework. So there is something a developer has to learn. I have tried Google's SDK and it is incredibly easy to use for typical tasks. I personaly like the service-based architecture and permission system that does not have to rely on code signing to have applications under control.
If you don't like the icons or the home screen, remmember that is can be changed easily, just by creating an application that will tell Android "I'm capable of being homescreen". I'm sure iPhone-like home screens will come. Also remmeber that although Andoid is an open platform, every provider or developer can deviler it relatively closed with pre-selected set of applications.
I know that Apple is superior in usability, but technology is a great advantage for Google in a long-run and technology cannot be switched easily (sometimes sacrificing compatibility). However usability of Android apps will improve overtime time. Everything will depend on developers of applications on both sides.
Competition is always good, so let the fight begin. I'm joining Google's side this time.
The technology is clearly on Apple's side, if you think otherwise you must not know enough about cocoa and objective-c. And don't overlook the technology advantage of multi-touch. Unless I overlooked it, I didn't see a single example of multi-touch in the google videos.
Market share and market momentum is also on Apple's side in this "battle" - they will have their second generation of hardware and software on the market before the first generation products with google's technology ships. And don't overlook that they not only have the established market momentum of the iPhone, they also can leverage the established market momentum of iPod and iTunes.
And you've already admitted that usability is on Apple's side.
There are more than 3 billion cell phone subscription in the world. There is place for everyone and it is impossible for one phone or phone OS to control even half that market.
There are more than 3 billion cell phone subscription in the world. There is place for everyone and it is impossible for one phone or phone OS to control even half that market.
What a lot are failing to recognize is that no one is going to buy Android. What they will buy is Samsung N32893847 which happens to run Android.
So Apple is not competing with Google as much as it is competing with Samsung and LG and Nokia. Google gives these companies a leg up (if they choose to take advantage of it) compared to before, but there is definitely one more corporate layer of control after Google to muck things up.
Quite like PlayForSure and all the music player makers that adopted it. Only advantage Google has over PlayForSure is that Android is open to the developer community, which may or may not be enough...
There are more than 3 billion cell phone subscription in the world. There is place for everyone and it is impossible for one phone or phone OS to control even half that market.
Except Apple isn't offering a cell phone OS, they're offering a computer OS optimized for a very small form factor.
The whole "competing against established cell phone companies" completely misses the point and is remarkably short sighted, IMO. The real competition is for pocketable computers that have ubiquitous connectivity. "Cell phone" is an app.
In that arena, Apple is playing from a position of strength, because that arena hasn't really been defined yet and Apple has the tools to do the defining.
We'll see in about a week, but my guess is that the iPhone 2.0 will make it very clear that Apple has a great deal more in mind for this platform than how people are thinking about it.
As a mobile app developer, one thing that people are forgetting is the compatibility with the hardware. IOW imagine if you have an awesome touch app for android. How many phones could it be compatible with? How about the screen size or the hardware specs?
Imagine trying to get your app to consumers, only so they could find out that their phone is incomparable or that it is bloatware because you weren't able to fully optimize the app because you couldn't test it on 10+ different phones. What if the phone has a physical qwerty and a puny screen? What if the manufacturer makes a sloppy bloated UI that your app has to suffer.
That my friend is the advantage of the iphone OSX platform. That is where we will see solid functional apps.
Except Apple isn't offering a cell phone OS, they're offering a computer OS optimized for a very small form factor.
The whole "competing against established cell phone companies" completely misses the point and is remarkably short sighted, IMO. The real competition is for pocketable computers that have ubiquitous connectivity. "Cell phone" is an app.
In that arena, Apple is playing from a position of strength, because that arena hasn't really been defined yet and Apple has the tools to do the defining.
I have to strongly disagree with you. The "pocketable computers with ubiquitous connectivity" that you are describing are simply pda-cellphone combos that have been around for a while. Mobile Wi-Fi connectivity has been around for some time, browsers, contacts and maps on phones aren't new either, touchscreens and mp3 support also existed before the iPhone. Apple likes to make their stuff seem "revolutionary", "polish well known features, get the full potential and sell as new" is the main idea of their marketing and they're doing it really well, I'm not having trouble admitting that, but saying they invented a whole new market is too much.
Quote:
As a mobile app developer, one thing that people are forgetting is the compatibility with the hardware. IOW imagine if you have an awesome touch app for android. How many phones could it be compatible with? How about the screen size or the hardware specs?
Imagine trying to get your app to consumers, only so they could find out that their phone is incomparable or that it is bloatware because you weren't able to fully optimize the app because you couldn't test it on 10+ different phones. What if the phone has a physical qwerty and a puny screen? What if the manufacturer makes a sloppy bloated UI that your app has to suffer.
Oh lord, I wonder how anyone can make applications for PCs these days, since people have different processors/screens/graphics cards. They must be all bloated!
The technology is clearly on Apple's side, if you think otherwise you must not know enough about cocoa and objective-c. And don't overlook the technology advantage of multi-touch. Unless I overlooked it, I didn't see a single example of multi-touch in the google videos.
Market share and market momentum is also on Apple's side in this "battle" - they will have their second generation of hardware and software on the market before the first generation products with google's technology ships. And don't overlook that they not only have the established market momentum of the iPhone, they also can leverage the established market momentum of iPod and iTunes.
And you've already admitted that usability is on Apple's side.
I have taken technology more as "software technology", which is clearly on Googles side.
I must agree that I'm not very experienced with ObjC. I used to be C++ developer and now Java developer, I tried ObjC and I must that it has too much bad features similar to C++ and SmallTalk combined, which makes it harder to use on larger projects. Which may not be so critical for small applications however. But I agree that good API (which Cocoa definitely is) and GUI designer solve a lot of problems caused by using the old language.
Thanks to using secure language, Google does not have to rely on code-signing and smilar stuff. Also the architecture of Google android is designed from the ground to be extensible, allowing background services running, easy to use cross-application interaction etc. You also have a lot of APIs for speech-to-text, text-to-speech, video/audio capturing, GPS, compass, gestures, Google Maps etc. Not sure how many of these will offer Apple.
I agree and I said that indirectly - Apple has an advantage now. What I said is that Google has advantage in long-run. Thanks to JVM switching underlying technologies (OS, HW) is extremely easy and unnoticable for users and developers. Also ARM processors are very well optimized for Java byte-code making them much faster than x86 on the same frequency (like 5-10 times faster). I hope LLVM by Apple makes also a good job here.
Google Android now needs a good GUI designer (there are already some projects out there) and that's all. Java IDEs are superior to XCode, but a GUI designer is a must have (although XML GUI files are not hard to edit, it's not for everyone). Multitouch is a question of how well patented is it by Apple. However notice that multitouch is not used so much - but that will probably change in the iPhone's future. I personally think conductive touch detection is more important to compete with Apple as current touch screens are very unprecise.
Those videos look really good, but google has a few key problems:
(1) phone makers are wary about adopting these operating systems, if they do, consumers could loose brand loyalty, and switch whenever, confident that they could use any phone running that system. Makers like Nokia are wanting to make their system standard
You are quite correct, this is a huge worry for handset manufacturers. I imagine that handset manufacturers also worry that mobile providers might use Android on generic hardware from companies like Asus or FoxConn, and cut out handset manufacturers from the profit loop.
I know that if I were running a major mobile service I would consider hiring a small staff of coders to adapt Android to hardware purchased directly from China.
You are quite correct, this is a huge worry for handset manufacturers. I imagine that handset manufacturers also worry that mobile providers might use Android on generic hardware from companies like Asus or FoxConn, and cut out handset manufacturers from the profit loop.
I know that if I were running a major mobile service I would consider hiring a small staff of coders to adapt Android to hardware purchased directly from China.
On the other side, it could lead to pure SW companies delivering their own solutions without developing whole HW + OS + low level stuff. They could sell the whole device with their SW similar way to Apple with much reduced investment cost.
All in all Google Android is serious threat for Windows Mobile and traditional manufacturers such as Nokia, Motorola etc. I think iPhone will stand side-by-side with Android each having different approach and different customers. Both phones are built on solid desktop-class systems unlike the others and seem to have a lot of momentum - especially iPhone gaining customers that would have never thought of a smart phone.
"The accelerometer that largely governs just screen rotation in the iPhone can now be used in a new Street View mode that rotates the point of view simply by changing direction in the real world."
Having a hard time visualizing this? Someone care to take stab at explaining this? Sound like the technology that?s already in a GPS unit? too me anyway.
Thanks
A GPS unit doesn't know you turned around to face a different direction unless it has some kind of compass in it. With Just GPS, you have to start moving again before it calculates a new orientation.
I rather pay for OS X than get Linux for free. I feel about the iPhone the same as I feel about Macs and iPods: I rather have a product that has been developed from the ground up and in all aspects, including the hardware, by Apple - than a Frankenstein contraption such as a PC or some random phone with some random carrier with Android on it.
I have taken technology more as "software technology", which is clearly on Googles side.
I was also talking primarily about software technology, which is clearly on Apple's side. I've been a software developer for 27 years, with extensive experience in C++, Java, and Objective-C and STRONGLY prefer Objective-C.
Quote:
Originally Posted by wessan
I must agree that I'm not very experienced with ObjC. I used to be C++ developer and now Java developer, I tried ObjC and I must that it has too much bad features similar to C++ and SmallTalk combined, which makes it harder to use on larger projects. Which may not be so critical for small applications however. But I agree that good API (which Cocoa definitely is) and GUI designer solve a lot of problems caused by using the old language.
Having features of SmallTalk is a strength, not a weakness. It makes it easer, not harder, to use for large software projects. Or do you think things like iLife, iWork and iPhone are small projects. There are very good reasons Apple primarily uses Objective-C over languages like Java and C++ even though Cocoa is fully usable from within Java.
And Objective-C/Cocoa are processor independent technologies. It's fairly trivial to move from one architecture to another, which is how Apple moved from Motorolla to Intel. The hard work involved in doing that wasn't to move Cocoa to the new architecture, it was moving Carbon to the new architecture.
Quote:
Originally Posted by wessan
Thanks to using secure language, Google does not have to rely on code-signing and smilar stuff.
Neither does Cocoa. There is no code signing requirement on the Macintosh.
Quote:
Originally Posted by wessan
Also the architecture of Google android is designed from the ground to be extensible, allowing background services running, easy to use cross-application interaction etc. You also have a lot of APIs for speech-to-text, text-to-speech, video/audio capturing, GPS, compass, gestures, Google Maps etc. Not sure how many of these will offer Apple.
iPhone is designed from the ground up to be reliable - specifically to ensure reliable telephone operation. There are plenty of frameworks in Cocoa and more can be added at any time . It's trivial to add an API like compass, it's not so easy to reintegrate a core feature like multi-touch into an system not designed for it from the ground up. Remember, iPhone has all of the frameworks in the MacOS to draw on as hardware technology advances. Proven APIs that developers are already familiar with.
[QUOTE=wessan;1257931] Also ARM processors are very well optimized for Java byte-code making them much faster than x86 on the same frequency (like 5-10 times faster). I hope LLVM by Apple makes also a good job here.[/quote[
iPhone uses ARM, not Intel - easy because of Cocoa/Obj-C being processor independent technologies. They compile directly to the target processor, which will be faster than java byte-code. Which is why Google doesn't write their underlying code in Java, the use C and very likely the same GCC compiler that Apple uses.
Quote:
Originally Posted by wessan
Google Android now needs a good GUI designer (there are already some projects out there) and that's all. Java IDEs are superior to XCode, but a GUI designer is a must have (although XML GUI files are not hard to edit, it's not for everyone). Multitouch is a question of how well patented is it by Apple. However notice that multitouch is not used so much - but that will probably change in the iPhone's future. I personally think conductive touch detection is more important to compete with Apple as current touch screens are very unprecise.
This is the same problem Linux has - no unified UI, lots of groups developing their own, no clear winner, no clear penetration of Linux on the desktop. Linux is fine for servers where there are no real UI requirements.
And I've had no problems at all with the precision of multi-touch on the iPhone. I use it all of the time in Safari and wouldn't want to go back to google's way of zooming a web browser.
I was also talking primarily about software technology, which is clearly on Apple's side. I've been a software developer for 27 years, with extensive experience in C++, Java, and Objective-C and STRONGLY prefer Objective-C.
Sorry, I respect the experience. But from my point of view it proves nothing of real knowledge. Development is so rapid last 5 years that older experience is often useless. I have met many developers in my life and there was no direct relation between skills/abitilities and knowledge. And many older developers often stuck with principles they know for a long time and ignore some new features. For example waiting for features in ObjC 2.0 available in Java since the very beggining? No thanks. And waiting another 10 years for features Java has now? No thanks.
Quote:
Originally Posted by alandail
Having features of SmallTalk is a strength, not a weakness. It makes it easer, not harder, to use for large software projects. Or do you think things like iLife, iWork and iPhone are small projects. There are very good reasons Apple primarily uses Objective-C over languages like Java and C++ even though Cocoa is fully usable from within Java.
There are many much bigger projects than iWork and iLife distributed amongs thousands of servers. And these things are mostly writen in other languages than C-family/Smalltalk family. Apple has a lot of resources (financial) to have a lot of average developers writing in ObjC. Not everyone can afford this and needs more efficient way of developing SW.
Quote:
Originally Posted by alandail
And Objective-C/Cocoa are processor independent technologies. It's fairly trivial to move from one architecture to another, which is how Apple moved from Motorolla to Intel. The hard work involved in doing that wasn't to move Cocoa to the new architecture, it was moving Carbon to the new architecture.
Do you mean that no developer had to recompile their applications? Come on, having a package with copy of executable code for every platform is a good solution? You can compile almost any language for almost any processor, but would you like to have 5x times bigger apps having package for PowerPC, UltraSparc, Intel, Itanium, etc.?
Quote:
Originally Posted by alandail
Neither does Cocoa. There is no code signing requirement on the Macintosh.
No there is not. But how do you control access to resources in Mac OS X. Simply in the way that ou enable the application to run under root, or your account. In Java you can control fine grained access to resources preciselly for every application (or every single class if you really want to).
Quote:
Originally Posted by alandail
iPhone is designed from the ground up to be reliable - specifically to ensure reliable telephone operation. There are plenty of frameworks in Cocoa and more can be added at any time . It's trivial to add an API like compass, it's not so easy to reintegrate a core feature like multi-touch into an system not designed for it from the ground up. Remember, iPhone has all of the frameworks in the MacOS to draw on as hardware technology advances. Proven APIs that developers are already familiar with.
Yes. As it's trivial to add APIs for Google and the API has changed significantly from the first release. Adding multitouch API is as simple as adding any other API, it's just another pack of events invoked by GUI components that you can listen to, no big deal for any robust UI framework (I would see more limitation in HW, if Apple has really patented everything related to it). I guess Android has all frameworks Java has, some are better than Mac OS X, some are worse, but both are very powerful. Additionaly Google adds new frameworks for media (so much missing in Java), speech and similar.
Quote:
Originally Posted by alandail
iPhone uses ARM, not Intel - easy because of Cocoa/Obj-C being processor independent technologies. They compile directly to the target processor, which will be faster than java byte-code. Which is why Google doesn't write their underlying code in Java, the use C and very likely the same GCC compiler that Apple uses.
The underlying code is not in Java for one single reason - development cost. Developing OS in Java is not simple/fast/cheap, but some projects are comming (jnode.org). And developing all things that are not in Java again would mean first release of Android in 2010+. But you clearly do not know much about ARM and Java byte-code. ARM has optimization for many instructions and code-structures typical for Java and support for Java primitive types format. Unfortunatelly there is stil need to run non-Java code, so the processor has to be still quite complex. We have to see both side by side, I think iPhone will be performing better for some time as Android virtual machne is still very young, but that will change over time.
Quote:
Originally Posted by alandail
This is the same problem Linux has - no unified UI, lots of groups developing their own, no clear winner, no clear penetration of Linux on the desktop. Linux is fine for servers where there are no real UI requirements.
Yes, I agree totally. But there could be some companies creating their own packages that will not even hold name Google Android.
Quote:
Originally Posted by alandail
And I've had no problems at all with the precision of multi-touch on the iPhone. I use it all of the time in Safari and wouldn't want to go back to google's way of zooming a web browser.
Yes. I think and I have said that Apple has better screen. And I just said the most important is it's precision that is not typical for other devices. As I have said multitouch is not limitation of API, but limitation of HW and I hope we will see more multitouch screen technology in the competition.
Comments
It's really embarrassing hearing Apple fanbois talk like grade school males comparing whose daddy can beat whose daddy. You guys need to get a hold of yourselves and stop giving apple users a bad rap.
Thank you for reading my mind and pretty much posting what I was thinking point for point...
If you don't like the icons or the home screen, remmember that is can be changed easily, just by creating an application that will tell Android "I'm capable of being homescreen". I'm sure iPhone-like home screens will come. Also remmeber that although Andoid is an open platform, every provider or developer can deviler it relatively closed with pre-selected set of applications.
I know that Apple is superior in usability, but technology is a great advantage for Google in a long-run and technology cannot be switched easily (sometimes sacrificing compatibility). However usability of Android apps will improve overtime time. Everything will depend on developers of applications on both sides.
Competition is always good, so let the fight begin. I'm joining Google's side this time.
I had similar thoughts, but the differentiator, I think, is that the iPhone is an iPod. Apple's done extremely well with the UI, and all the Android phones are going to look kind of similar and pedestrian. It will still be the iPhone users that have something special.
I do wish Apple had taken the iPhone opportunity to dump Objective-C and Cocoa and gone with a more modern API, and that's one area that Android will have a HUGE advantage over the iPhone in. You'll have droves of developers who have years of experience in the toolchains, languages, and systems involved.
you have that last part backwards - Cocoa Touch and Objective-C are the more modern API. That is a significant competitive advantage in Apple's favor, both for the mac and for the iPhone. And it certainly helps that you program both the same way - Cocoa and MacOS X.
Apparently some 100,000 developers disagree.
It's over 200,000 now. 100,000 in the first week.
Apple did a lot of the groundwork here on a stable system and its written in a coding variety they know and love.
Its seems brilliant to me.
For example, with the tab bar interface and navigation controls at the top, I can program that entire interface (with exactly the same brilliant graphical look) in around 10 lines of code to set up for view controllers on it. That is pretty impressive. Its not much work to set up half the screen with a beautiful interface like that.
And the entire OS down to the OS X is designed for Cocoa APIs that work. Why change it?
I think technology is on Google's site. Java is clearly better choice thanks to huge developer community, although Android does not use SWING or Java ME GUI framework. So there is something a developer has to learn. I have tried Google's SDK and it is incredibly easy to use for typical tasks. I personaly like the service-based architecture and permission system that does not have to rely on code signing to have applications under control.
...
I know that Apple is superior in usability, but technology is a great advantage for Google in a long-run and technology cannot be switched easily (sometimes sacrificing compatibility). However usability of Android apps will improve overtime time. Everything will depend on developers of applications on both sides.
Competition is always good, so let the fight begin. I'm joining Google's side this time.
Ah, it brings tears of joy and sadness to my eyes. The naivety. You'll learn pragmatism and cynicism soon enough.
I think technology is on Google's site. Java is clearly better choice thanks to huge developer community, although Android does not use SWING or Java ME GUI framework. So there is something a developer has to learn. I have tried Google's SDK and it is incredibly easy to use for typical tasks. I personaly like the service-based architecture and permission system that does not have to rely on code signing to have applications under control.
If you don't like the icons or the home screen, remmember that is can be changed easily, just by creating an application that will tell Android "I'm capable of being homescreen". I'm sure iPhone-like home screens will come. Also remmeber that although Andoid is an open platform, every provider or developer can deviler it relatively closed with pre-selected set of applications.
I know that Apple is superior in usability, but technology is a great advantage for Google in a long-run and technology cannot be switched easily (sometimes sacrificing compatibility). However usability of Android apps will improve overtime time. Everything will depend on developers of applications on both sides.
Competition is always good, so let the fight begin. I'm joining Google's side this time.
The technology is clearly on Apple's side, if you think otherwise you must not know enough about cocoa and objective-c. And don't overlook the technology advantage of multi-touch. Unless I overlooked it, I didn't see a single example of multi-touch in the google videos.
Market share and market momentum is also on Apple's side in this "battle" - they will have their second generation of hardware and software on the market before the first generation products with google's technology ships. And don't overlook that they not only have the established market momentum of the iPhone, they also can leverage the established market momentum of iPod and iTunes.
And you've already admitted that usability is on Apple's side.
There are more than 3 billion cell phone subscription in the world. There is place for everyone and it is impossible for one phone or phone OS to control even half that market.
What a lot are failing to recognize is that no one is going to buy Android. What they will buy is Samsung N32893847 which happens to run Android.
So Apple is not competing with Google as much as it is competing with Samsung and LG and Nokia. Google gives these companies a leg up (if they choose to take advantage of it) compared to before, but there is definitely one more corporate layer of control after Google to muck things up.
Quite like PlayForSure and all the music player makers that adopted it. Only advantage Google has over PlayForSure is that Android is open to the developer community, which may or may not be enough...
There are more than 3 billion cell phone subscription in the world. There is place for everyone and it is impossible for one phone or phone OS to control even half that market.
Except Apple isn't offering a cell phone OS, they're offering a computer OS optimized for a very small form factor.
The whole "competing against established cell phone companies" completely misses the point and is remarkably short sighted, IMO. The real competition is for pocketable computers that have ubiquitous connectivity. "Cell phone" is an app.
In that arena, Apple is playing from a position of strength, because that arena hasn't really been defined yet and Apple has the tools to do the defining.
We'll see in about a week, but my guess is that the iPhone 2.0 will make it very clear that Apple has a great deal more in mind for this platform than how people are thinking about it.
Imagine trying to get your app to consumers, only so they could find out that their phone is incomparable or that it is bloatware because you weren't able to fully optimize the app because you couldn't test it on 10+ different phones. What if the phone has a physical qwerty and a puny screen? What if the manufacturer makes a sloppy bloated UI that your app has to suffer.
That my friend is the advantage of the iphone OSX platform. That is where we will see solid functional apps.
Except Apple isn't offering a cell phone OS, they're offering a computer OS optimized for a very small form factor.
The whole "competing against established cell phone companies" completely misses the point and is remarkably short sighted, IMO. The real competition is for pocketable computers that have ubiquitous connectivity. "Cell phone" is an app.
In that arena, Apple is playing from a position of strength, because that arena hasn't really been defined yet and Apple has the tools to do the defining.
I have to strongly disagree with you. The "pocketable computers with ubiquitous connectivity" that you are describing are simply pda-cellphone combos that have been around for a while. Mobile Wi-Fi connectivity has been around for some time, browsers, contacts and maps on phones aren't new either, touchscreens and mp3 support also existed before the iPhone. Apple likes to make their stuff seem "revolutionary", "polish well known features, get the full potential and sell as new" is the main idea of their marketing and they're doing it really well, I'm not having trouble admitting that, but saying they invented a whole new market is too much.
As a mobile app developer, one thing that people are forgetting is the compatibility with the hardware. IOW imagine if you have an awesome touch app for android. How many phones could it be compatible with? How about the screen size or the hardware specs?
Imagine trying to get your app to consumers, only so they could find out that their phone is incomparable or that it is bloatware because you weren't able to fully optimize the app because you couldn't test it on 10+ different phones. What if the phone has a physical qwerty and a puny screen? What if the manufacturer makes a sloppy bloated UI that your app has to suffer.
Oh lord, I wonder how anyone can make applications for PCs these days, since people have different processors/screens/graphics cards. They must be all bloated!
The technology is clearly on Apple's side, if you think otherwise you must not know enough about cocoa and objective-c. And don't overlook the technology advantage of multi-touch. Unless I overlooked it, I didn't see a single example of multi-touch in the google videos.
Market share and market momentum is also on Apple's side in this "battle" - they will have their second generation of hardware and software on the market before the first generation products with google's technology ships. And don't overlook that they not only have the established market momentum of the iPhone, they also can leverage the established market momentum of iPod and iTunes.
And you've already admitted that usability is on Apple's side.
I have taken technology more as "software technology", which is clearly on Googles side.
I must agree that I'm not very experienced with ObjC. I used to be C++ developer and now Java developer, I tried ObjC and I must that it has too much bad features similar to C++ and SmallTalk combined, which makes it harder to use on larger projects. Which may not be so critical for small applications however. But I agree that good API (which Cocoa definitely is) and GUI designer solve a lot of problems caused by using the old language.
Thanks to using secure language, Google does not have to rely on code-signing and smilar stuff. Also the architecture of Google android is designed from the ground to be extensible, allowing background services running, easy to use cross-application interaction etc. You also have a lot of APIs for speech-to-text, text-to-speech, video/audio capturing, GPS, compass, gestures, Google Maps etc. Not sure how many of these will offer Apple.
I agree and I said that indirectly - Apple has an advantage now. What I said is that Google has advantage in long-run. Thanks to JVM switching underlying technologies (OS, HW) is extremely easy and unnoticable for users and developers. Also ARM processors are very well optimized for Java byte-code making them much faster than x86 on the same frequency (like 5-10 times faster). I hope LLVM by Apple makes also a good job here.
Google Android now needs a good GUI designer (there are already some projects out there) and that's all. Java IDEs are superior to XCode, but a GUI designer is a must have (although XML GUI files are not hard to edit, it's not for everyone). Multitouch is a question of how well patented is it by Apple. However notice that multitouch is not used so much - but that will probably change in the iPhone's future. I personally think conductive touch detection is more important to compete with Apple as current touch screens are very unprecise.
Those videos look really good, but google has a few key problems:
(1) phone makers are wary about adopting these operating systems, if they do, consumers could loose brand loyalty, and switch whenever, confident that they could use any phone running that system. Makers like Nokia are wanting to make their system standard
You are quite correct, this is a huge worry for handset manufacturers. I imagine that handset manufacturers also worry that mobile providers might use Android on generic hardware from companies like Asus or FoxConn, and cut out handset manufacturers from the profit loop.
I know that if I were running a major mobile service I would consider hiring a small staff of coders to adapt Android to hardware purchased directly from China.
You are quite correct, this is a huge worry for handset manufacturers. I imagine that handset manufacturers also worry that mobile providers might use Android on generic hardware from companies like Asus or FoxConn, and cut out handset manufacturers from the profit loop.
I know that if I were running a major mobile service I would consider hiring a small staff of coders to adapt Android to hardware purchased directly from China.
On the other side, it could lead to pure SW companies delivering their own solutions without developing whole HW + OS + low level stuff. They could sell the whole device with their SW similar way to Apple with much reduced investment cost.
All in all Google Android is serious threat for Windows Mobile and traditional manufacturers such as Nokia, Motorola etc. I think iPhone will stand side-by-side with Android each having different approach and different customers. Both phones are built on solid desktop-class systems unlike the others and seem to have a lot of momentum - especially iPhone gaining customers that would have never thought of a smart phone.
"The accelerometer that largely governs just screen rotation in the iPhone can now be used in a new Street View mode that rotates the point of view simply by changing direction in the real world."
Having a hard time visualizing this? Someone care to take stab at explaining this? Sound like the technology that?s already in a GPS unit? too me anyway.
Thanks
A GPS unit doesn't know you turned around to face a different direction unless it has some kind of compass in it. With Just GPS, you have to start moving again before it calculates a new orientation.
I have taken technology more as "software technology", which is clearly on Googles side.
I was also talking primarily about software technology, which is clearly on Apple's side. I've been a software developer for 27 years, with extensive experience in C++, Java, and Objective-C and STRONGLY prefer Objective-C.
I must agree that I'm not very experienced with ObjC. I used to be C++ developer and now Java developer, I tried ObjC and I must that it has too much bad features similar to C++ and SmallTalk combined, which makes it harder to use on larger projects. Which may not be so critical for small applications however. But I agree that good API (which Cocoa definitely is) and GUI designer solve a lot of problems caused by using the old language.
Having features of SmallTalk is a strength, not a weakness. It makes it easer, not harder, to use for large software projects. Or do you think things like iLife, iWork and iPhone are small projects. There are very good reasons Apple primarily uses Objective-C over languages like Java and C++ even though Cocoa is fully usable from within Java.
And Objective-C/Cocoa are processor independent technologies. It's fairly trivial to move from one architecture to another, which is how Apple moved from Motorolla to Intel. The hard work involved in doing that wasn't to move Cocoa to the new architecture, it was moving Carbon to the new architecture.
Thanks to using secure language, Google does not have to rely on code-signing and smilar stuff.
Neither does Cocoa. There is no code signing requirement on the Macintosh.
Also the architecture of Google android is designed from the ground to be extensible, allowing background services running, easy to use cross-application interaction etc. You also have a lot of APIs for speech-to-text, text-to-speech, video/audio capturing, GPS, compass, gestures, Google Maps etc. Not sure how many of these will offer Apple.
iPhone is designed from the ground up to be reliable - specifically to ensure reliable telephone operation. There are plenty of frameworks in Cocoa and more can be added at any time . It's trivial to add an API like compass, it's not so easy to reintegrate a core feature like multi-touch into an system not designed for it from the ground up. Remember, iPhone has all of the frameworks in the MacOS to draw on as hardware technology advances. Proven APIs that developers are already familiar with.
[QUOTE=wessan;1257931] Also ARM processors are very well optimized for Java byte-code making them much faster than x86 on the same frequency (like 5-10 times faster). I hope LLVM by Apple makes also a good job here.[/quote[
iPhone uses ARM, not Intel - easy because of Cocoa/Obj-C being processor independent technologies. They compile directly to the target processor, which will be faster than java byte-code. Which is why Google doesn't write their underlying code in Java, the use C and very likely the same GCC compiler that Apple uses.
Google Android now needs a good GUI designer (there are already some projects out there) and that's all. Java IDEs are superior to XCode, but a GUI designer is a must have (although XML GUI files are not hard to edit, it's not for everyone). Multitouch is a question of how well patented is it by Apple. However notice that multitouch is not used so much - but that will probably change in the iPhone's future. I personally think conductive touch detection is more important to compete with Apple as current touch screens are very unprecise.
This is the same problem Linux has - no unified UI, lots of groups developing their own, no clear winner, no clear penetration of Linux on the desktop. Linux is fine for servers where there are no real UI requirements.
And I've had no problems at all with the precision of multi-touch on the iPhone. I use it all of the time in Safari and wouldn't want to go back to google's way of zooming a web browser.
I was also talking primarily about software technology, which is clearly on Apple's side. I've been a software developer for 27 years, with extensive experience in C++, Java, and Objective-C and STRONGLY prefer Objective-C.
Sorry, I respect the experience. But from my point of view it proves nothing of real knowledge. Development is so rapid last 5 years that older experience is often useless. I have met many developers in my life and there was no direct relation between skills/abitilities and knowledge. And many older developers often stuck with principles they know for a long time and ignore some new features. For example waiting for features in ObjC 2.0 available in Java since the very beggining? No thanks. And waiting another 10 years for features Java has now? No thanks.
Having features of SmallTalk is a strength, not a weakness. It makes it easer, not harder, to use for large software projects. Or do you think things like iLife, iWork and iPhone are small projects. There are very good reasons Apple primarily uses Objective-C over languages like Java and C++ even though Cocoa is fully usable from within Java.
There are many much bigger projects than iWork and iLife distributed amongs thousands of servers. And these things are mostly writen in other languages than C-family/Smalltalk family. Apple has a lot of resources (financial) to have a lot of average developers writing in ObjC. Not everyone can afford this and needs more efficient way of developing SW.
And Objective-C/Cocoa are processor independent technologies. It's fairly trivial to move from one architecture to another, which is how Apple moved from Motorolla to Intel. The hard work involved in doing that wasn't to move Cocoa to the new architecture, it was moving Carbon to the new architecture.
Do you mean that no developer had to recompile their applications? Come on, having a package with copy of executable code for every platform is a good solution? You can compile almost any language for almost any processor, but would you like to have 5x times bigger apps having package for PowerPC, UltraSparc, Intel, Itanium, etc.?
Neither does Cocoa. There is no code signing requirement on the Macintosh.
No there is not. But how do you control access to resources in Mac OS X. Simply in the way that ou enable the application to run under root, or your account. In Java you can control fine grained access to resources preciselly for every application (or every single class if you really want to).
iPhone is designed from the ground up to be reliable - specifically to ensure reliable telephone operation. There are plenty of frameworks in Cocoa and more can be added at any time . It's trivial to add an API like compass, it's not so easy to reintegrate a core feature like multi-touch into an system not designed for it from the ground up. Remember, iPhone has all of the frameworks in the MacOS to draw on as hardware technology advances. Proven APIs that developers are already familiar with.
Yes. As it's trivial to add APIs for Google and the API has changed significantly from the first release. Adding multitouch API is as simple as adding any other API, it's just another pack of events invoked by GUI components that you can listen to, no big deal for any robust UI framework (I would see more limitation in HW, if Apple has really patented everything related to it). I guess Android has all frameworks Java has, some are better than Mac OS X, some are worse, but both are very powerful. Additionaly Google adds new frameworks for media (so much missing in Java), speech and similar.
iPhone uses ARM, not Intel - easy because of Cocoa/Obj-C being processor independent technologies. They compile directly to the target processor, which will be faster than java byte-code. Which is why Google doesn't write their underlying code in Java, the use C and very likely the same GCC compiler that Apple uses.
The underlying code is not in Java for one single reason - development cost. Developing OS in Java is not simple/fast/cheap, but some projects are comming (jnode.org). And developing all things that are not in Java again would mean first release of Android in 2010+. But you clearly do not know much about ARM and Java byte-code. ARM has optimization for many instructions and code-structures typical for Java and support for Java primitive types format. Unfortunatelly there is stil need to run non-Java code, so the processor has to be still quite complex. We have to see both side by side, I think iPhone will be performing better for some time as Android virtual machne is still very young, but that will change over time.
This is the same problem Linux has - no unified UI, lots of groups developing their own, no clear winner, no clear penetration of Linux on the desktop. Linux is fine for servers where there are no real UI requirements.
Yes, I agree totally. But there could be some companies creating their own packages that will not even hold name Google Android.
And I've had no problems at all with the precision of multi-touch on the iPhone. I use it all of the time in Safari and wouldn't want to go back to google's way of zooming a web browser.
Yes. I think and I have said that Apple has better screen. And I just said the most important is it's precision that is not typical for other devices. As I have said multitouch is not limitation of API, but limitation of HW and I hope we will see more multitouch screen technology in the competition.