I believe I'm using the default eclipse compiler warning settings and I got a bunch of "unused import/instance variable" warnings in my workspace when adding the LVL project. Furthermore, all the warnings were doubled up - once for the library project at the top level and once for the library project as a child node of my own project.
Since changing the project warning settings was not an option, I solved this by adding @SuppressWarnings annotation at the class level of a couple of the LVL classes. But this is far from ideal as it requires modifying the code (which I will later want to update as new versions are released). Another problem was that when I changed the LVL code (saving the changes), my main project required a "Clean" before it picked up the changes. It would be nice if library project changes triggered clean to all downstream projects (I think this is how things normally work). This problem might have been caused by me editing files in the top level LVL project rather than the child LVL node. Again (mentioned last month in another thread), this is a problem where the same class can appear twice in the workspace (once for the top level, once for the child level). The easiest solution to this would be to NOT make the LVL child node browsable. So forcing the dev to do everything through the top level project. Also trigger the Cleans accordingly. One final point about the LVL code.... I wanted to subclass ServerManagerPolicy but had to make a bunch of instance fields protected to do so. Would be great if they were already protected. Also, ResponseData is package private. This prevents devs from implementing their own Policy in their own package. Since I wanted to make only minimal changes the the LVL project, I just included my Policy class in a "com.android.vending.licensing" package within my main project instead. Still, would prefer to use my own package though... On Jul 29, 3:00 am, Zsolt Vasvari <[email protected]> wrote: > Thanks for your answer, Xavier. > > > $NON-NLS is something specific to Eclipse that we do not use in Android. > > Our convention for the android source code do not enforce the use of > > this qualifier. > > > As for importing java.lang.String, those 2 files have been created > > automatically by aidl (see the files in aidl/) and the tool doesn't > > care about unneeded imports and automatically put import statements > > for all the used classes. > > Ok, fair comment about the java.lang.String import. That said, since > you are recommending to use Eclipse as the development environment, I > think it would be benefitial for everybody if a few minutes taken > before release to make sure it compiles with any possible settings the > user may have in their Eclipse project. If that means cleaning up the > generated code, I believe that should be undertaken. Otherwise you > will end up with aggrevated users. > > Do you honestly expect the user having to modify their project warning > levels to be able to successfully integrate LVL? Perhaphs the answer > is yes, but then it should be documented and spelt out how warning > levels need to be set for the project. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
