When you target P or anything not a released versi...
# android
k
When you target P or anything not a released version, it's always been painful. Don't do it unless you have to
βž• 2
c
Few more hours of messing around with the preview convinced me its a thankless waste of time. Generating projects, they don't even run, before I have added a lick of my own code. Jesus build is still a raging dumpster fire all these years later.. complaining about already having seen certain classes, because different app compat libs are being dragged in.
k
P is more painful this year if you try the jetpack stuff too. Those templates have never been great FYI... Even when they work, they're not best practice πŸ˜’ Unless you have to use P for development and testing if prerelease features, don't do it IMHO
c
dude the main reason is there will be devices with it in the wild in a few months, would be nice to have a running start, but I am so tired of wasting time on runny eggs.. ugh..
(I have an app in the store, so will get emails about how it doesn't work on P if I don't prepare..)
The templates are absurd, clearly no one ran the one I used (map activity).
πŸ˜‚ 1
k
Yep.. The templates are terrible. The prerelease sdks are always painful... Usually not this bad though... Give it another shot in the next version. I wasted almost a day this week repro'ing and working around what turned out to be "don't use the EAP Kotlin plugin because Google patched the version on stable", so I can empathize. But it's bleeding edge and that's what guinea pigs are supposed to find and report back...
c
what a waste of effort, Apple has become much more stable, and rarely releases junk that's this broken anymore (they used to).. but then, they also get to 80% within a month of a major OS release, a feat Android will probably never match.. just happened to have watched the Fragment session just now, the whole thing felt a little like 'yeah, we didn't really think through Fragments much, and now that we have seen the devastation we wrought, we've retained them just so you won't scream, but there's not much reason to use them anymore....' What a typical, but dark picture that paints.. 'no hurry up and learn all this crap and get up on the wheel and get tortured, then later we'll actually give some thought to how this should have been done and just reduce your hard earned knowledge to a pile of ashes....'
k
lol..how long have you been using Android? That sounds like a cynical veteran's point of view πŸ˜‰ Android can never get to 80% of the latest because carriers and phone makers want you to keep upgrading your outdated phones so they drag their feet on upgrades. Fragments have always been quirky...that's why there were alternatives like Conductor, etc. The nav component goes a long way towards making them less of a "shoot foot off gun" at least πŸ™‚
c
Yeah the nav component looks pretty good. I like Android a lot, but dude if you think I am a cynic, you have seen all the videos where they say that the lifecycle is unknowable and hopelessly complex? It's ok. I am kinda into ConstraintLayout now. Do I need fragments? not sure I do. I am old though. Components, and composable ones, have been a dream for a long time. Fragments sounded like they might deliver that, of course, they didn't.. πŸ™‚
k
I've lived through fragment API quirks too. The nav and viewmodel stuff already has a bunch of hacks to work around the fragment flakiness πŸ˜’ Yes the lifecycle for fragments is crazy πŸ˜”
c
I love the MVP patterns, huge leap forward, LiveData/ViewModel, etc. the new stuff for that this year was nice..
k
MVVM you mean πŸ˜‰ Yeah, being a bit opinionated helps so people don't shoot their feet off πŸ™‚
c
Dude, they are the ones who said MVP right?? oh wait
we're both right.. can I paste a pic in here?
the blueprints have MVP and MVVM versions in K...
k
Yep, the blueprints show multiple ways of doing things. The arch components and data binding look very MVVM to me (though you could use them for MVP as well by using the VM as the P)