It would create a dependancy loop: * the app code requires R.java to be generated * the R.java generation requires the XML to be scanned * the XML @java would require the app code to be scanned
Maybe you intend the XML to be scanned twice, with two different sets of rules as to what is allowed to be broken on each pass, such that nothing broken slips through the two passes. On the first pass, find @+id kinds of things to add to R.java; on the second pass, find @java kinds of things to validate the code. All of the rest of the XML DTD rules would need to be covered on at least one of those passes. That kind of duplicity is very error-prone and troublesome. On Jan 26, 12:14 pm, mkh <mike.hana...@gmail.com> wrote: > One example from an AndroidManifest.xml: > > <provider android:name="NotePadProvider" > android:authorities="com.exampl.notepad.provider.NotePad" / > > > > This deliberately includes a typo that cannot be flagged by an IDE > because it is just a string. > > Instead as an enhancement, why not define "@java/" to be a reference > to the a public static final, then the above becomes: > > <provider android:name="NotePadProvider" > android:authorities="@java/ > com.example.android.notepad.AUTHORITY" /> > > Now an IDE can provide completion on these @java variables, and the > IDE can also immediately flag undefined references. Also, the > definition of the authority string can be changed in one place, and > the code does not break. > > Is there any reason this would not work -- it seems like the benefits > offered are significant. -- 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
