Can somebody explain what this means? "the platform should not perform any extra work to maintain forward- compatibility with the target version." "Specifying this target version allows the platform to disable compatibility settings"
Is it install time or runtime? What exactly are compatibility settings? Thanks. On Oct 14, 10:18 am, jotobjects <jotobje...@gmail.com> wrote: > Also 1.6 introduces android:targetSdkVersion, which allows you to say > the > higher version of the platform you are designed for, while still > leaving > android:minSdkVersion to the minimum version you support. This allows > you > > Hi Greivin - > > From looking at the 1.6 reference docs it appears that BOTH classes > exist in 1.6 (API level 4). > > android.telephony.SmsManager > android.telephony.gsm.SmsManager > > In that case you should (hopefully) be able to use Dianne's suggestion > of setting > > android:targetSdkVersion="4" > android:minSdkVersion="2" > > Then you have only one application built on Level 4 that uses > reflection to still work on Level 2. Actually the targetSdkVersion=4 > doesn't seem to be REQUIRED, but the documentation implies that your > app will be more efficient when run on Level 4 (SDK 1.6). > > BTW - in this case the Deprecated classes are correctly designated in > the API docs for 1.6. > > On Oct 14, 9:08 am, gnugu <rho...@gmail.com> wrote: > > > Greivin, > > > If you had conditional compile you would have to compile two versions > > of your application anyway, wouldn't you? So your users would be > > equally confused as if you maintained two versions of the code. > > > Maintaining two versions of the code isn't that confusing. In fact I > > personally think conditional compile can mess your code much more than > > having two source trees. Look up "Subversion Book" on the net. That's > > where I learned about maintaining multiple source trees. > > > I think your best option is reflection. I think you missed the fine > > point in EboMike's response. He said that the class is loaded only as > > needed. > > What I took from that is: > > Make a wrapper class that will use either 1.5 or 1.6 version of API at > > a time, but not both (avoid static variables...). > > Once and only once when you start the application probe for the API > > level and keep a global variable alive that will tell your wrapper > > class which of the two API's to use. Reflection only happens once when > > probing for API level. And may be Android will tell you API level > > without reflection... > > > On Oct 14, 8:03 am, Greivin Lopez <greivin.lo...@gmail.com> wrote: > > > > Thanks to jotobjects and EboMike for their responses. > > > > I will try to describe my situation better: I have an application that > > > send SMS messages by using SmsManager class. In the SDK 1.5 version of > > > the application (I mean I set 1.5 as the Project Build Target) > > > everything works fine because I use the SmsManager class located at: > > > android.telephony.gsm.SmsManager which does only support GSM. > > > > When i try to create the SDK 1.6 version of it (Setting the Project > > > Build Target as 1.6) it does not compile because the SmsManager class > > > was moved to android.telephony.SmsManager (which is ok because it now > > > supports CDMA). But then my codeshouldbe changed if I want to > > > compile using the new SDK. > > > > ======================================= > > > My desired solution is: Use conditional compilation to mark my code to > > > use one of the SmsManager classes depending on the SDK I choose as my > > > project build target. Encapsulating this logic into my own SmsEngine > > > class so everything in my code works smoothly and supporting 1.5-1.6 > > > firmware devices and also supporting CDMA in the devices that use > > > 1.6. Without the need to change my code further than a simple > > > conditional compilation. > > > > Problem: As EboMike says there is not such thing as conditional > > > compilation in Java (because Java gurus claim there is not need to > > > such a thing). I personally believe that in the fantasy world were > > > nobody fails designing their APIS the though "Nobody needs conditional > > > compilation" is valid. But nobody is perfect and all the APIs out > > > there in every platforms contains design errors or changes in future > > > designs that leads to the need to improve!. > > > ======================================= > > > > ======================================= > > > My current solution is: Keep my project build target as 1.5. > > > Supporting 1.5 and 1.6 devices without any changes in my source code. > > > > Problem: My application does not support CDMA Sms messaging. I can't > > > benefit from new improvements of performance or bug fixes for the new > > > 1.6 implementation of the SDK. > > > ======================================= > > > > ======================================= > > > Possible alternatives: Keep two releases of the application, one for > > > 1.5 and another one for 1.6 supporting CDMA. Use reflection into a > > > wrapper class to identify which of the firmware I am running allowing > > > me to decide the implementation to use. > > > > Problem: Neither alternative convince me. Two releases can confuse my > > > users. Reflection is too expensive in performance and also does not > > > makes my code clear (It scrambles the source code a little). > > > ======================================= > > > > Until there is aren't 1.5 firmware device out there I suppose I > > > couldn't resolve my problem. > > > > Thanks for your help everyone!. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
