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.
On Aug 3, 1:39 pm, Leigh McRae <leigh.mc...@lonedwarfgames.com> wrote:
> On 8/2/2010 10:49 PM, Bob Kerns wrote:> First of all -- if you want to list
> the faults of the C language, the
> > preprocessor is very near the top.
>
> Just your opinion.
> > That's why C++ went to great lengths to mostly remove the need for
> > using it, with inline functions, constants, and the like.
>
> Now your just talking specifically about macros which still can be
> useful and there are somethings that can only be done using a macro.> It's
> too bad they didn't remove it. It causes all kinds of difficulty
> > for tools. The tools for Java are generally far better than for C++ --
> > and the lack of a preprocessor to screw up and ambiguate the
> > interpretation of any piece of syntax you look at, is a huge part of
> > the reason.
>
> MS tools destroy what Java has to offer IMHO. Only the re-factoring is
> better for Java. It's all opinion either way.
>
> I think you have to realize that preprocesing is just a tool and isn't
> to be used to solve all problems. Just because I want a hammer doesn't
> mean I regard every issue as being a nail. It's very appropriate to
> handle cross platform issues, hardware issue, diagnostic code etc. All
> of these issues are very relevant to Android. Sure these issues might
> be handled differently for a desktop solution where resources aren't as
> big of an issue.
>
> Why force everyone to do it the so called right way? Why does C# have
> conditional compile? Just because SUN chose not to support
> preprocessing in javac doesn't mean they aren't behind it. Maybe they
> chose to support it through tools so that j2me code would still work
> with j2se? That would make a lot of sense to me. For something they
> aren't behind they sure put a lot of effort into it.
>
>
>
>
>
> > It's also a major compilation performance hit. With a significant
> > amount of pain, you can get Visual Studio to avoid a lot of the
> > reparsing it requires, but the language basically says that to compile
> > any particular program file, you have to parse all the #includes,
> > recursively, processing the same file over and over and over again --
> > possibly differently each and every time, because INTEGER may mean int
> > in one case, unsigned int in another, and unsigned long long in yet
> > another.
>
> > And that's a problem for programmers, too. No, I don't mean a problem
> > for me, that a good C++ programmer knows how to avoid the problems. I
> > mean its a problem I've had to help MANY experienced C++ programmers
> > resolve time and time again -- often in vendor-supplied code, rather
> > than their own. Or when two different vendor's include files conflict
> > -- or one vendor's include files conflict with their own.
>
> > My long experience is that every time someone tells me they need a
> > preprocessor -- there turns out to be a better way. Sometimes you
> > replace that with code generation -- but most of the time, code
> > generation isn't the ultimate solution, either. Often, proper use of
> > introspection and metadata (the annotation facility, for example)
> > provide a superior (more robust, more compact, and more maintainable)
> > solution.
>
> Solve this one for me. BlackBerry has a version of atan2 that is
> fixed-point and is much faster that the Math.atan2. How can I take
> advantage of this without an interface or an extra function call?
>
> public static final float VecToHeading( float x, float y )
> {
> //#if PLATFORM_BLACKBERRY
> float fAngle = ((float)Fixed32.atand2( (int)(x * 65536.0f),
> (int)(y * 65536.0f) )) / 65536.0f;
> //#else
> //@ float fAngle = ((float)Math.atan2( x, y )) *
> 57.295779513082320876798154814105f;
> //#endif
> if ( fAngle< 0.0f )
> return fAngle + 360.0f;
>
> return fAngle;
> }
>
> Here is another one. The math function is in two different packages.
>
> //#if PLATFORM_BLACKBERRY
> omega = (float)net.rim.device.api.util.MathUtilities.acos( cosom );
> //#else
> //@ omega = (float)java.lang.Math.acos( cosom );
> //#endif
>
> > And that includes the use here -- of selecting what code to run. For
> > that, often the solution lies in correct modularity of the program.
>
> > Trust me -- littering your code with conditionals does not improve it.
>
> Actually laying down some surgical preprocess strikes within my code has
> allowed me to finish the project without having to create more code that
> I would have to manage and pay for at run-time.
>
> --
> Leigh McRaewww.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
