So, Android is a Google flavor of Java ME?
Wendong
sharvil
should be left at the door when we're talking about the mobile
industry. *sigh*
cleverthi...@gmail.com
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
cleverthi...@gmail.com
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/SmsMessage.html
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!
Akeem A.
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...
Wendong
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!
Joe
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...
Marinho Brandao
think is the first Java alternative, I think...
2007/11/12, Joe <j...@shomphe.com>:
--
Marinho Brandão (José Mário)
Desenvolvimento
Tron Informática Ltda
Telefone: 55 (62) 3239 7337
proberts9999
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.
Rob Jellinghaus
> 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.
Cheers!
Rob
cleverthi...@gmail.com
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.
John Doe
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.
Pranav Sharma
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?
Aditya
http://benno.id.au/blog/2007/11/13/android-native-apps
On Nov 13, 3:59 pm, John Doe <john.john...@gmail.com> wrote:
John Doe
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.
gabrielpalomino
an more dificult try to imagine you can distribute it...
ramon lima
Rob Jellinghaus
> 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!
Sincerely,
Rob Jellinghaus
http://robjsoftware.org
John Doe
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
gaz
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.
odradek
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.
matro
> of single, badly designed, buggy PC platform is demagogic. There are
> is among them.
^^^^^^^^^^^^^^^^^
oh... you've lost.
exactly here.