Why Do We Have ...

[Lawrence D'Oliveiro]

.... <http://developer.android.com/reference/android/net/Uri.html>

versus

<http://developer.android.com/reference/java/net/URI.html>

?

--
someone who just had to write

final android.net.Uri Target = Data.getData();
...
new java.io.FileInputStream
(
new java.io.File(new java.net.URI(Target.toString()))
)

 

[Nigel Wade]

... <http://developer.android.com/reference/android/net/Uri.html>

versus

<http://developer.android.com/reference/java/net/URI.html>

We don't.

We have:
http://download.oracle.com/javase/6/docs/api/java/net/URI.html

If you want to know why Android isn't Java you may be better asking Android.

 

[Lew]

We don't.

We have:
http://download.oracle.com/javase/6/docs/api/java/net/URI.html

If you want to know why Android isn't Java you may be better asking Android.

Hey, "Larry", why does Apache Commons Collections have
'org.apache.commons.collections.map.HashedMap' versus 'java.util.HashMap'?

Answer:

BECAUSE IT'S A DIFFERENT LIBRARY!

Related question, "Larry"-boy:

Why does Hibernate have 'org.hibernate.criterion.Property' vs.
'org.hibernate.tuple.Property' vs. 'org.hibernate.mapping.Property' vs.
'java.awt.image.renderable.RenderableImageOp'?

 

[Daniele Futtorovic]

Why does Hibernate have 'org.hibernate.criterion.Property' vs.
'org.hibernate.tuple.Property' vs. 'org.hibernate.mapping.Property' vs.
'java.awt.image.renderable.RenderableImageOp'?

Yeah, I've always wondered about that last one...

)

 

[markspace]

"In the interest of performance, this class performs little
to no validation."

It's almost as if they're expecting a programmer to be literate enough
to RTFM or something.

Yeah, I know, I'm piling on at this point, but really Lawerence is
getting annoying with posts that say very little and evince very little
thought.

To the OP: that's intended as constructive criticism. Could you try to
put more thought, and a little more thoughtful verbiage, in your future
posts?

 

[Arne Vajhøj]

...<http://developer.android.com/reference/android/net/Uri.html>

versus

<http://developer.android.com/reference/java/net/URI.html>

?

If you read the documentation, then you would
see that the classes are very different regarding
what functionality they provide.

Arne

 

[Lawrence D'Oliveiro]

"In the interest of performance, this class performs little
to no validation."

Defeated somewhat by having to use both, didn’t you think?

 

[Lew]

If you read the documentation, then you would
see that the classes are very different regarding
what functionality they provide.

Oh, that that premise *ever* were valid! (I'm speaking industry-wide, not of
any one particular individual, of course. Naturally. What else?)

 

[Arne Vajhøj]

Defeated somewhat by having to use both, didn’t you think?

No, because you don't need to use both.

Arne

 

[Lawrence D'Oliveiro]

No, because you don't need to use both.

How would you rewrite my example, then?

Here it is again:

final android.net.Uri Target = Data.getData();
...
new java.io.FileInputStream
(
new java.io.File(new java.net.URI(Target.toString()))
)

 

[Roedy Green]

If you want to know why Android isn't Java you may be better asking Android.

Android is a resource starved-environment compared with Java desktop.
Apps are small. You are constantly trying to shave bytes and CPU
cycles at the expense of program readability. You have roughly 200 ms
to respond or the user will perceive you as laggy. You have 5 seconds
to respond before the OS says your app has died. Your user is more
impatient and you have fewer resources to satisfy him. You are doing
everything you can to avoid draining the battery. This means letting
the screen go off, cpu turn off etc. whenever possible.

Since apps are smaller, there is more competition. If yours is not
best of breed, you will be quickly be replaced. Since apps are free or
cheap, users have no investment is sticking with what they first try.

 

[Lawrence D'Oliveiro]

Android is a resource starved-environment compared with Java desktop.

In fact the typical current Android smartphone has enough RAM and CPU power
to run a full-featured desktop OS. That’s not the limiting factor at all.

Apps are small. You are constantly trying to shave bytes and CPU
cycles at the expense of program readability.

I haven’t felt the need to go that far—yet.

You have roughly 200 ms to respond or the user will perceive you as laggy.

That happens on the desktop as well.

You have 5 seconds to respond before the OS says your app has died.

That kind of discipline is useful on the desktop as well.

Your user is more impatient and you have fewer resources to satisfy him.
You are doing everything you can to avoid draining the battery.

The battery can be a limiting factor, but the real issue is the user
interface: you simply haven’t got room for a full-size screen, a full-size
keyboard, or a full-size mouse. So you have to interact through narrower-
bandwidth channels.

Since apps are smaller, there is more competition. If yours is not
best of breed, you will be quickly be replaced. Since apps are free or
cheap, users have no investment is sticking with what they first try.

Which puts the high-overhead corporate code-cutter approach at a severe
disadvantage.

 

[Dirk Bruere at NeoPax]

Android is a resource starved-environment compared with Java desktop.
Apps are small. You are constantly trying to shave bytes and CPU
cycles at the expense of program readability. You have roughly 200 ms
to respond or the user will perceive you as laggy. You have 5 seconds
to respond before the OS says your app has died. Your user is more
impatient and you have fewer resources to satisfy him. You are doing
everything you can to avoid draining the battery. This means letting
the screen go off, cpu turn off etc. whenever possible.

That's got to change, at least with Honeycomb.
I am working on a £200 ($300) Android 2.2 Tablet with a Tegra 2 chipset
and half a gig or RAM. That kind of processing power was found on
desktops not very long ago.