I just started using the LVL also. I had problems adding a reference to the LVL project (I kept getting manifest errors immediately upon adding the reference) so I just added it directly. Then, I tried to buile the sample code into my project but I find it all very "clunky". I think it is absurd to not take the time to build methods and properties that automatically can set obfuscation properties, obtain device Id, make a call to do the validation and such. Having source code is mice but they really should have made this quicker to implement with the option to customize and do more with it or to not and take a simpler approach. I was so looking forward to using this but am sorely disappointed. There is a competing android market with a much better licensing implementation, by the way.
On Jul 29, 2:06 am, Mark Carter <[email protected]> wrote: > 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
