[android-developers] Re: Inadvertent breakage by SDK going forward
That would be very 'icky'... I hoped that the 'targetSdkVersion' setting could prevent this. On Feb 12, 7:20 pm, jasper wrote: > Does this truly mean that even if I compile to the 1.6 platform, if my > code implements a 2.1 callback method, that method will *never* be > invoked on 1.6 devices but *will* be invoked on 2.1 devices? Even > though I compiled to the 1.6 platform? That's crazy! > > On Feb 12, 4:01 pm, Mike Collins wrote: > > > > > Ran into the below issue and wanted to see what solutions people > > have... > > > In SDK 1.6 Activity did not have a method onBackPressed (), in 2.0 it > > appeared. > > Using the current docs I added an onBackPressed to a couple of our > > classes. > > We build against 1.6 (customer requirement) it seemed a bit odd that > > the compiler > > got upset when I put in a @Override, so I took it out and proceeded to > > verify that > > everything was working, which it was, the method was being invoked > > exactly as > > expected. > > > Turns out this works only on phones/emulators with 2.0 or greater > > firmware. On > > 1.6 firmware it fails to function at all because nobody calls it. > > > OK, with hindsight it's obvious what's happening and we've made the > > @Override > > an error not a warning. > > > But it raises the issue of how to I protect my app if in the future > > Android implements > > a method that collides with the name of method I invent for my derived > > class. In > > this case Android will be calling my method at inappropriate times and > > expecting > > it to do things that it probably doesn't do. > > > One solution is prefix every method of ours of every class that > > derives from an Android > > class with something specific to the app. Or use a different naming > > convention, like > > always use an initial capital or an underscore etc. > > > thoughts? > > mike- Hide quoted text - > > - Show quoted text - -- 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
[android-developers] Re: Inadvertent breakage by SDK going forward
Does this truly mean that even if I compile to the 1.6 platform, if my code implements a 2.1 callback method, that method will *never* be invoked on 1.6 devices but *will* be invoked on 2.1 devices? Even though I compiled to the 1.6 platform? That's crazy! On Feb 12, 4:01 pm, Mike Collins wrote: > Ran into the below issue and wanted to see what solutions people > have... > > In SDK 1.6 Activity did not have a method onBackPressed (), in 2.0 it > appeared. > Using the current docs I added an onBackPressed to a couple of our > classes. > We build against 1.6 (customer requirement) it seemed a bit odd that > the compiler > got upset when I put in a @Override, so I took it out and proceeded to > verify that > everything was working, which it was, the method was being invoked > exactly as > expected. > > Turns out this works only on phones/emulators with 2.0 or greater > firmware. On > 1.6 firmware it fails to function at all because nobody calls it. > > OK, with hindsight it's obvious what's happening and we've made the > @Override > an error not a warning. > > But it raises the issue of how to I protect my app if in the future > Android implements > a method that collides with the name of method I invent for my derived > class. In > this case Android will be calling my method at inappropriate times and > expecting > it to do things that it probably doesn't do. > > One solution is prefix every method of ours of every class that > derives from an Android > class with something specific to the app. Or use a different naming > convention, like > always use an initial capital or an underscore etc. > > thoughts? > mike -- 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
[android-developers] Re: Inadvertent breakage by SDK going forward
And doesn't this also mean that there's an implicit requirement that I prefix my methods with a tag to avoid future version name collisions? If I have a method in my 1.6 app called MyView.doSomething(), and MyView extends an Android class like TextView, and subsequent to 1.6, Google adds a method to TextView called "doSomething()", my method would overwrite Google's method, even though I'm compiling for the 1.6 platform? If Mike's post is true, then even if I compile with the 1.6 target and run on the 2.1 target, the 1.6 app's method will overwrite the 2.1 method. Therefore, this is an implicit requirement that I should prefix all of my methods with my own tag like myDoSomething(). But I already have hundreds of methods in my app - what a pain. On Feb 12, 4:01 pm, Mike Collins wrote: > Ran into the below issue and wanted to see what solutions people > have... > > In SDK 1.6 Activity did not have a method onBackPressed (), in 2.0 it > appeared. > Using the current docs I added an onBackPressed to a couple of our > classes. > We build against 1.6 (customer requirement) it seemed a bit odd that > the compiler > got upset when I put in a @Override, so I took it out and proceeded to > verify that > everything was working, which it was, the method was being invoked > exactly as > expected. > > Turns out this works only on phones/emulators with 2.0 or greater > firmware. On > 1.6 firmware it fails to function at all because nobody calls it. > > OK, with hindsight it's obvious what's happening and we've made the > @Override > an error not a warning. > > But it raises the issue of how to I protect my app if in the future > Android implements > a method that collides with the name of method I invent for my derived > class. In > this case Android will be calling my method at inappropriate times and > expecting > it to do things that it probably doesn't do. > > One solution is prefix every method of ours of every class that > derives from an Android > class with something specific to the app. Or use a different naming > convention, like > always use an initial capital or an underscore etc. > > thoughts? > mike -- 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
[android-developers] Re: Inadvertent breakage by SDK going forward
Reworking the platform isn't an option...guess that leaves me with some naming convention. thanks, mike -- 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
