https://kotlinlang.org logo
Join Slack
Powered by
yeesh. view models have ruined what should otherwi...
# android
j
yeesh. view models have ruined what should otherwise be a trivial operation.
👍 4
😂 8
🙃 8
➕ 1
😃 2
g
Wait, how bad must be the rest of the system if it's still an improvement?
j
Is it an improvement? Doesn't look like it to me.
g
I was sarcastic, but for what it's worth you don't have to manually juggle retained headless fragments now, lol. That doesn't change the fact that it's one big jenga of piled hacks.
j
Oh compared to that, sure. I also don't use fragments. But was it really too much to ask for a simple key/value store that doesn't require subtyping or this provider nonsense and doesn't have a ridiculous name like "view model"?
➕ 8
g
Genuine question, how would you name it? Do you think they went too far with assumptions about client's architecture with this name? (MVVM, I suppose.)
p
Whats your problem with aacs viewmodels? @jw
j
I stated it already
@ghedeon don't have a good name. lifecycle store maybe?
now whenever i say "view model" i have to make sure and qualify that i'm talking about the extremely useful pattern which i recommend and not the hashmap sent through non-config instance which i don't
😆 3
➕ 3
r
Lifecycle store aka Redux for Android 😅
j
I'd name it NonConfigHashMapWhereTheyKeysAreClassesAndTheValuesAreSubtypesBecauseWeLoveInheritenceOnAndroid
🙄 1
➕ 1
😰 1
🤣 20
that would also be the package name
r
thank Goodness your not in charge of naming conventions😂😂
😂 3
I actually dont mind the naming lol. But I do wish they would have found a better because assembling and injecting it can be a pain.
j
it's not a view model. it's like if they wrote a service locator and called it dependency injector.
oh wait, it is a service locator
🤣 5
r
😅
Bwhahhaha
I think it was just to promote MVVM . So in essence, they want you to take it as a Base class , rather than naming it the underlying component
Atleast that's my guess. They want uniformity in how people use it. And naming it in that manner subjectively pulls you to a certain architecture
j
I wouldn't mind if they also weren't trying to remove the non config instance as well. I don't mind them being opinionated even if they're wrong, just don't shove your bad opinions down everyone's throats by removing existing mechanisms we already have
➕ 2
😂 2
r
@jw aren't you at Google. These are your teammates your talking about😂
I mean but you still got to admit. The ecosystem is much better than what we had before.
j
So? I don't become a cheerleader for everything Google because I'm employed there. Half the AndroidX libraries shouldn't be AndroidX libraries and most of the architecture components I don't like
👍 8
👌 1
AndroidX is a home for solutions to problems that Android invented and they keep doubling down on them instead of fundamentally blowing things up and fixing them properly
🤔 1
😂 4
➕ 12
Also fuck GMail. Inbox is so much nicer.
👌 18
🏆 1
➕ 19
✔️ 14
🍪 3
🔥 11
👍🏼 28
🤘🏼 15
😍 16
😀 1
💯 22
❤️ 19
👍 5
r
You would rather them release breaking changes
Wtf bwhahahha
😅
j
No. Just abandon libraries like they abandon framework APIs and build new ones.
🔥 3
No one should have been using fragments past 2014.
r
Really , so you dont like the whole Single Acticity with navigation component
j
oh i've been doing single activity since 2013 but you don't need fragments for that
r
What are you using than custom views
j
i've built about 5 different presenter/controller/component/whatever systems
they don't really require a ton of work
and when one sucks, you take the failures and build a new one. you don't double down year after year on a bad one
👍 4
r
Yea , I guess the fact that fragments have lifecycles to can be a pain. So do you feel they got anything right lol. Databinding, workmanager , livedata?
d
Even the upcoming soon to be released navigation?
r
I dont know I'm happy that they have been trying to improve the ecosystem... because a few years back android was rough
j
I haven't looked at it in months. Last time i checked they weren't exposing programmatic mutation of the backstack which means it's entirely a non-starter for me
don't like live data. far too simple of an abstraction to be useful. and the main thread confinement means composition on background threads doesn't work.
➕ 4
don't like databinding. you can code gen view bindings which is what i'm working on but the binding logic shouldn't be shove into xml
➕ 7
haven't used workmanager. i rarely need anything other than job scheduler.
r
Bruh, I think you just hate Google, at this point. You even hate gmail😂
👍 1
d
Inbox is much nicer. Not sure why it's being discontinued.
j
GMail was great in 2010 but someone should have told them to keep innovating. Then Inbox ate their lunch.
r
But to argue databinding has helped to remove a absorbent amount of 3 liner methods.like setVisible , setText, set anything on a view lol
j
sure but then you start putting business logic in there which goes untested and deviates across platforms instead of having a strong view model (not the library, the pattern) that can ensure consistency
💪 1
i lived that terrible life in XAML for 4 years. never again.
👍 7
☝️ 2
r
But your business logic is contained in the viewModel which is testable and than databinding only needs to reflect what's in your viewmodel.. So you can Unit test the viewmodel and espresso test the actual View
g
Love this thread. The only thing missing is to say something about diversity hiring at Google or similar shit and that's how you get fired in 2019 😆. Jokes aside, you can't deny that it's all fucking true. Databinding is definitely a failure, Livedata is a retarded kid of a pathetic rx attempt and Workmanager is maybe good, but we'll never know because fool me once with AsyncTask, fool me twise with Loaders... After so many years, I guess I just need to give myself a reality slap, move to Scrum Master/Jira Board Evangelist or something and let the naive youth to fall on this android sword.
😂 19
🤣 4
👍 11
r
Bwjahahahhahahahaha you guys are wild😂😂😂
m
the biggest benefit of 
ViewModel
the class imo is the ease in retaining state across config changes. do you just handle destructive lifecycle callbacks manually?
j
No. I use the non config instance available since API 1
And their whole argument is that view models enable composition which i like but don't call it view model and don't require subtyping. Just make it a simple map from class to instance and call it something reasonable and move on. Instead we get a conflation of retaining instances and also being a factory and also knowing about context
r
Yes I def agree with the subtyping. They could have simplified it
j
Not to mention that we wouldn't need this whole system if we decoupled our presentation layer from the activity and the activity just observed view models (pattern, not library)
m
the non config instance?
➕ 1
r
Lol one thing they finally got rid of is Instant Run , as of android studio 3.5 Canary ... well greatly refactored it....
Still doesnt work the best. But it's not as broken as before lol
j
Activity.onRetainNonConfigInstance
It's the mechanism which view model is stealing from us to push their subtyping and totally-not-a-view-model agenda
c
Ah this thread makes me feel like a sane person again. Thanks.
✔️ 7
➕ 8
😅 3
s
Thank you Jake for sharing your honest opinion on that topic. Many devs are blindly following what Google says to use, no matter what the arguments against are. Maybe your opinion will make it more easy to stand against all this aggressive pushing of AAC
m
Great to know other's feel similar. Also, I will use Inbox to the hour they shut it down.
✔️ 5
👍🏼 3
🤘🏼 4
❤️ 7
➕ 10
👏 5
a
I gave up on the whole "it's not a view model" thing long time ago. Use it if you like it. Don't if you don't. It's no big deal.
d
I use the 
ViewModel
AAC as the, object that doesn't get destroyed when Android goes to crap (rotations...etc). It holds a single observable state object and get's the system that handles everything else injected into it.
b
Suddenly I am not so crazy after all. Appreciate the honesty.
p
Now that we are talking... Am I the only one who finds the paging library totally awful?
👍 1
👌 6
n
@jw I'd love to see an app you've written, do you have any that are public? I'm very curious now
➕ 2
j
Nothing with significant architecture on one platform. I've been playing with multiplatform architecture though
d
@jw How do you think view navigation should be done with multiplatform projects? Or do you suggest keeping the common stuff more about business logic?
a
@Paul Woitaschek It’s kind of nice, but not really 😛 Recently, I was surprised to see that you can’t use it to implement “scroll to load more”, because the library assumes you want items to load automatically
p
Before I could just pass lists to my view and have it render it. Now I have lists that contain business logic which know where I'm scrolling and which can't be unit-tested. It completely conflicts with how I write code
a
One more thing, they don’t really support inserting headers between list items…
s
onRetainCustomNonConfigurationInstance is deprecated
nice move android team
😄
d
I agree with All of Jake’s points, but I have to admit that I still find them handy. Purely due to the system retaining them after view destruction.
a
The only thing I have issues with is the "business logic" argument. Logic used to adapt existing data to something the view needs is not business logic. Getting data from an api is business logic. Calculating values is business logic. Producing a bunch of statistics for a graph is business logic. Making a call to fetch data from within an aac view model, when done properly, is not business logic. It's simply a call across a boundary interface for something else to do the work. That said, I do see Google examples that violate SOLID and in particular DIP. And to me, that's more irritating than whether or not someone prefers one method of handling device rotation over another.
d
@Al Warren Well put!
r
@Al Warren I have to disagree. The components that google provides doesn't violate the solid prinpal. Perhaps the different ways in which people used them does, but the component themselves do not
a
@rkeazor I'm talking about an example app.
"That said, I do see Google examples that violate SOLID..."
r
Which example are you referring to Because there are alot of them?
a
Not worth discussing really. There was a disagreement in another thread about whether a ViewModel should access R properties. And I found an example that did that. Can't remember which one at the moment.
I didn't mean to infer that components violate SOLID>
r
yea that is annoying actually lol... I have even argue that argument at work before. The main disadvantage is evident when you have to write tests for the Viewmodels, and you realize that all android left you with is stubs, and you have to mock out everything or use roboelctric lol
💯 1
Gotcha, i misread. Figured you were talking about the components themselves, Since the thread is focused on the components
Its good to see this thread is still alive though 😂 . My stance is still pretty much opposite of everyone else, I am actually happy with Jetpack components. The ecosystem has really improved. I mean I remember a time when people where creating headless fragments just to retain state via configuration changes. Life was much darker in those days.
a
I'm pretty out there myself. But I'm retired and have lots of time to sit around and think about this stuff and experiment. I wrote a blog post the other day about MVVM. By the time I finished typing up my thoughts, I managed to convince myself that MVVM is just the UI architecture and that the underlying architecture of Android apps is MVC. 🤣 https://ntxdroid.com/mvp-mvvm-conundrum
2 Views
Open in Slack
PreviousNext
Powered by