btw - will the JetNews app (which seems to be the ...
# compose
k
btw - will the JetNews app (which seems to be the most complete example out there) be getting updated to dev04/dev05?
i
Well, it is still Developer Preview.
k
understood - but I've found it super handy to refer to when trying to play with compose in my app and it would be a good reference when (for instance) I'm trying to figure out why AppBarIcon doesn't look right in my case.
a
check the
develop
branch, it's been brought forward a bit already
it's been the topic of some debate and discussion. It's not realistic to keep the -devNN cadence we've set up and bring all of the supporting materials along completely in sync at each one, so then there's the question of where to balance it
one thought is that perhaps we shouldn't update any samples unless we completely rewrite them from spec each time; since the APIs are changing so much at the level of recommended idioms, it might result in samples that look like they've been run through google translate too many times if they're updated for mechanical API changes and not for structural recommendations
👍 1
not sure we have any firm decisions yet
m
@Adam Powell is the Kdoc following the devNN releases ? https://developer.android.com/reference/kotlin/androidx/ui/layout/package-summary
It still has FlexRow/FlexColumn so I guess not ?
i
FlexRow and FlexColumn no more in
dev04
afaik
m
I think they're deprecated but still there ?
In all cases, my point is: I understand it's a lot of work to maintain samples and codelabs while doing big API changes but kdoc should be automated and always up-to-date.
👍 1
i
yes true I think so
a
Thanks for the feedback. 🙂 The discussion on that part has been on whether the kdoc on dac should be consistent with bleeding edge or the most recent codelabs+samples
m
I see... Ideally, being able to version the hosted kdoc while APIs are evolving would be nice:
/reference/dev-04/kotlin/androidx/ui/layout/
, etc... But that might not be easy
a
It is very much not easy 🙂
😀 1
c
demoting the existing version to a feature branch and redoing it would be great, even better would be doing that in a whole series of commits that people could inspect… would that really be that bad? jetnews does not do that much…
a
Just a question of opportunity costs. Is updating existing samples vs. rewriting them more idiomatically faster and would it mean being able to write more samples and codelabs and tutorials on more compose-related topics? Maybe.
m
In all cases, please remove obsolete content or mark it clearly as deprecated. It's quite frustrating to spend some time looking up some help then trying to understand it just to realize it's outdated 😕
1
a
@nickbutcher you would probably find this thread interesting if you haven't seen it already 🙂
c
@Adam Powell but I think you are missing my point: when a new release drops, I don’t know that some thing has been ditched in favor of something else. If I can see a commit that says ‘updating the layout fill mechanism,’ I can see some examples of porting the code… which is good…
👍 1