It's certainly not J2ME. Nobody would be dumb enough to use that crippled environment.
First glance there seems to be more commonality with GWT. My guess is that Google will try to create as much compatibility between GWT and Android as possible to allow Google Gadget type apps to run accros both platforms.
One question is how Google see the API standardisation process? It could adopt a JCP style of governence, which should slow things down nicely, or it could act unilaterally/bilaterally with key OHA members. fwiw I hope for the latter
On Nov 12, 4:44 pm, Wendong <wendong...@gmail.com> wrote:
You've observed that Android is based on Java and jumped to all the wrong conclusions.
The difference between J2ME and Android is thus... J2ME was a bolt on which was specifically designed to be kept as far away from the handset's core functionality as possible. Therefore it sucked big time and was only useful for ... well not much actually.
Android is more in the spirit of SavaJe where the phone applications are themselves Java apps. This therefore means the underlying APIs expose just about the whole handset. Just read the SMS API http://code.google.com/android/reference/android/telephony/gsm/SmsMes... to see how much low level control you now have.
The choice of Java makes so much sense in that it provides the phone with much needed protection against sloppy programming. Correct me if I'm wrong but the chips in typical handsets don't implement virtual memory in the same way a i386 does, so the potential for bad userspace code to panic the OS is significant. By running apps in a Java VM, the OS is protected.
Maybe you were expecting .NET. Sorry, wrong camp!
On Nov 12, 4:53 pm, sharvil <snrr...@gmail.com> wrote:
> Yeah, talk about sucktastic. I expected more but I guess expectations > should be left at the door when we're talking about the mobile > industry. *sigh*
> On Nov 13, 12:44 am, Wendong <wendong...@gmail.com> wrote:
> > It is not MIDlet. It is not Xlet. It is not SuperWaba.
I believe that the provided software will be more than enough. I am really interested in how the VM on the devices will handle it. We will have to wait and see wont we! ;-)
On Nov 12, 12:03 pm, "cleverthinking....@gmail.com"
<cleverthinking....@gmail.com> wrote: > I'm not sure what "more" you were expecting.
> You've observed that Android is based on Java and jumped to all the > wrong conclusions.
> The difference between J2ME and Android is thus... > J2ME was a bolt on which was specifically designed to be kept as far > away from the handset's core functionality as possible. Therefore it > sucked big time and was only useful for ... well not much actually.
> Android is more in the spirit of SavaJe where the phone applications > are themselves Java apps. This therefore means the underlying APIs > expose just about the whole handset. Just read the SMS APIhttp://code.google.com/android/reference/android/telephony/gsm/SmsMes... > to see how much low level control you now have.
> The choice of Java makes so much sense in that it provides the phone > with much needed protection against sloppy programming. Correct me if > I'm wrong but the chips in typical handsets don't implement virtual > memory in the same way a i386 does, so the potential for bad userspace > code to panic the OS is significant. By running apps in a Java VM, the > OS is protected.
> Maybe you were expecting .NET. Sorry, wrong camp!
> On Nov 12, 4:53 pm, sharvil <snrr...@gmail.com> wrote:
> > Yeah, talk about sucktastic. I expected more but I guess expectations > > should be left at the door when we're talking about the mobile > > industry. *sigh*
> > On Nov 13, 12:44 am, Wendong <wendong...@gmail.com> wrote:
> > > It is not MIDlet. It is not Xlet. It is not SuperWaba.
I just watched the videos and I am very impressed. As a Java developer, I am very excited to see that Google takes "Java ME" (I actually mean the Java on mobile devices) to a new level. I want a Android Phone now!
<cleverthinking....@gmail.com> wrote: > I'm not sure what "more" you were expecting.
> You've observed that Android is based on Java and jumped to all the > wrong conclusions.
> The difference between J2ME and Android is thus... > J2ME was a bolt on which was specifically designed to be kept as far > away from the handset's core functionality as possible. Therefore it > sucked big time and was only useful for ... well not much actually.
> Android is more in the spirit of SavaJe where the phone applications > are themselves Java apps. This therefore means the underlying APIs > expose just about the whole handset. Just read the SMS APIhttp://code.google.com/android/reference/android/telephony/gsm/SmsMes... > to see how much low level control you now have.
> The choice of Java makes so much sense in that it provides the phone > with much needed protection against sloppy programming. Correct me if > I'm wrong but the chips in typical handsets don't implement virtual > memory in the same way a i386 does, so the potential for bad userspace > code to panic the OS is significant. By running apps in a Java VM, the > OS is protected.
> Maybe you were expecting .NET. Sorry, wrong camp!
> On Nov 12, 4:53 pm, sharvil <snrr...@gmail.com> wrote:
> > Yeah, talk about sucktastic. I expected more but I guess expectations > > should be left at the door when we're talking about the mobile > > industry. *sigh*
> > On Nov 13, 12:44 am, Wendong <wendong...@gmail.com> wrote:
> > > It is not MIDlet. It is not Xlet. It is not SuperWaba.
> Interesting...I wonder if/how android will influence JavaFX mobile and > vice versa.....
> On Nov 12, 9:03 am, "cleverthinking....@gmail.com" > <cleverthinking....@gmail.com> wrote: > > I'm not sure what "more" you were expecting.
> > You've observed that Android is based on Java and jumped to all the > > wrong conclusions.
> > The difference between J2ME and Android is thus... > > J2ME was a bolt on which was specifically designed to be kept as far > > away from the handset's core functionality as possible. Therefore it > > sucked big time and was only useful for ... well not much actually.
> > Android is more in the spirit of SavaJe where the phone applications > > are themselves Java apps. This therefore means the underlying APIs > > expose just about the whole handset. Just read the SMS APIhttp://code.google.com/android/reference/android/telephony/gsm/SmsMes... > > to see how much low level control you now have.
> > The choice of Java makes so much sense in that it provides the phone > > with much needed protection against sloppy programming. Correct me if > > I'm wrong but the chips in typical handsets don't implement virtual > > memory in the same way a i386 does, so the potential for bad userspace > > code to panic the OS is significant. By running apps in a Java VM, the > > OS is protected.
> > Maybe you were expecting .NET. Sorry, wrong camp!
> > On Nov 12, 4:53 pm, sharvil <snrr...@gmail.com> wrote:
> > > Yeah, talk about sucktastic. I expected more but I guess expectations > > > should be left at the door when we're talking about the mobile > > > industry. *sigh*
> > > On Nov 13, 12:44 am, Wendong <wendong...@gmail.com> wrote:
> > > > It is not MIDlet. It is not Xlet. It is not SuperWaba.
-- Marinho Brandão (José Mário)
Desenvolvimento Tron Informática Ltda Telefone: 55 (62) 3239 7337
On Nov 12, 9:03 am, "cleverthinking....@gmail.com"
<cleverthinking....@gmail.com> wrote: > I'm not sure what "more" you were expecting.
> The choice of Java makes so much sense in that it provides the phone > with much needed protection against sloppy programming. Correct me if > I'm wrong but the chips in typical handsets don't implement virtual > memory in the same way a i386 does, so the potential for bad userspace > code to panic the OS is significant. By running apps in a Java VM, the > OS is protected.
Most AP-BP phones have memory protection of some sort, or other mechanisms to deal with invalid memory access. Symbian's S60 platform is an example- no signed S60 app has ever paniced any of my S60 phones, though I've done it while debugging. (I've also had a buggy JVM panic a phone.)
> Maybe you were expecting .NET. Sorry, wrong camp!
I was expecting something more than another JUIX. Something more akin to Symbian or EZX but with an open source, native API. As far as JVMs, Tao's Intent platform was more interesting than this.
Java is sold as a "write once-run everywhere" solution, when in fact, for mobile, you have to manage about 30 different JVM variations, each with its own quirks. I've developed both native and java apps for phones and honestly found native apps to be less work to develop if written portable from the start. At least with C development, the tools are supportive of platform differences (#ifdef, etc). Java is still pretending there's no differences between JVMs.
On Nov 12, 10:12 am, proberts9999 <proberts9...@gmail.com> wrote:
> Most AP-BP phones have memory protection of some sort, or other > mechanisms to deal with invalid memory access. Symbian's S60 platform > is an example- no signed S60 app has ever paniced any of my S60 > phones, though I've done it while debugging. (I've also had a buggy > JVM panic a phone.)
Well, that's the difference. Google's pretty clearly wanting to minimize the risk of buggy apps crashing the phone. If they get the JVM right, then it becomes *impossible* for a buggy Android app to crash the phone. Signing is no protection against native phone- crashing apps, particularly since the whole point of this phone is to be open.
> Java is still pretending there's no differences between JVMs.
Google isn't Sun. When Google uses Java technology in creative ways, they are very upfront about the leaks in their abstractions. I expect a lot of details about the Davlik VM and its idiosyncrasies. Google's not using Java because of write-once-run-anywhere; they're using Java because it's the best way to ensure that Android apps can do damn near anything with good performance and without risking the OS-level stability of the phone. That tradeoff works for me. If it doesn't work for you, Android's not for you.
J2ME sucked for many reasons, amongst them . combination of a lowest common denominator API . ability for handset manufacturers to interpret the APIs any way they felt like . ... leading to consistent APIs but inconsistent behaviour
I don't see Android making those mistakes.
We've all been burned by how bad J2ME is from a developer's standpoint. Android is not J2ME.
... and I have several S60e3 apps that crash my phone.
cleverthinking....@gmail.com wrote: > I'm not sure what "more" you were expecting.
I will tell you what I was expecting and how android is failing my expectations.
I was expecting total control over handset, not just user visible applications. I was expecting to be able write my own codecs (ok, port ffmpeg codecs), I wanted to have custom VPN client (that means kernel driver and associated userspace support), I wanted to filter incoming calls/sms/xmpp connections, so contacts in blacklist would not even ring and the callers would get busy tone. I wanted to modify what happens when someone rings me (to display her or his full screen photo, for example). I wanted seamless SIP support, whether carriers agree with it or not. I wanted SyncML support for data providers. I wanted file manager, that can open every directory and file. I wanted to port existing applications, for example ScummVM (i.e. C/C++).
Instead what you offer is writing toys. Social applications like Skypop may be seen cool, but I wanted something practical. Right now, Android offers less than Symbian. In Symbian terms, Android offers "Basic Capablities" and a bit of "Extended capabilities" - something you need only self-signed or certificate without ACS Publisher ID. What I was aiming for was functionality requiring "Platform-approved capabilities" and "Manufacturer-approved capabilities" (in Symbian- talk).
I was hoping that Android would be much more open towards experiments than competition. Something like PC, where you can change everything, including boot loader. But now it looks no more open than Symbian or Windows Mobile.
I haven't tried out the SDK yet but as far as I understand, the source code is open so you can do whatever you want with it ... why do you feel that you are restricted in doing all of those things you mentioned?
> cleverthinking....@gmail.com wrote: > > I'm not sure what "more" you were expecting.
> I will tell you what I was expecting and how android is failing my > expectations.
> I was expecting total control over handset, not just user visible > applications. I was expecting to be able write my own codecs (ok, port > ffmpeg codecs), I wanted to have custom VPN client (that means kernel > driver and associated userspace support), I wanted to filter incoming > calls/sms/xmpp connections, so contacts in blacklist would not even > ring and the callers would get busy tone. I wanted to modify what > happens when someone rings me (to display her or his full screen > photo, for example). I wanted seamless SIP support, whether carriers > agree with it or not. I wanted SyncML support for data providers. I > wanted file manager, that can open every directory and file. I wanted > to port existing applications, for example ScummVM (i.e. C/C++).
> Instead what you offer is writing toys. Social applications like > Skypop may be seen cool, but I wanted something practical. Right now, > Android offers less than Symbian. In Symbian terms, Android offers > "Basic Capablities" and a bit of "Extended capabilities" - something > you need only self-signed or certificate without ACS Publisher ID. > What I was aiming for was functionality requiring "Platform-approved > capabilities" and "Manufacturer-approved capabilities" (in Symbian- > talk).
> I was hoping that Android would be much more open towards experiments > than competition. Something like PC, where you can change everything, > including boot loader. But now it looks no more open than Symbian or > Windows Mobile.
On Nov 13, 12:48 pm, Pranav Sharma <pra...@pranavsharma.com> wrote:
> I haven't tried out the SDK yet but as far as I understand, the source > code is open so you can do whatever you want with it ... why do you > feel that you are restricted in doing all of those things you > mentioned?
Pranav, just because source is open (or will be open) does not mean that you will be able to put your modification on the handset. Have a look at existing practices: other phones use WebKit as their browser engine. Source code for WebKit is open. You would expect, that you could replace the supplied WebKit with your own, right? Wrong, you can't. The handset will not allow you, the user and the owner, to modify it's image[*]. That's why I was asking for "Manufacturer- approved capabilities" for everyone.
Right now, it looks like handset manufacturers will be able to take the source, make modifications and put the result on the phones. There was nothing said or written about end users' ability to do the same. Existing practice in cell phone industry suggests otherwise.
Have a look at architecture videos at youtube. There are several layers: kernel, native libraries, java libraries, applications. What I'm interested in are all layers, including the bottom three. The SDK sanctioned development is only for the top layer: applications. In principle I understand, it allows you to write application, compile it into bytecode and it will execute no matter what CPU architecture the handset is using. On the other hand, it will close doors to develop "interesting" drivers/libraries/applications, that require C. Until there is assurance that you will be able to replace vendor provided system image with your own, Android will be JavaME with slightly different APIs and uniform behaviour accross different handsets. But it will be not platform open for everyone, only for manufacturers. Unlike the PC and like the competing systems.
Imagine typical desktop computer with windows or linux: you would be able to write .net (or python) applications. Only applications, not shared .net (python) libraries (likes of java libraries in android), not native dlls/libs (likes of native libraries) and not device drivers. Would you call such a system open? Even if the source were available?
* - If some of you remember the push for Trusted Computing few years ago, then yes, this is it. On cell phones, TC is alive and doing well. If you don't have the "right certificate", your ability to do what you want is limited.
> On Nov 13, 12:48 pm, Pranav Sharma <pra...@pranavsharma.com> wrote:
> > I haven't tried out the SDK yet but as far as I understand, the source > > code is open so you can do whatever you want with it ... why do you > > feel that you are restricted in doing all of those things you > > mentioned?
> Pranav, just because source is open (or will be open) does not mean > that you will be able to put your modification on the handset. Have a > look at existing practices: other phones use WebKit as their browser > engine. Source code for WebKit is open. You would expect, that you > could replace the supplied WebKit with your own, right? Wrong, you > can't. The handset will not allow you, the user and the owner, to > modify it's image[*]. That's why I was asking for "Manufacturer- > approved capabilities" for everyone.
> Right now, it looks like handset manufacturers will be able to take > the source, make modifications and put the result on the phones. There > was nothing said or written about end users' ability to do the same. > Existing practice in cell phone industry suggests otherwise.
> Have a look at architecture videos at youtube. There are several > layers: kernel, native libraries, java libraries, applications. What > I'm interested in are all layers, including the bottom three. The SDK > sanctioned development is only for the top layer: applications. In > principle I understand, it allows you to write application, compile it > into bytecode and it will execute no matter what CPU architecture the > handset is using. On the other hand, it will close doors to develop > "interesting" drivers/libraries/applications, that require C. Until > there is assurance that you will be able to replace vendor provided > system image with your own, Android will be JavaME with slightly > different APIs and uniform behaviour accross different handsets. But > it will be not platform open for everyone, only for manufacturers. > Unlike the PC and like the competing systems.
> Imagine typical desktop computer with windows or linux: you would be > able to write .net (or python) applications. Only applications, not > shared .net (python) libraries (likes of java libraries in android), > not native dlls/libs (likes of native libraries) and not device > drivers. Would you call such a system open? Even if the source were > available?
> * - If some of you remember the push for Trusted Computing few years > ago, then yes, this is it. On cell phones, TC is alive and doing well. > If you don't have the "right certificate", your ability to do what you > want is limited.
> I can't believe you will be able to install c code in a phone,
> an more dificult try to imagine you can distribute it...
> On Nov 13, 12:34 pm, John Doe <john.john...@gmail.com> wrote: > > On Nov 13, 12:48 pm, Pranav Sharma <pra...@pranavsharma.com> wrote:
> > > I haven't tried out the SDK yet but as far as I understand, the source > > > code is open so you can do whatever you want with it ... why do you > > > feel that you are restricted in doing all of those things you > > > mentioned?
> > Pranav, just because source is open (or will be open) does not mean > > that you will be able to put your modification on the handset. Have a > > look at existing practices: other phones use WebKit as their browser > > engine. Source code for WebKit is open. You would expect, that you > > could replace the supplied WebKit with your own, right? Wrong, you > > can't. The handset will not allow you, the user and the owner, to > > modify it's image[*]. That's why I was asking for "Manufacturer- > > approved capabilities" for everyone.
> > Right now, it looks like handset manufacturers will be able to take > > the source, make modifications and put the result on the phones. There > > was nothing said or written about end users' ability to do the same. > > Existing practice in cell phone industry suggests otherwise.
> > Have a look at architecture videos at youtube. There are several > > layers: kernel, native libraries, java libraries, applications. What > > I'm interested in are all layers, including the bottom three. The SDK > > sanctioned development is only for the top layer: applications. In > > principle I understand, it allows you to write application, compile it > > into bytecode and it will execute no matter what CPU architecture the > > handset is using. On the other hand, it will close doors to develop > > "interesting" drivers/libraries/applications, that require C. Until > > there is assurance that you will be able to replace vendor provided > > system image with your own, Android will be JavaME with slightly > > different APIs and uniform behaviour accross different handsets. But > > it will be not platform open for everyone, only for manufacturers. > > Unlike the PC and like the competing systems.
> > Imagine typical desktop computer with windows or linux: you would be > > able to write .net (or python) applications. Only applications, not > > shared .net (python) libraries (likes of java libraries in android), > > not native dlls/libs (likes of native libraries) and not device > > drivers. Would you call such a system open? Even if the source were > > available?
> > * - If some of you remember the push for Trusted Computing few years > > ago, then yes, this is it. On cell phones, TC is alive and doing well. > > If you don't have the "right certificate", your ability to do what you > > want is limited.
-- Binary packages encourage inconsistency and incompatibility, whearas source encourages unified development frameworks and integration gentoo.org
On Nov 13, 4:34 am, John Doe <john.john...@gmail.com> wrote:
> Imagine typical desktop computer with windows or linux: you would be > able to write .net (or python) applications. Only applications, not > shared .net (python) libraries (likes of java libraries in android), > not native dlls/libs (likes of native libraries) and not device > drivers. Would you call such a system open? Even if the source were > available?
Yes. Yes, I would. Google is obviously trading safety for power in Android. I think this is an incredibly smart tradeoff, given that consumers expect their phones to Just Work.
Nobody expects PCs to stay stable for long (or if they do, they must be a very novice PC user). The total openness you praise on PC is the main cause of PCs' flakiness and instability. Google knows that if Android supported unrestricted native development, the result would be a huge quantity of buggy, phone-crashing applications, each of which had its own flaky codecs, drivers, and CPU-hogging inner loops.
For Android phones to become a successful ecosystem, Google knows that *they have to be reliable*. If Android phones get a reputation for crashing every couple of hours, Android will be a complete disaster. Google's too smart to let that happen.
Of course *your* native apps wouldn't have any crash bugs in them. And of course every individual native app developer would say the same thing -- MY app is 100% rock solid. Forgive me if I don't believe all of you are right. And once you throw all the different hardware variations of OHA phones into the mix, the odds of all native app developers being able to properly QA all their applications drops to nil.
Google wants to ensure *by construction* that apps you buy for any OHA phone will run on all OHA phones. Yes, there will be some sticking points there. But with Google's resources behind fixing them, they'll be smoothed over hugely more quickly than would ever be remotely possible with unrestricted native development.
I think one big reason no mobile platform has taken off yet is *because* they've all been trying to replicate the PC environment where all apps can do anything they want with the hardware. That leads to a bad user experience once the user tries scaling up the number of apps that run (especially concurrently) on their phone. A more tightly managed environment seems like exactly the right thing.
In any case, if you don't like Android, by all means, don't develop for it!
Safety is just smokescreen. Discussing safety based on understanding of single, badly designed, buggy PC platform is demagogic. There are platforms that are both open and safe - and Linux, base of android - is among them.
> "customers expect"
You probably wanted to say: "mainstream end users expect". Developers and innovators expect something else, something that android doesn't provide (yet, but we will see).
During introduction and growth stage of your product life cycle you have to attract early adopters, not followers. Attracting laggers without early adopters is both difficult and unstable. You will create fashion fad instead of trend.
> "PC is unreliable, users have low expectations, openness is cause of flakiness and instability"
Again, you are discussing Windows, not PC. And quite contrary, openness is prerequisite for innovation. If you have only few parties allowed to innovate and they are satisfied with status quo, why they would innovate? For a case study, see Internet vs cellphone networks since late 80's until now.
This is not to say that closed handsets are stable or reliable. Go to some random telco support center and look at the complaints.
> "native code is buggy and crashing", "my application is 100% solid", "100% binary compatibility across handsets"
Yes, I know that no application, whether native or interpreted is 100% solid. But there are things you simply cannot do in interpreted language. This is not lisp or smalltalk machine, where you could. This is higher layer and everything below is unaccessible to you.
So I agree with you, high level languages are good, I'm myself big Python fan. But there is definitely difference between "being able to drop into lower layers" and "being stuck with provided API".
I also agree with you on binary compatibility. It is convenient. But again: being able to drop into lower layers and having to handle the PITA of different CPU architectures is different from "can't do".
> "No mobile platform has taken off yet because they all replicate PC environment"
You must be talking about some mobile platforms that are unknown to me. Until now, I've seen only mobile platforms that very either very locked down or just locked down. From entirely proprietary systems through BREW, Symbian, JME, to Windows Mobile, they all are locked down to certain extent.
To understand why, you must know more about mobile business.
Why telcos are in business? For profit. Right now in telco business, that means ARPU[1]. You, as a customer, either have enough impact to negotiate CUG[2], or you buy retail services at retail prices. Telco is only one, who is allowed to create new services and set their prices. For case study of such telco successes, see WAP. For PC equivalent, see the concept of network neutrality.
Why handsets manufacturers are in business? For profit. Right now in handset manufacturing business, that means selling handsets, devices and software to two groups: businesses (those who have CUG) and telcos/ retail. Telcos have big impact on retail sales, so handsets are crippled to not endanger any retail service (this is big problem in North America and presents problem in Europe too, but as big as in NA). In business segment, you can have things like VPN, if you are willing to pay (Nokia for example sells very expensive VPN gateway for E-series phones. These phones are unable to use different VPN scheme, only Nokia's. Other than E-series phones are unable to use VPN at all). There is also no place for 3rd-party innovators, unless they secured enough capital and have political clout to enter negotiation with manufacturers (read: not your typical garage inventors).
Even smartphones are engineered in a way that does not endanger relationship between telcos and manufacturers. You don't have low level access, so you can't encrypt your calls, avoid voice services by using VoIP or just easily avoid paid services your handset would be capable doing on it's own, like blocking unwanted SMS messages or CLIR calls.
Therefore I don't understand how you could even suggest that mobile environment was replicating PC. Until now, mobiles were doing everything but replicate PC. Again, with "huge" success. Voice calls and sms is everything that "average customer", as you put it, uses.
And this is the reason, why mCommerce is DOA and eCommerce is doing well. I'm really interested, for how long we are going to see "stellar successes" like MMS and when the different mobile interest groups will get the message, that openness is the only way forward.
Android is not disruptive. Android is "me too" technology. So pardon me if I consider android "more of the same".
> "In any case, if you don't like Android, by all means, don't develop for it!"
I won't touch android platform as it exists today. And I doubt I will be alone, judging by the number of people in the group asking for native development. Life is too short to waste it for nothing, without making any difference. I wish good luck to Google, they will need it. Right now, they are offering less than their competition (and I'm saying that as someone who hates changes that Symbian did in 9.x). I really don't understand how Google wants to foster innovation in such closed environment. And I don't consider Google Maps mashups an innovation.
--- [1] Average Revenue Per User [2] Closed User Group
Amen! I almost agree on 100% of your statement here. I personally do not find the lack of C/C++ to be *that* huge of a problem iff the provided high level language allows you to access all the layers in a portable and sane way. Android, under the influence of carriers/operators/dev-manufacturers that have been able to smuggle inside the OHA, seems to be taking the paths that already failed before (see the whole app signing BS). And this is really sad, because the mobile world could really use a sane unification from a platform POV. Developers must be able to access the whole set of device functionalities, and end users must be able to freely use the products of this creativity. Free the developers and free the end users, despite the pressure of the "middle men" operators and phone manufacturers. I hoped Google had the power to do so, but I think that might not be the case.
On Nov 14, 4:12 am, John Doe <john.john...@gmail.com> wrote:
> Safety is just smokescreen. Discussing safety based on understanding > of single, badly designed, buggy PC platform is demagogic. There are > platforms that are both open and safe - and Linux, base of android - > is among them.
> > "customers expect"
> You probably wanted to say: "mainstream end users expect". Developers > and innovators expect something else, something that android doesn't > provide (yet, but we will see).
> During introduction and growth stage of your product life cycle you > have to attract early adopters, not followers. Attracting laggers > without early adopters is both difficult and unstable. You will create > fashion fad instead of trend.
> > "PC is unreliable, users have low expectations, openness is cause of flakiness and instability"
> Again, you are discussing Windows, not PC. And quite contrary, > openness is prerequisite for innovation. If you have only few parties > allowed to innovate and they are satisfied with status quo, why they > would innovate? For a case study, see Internet vs cellphone networks > since late 80's until now.
> This is not to say that closed handsets are stable or reliable. Go to > some random telco support center and look at the complaints.
> > "native code is buggy and crashing", "my application is 100% solid", "100% binary compatibility across handsets"
> Yes, I know that no application, whether native or interpreted is 100% > solid. But there are things you simply cannot do in interpreted > language. This is not lisp or smalltalk machine, where you could. This > is higher layer and everything below is unaccessible to you.
> So I agree with you, high level languages are good, I'm myself big > Python fan. But there is definitely difference between "being able to > drop into lower layers" and "being stuck with provided API".
> I also agree with you on binary compatibility. It is convenient. But > again: being able to drop into lower layers and having to handle the > PITA of different CPU architectures is different from "can't do".
> > "No mobile platform has taken off yet because they all replicate PC environment"
> You must be talking about some mobile platforms that are unknown to > me. Until now, I've seen only mobile platforms that very either very > locked down or just locked down. From entirely proprietary systems > through BREW, Symbian, JME, to Windows Mobile, they all are locked > down to certain extent.
> To understand why, you must know more about mobile business.
> Why telcos are in business? For profit. Right now in telco business, > that means ARPU[1]. You, as a customer, either have enough impact to > negotiate CUG[2], or you buy retail services at retail prices. Telco > is only one, who is allowed to create new services and set their > prices. For case study of such telco successes, see WAP. For PC > equivalent, see the concept of network neutrality.
> Why handsets manufacturers are in business? For profit. Right now in > handset manufacturing business, that means selling handsets, devices > and software to two groups: businesses (those who have CUG) and telcos/ > retail. Telcos have big impact on retail sales, so handsets are > crippled to not endanger any retail service (this is big problem in > North America and presents problem in Europe too, but as big as in > NA). In business segment, you can have things like VPN, if you are > willing to pay (Nokia for example sells very expensive VPN gateway for > E-series phones. These phones are unable to use different VPN scheme, > only Nokia's. Other than E-series phones are unable to use VPN at > all). There is also no place for 3rd-party innovators, unless they > secured enough capital and have political clout to enter negotiation > with manufacturers (read: not your typical garage inventors).
> Even smartphones are engineered in a way that does not endanger > relationship between telcos and manufacturers. You don't have low > level access, so you can't encrypt your calls, avoid voice services by > using VoIP or just easily avoid paid services your handset would be > capable doing on it's own, like blocking unwanted SMS messages or CLIR > calls.
> Therefore I don't understand how you could even suggest that mobile > environment was replicating PC. Until now, mobiles were doing > everything but replicate PC. Again, with "huge" success. Voice calls > and sms is everything that "average customer", as you put it, uses.
> And this is the reason, why mCommerce is DOA and eCommerce is doing > well. I'm really interested, for how long we are going to see "stellar > successes" like MMS and when the different mobile interest groups will > get the message, that openness is the only way forward.
> Android is not disruptive. Android is "me too" technology. So pardon > me if I consider android "more of the same".
> > "In any case, if you don't like Android, by all means, don't develop for it!"
> I won't touch android platform as it exists today. And I doubt I will > be alone, judging by the number of people in the group asking for > native development. Life is too short to waste it for nothing, without > making any difference. I wish good luck to Google, they will need it. > Right now, they are offering less than their competition (and I'm > saying that as someone who hates changes that Symbian did in 9.x). I > really don't understand how Google wants to foster innovation in such > closed environment. And I don't consider Google Maps mashups an > innovation.
> --- > [1] Average Revenue Per User > [2] Closed User Group
On Nov 13, 1:34 pm, John Doe <john.john...@gmail.com> wrote:
> On Nov 13, 12:48 pm, Pranav Sharma <pra...@pranavsharma.com> wrote:
> > I haven't tried out the SDK yet but as far as I understand, the source > > code is open so you can do whatever you want with it ... why do you > > feel that you are restricted in doing all of those things you > > mentioned?
> Pranav, just because source is open (or will be open) does not mean > that you will be able to put your modification on the handset.
Yes, but one day there will be a rogue Chinese cell phone manufacturer who will sell an Android based phone which can be re-flashed and developers will buy that phone and add a VPN client, VoIP over der VPN, YouTube streaming, MAME and an iPhone emulator and the default user will say: "I want this $99 phone which runs Pac-Man and can not be eavesdropped by homeland security" -- and that's a market force.
> Right now, it looks like handset manufacturers will be able to take > the source, make modifications and put the result on the phones. There > was nothing said or written about end users' ability to do the same. > Existing practice in cell phone industry suggests otherwise.
Existing practice in cell phone industry is, that makers license their cell phone OS from some maker and are obliged to protect the implementation internals, because they've licensed trade secrets and whatnots. There is also a security aspect, in the sense that someone with unlimited access to the radio could DoS his radio cell or somethings. On the other hand, a Treo is unprotected and open enough to boot linux and apparently the radio is accessible via an UART: http://grack.com/blog/articles/2005/12/13/treo-650-boots-linux
So basically, a stock Treo should be able to run Android *today* with root shell access and writeable flash.
> Have a look at architecture videos at youtube. There are several > layers: kernel, native libraries, java libraries, applications. What > I'm interested in are all layers, including the bottom three. The SDK > sanctioned development is only for the top layer: applications. In > principle I understand, it allows you to write application, compile it > into bytecode and it will execute no matter what CPU architecture the > handset is using. On the other hand, it will close doors to develop > "interesting" drivers/libraries/applications, that require C. Until > there is assurance that you will be able to replace vendor provided > system image with your own, Android will be JavaME with slightly > different APIs and uniform behaviour accross different handsets. But > it will be not platform open for everyone, only for manufacturers. > Unlike the PC and like the competing systems.
As far as I understood the Android thing, we are not ipse facto supposed to be locked into DalekVM, sorry DalvikVM, for example by the source code license. Some Google guy said in another thread, that the source to Dalek is *yet* not available. So it very well might become available soon (which is sensible btw. because cell phone CPUs often have customized instruction sets, thus you need source access somehow) and then you'll be able to write your own JNI libraries, provided you have the Chinaphone to install them.
> Imagine typical desktop computer with windows or linux: you would be > able to write .net (or python) applications. Only applications, not > shared .net (python) libraries (likes of java libraries in android), > not native dlls/libs (likes of native libraries) and not device > drivers. Would you call such a system open? Even if the source were > available?
I think it's a bit rash to conclude that every Android-Phone will be TiVoized. But I admit, that the TelCo providers will hesitate to offer a subsidized phone which can make undetectable VoIP calls with their plans. Who cares? The subsidized phones are to expensive anyway.
