Hi Greivin,
if you look into the 1.6 Android framework source, you see that
telephony.gsm.SmsManager is only a proxy for telephony.SmsManager.
So if you start a SDK 1.5 app on 1.6 it automatically (indirectly)
uses the telephony.SmsManager with all it's features.
Here's the snippet of the
Thank you Mark. It sounds very interesting!, specially the JavaPP link.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to
In a perfect world you would be right about @Deprecated - but I have
seen an example in the 1.6 SDK where a method has been @Deprecated
with the 1.6 release, along with some nice comments on how to do
things the new way, only to find that in this case @Deprecated
actually means the method has
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
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
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
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
jotobjects I'm going to try what you suggest. It seems more like what
I'm looking for. And also let you know what was the result. Thanks.
With conditional compilation I refer of something more like an
attribute that let you tell the compiler to either use one method or
another.
I would like to
Greivin Lopez wrote:
jotobjects I'm going to try what you suggest. It seems more like what
I'm looking for. And also let you know what was the result. Thanks.
With conditional compilation I refer of something more like an
attribute that let you tell the compiler to either use one method or
Deprecated classes and methods still work but they are a notification
to developers that they will be dropped eventually so new code should
not use them and updates should stop using them. There should be a
compiler warning if you use an @Deprecated method and it should show
as deprecated in the
I have a question related to backward compatibility in Android. My
applications uses SmsManager class that was deprecated in SDK 1.5 and
moved to other package in SDK 1.6 to support CDMA. That's OK.
The problem is I want to support 1.5 SDK and also being able to use
the new SmsManager class. I
I haven't tried using a deprecated class in 1.6 - is it marked as
deprecated, and the compiler refuses to process it? There is a
compiler flag for that. Or is it gone completely?
You need to consider the way the JVM works. The class manager will not
load a class until it is referenced (in ANY
Thanks Mike.
Your answer was very useful. I think I'm going to keep a version
supporting CDMA and another one for GSM. At least until new CDMA
Android devices reach the market.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
There's also a great article on the developer blog about using newer
API with an old target:
http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html
I'm extensively using 1.5 features in my app while still maintaing
compatibility with 1.1. The key is to set the
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
to turn off compatibility code that would otherwise be run for an
Thank you both for your answers! They are both very good and I'll keep
them in my back pocket.
I have decided to abandon API 2 and set minimum to API 3. I don't
believe there is that many 1.1 phones left out there.
Strangely after I did that my downloads went up rapidly. It's probably
unrelated
Every time you update your app, it will show on top of the what's
new lists, so a lot of people discover it and download it.
Some people may try to game the market and push regular updates just
to benefit from that spike. However, many users hate constant updates,
so expect lots of too many
Mike,
thanks for the insight.
No, I would never game the market like that, but it's good to know how
the things work.
On Oct 8, 1:15 pm, EboMike ebom...@gmail.com wrote:
Every time you update your app, it will show on top of the what's
new lists, so a lot of people discover it and download
You can use any newer XML attributes, and they will be ignored on older
platforms. So just specify the appropriate attributes for the IME for the
newer platforms. (And also be sure to still test on older platforms, if you
really care about that. I don't think there are a ton of devices left at
Just to make sure I understand you correctly, I set the API level in
my app to 3 and when someone runs it on Android 1.1 the attributes
will be ignored?
Because when I keep the API level at 2 the project will not compile
(at least in Eclipse).
On Oct 7, 10:13 am, Dianne Hackborn
If you set it to 3 it won't be installed on older devices. I don't know
enough about the dev tools to help with compiling problems there (especially
without even seeing the error message).
On Wed, Oct 7, 2009 at 10:18 AM, gnugu rho...@gmail.com wrote:
Just to make sure I understand you
21 matches
Mail list logo
