Skip to content
Toby Kurien edited this page Jul 31, 2014 · 20 revisions

TODO before release

  • Deprecate field-level annotations in favour of class-level annotations? Discuss
  • Update all unit tests, documentation
    • @JsonProperty
    • @AndroidParcelable
    • @AndroidFragment
    • @CustomView(Group)
    • @AndroidAdapter
    • @EnumProperty
    • @AndroidLoader, BgLoader
    • @BundleProperty
  • Create an example app demonstrating all of this stuff (e.g. Property cross), bonus: it talks with a real json back end, so the efficacy of @JsonProperty can be demonstrated.
    • It's actually much better to have lots of small samples (like with Android's APIDemos), so that it's easy to see how each feature is used independently, without having to look through the code of an entire app.
  • Discuss @OnCreate vs. method signature matching (lifecycle methods are filtered out) (i.e. if method has one parameter, that is a Bundle, that is not named after a lifecycle method, then plug into Activity#onCreate or Fragment#onActivityCreated or Fragment#onCreateView, reference: @CustomViewGroup)
    • (Toby) My view is to still use @OnCreate as it leaves us with a choice of adding other lifecycle interceptors in future. It also allows us to use @OnCreate anywhere (even services, etc.) in future without dev having to worry about exact method name.
  • Discuss @AndroidView (since AnnotationLayoutUtils does everything already, if the layout is declared)
    • (Toby) Happy to deprecate this annotation
  • Bonus: give point-by-point example why Xtendroid rules and DI frameworks like RoboGuice, Android Annotations, fair less.
    • (Toby) I have a whole section of documentation planned out called "Design patterns" which will include discussion of DI as well as FRP, etc. I'll start the docs (in the dev branch) and you can add to it.
  • Refactor out expression getting methods to AnnotationLayoutUtils(?) from
    • @Android{Activity, Fragment}
    • @CustomViewGroup
Clone this wiki locally