Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 16 2016 12:10

    graknol on master

    Proof of concept (compare)

  • May 10 2016 22:38

    graknol on master

    Update README.md (compare)

  • May 10 2016 22:37
    graknol closed #1
  • May 10 2016 22:35

    graknol on master

    Modifications Merge remote-tracking branch 'o… (compare)

  • May 10 2016 22:34

    graknol on master

    Update README.md (compare)

  • May 10 2016 22:34

    graknol on master

    Update README.md (compare)

  • May 10 2016 22:33

    graknol on master

    Initial commit (compare)

Lalit Maganti
@tilal6991
@g
The comment ties in with the idea of composability + context I think
Sindre Tellevik
@graknol
Yes, and I kind of find what he mentioned more or likely summed up what I want to achieve
Composition and easy extensibility
Sindre Tellevik
@graknol
I'm reading through the Kotlin reference, once more, to make sure that I know about anything which will make this library nice and simple :) Such as sealed classes, perhaps they'll be of use ;)
Sindre Tellevik
@graknol
I'll be working on this on the side, as I've possibly just gotten a "client" who needs an Android AND an iOS app by november, so I'll be busy doing that, but I'll still continue to explore new ideas!
Lalit Maganti
@tilal6991
Sounds good :)
Sindre Tellevik
@graknol
One thing I'm fiddling with right now, is the use of completely normal View objects, but compare them using equals to check if they've changed since last render
Lalit Maganti
@tilal6991
I'll start exploring stuff after I finish exams
Sindre Tellevik
@graknol
sounds good :)
Sindre Tellevik
@graknol
hmmm
this could work
Sindre Tellevik
@graknol
we could keep the existing convenience functions like size gravity etc, and implement the basic ones in the code, and if they can't cast it to the right layoutparams, then we loop through a list with functions which can process a given convenience function
that way, we can keep the cleanliness of the dsl, while still allowing the support libraries and possibly custom libraries to provide "middleware"
Also, this allows for total transparency when dividing the code!
Lalit Maganti
@tilal6991
@graknol do you just mean a list of instanceofs?
I did think that would be an option but seems a bit ugly
But I guess it makes the frontend much prettier
Sindre Tellevik
@graknol
yes indeed, that's what I mean :)
plus I strongly be
believe that the JVM easily optimizes the if statements away, so there's no overhead either
Sindre Tellevik
@graknol
My current plan is writing the base classes over again (Anvil.java, etc), adding some functionality (keeping the function based DSL). Then write a buildSrc module which uses reflection on the android.jar and generates DSL classes (not that hard when you don't write a generic library)
the current implementation supports attribute functions with multiple parameters too, so no missing out on functionality!
Sindre Tellevik
@graknol
Ok, so I've identified the biggest challenge which Anko doesn't have to deal with, and that is:
  • we have to wrap each View class with custom methods if we are to do it react-ish
  • which means we need to do multiple inheritance and inherit every function (even lparams, which means we can't differentiate between different LayoutParams because of signature and override)
  • Anko does this across the whole DSL --> _RadioGroup : android.widget.RadioGroup { } because they dont have to wrap any functions, only a few, thus they can define different lparams too (since every View class has nothing in common)