I can see a use case where a library is only used by 2 applications (different versions of the same app really), and the 2 apps provide the same set of constants (with different values of course) to enable/disable features in the library. This would require the library to import a class present in both apps, and would prevent the library code to compile on its own, i.e. it would only compile alongside the apps code.
This is a use case we clearly didn't anticipate, and that will not work with the new mechanism. Xav On Sun, Oct 23, 2011 at 11:21 AM, Brian Conrad <[email protected]> wrote: > Apparently but let me do a test project to see if the proper steps allow > such a reference. Are you saying they still should work? > > On 10/22/2011 07:59 PM, Xavier Ducrohet wrote: >> >> does this means your library would not compile on its own because it >> references something in your activity? >> >> On Sat, Oct 22, 2011 at 6:46 PM, Brian Conrad<[email protected]> >> wrote: >>> >>> By wrapper I mean an Activity that calls your library which is actually >>> your >>> app. This way you can have different project versions like one with LVL >>> and >>> one without for testing, etc. This approach was discussed in one of the >>> blogs. With the merged code I would have a definition in the calling >>> Activity that caused a function section to compile or not. With the >>> library >>> as it is now either you have a definition file in the library or pass the >>> variable to the library jar though then the code is always compiled and >>> gets >>> run depending on the setting. I hope that is clear. >>> >>> - Brian >>> >>> On 10/22/2011 05:42 PM, Xavier Ducrohet wrote: >>>> >>>> Hi Brian, >>>> >>>> Looks like I actually did write some quick migration info here: >>>> http://tools.android.com/recent/buildchangesinrevision14 but I think >>>> most people overlooked the document (it's not just a migration >>>> document, that particular info is kind of buried in there), even >>>> though it was linked from the release notes. Also note that this >>>> documents was published 3 weeks before the release, and we released a >>>> preview of ADT 14 too. >>>> >>>> I do agree that we need to better warn developers of changes. Reaching >>>> them all I think is a tough issue though. We do publish a lot of info >>>> about upcoming changes on our site, we tweet about it, we post on g+ >>>> about it, but I'm not sure how much more we can do. >>>> >>>> As a rules though, a developer who is about to release an app really >>>> shouldn't make any update to his development environment. Maybe we'll >>>> post a warning about this on the release notes. >>>> >>>> Regarding your specific issue, I'm not sure what you mean by your >>>> wrapper? Are those variables java constants? Those constants should be >>>> in the jar file generated and this should impact the compilation of >>>> your app. >>>> >>>> >>>> On Sat, Oct 22, 2011 at 10:23 AM, Brian Conrad<[email protected]> >>>> wrote: >>>>> >>>>> Xavier finally commented on the issues page involving this. Apparently >>>>> they >>>>> planned a migration article but didn't get to it by the release. It >>>>> has >>>>> bitten developers in different ways. One thing I had notice about my >>>>> build >>>>> using a library was that with the release prior to 14 I was getting two >>>>> R.java files, one for the wrapper and one for the library. I was >>>>> concerned >>>>> about problems that might cause but observed that both were the same. >>>>> However in one mention about changes on the developer section ID >>>>> collisions >>>>> were a concern and one reason for the change. >>>>> >>>>> http://code.google.com/p/android/issues/detail?id=20398 >>>>> >>>>> And then there are the different ways that developers use libraries. >>>>> In >>>>> my >>>>> case I was referencing some other source code but not really using it >>>>> as >>>>> a >>>>> "library" in the sense of using the jar file. This was one of two ways >>>>> that >>>>> was previously mentioned in articles on using a library. This allowed >>>>> for >>>>> my wrapper to set some variables then that would cause my "library" to >>>>> build >>>>> a specific version for that release. With this method no jar was >>>>> created >>>>> for the library but the code just merged. I still think this is a >>>>> reasonable method of development but the "merge" system no longer >>>>> works. >>>>> >>>>> With the new method a jar is created. But that means I have to put the >>>>> definition file in the library code and change it every time I want a >>>>> slightly different version of the library (usually only effecting a >>>>> couple >>>>> of functions). They also said they did the jar thing to speed up >>>>> builds >>>>> though I wouldn't have noticed on my multi-core 64-bit machine that >>>>> merged >>>>> code took any more time. >>>>> >>>>> What I think the team learned from this was you can't make such radical >>>>> changes without forewarning developers. Some who needed to issue an >>>>> update >>>>> for their app were burned by this. >>>>> >>>>> - Brian >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups >>>>> "Android Discuss" 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-discuss?hl=en. >>>>> >>>>> >>>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Android Discuss" 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-discuss?hl=en. >>> >>> >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Android Discuss" 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-discuss?hl=en. > > -- Xavier Ducrohet Android SDK Tech Lead Google Inc. http://developer.android.com | http://tools.android.com Please do not send me questions directly. Thanks! -- You received this message because you are subscribed to the Google Groups "Android Discuss" 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-discuss?hl=en.
