To take this a bit further: Platform can be an Enum, that implements
an IPlatform interface, and you can attach methods to BLACKBERRY and
friends to do the platform-specific stuff.
Then this becomes:
Platform.OS.doStuff();
And you don't have to touch it when you add a new platform.
On Aug 3, 6:55 pm, dm1973 <david050...@gmail.com> 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.
>
> 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
