You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Nop. We can add it :)
But instead of a new annotations, I think it would be better to add a features field in @EActivity and mark @NoTitle as deprecated
After some time using @WindowFeature, I agree... It was a mistake and we should add an annotation for each WindowFeature.
Also, I think we should add a Feature prefix on theses annotations. ADYT ?
Guys, how many annotations should there be? I think, @WindowFeature is complete functionality. Adding additional @Features that differ only in a few lines of code trashes the API. @DayS , what mistakes did you learn on using it? I can imagine, that there are 7-10 annotations before each Activity, and I'll tell you, it seems to me awful. Of course, the propose of the lib is to remove boilerplate code, but by removing, it makes new.
Off topic. I am watching the progress of the lib almost for 4 years, and telling you honestly, the last changes for about half a year or more make me sad. The lib hasn't grown in a monstrous creature, but on its way in adding every few mirror of Android code in annotations. I see, that a lot of features are accepted even without analyzing of their usefulness in global sense. Thats IMHO, of course. But guys, can be more strict?
Missing old good days... Peace :)
However i do not think you are right about the off topic. To prove myself I just read the commit logs, as you can see almost no new annotations are added in the period you are talking about.
@WonderCsabo Also, you can see the number enhancements to be implemented. If even half of them would be implemented, the library will be much more complex than native Android code. Also, note the existing PRs.
The library tries to cover all the existing problems of Android framework but in a limited way, where some more specialized solutions exist. So, whats the goal now, to reimplement everything?
Don't you think, some cleanup is needed? And some features to focus, for sure.
Maybe I exaggerate, but the message to think, you've heard.
I think @WindowFeature correctly covers this case, so we can close this issue.
@naixx since this is an open source project, you can have your oppinion about every single issue/PR. If you think something is not needed, just tell it! :) Also it seems we will have a plugin system soon, so we can split the library.
Activity
DayS commentedon Jun 5, 2013
Nop. We can add it :)
But instead of a new annotations, I think it would be better to add a
featuresfield in@EActivityand mark@NoTitleas deprecatedJoanZapata commentedon Jun 5, 2013
I don't like
@EActivitybeing yelling at us. 👎DayS commentedon Jun 5, 2013
Maybe a
@WindowFeatureannotation then.@WindowFeature({ Window.FEATURE_NO_TITLE, Window.FEATURE_INDETERMINATE_PROGRESS })I'm not a big fan of creating an annotation by feature for two reasons :
JoanZapata commentedon Jun 5, 2013
You convinced me. ;)
I like this one.
Handle new annotation WindowFeature. See issue #614
JoanZapata commentedon Jun 5, 2013
Nice, thanks!
mathieuboniface commentedon Aug 2, 2013
Hi folks o/
I'm using AA, and i'm seeing this in my generated code :
Constants are made to be used :)
I think this should be fixed.
mathieuboniface commentedon Aug 2, 2013
if this annotation is made to take multiple features, why don't calling it
@WindowFeatures?mathieuboniface commentedon Aug 2, 2013
Just my opinion : Dealing with constants like
Window.FEATURE_*is boring and generates boilerplate code.I would prefer to have one annotation per window feature.
DayS commentedon May 12, 2014
After some time using
@WindowFeature, I agree... It was a mistake and we should add an annotation for each WindowFeature.Also, I think we should add a
Featureprefix on theses annotations. ADYT ?naixx commentedon May 12, 2014
Guys, how many annotations should there be? I think,
@WindowFeatureis complete functionality. Adding additional@Featuresthat differ only in a few lines of code trashes the API. @DayS , what mistakes did you learn on using it? I can imagine, that there are 7-10 annotations before each Activity, and I'll tell you, it seems to me awful. Of course, the propose of the lib is to remove boilerplate code, but by removing, it makes new.Off topic. I am watching the progress of the lib almost for 4 years, and telling you honestly, the last changes for about half a year or more make me sad. The lib hasn't grown in a monstrous creature, but on its way in adding every few mirror of Android code in annotations. I see, that a lot of features are accepted even without analyzing of their usefulness in global sense. Thats IMHO, of course. But guys, can be more strict?
Missing old good days... Peace :)
WonderCsabo commentedon May 12, 2014
@naixx, i agree with you on
@WindowFeature.However i do not think you are right about the off topic. To prove myself I just read the commit logs, as you can see almost no new annotations are added in the period you are talking about.
naixx commentedon May 12, 2014
@WonderCsabo Also, you can see the number enhancements to be implemented. If even half of them would be implemented, the library will be much more complex than native Android code. Also, note the existing PRs.
The library tries to cover all the existing problems of Android framework but in a limited way, where some more specialized solutions exist. So, whats the goal now, to reimplement everything?
Don't you think, some cleanup is needed? And some features to focus, for sure.
Maybe I exaggerate, but the message to think, you've heard.
WonderCsabo commentedon Dec 23, 2014
I think
@WindowFeaturecorrectly covers this case, so we can close this issue.@naixx since this is an open source project, you can have your oppinion about every single issue/PR. If you think something is not needed, just tell it! :) Also it seems we will have a plugin system soon, so we can split the library.