> > well, coming from someone (me) who read the docs but didn't adopt macroid, >> I thought the docs were great. >> > > Thanks! You are more than welcome to elaborate why you did not adopt it > though ;) > > >> A short paragraph or two of a high level overview of the implementation >> before diving into the samples would be nice. >> > > I guess recipes have higher priority for now, but it would be interesting > to see what aspects of implementation you are interested in (performance is > different from implementation, as it has to be substantiated with > benchmarks). >
You're right, talking about performance implies benchmarks. I'm not promoting some set of microbenchmarks are needed here to be clear though. My knowledge may be outdated but as I recall, xml templates are parsed to a binary format during app packaging to speed up loading of a layout during runtime. So an example question I had was, on orientation change, is what's generated by macroid inspecting the view configuration and responding live in the app by generating a new viewgroup or does it cache all the possibilities in memory and return the appropriate one or does it transpile to xml to take advantage of any tooling benefits, or so on. > > I vaguely recall something about it using ?compiler templates? somewhere >> in the docs. Sorry, there's still plenty I'm not familiar with in scala. >> > > Do you mean macros? That’s the closest thing I can think of. They don’t > affect performance, as the expansion is done at compile-time. Anyway, > speaking of performance, this is clearly not my primary concern :) There is > some wrapping going on here and there, most notably everything is wrapped > into UI actions, and a <~ b is turned into > TweakingOps(a).<~(b)(someTypeclassInstance). I haven’t observed any > significant “snappiness” degradation, but again, somebody might want to > benchmark this. Overall, Macroid should be reasonably close to the vanilla > Java API. Obviously it’s not a good idea to use it for modern game-dev :) > Right, macros. I've been needing to read up on that to tidy up a managed event trait I wrote that makes broadcast receiver and content observer use more orthogonal across activities, fragments, and custom views. My concern again comes around in the implementation. I'm working on some fairly mid sized projects and memory is already a concern, so if I have 184 layout files (b/c I do just looking at this one project now), I'd want an idea of what to expect based on at least a simplistic understanding of the implementation. I'd actually like to use something like macroid b/c on this particular project, I can't use certain resource qualifiers due to the target devices. Do avoid dup layouts, I soft link locally but that's a bad approach. > > >> But my main concern was the implementation and runtime performance. >> Admittedly, I don't want to type tilde a lot either but that's more of a >> minor note. >> > > Not sure if you saw this coming, but could you suggest any alternatives to > tilde? I’m happy to introduce aliases. > I didn't see that coming, no :) If I'm being honest, I should probably just suck it up. Most of the scala community doesn't seem to have a problem with such things or even using unicode characters in place of things like -> or => or even the stuff i've seen in scalaz. > > Nick > >> -- > You received this message because you are subscribed to the Google Groups > "scala-on-android" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "scala-on-android" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
