The imports is the whole issue. I was not aware of stub classes but my
initial googling shows me it's some kind of remote object and that sure
doesn't sound fast. Anyway thank you for the point and I will look into it.
I for one don't leave anything up to a C compiler when it comes to a hot
spot so there is no way I am putting my life in the hands of a JIT. I
think part of the issue could be the type of projects being written.
For an app that is mainly data entry and isn't constantly requiring
every last cycle from the CPU then I would rather use interfaces or
maybe even these stubs but not for a real-time game.
Every single game project I have worked has had math functions that are
conditionally compiled based on platform.
On 8/3/2010 9:55 PM, dm1973 wrote:
if (Platform.OS == BLACKBERRY){
// DO blackberry
}else{
// DO JAVA
}
class Platform{
static final int OS = BLACKBERRY;
}
The only trick part is doing the imports. Stub classes are a one way.
Interfaces (don't worry about the performance overhead. Count on the
JIT to optimize the code until it is proven to be a problem. HotSpot
is great at optimizing simple cases like this. I expect Dalvik will be
also in another year) are another way. You could also do a build
system approach (include different versions depending on what you are
doing). Even in C/C++ #define code like this is rarely the best way to
go. I always put platform specific code in platform specific files.
Some of that is personal preference but my team found it much easier
to maintain.
--
Leigh McRae
www.lonedwarfgames.com
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
