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.
Obj-C has features Java doesn't have and likely will never have. And why do you assume it's been 5 years since I used other technologies. I've used all 3 extensively, you admittedly have little to no experience with ObjC/Cocoa.
Quote:
Originally Posted by wessan
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.
Apple uses ObjC because it is efficient to write software, including very large projects like iPhone, which was also on my list. They don't blindly throw resources at problems, they use the most efficient ways to get things done. Again, they could program cocoa in Java - they have built the tools to do just that - it just isn't as efficient as doing it in ObjC.
Quote:
Originally Posted by wessan
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.?
not 5x bigger - you only get one set of the application resources, and installers can certainly strip out the extra binaries. And it's no extra work on the part of developers beyond checking a checkbox.
Quote:
Originally Posted by wessan
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.
Adding a core UI feature like multi-touch is in no way as easy as adding something like compass. Compass is a standalone feature, multi-touch is a core feature that impacts other frameworks and application code.
Quote:
Originally Posted by wessan
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.
Apple doesn't have this strange dual development restriction as their development costs are lower just using ObjC. By developing with ObjC their first release was 2007, 2nd generation in a week. See the difference? Apple writes their frameworks and their apps with the same languages and tools they ask their developers to use to create their own frameworks and apps.
Quote:
Originally Posted by wessan
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.
better screen, better UI, first to market, 2nd generation in a week,
one more thing - you are contradicting yourself about Java.
You hype the advantage that you can easily move code to another architecture but then turn around and talk about the extra complexity in the ARM architecture to make Java run faster. If Java needs this extra complexity to run efficiently, how will it be easy to move Android to another general purpose architecture. Won't you lose some of the performance gains that a pure ObjC design will automatically gain in such a move?
one more thing - you are contradicting yourself about Java.
You hype the advantage that you can easily move code to another architecture but then turn around and talk about the extra complexity in the ARM architecture to make Java run faster. If Java needs this extra complexity to run efficiently, how will it be easy to move Android to another general purpose architecture. Won't you lose some of the performance gains that a pure ObjC design will automatically gain in such a move?
I'm sorry. Maybe I haven't wrote it clearly. The complexity in CPU is necessary to run Linux C-based kernel, not Java code. Java byte-code has very limited instruction set, thus limiting amount of instructions needed in processor. You also have no need for out-of-order execution, branch-prediction, dependency-detection etc. as these operations can be performed once in compile time and optimized for each particular processor (as compilation in Java occurs just before the code is used).
If you would like to move Android on different processor, all you need is to recompile non-Java code and write new byte-code-to-native compiler for particular processor. But all Java applications won't require any modification/recompilation and that is the point. The performance of Java heavily depends on processor architecture. Simple processor being optimized for Java can be more powerful than complex/powerful processor that has for example incompatible floating-point numbers format. For example Itanium would be great procesor for Java at is strongly relies on Just-In-Time compilation, however Sun decided not to support it, probably due to their own UltraSPARC.
Java evolves rapidly last years and the current Sun's JVMs in "server" mode are amazingly fast due to very complex optimization for each processor. These are however unusable on current mobile devices as the compilation time is relatively long to improve performance in runtime. As I said Android's VM will be probably slower than ObjC on iPhone right now. It's relatively young and I guess complex optimization mechanisms were not primary goal of Google's development.
So the point of this feature is that it allows me to wave my phone around certain retail areas I might be in so I can see advertising in an HUD overlay? Anything else? Because that falls well short of my definition of "brilliant."
I think it's demo ware-- looks very cool, really not very useful.
I agree, but but I think a mapping program sometimes needs to show what the building/house looks like somehow, it looks like they may be getting there.
It looks like it might even be doing that, showing you what it would look like if you were there. The compass input is the unnecessary part here, except to make sure you're walking in the right direction.
How about we stop fighting and get back on topic???
It really isn't important which coding is better, I don't see, as each company has seen this is the way they want to work, so they know its going to work.
The real question in my mind is not so much about coding, but about what the two are capable of.
The iPhone is not just a phone and a PDA, but a very well organised media player/iPod. The integration of everything into one is the key selling point as it does everything well, and it comes out looking good to boot.
Do you think that google can fight that element?
Also, I see the difficulty being that each time Android is put on a new phone, they have to customize it and set the drivers up, etc, something Apple is already planning ahead for, and they won't exactly be releasing a swath of handsets with the exact same OS on it.
I see Apple as having both the media element, the integration element, the visual element, a simple handset family (when they start releasing different versions and generations) and so overall they have an advantage, be it big or perhaps not so big.
So the point of this feature is that it allows me to wave my phone around certain retail areas I might be in so I can see advertising in an HUD overlay? Anything else? Because that falls well short of my definition of "brilliant."
I think it's demo ware-- looks very cool, really not very useful.
The most brilliant technological advances are ones whose potential is not yet foreseen. There are many examples among Apple, right from the start. (though Tesla is my favorite example to use, but I'm sure this forum knows plenty about him and Apple so I'll spare the examples).
I can't really think of any reasons how a compass-like device in a cell phone would be a benefit but I do look at this demo and see something that appears to be a new way of using technology.
How about we stop fighting and get back on topic???
It really isn't important which coding is better, I don't see, as each company has seen this is the way they want to work, so they know its going to work.
The real question in my mind is not so much about coding, but about what the two are capable of.
The iPhone is not just a phone and a PDA, but a very well organised media player/iPod. The integration of everything into one is the key selling point as it does everything well, and it comes out looking good to boot.
Do you think that google can fight that element?
Also, I see the difficulty being that each time Android is put on a new phone, they have to customize it and set the drivers up, etc, something Apple is already planning ahead for, and they won't exactly be releasing a swath of handsets with the exact same OS on it.
I see Apple as having both the media element, the integration element, the visual element, a simple handset family (when they start releasing different versions and generations) and so overall they have an advantage, be it big or perhaps not so big.
Google won't be delivering devices directly as it says. It may change the strategy in the future. But I believe that what Google wants is just to enable everyone to use its services on the go. I believe that there will be companies delivering custom packages with pre-selected customized applications. Android is totally open to this. The main thing is to provide developers with low level stuff. I think some Google Andoid-based devices won't even declare they have anything to do with Google Android.
Apple is great in designing interfaces, but there could be young dynamic companies doing great interfaces as well and Google Android could enable them to deliver devices with their applications. They might not be able to nvest into development of HW+OS+JVM+Media+Text-to-speech, but might be able to provide great well-integrated applications.
The most brilliant technological advances are ones whose potential is not yet foreseen. There are many examples among Apple, right from the start. (though Tesla is my favorite example to use, but I'm sure this forum knows plenty about him and Apple so I'll spare the examples).
I can't really think of any reasons how a compass-like device in a cell phone would be a benefit but I do look at this demo and see something that appears to be a new way of using technology.
I'm sorry. Maybe I haven't wrote it clearly. The complexity in CPU is necessary to run Linux C-based kernel, not Java code. Java byte-code has very limited instruction set, thus limiting amount of instructions needed in processor. You also have no need for out-of-order execution, branch-prediction, dependency-detection etc. as these operations can be performed once in compile time and optimized for each particular processor (as compilation in Java occurs just before the code is used).
I fail to see where the advantage is, then, since iPhone is a Unix based (MACH based) OS and also runs on ARM processors currently.
Apple is great in designing interfaces, but there could be young dynamic companies doing great interfaces as well and Google Android could enable them to deliver devices with their applications.
There is no reason that Apple can't use aspects of Android for it's own gain, like it used FreeBSD and other open source software. There is also the option for Google or anyone else to create mobile OS X apps that interact with Google's services. Ones that are easily DLed from Apple's upcoming App Store.
That is the beauty of Android. People will use Apple's UI as a template and Apple will use the creative efforts of Android developers to further its platform. Apple will still have a more closed and tighter integrated product and Android will be free and open. We all win here.
The most brilliant technological advances are ones whose potential is not yet foreseen. There are many examples among Apple, right from the start. (though Tesla is my favorite example to use, but I'm sure this forum knows plenty about him and Apple so I'll spare the examples).
I can't really think of any reasons how a compass-like device in a cell phone would be a benefit but I do look at this demo and see something that appears to be a new way of using technology.
True enough, and you may be right. I just question if there is a huge advantage in delivering localized data via a HUD that overlays an image of what you're looking at, and one that delivers data by just being in the vicinity of what you're looking at, which presumably you are (in the vicinity of what you're looking at).
At any rate, since this kind of stuff will almost certainly be advertising driven, I'm not hugely interested in having retail operations yammering at my personal device at any level. If there is a cool, useful application for this tech that we haven't thought of, I'll happily stand corrected.
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.
Running desktop OSes?
Quote:
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.
Yes, of course, connectivity has been around, my point is that "pocket computer" plus "ubiquitous connectivity" equal "new category of device." Listing apps that have been available on small devices before this, again, misses the point. What's important is what a tiny computer that you have on you at all times and which is always connected makes possible.
Does the existence of cell phones with apps make UMPCs late to the party? What can a UMPC do that my cell phone can't do? A lot? Oh, you mean "can run apps" isn't the only distinguishing criteria of a mobile device?
Quote:
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.
A handheld device that runs OS X is in a different category of device than a cell phone that has some apps on it. It's more closely resembles a UMPC with a highly optimized UI. Apple isn't the only one in this space, but talking about the unassailable might of incumbent cell phone companies is the wrong conversation.
It doesn't anything to do with making claims for being revolutionary, it's just a fact.
Quote:
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!
I wonder how anyone could make apps for PCs if you had to write to a platform that might or might not have a mouse, a trackpad, a full keyboard, processor and memory resources that can support basic UI conventions or a display capable of showing them.
If there is a cool, useful application for this tech that we haven't thought of, I'll happily stand corrected.
I really don't know, none of my ideas below are well thought out. It is just an experiment to think outside the box a little and use this tech outside of the demo we saw. If anyone has anything better, please feel free to post; they can't be worse than mine.
Theme parks can use this for more interactive mapping of their parks where a expensive physical signs or park maps can't compete. I suppose this could be true for large wildlife parks.
A scavenger hunt game where you have a large buy in (say $500 for the app but with a buy out that includes the a percentage of the revenue generated) and then you have a nationwide search using the app to find clues which include using this tech to find items that are otherwise hidden from view. For instance, if you follow the clues correctly to the approximate location you can then use this feature to find the next clue as it will present itself within the map's street view.
Interactive video game that uses actual turns to maneuver.
Government use so that the user can quickly compare any changes that have occurred to an area since the last image mapping.
In conjunction with Google Maps Street View, to stand in front of buildings to get detailed information of the building's history, contact info, what company rent offices and their info and links to corporate websites and numbers without going in to check. Perhaps this could be used to see landmarks too.
GPS location mapping of information info to log data which is then uploaded to server. Then you can use this mapping on the dig site or over water. Of course, these are usually done on a flat surface, but it could include virtual flags sticking out of the ground so you can easily turn to see where these flags are in relation to your location. You can then access specific info that would otherwise have to be memorize
Large warehouse where you can easily turn toward a container and then in one touch see all the info without have to do a manual lookup by the cargo number.
with GPS, a compass and an accelerometer, you can potentially have your camera know what you took a picture of and where. i.e. if you are in disneyworld in front of the castle, are you taking a photo of the castle or of main street usa.
Tell me, what's that special thing about the iPhone that makes you immediately notice it's not "just running phone apps" but a "full desktop os" instead? Because I think a comparable device like the Nokia N95 that, by your definition, "just runs apps", is pretty much equal in functionality. I fail to notice the lack of DesktopOSness. Again -- I'm not saying it's the same, Apple made an AWESOME interface, I own the iPod Touch and am very happy with it. It's fun and easy to use, I just don't see how it provides this new level of functionality you are mentioning.
Quote:
Does the existence of cell phones with apps make UMPCs late to the party? What can a UMPC do that my cell phone can't do? A lot? Oh, you mean "can run apps" isn't the only distinguishing criteria of a mobile device?
Well, that's a whole different thing. The biggest thing about UMPCs is that they are simply bigger. They have bigger screens, better battery life and more storage capacity. Although even the lamest mobile phone nowadays can play videos, you wouldn't want watch a full movie on it. Or edit spreadsheets / text documents. Well, there you go, you can do that on a UMPC. I really think size is the most important thing defining different "types" of computers. Ultraportable laptops, desktop replacment laptops, desktop machines and powerful workstations are all different computers because they offer different size and performance.
The iPhone didn't create a new type of computers, because devices of similar size and performance existed and were fairly popular before it arrived.
Quote:
I wonder how anyone could make apps for PCs if you had to write to a platform that might or might not have a mouse, a trackpad, a full keyboard, processor and memory resources that can support basic UI conventions or a display capable of showing them.
I think you're slightly exaggerating with this. Many PC apps can run on very different PCs, I've seen firefox work decently on a 333 MHz computer with 64 MB of RAM and an 800x600 monitor. My current machine is 10-20x faster, has 30x as much ram and a 5x bigger screen (pretty average machine nowadays). Firefox still provides me with similar functionality.
As far as other things that have to do with interface are concerned - a mobile developer usually knows the device he's developing for will have either a normal keypad or touch controls (let's leave QUERTY out, I honestly haven't seen apps developed specifically for it). Other than that the main differences are CPU speed and resolution. They know what the lowest config is (I doubt there will be RAZR-like Android devices, most will be PDA sized, iPhone/N95 style), so they just code for that and make sure it scales well. Of course, this will never be as good as making an app for the iPhone, where you strictly know how much RAM/CPU/display you have available, but it also IMHO won't be as bad as you try to make it sound.
Anyway, another thing crossed my mind. We might both be right (as right as one can be on the internet :>) about the iPhone opening a new part of market. I remember reading a bunch of newsreports that said Apple is scoring big on the high class smartphone part of market in the USA, which is what you might be referring to.
It's quite different here in the EU though. I don't want to make this sound as an insult, but the mobile market is much more developed (for example we've had full 3G coverage nearly everywhere for quite some time) and advanced PDA/mobile combos have also been popular for pretty long. When the iPhone came out, there was a lot of criticism about the lack of modern features most people already expected from their phones.
So this could be just us looking at the same thing from very different points of view.
The competition will be good for the industry. I personally prefer the Blackberry simplicity but would enjoy the Android OS on it.
The one thing the iPhone has done for the industry is to up the bar for mobile web browsing. The Blackberry severely lacks in that area. A full fledged browser would be welcomed.
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.
It's really embarrassing listening to someone resort to petty name calling to make him/herself feel intellectually superior.
To call someone a "fanboi" would suggest you do not have the ability to take part in reasoned discussion, resorting to petty and childish name calling instead.
You also seem to be suffering from what phychologists call 'Freudian Projection' by projecting your own "grade school" behavior on to others.
I find the frequency of the deliberately belittling term "fanboi" on this site mildly annoying, last I knew this was a mac forum, not a playground. And to replace the 'y' with an 'i', how old are you boy?
Some technologies are better or worse than others, not everything is created equal, and humans like to talk about the merits of one system over another. It should come as no surprise that there is a preponderance of mac 'supporters' on this site.
Also, I see the difficulty being that each time Android is put on a new phone, they have to customize it and set the drivers up, etc.
I consider this to be one of the main weaknesses of the Android platform. Every cell phone manufacturer who uses hardware on which Android hasn't been ported yet is going to have to either:
a) Come up with their own implementation of the Android platform
b) Lobby Google to support their platform
If the hardware is obscure enough (or the manufacturer is too small), then option b is out of the question.
For people who remember the early days of the JVM on Linux (before Sun took over maintaining it), the implementation tended to lag behind the official releases and not behave the same as it did on other platforms (though I give the Blackdown folks full credit for their effort at the time). I'm envisioning a similar situation for Android on cellular platforms which aren't officially supported.
Write once, debug everywhere was the motto back in those early Java days.
I consider this to be one of the main weaknesses of the Android platform. Every cell phone manufacturer who uses hardware on which Android hasn't been ported yet is going to have to either:
a) Come up with their own implementation of the Android platform
b) Lobby Google to support their platform
If the hardware is obscure enough (or the manufacturer is too small), then option b is out of the question.
Manufacturers already have to write drivers for the firmware they use. If Android becomes popular then drivers for the same chips can be used with no alteration and there will be a very large developer community available to write these drivers at a much lower cost because of the widespread use of the platform and significant competition among coders in a open SDK.
They could even reduce their in-house coders for many aspects of the software as they can simply buy many drivers from a 3rd party who has already done the leg work.
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.
Comments
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.
Obj-C has features Java doesn't have and likely will never have. And why do you assume it's been 5 years since I used other technologies. I've used all 3 extensively, you admittedly have little to no experience with ObjC/Cocoa.
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.
Apple uses ObjC because it is efficient to write software, including very large projects like iPhone, which was also on my list. They don't blindly throw resources at problems, they use the most efficient ways to get things done. Again, they could program cocoa in Java - they have built the tools to do just that - it just isn't as efficient as doing it in ObjC.
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.?
not 5x bigger - you only get one set of the application resources, and installers can certainly strip out the extra binaries. And it's no extra work on the part of developers beyond checking a checkbox.
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.
Adding a core UI feature like multi-touch is in no way as easy as adding something like compass. Compass is a standalone feature, multi-touch is a core feature that impacts other frameworks and application code.
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.
Apple doesn't have this strange dual development restriction as their development costs are lower just using ObjC. By developing with ObjC their first release was 2007, 2nd generation in a week. See the difference? Apple writes their frameworks and their apps with the same languages and tools they ask their developers to use to create their own frameworks and apps.
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.
better screen, better UI, first to market, 2nd generation in a week,
You hype the advantage that you can easily move code to another architecture but then turn around and talk about the extra complexity in the ARM architecture to make Java run faster. If Java needs this extra complexity to run efficiently, how will it be easy to move Android to another general purpose architecture. Won't you lose some of the performance gains that a pure ObjC design will automatically gain in such a move?
one more thing - you are contradicting yourself about Java.
You hype the advantage that you can easily move code to another architecture but then turn around and talk about the extra complexity in the ARM architecture to make Java run faster. If Java needs this extra complexity to run efficiently, how will it be easy to move Android to another general purpose architecture. Won't you lose some of the performance gains that a pure ObjC design will automatically gain in such a move?
I'm sorry. Maybe I haven't wrote it clearly. The complexity in CPU is necessary to run Linux C-based kernel, not Java code. Java byte-code has very limited instruction set, thus limiting amount of instructions needed in processor. You also have no need for out-of-order execution, branch-prediction, dependency-detection etc. as these operations can be performed once in compile time and optimized for each particular processor (as compilation in Java occurs just before the code is used).
If you would like to move Android on different processor, all you need is to recompile non-Java code and write new byte-code-to-native compiler for particular processor. But all Java applications won't require any modification/recompilation and that is the point. The performance of Java heavily depends on processor architecture. Simple processor being optimized for Java can be more powerful than complex/powerful processor that has for example incompatible floating-point numbers format. For example Itanium would be great procesor for Java at is strongly relies on Just-In-Time compilation, however Sun decided not to support it, probably due to their own UltraSPARC.
Java evolves rapidly last years and the current Sun's JVMs in "server" mode are amazingly fast due to very complex optimization for each processor. These are however unusable on current mobile devices as the compilation time is relatively long to improve performance in runtime. As I said Android's VM will be probably slower than ObjC on iPhone right now. It's relatively young and I guess complex optimization mechanisms were not primary goal of Google's development.
So the point of this feature is that it allows me to wave my phone around certain retail areas I might be in so I can see advertising in an HUD overlay? Anything else? Because that falls well short of my definition of "brilliant."
I think it's demo ware-- looks very cool, really not very useful.
I agree, but but I think a mapping program sometimes needs to show what the building/house looks like somehow, it looks like they may be getting there.
It looks like it might even be doing that, showing you what it would look like if you were there. The compass input is the unnecessary part here, except to make sure you're walking in the right direction.
It really isn't important which coding is better, I don't see, as each company has seen this is the way they want to work, so they know its going to work.
The real question in my mind is not so much about coding, but about what the two are capable of.
The iPhone is not just a phone and a PDA, but a very well organised media player/iPod. The integration of everything into one is the key selling point as it does everything well, and it comes out looking good to boot.
Do you think that google can fight that element?
Also, I see the difficulty being that each time Android is put on a new phone, they have to customize it and set the drivers up, etc, something Apple is already planning ahead for, and they won't exactly be releasing a swath of handsets with the exact same OS on it.
I see Apple as having both the media element, the integration element, the visual element, a simple handset family (when they start releasing different versions and generations) and so overall they have an advantage, be it big or perhaps not so big.
So the point of this feature is that it allows me to wave my phone around certain retail areas I might be in so I can see advertising in an HUD overlay? Anything else? Because that falls well short of my definition of "brilliant."
I think it's demo ware-- looks very cool, really not very useful.
The most brilliant technological advances are ones whose potential is not yet foreseen. There are many examples among Apple, right from the start. (though Tesla is my favorite example to use, but I'm sure this forum knows plenty about him and Apple so I'll spare the examples).
I can't really think of any reasons how a compass-like device in a cell phone would be a benefit but I do look at this demo and see something that appears to be a new way of using technology.
How about we stop fighting and get back on topic???
It really isn't important which coding is better, I don't see, as each company has seen this is the way they want to work, so they know its going to work.
The real question in my mind is not so much about coding, but about what the two are capable of.
The iPhone is not just a phone and a PDA, but a very well organised media player/iPod. The integration of everything into one is the key selling point as it does everything well, and it comes out looking good to boot.
Do you think that google can fight that element?
Also, I see the difficulty being that each time Android is put on a new phone, they have to customize it and set the drivers up, etc, something Apple is already planning ahead for, and they won't exactly be releasing a swath of handsets with the exact same OS on it.
I see Apple as having both the media element, the integration element, the visual element, a simple handset family (when they start releasing different versions and generations) and so overall they have an advantage, be it big or perhaps not so big.
Google won't be delivering devices directly as it says. It may change the strategy in the future. But I believe that what Google wants is just to enable everyone to use its services on the go. I believe that there will be companies delivering custom packages with pre-selected customized applications. Android is totally open to this. The main thing is to provide developers with low level stuff. I think some Google Andoid-based devices won't even declare they have anything to do with Google Android.
Apple is great in designing interfaces, but there could be young dynamic companies doing great interfaces as well and Google Android could enable them to deliver devices with their applications. They might not be able to nvest into development of HW+OS+JVM+Media+Text-to-speech, but might be able to provide great well-integrated applications.
The most brilliant technological advances are ones whose potential is not yet foreseen. There are many examples among Apple, right from the start. (though Tesla is my favorite example to use, but I'm sure this forum knows plenty about him and Apple so I'll spare the examples).
I can't really think of any reasons how a compass-like device in a cell phone would be a benefit but I do look at this demo and see something that appears to be a new way of using technology.
I would love to have compass for geo-caching
I'm sorry. Maybe I haven't wrote it clearly. The complexity in CPU is necessary to run Linux C-based kernel, not Java code. Java byte-code has very limited instruction set, thus limiting amount of instructions needed in processor. You also have no need for out-of-order execution, branch-prediction, dependency-detection etc. as these operations can be performed once in compile time and optimized for each particular processor (as compilation in Java occurs just before the code is used).
I fail to see where the advantage is, then, since iPhone is a Unix based (MACH based) OS and also runs on ARM processors currently.
Apple is great in designing interfaces, but there could be young dynamic companies doing great interfaces as well and Google Android could enable them to deliver devices with their applications.
There is no reason that Apple can't use aspects of Android for it's own gain, like it used FreeBSD and other open source software. There is also the option for Google or anyone else to create mobile OS X apps that interact with Google's services. Ones that are easily DLed from Apple's upcoming App Store.
That is the beauty of Android. People will use Apple's UI as a template and Apple will use the creative efforts of Android developers to further its platform. Apple will still have a more closed and tighter integrated product and Android will be free and open. We all win here.
The most brilliant technological advances are ones whose potential is not yet foreseen. There are many examples among Apple, right from the start. (though Tesla is my favorite example to use, but I'm sure this forum knows plenty about him and Apple so I'll spare the examples).
I can't really think of any reasons how a compass-like device in a cell phone would be a benefit but I do look at this demo and see something that appears to be a new way of using technology.
True enough, and you may be right. I just question if there is a huge advantage in delivering localized data via a HUD that overlays an image of what you're looking at, and one that delivers data by just being in the vicinity of what you're looking at, which presumably you are (in the vicinity of what you're looking at).
At any rate, since this kind of stuff will almost certainly be advertising driven, I'm not hugely interested in having retail operations yammering at my personal device at any level. If there is a cool, useful application for this tech that we haven't thought of, I'll happily stand corrected.
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.
Running desktop OSes?
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.
Yes, of course, connectivity has been around, my point is that "pocket computer" plus "ubiquitous connectivity" equal "new category of device." Listing apps that have been available on small devices before this, again, misses the point. What's important is what a tiny computer that you have on you at all times and which is always connected makes possible.
Does the existence of cell phones with apps make UMPCs late to the party? What can a UMPC do that my cell phone can't do? A lot? Oh, you mean "can run apps" isn't the only distinguishing criteria of a mobile device?
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.
A handheld device that runs OS X is in a different category of device than a cell phone that has some apps on it. It's more closely resembles a UMPC with a highly optimized UI. Apple isn't the only one in this space, but talking about the unassailable might of incumbent cell phone companies is the wrong conversation.
It doesn't anything to do with making claims for being revolutionary, it's just a fact.
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!
I wonder how anyone could make apps for PCs if you had to write to a platform that might or might not have a mouse, a trackpad, a full keyboard, processor and memory resources that can support basic UI conventions or a display capable of showing them.
If there is a cool, useful application for this tech that we haven't thought of, I'll happily stand corrected.
I really don't know, none of my ideas below are well thought out. It is just an experiment to think outside the box a little and use this tech outside of the demo we saw. If anyone has anything better, please feel free to post; they can't be worse than mine.
Running desktop OSes?
Tell me, what's that special thing about the iPhone that makes you immediately notice it's not "just running phone apps" but a "full desktop os" instead? Because I think a comparable device like the Nokia N95 that, by your definition, "just runs apps", is pretty much equal in functionality. I fail to notice the lack of DesktopOSness. Again -- I'm not saying it's the same, Apple made an AWESOME interface, I own the iPod Touch and am very happy with it. It's fun and easy to use, I just don't see how it provides this new level of functionality you are mentioning.
Does the existence of cell phones with apps make UMPCs late to the party? What can a UMPC do that my cell phone can't do? A lot? Oh, you mean "can run apps" isn't the only distinguishing criteria of a mobile device?
Well, that's a whole different thing. The biggest thing about UMPCs is that they are simply bigger. They have bigger screens, better battery life and more storage capacity. Although even the lamest mobile phone nowadays can play videos, you wouldn't want watch a full movie on it. Or edit spreadsheets / text documents. Well, there you go, you can do that on a UMPC. I really think size is the most important thing defining different "types" of computers. Ultraportable laptops, desktop replacment laptops, desktop machines and powerful workstations are all different computers because they offer different size and performance.
The iPhone didn't create a new type of computers, because devices of similar size and performance existed and were fairly popular before it arrived.
I wonder how anyone could make apps for PCs if you had to write to a platform that might or might not have a mouse, a trackpad, a full keyboard, processor and memory resources that can support basic UI conventions or a display capable of showing them.
I think you're slightly exaggerating with this. Many PC apps can run on very different PCs, I've seen firefox work decently on a 333 MHz computer with 64 MB of RAM and an 800x600 monitor. My current machine is 10-20x faster, has 30x as much ram and a 5x bigger screen (pretty average machine nowadays). Firefox still provides me with similar functionality.
As far as other things that have to do with interface are concerned - a mobile developer usually knows the device he's developing for will have either a normal keypad or touch controls (let's leave QUERTY out, I honestly haven't seen apps developed specifically for it). Other than that the main differences are CPU speed and resolution. They know what the lowest config is (I doubt there will be RAZR-like Android devices, most will be PDA sized, iPhone/N95 style), so they just code for that and make sure it scales well. Of course, this will never be as good as making an app for the iPhone, where you strictly know how much RAM/CPU/display you have available, but it also IMHO won't be as bad as you try to make it sound.
Anyway, another thing crossed my mind. We might both be right (as right as one can be on the internet :>) about the iPhone opening a new part of market. I remember reading a bunch of newsreports that said Apple is scoring big on the high class smartphone part of market in the USA, which is what you might be referring to.
It's quite different here in the EU though. I don't want to make this sound as an insult, but the mobile market is much more developed (for example we've had full 3G coverage nearly everywhere for quite some time) and advanced PDA/mobile combos have also been popular for pretty long. When the iPhone came out, there was a lot of criticism about the lack of modern features most people already expected from their phones.
So this could be just us looking at the same thing from very different points of view.
The one thing the iPhone has done for the industry is to up the bar for mobile web browsing. The Blackberry severely lacks in that area. A full fledged browser would be welcomed.
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.
It's really embarrassing listening to someone resort to petty name calling to make him/herself feel intellectually superior.
To call someone a "fanboi" would suggest you do not have the ability to take part in reasoned discussion, resorting to petty and childish name calling instead.
You also seem to be suffering from what phychologists call 'Freudian Projection' by projecting your own "grade school" behavior on to others.
I find the frequency of the deliberately belittling term "fanboi" on this site mildly annoying, last I knew this was a mac forum, not a playground. And to replace the 'y' with an 'i', how old are you boy?
Some technologies are better or worse than others, not everything is created equal, and humans like to talk about the merits of one system over another. It should come as no surprise that there is a preponderance of mac 'supporters' on this site.
Also, I see the difficulty being that each time Android is put on a new phone, they have to customize it and set the drivers up, etc.
I consider this to be one of the main weaknesses of the Android platform. Every cell phone manufacturer who uses hardware on which Android hasn't been ported yet is going to have to either:
a) Come up with their own implementation of the Android platform
b) Lobby Google to support their platform
If the hardware is obscure enough (or the manufacturer is too small), then option b is out of the question.
For people who remember the early days of the JVM on Linux (before Sun took over maintaining it), the implementation tended to lag behind the official releases and not behave the same as it did on other platforms (though I give the Blackdown folks full credit for their effort at the time). I'm envisioning a similar situation for Android on cellular platforms which aren't officially supported.
Write once, debug everywhere was the motto back in those early Java days.
I consider this to be one of the main weaknesses of the Android platform. Every cell phone manufacturer who uses hardware on which Android hasn't been ported yet is going to have to either:
a) Come up with their own implementation of the Android platform
b) Lobby Google to support their platform
If the hardware is obscure enough (or the manufacturer is too small), then option b is out of the question.
Manufacturers already have to write drivers for the firmware they use. If Android becomes popular then drivers for the same chips can be used with no alteration and there will be a very large developer community available to write these drivers at a much lower cost because of the widespread use of the platform and significant competition among coders in a open SDK.
They could even reduce their in-house coders for many aspects of the software as they can simply buy many drivers from a 3rd party who has already done the leg work.
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 may want to read the article below: