Civilized type usage in Android

[Andreas Petersson]

Something came back to my mind while listening to the latest episode.
The whole Android API is cluttered with int constants and Api signatures.
why does something like this even compile:
myTextView.setBackgroundColor(R.id.redTextBox)

why does android not use interfaces/type safety more often?

has it something to do with performance?

also, i see byte[] very often especially when dealing with camera and
bitmaps. my impression with the jvm is that int[] or even long[] will
bring a significant speedup.
please enlighten me.

br
Andreas

[Fabrizio Giudici]

If you search in the archive, this question was discussed I believe the
past year. In short, I share the same doubts, and the choice was done by
Android architects because of performance reasons. Actually I realize that
back in 2008 the hardware was much less powerful and Dalvik was surely
less optimized. Today I think int constants can be substituted by proper
annotations and dependency injection and even though I don't have the link
at hand I'm sure there's at least one framework that does that.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Cédric Beust ♔]

In the early days, we were even hesitant to use enums instead of ints, and also tended to use concrete classes instead of interfaces (huge different in this case). I think it was a valid concern at the time.

As for type safety, I would argue that Android's API's are "more" type safe than usual in the sense that they make resource look ups type safe (if a resource gets removed or renamed, your code won't compile until you adjust it).

-- 

Cédric

Andreas

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Casper Bang]

As for type safety, I would argue that Android's API's are "more" type safe than usual in the sense that they make resource look ups type safe (if a resource gets removed or renamed, your code won't compile until you adjust it).

The R thing is... special, and only doable because of how Android extends the tool-chain with source-code generation. What bugs me the most is all the casting when accessing elements of a layout. Although the runtime penalty is probably neglectable, it's inherently typeless at compile-time to the author. Android's remedy here again is in tooling, but it still reeks of a type-system mismatch between XML and Java, and makes it hard to pick up other development tools which are not "hardwired" for this ad-hoc way the Android SDK does things.

[Cédric Beust ♔]

On Sun, Jun 3, 2012 at 12:30 AM, Casper Bang <caspe...@gmail.com> wrote:

As for type safety, I would argue that Android's API's are "more" type safe than usual in the sense that they make resource look ups type safe (if a resource gets removed or renamed, your code won't compile until you adjust it).

The R thing is... special, and only doable because of how Android extends the tool-chain with source-code generation. What bugs me the most is all the casting when accessing elements of a layout. Although the runtime penalty is probably neglectable, it's inherently typeless at compile-time to the author. Android's remedy here again is in tooling, but it still reeks of a type-system mismatch between XML and Java, and makes it hard to pick up other development tools which are not "hardwired" for this ad-hoc way the Android SDK does things.

Yup. Note that theoretically, you could get rid of these casts by generating smarter code, but  it seems to me that it might not be worth it (in my experience, class cast exceptions hardly ever happen during that look up).

Also, an open type system like Gosu's would allow to skip the code generation phase and possibly create more strongly typed look up functions.

-- 

Cédric

[Josh Berry]

On Sun, Jun 3, 2012 at 3:49 AM, Cédric Beust ♔ <ced...@beust.com> wrote:
> On Sun, Jun 3, 2012 at 12:30 AM, Casper Bang <caspe...@gmail.com> wrote:
>>>
>>> As for type safety, I would argue that Android's API's are "more" type
>>> safe than usual in the sense that they make resource look ups type safe (if
>>> a resource gets removed or renamed, your code won't compile until you adjust
>>> it).
>>
>>
>> The R thing is... special, and only doable because of how Android extends
>> the tool-chain with source-code generation. What bugs me the most is all the
>> casting when accessing elements of a layout. Although the runtime penalty is
>> probably neglectable, it's inherently typeless at compile-time to the
>> author. Android's remedy here again is in tooling, but it still reeks of a
>> type-system mismatch between XML and Java, and makes it hard to pick up
>> other development tools which are not "hardwired" for this ad-hoc way the
>> Android SDK does things.
>
>
> Yup. Note that theoretically, you could get rid of these casts by generating
> smarter code, but  it seems to me that it might not be worth it (in my
> experience, class cast exceptions hardly ever happen during that look up).

Wouldn't have to be that much smarter. Make the keys something
generic on what you are looking up, and you can basically use the
"hetereogeneous container pattern", right? Question then is simply if
there is a major penalty for doing this instead of just using
primitives.

And, I should say I agree with you. Not sure this is worth it.