Deprecate @View in favor of a new class that doesn't conflict with a common android class name

[ghost]

I am finding myself qualifying my usage of android.view.View all over the place... would you consider adding a new @tview or @ViewRef or something that doesn't conflict so frequently?

This actually might be an issue with a couple others as well.. I feel like we should avoid name conflicts with common core android components whenever possible.

[ghost]

Fragment is another good example.. especially when dealing with the support libraries, you can end up with some nasty qualified class names in your code.

[johncarl81]

I'll consider it, but I do like keeping the annotation names simple and readable... even if you do have to use them fully-qualified from time to time.

[ghost]

Yeah.. I guess it's a style choice.. we just have some pretty complex Fragments that now have quite a few fully qualified references to android.view.View and the support library version of Fragments.. it's a tad ugly... would it be a huge pain/hack to add in some "aliases" that work the same way but don't conflict and just have them all in there? It's too bad Java doesn't support Scala style import aliasing

[johncarl81]

Actually, aliasing could be accomplished... I'll have to think about it though.

[johncarl81]

@dbachelder , this was you right? I'm leaning more in this direction now. I kindof like @TView... should we also change @Activity to @TActivity?

[dbachelder]

Yes, please! Would be great to remove ambiguity with any annotation names that conflict with platform classes

[johncarl81]

what's your preference on naming convention? Prepend with a T (Ugh, I hate to copy Android Annotations here, they prepend with E: @EActivity)? Append a 'Ref'?

[dbachelder]

hah.. prepending a letter is a tradition as old as Java :) Save everyone the typing and go with T prefix.. that's my opinion.