4 ms·

Yeah UIKit is deeply MVC. It may not be the most conceptually elegant but in my experience you're almost always better off cutting with the grain of the underly

Yeah UIKit is deeply MVC. It may not be the most conceptually elegant but in my experience you're almost always better off cutting with the grain of the underlying platform's abstractions instead of trying to superimpose a new leaky abstraction on top of them. I worked on one large iOS codebase that went all in on the VIPER architecture and it was one of the most unweildy and baroque codebases I've ever had the misfortune to work in.

ChrisMarshallNY 4y ago
> the VIPER architecture < Takes out a foil blanket. Hands you a flask. >
- emehex 4y ago
  VIPER is horrific at scale. Don't. Just don't.
tarentel 4y ago
I apologize to the people who bought into this pattern but what was anyone thinking? Just reading through how it was supposed to be done set off so many red flags I never even considered it. There is so much useless abstraction it makes no sense.
- ChrisMarshallNY 4y ago
  I think it was designed to break up app development into large, relatively unskilled, teams. The traditional UIKit model (and, I suspect, the SwiftUI model) is for small (maybe single IC), skilled, teams.
- cokeandpepsi 4y ago
  It's sometimes impossible to fight the architecture astronauts, they can be deeply appalled at how software maps to their thinking and wish to bend it towards nonsense until it does
quux 4y ago
Could be worse, they could have adopted RIBs https://github.com/uber/RIBs https://github.com/uber/RIBs
- throwaway1777 4y ago
  Or ComponentKit
- nyanpasu64 4y ago
  One recurring issue I see on native Android navigation is, when you open an image in a file manager, switch back to the file manager and open a second image in the same viewer, sometimes pressing Back takes you to the first image. As a specific example, in Foxy Droid, if you download 3 apps in the background, get 3 "app downloaded" notifications, and click each one in sequence, you have to press Back 3 times to get back to Foxy Droid's home screen. What's the best way to avoid this issue without reimplementing your own navigation system replacing activities?
  - tadfisher 4y ago
    Basically, don't use Intent flags you don't need to use. FLAG_ACTIVITY_NEW_TASK will launch the external activity in its own back stack according to its `launchMode` rules. If you just launch the Intent with no flags, the default behavior is to add the activity to your own task, which is usually what you want. The other half of the equation is: don't override Back behavior unless you "own" the current task (it's rooted at one of your activities). When handling "Up" navigation and deep-links, you want Back to behave like "Up" and go to the logical parent of the current screen. When being launched in someone else's task, "Up" should launch a new task at the logical parent and "Back" should perform the default behavior (usually, Activity.finish()).
  - aaaaaaaaata 4y ago
    Build a PWA =^]
jkubicek 4y ago
> better off cutting with the grain of the underlying platform's abstractions That's a great little turn-of-phrase that I plan on stealing in the future. Apple's APIs will absolutely reward you for taking the time to step back, figure out how Apple wants you to use them, and try your hardest to use them in that way. An example from the olden days of iOS development: many of the apps I worked on went out of their way to avoid subclassing UIView, filling their view controllers with layout and interface updates that would have made much more sense in a view. If only they had read all the docs for UIView would they know that doing something like subclassing a button and tweaking a few methods would have done exactly what they wanted with a minimal amount of work.
bsaul 4y ago
i've been developping for 20 years, and 10 years on iOS as a freelance. I've seen all the horrors, and i can now safely claim that all the problems i've seen on iOS development come from not designing the model layer properly in their MVC app. Because most developers start by coding UIs and later end up wondering where to put that business logic and make it reusable. And now every time i see another pattern that claim to facilitate refreshing the UI upon model change ( and vice versa), i know it's going to be a failure.
JamesSwift 4y ago
UIKit isnt even deeply MVC. Its purely C. The Controller is the god object by design, but also because the first 10 years of iOS tutorials never took the time to even split out a single View. So that became the gateway for everyone learning the platform, and is what they imitated. Its not much better today overall, but is usually not an issue within companies themselves.

ChrisMarshallNY 4y ago

> the VIPER architecture < Takes out a foil blanket. Hands you a flask. >

emehex 4y ago
VIPER is horrific at scale. Don't. Just don't.

tarentel 4y ago

I apologize to the people who bought into this pattern but what was anyone thinking? Just reading through how it was supposed to be done set off so many red flags I never even considered it. There is so much useless abstraction it makes no sense.

ChrisMarshallNY 4y ago
I think it was designed to break up app development into large, relatively unskilled, teams. The traditional UIKit model (and, I suspect, the SwiftUI model) is for small (maybe single IC), skilled, teams.
cokeandpepsi 4y ago
It's sometimes impossible to fight the architecture astronauts, they can be deeply appalled at how software maps to their thinking and wish to bend it towards nonsense until it does

quux 4y ago

Could be worse, they could have adopted RIBs https://github.com/uber/RIBs https://github.com/uber/RIBs

throwaway1777 4y ago
Or ComponentKit
nyanpasu64 4y ago
One recurring issue I see on native Android navigation is, when you open an image in a file manager, switch back to the file manager and open a second image in the same viewer, sometimes pressing Back takes you to the first image. As a specific example, in Foxy Droid, if you download 3 apps in the background, get 3 "app downloaded" notifications, and click each one in sequence, you have to press Back 3 times to get back to Foxy Droid's home screen. What's the best way to avoid this issue without reimplementing your own navigation system replacing activities?
- tadfisher 4y ago
  Basically, don't use Intent flags you don't need to use. FLAG_ACTIVITY_NEW_TASK will launch the external activity in its own back stack according to its `launchMode` rules. If you just launch the Intent with no flags, the default behavior is to add the activity to your own task, which is usually what you want. The other half of the equation is: don't override Back behavior unless you "own" the current task (it's rooted at one of your activities). When handling "Up" navigation and deep-links, you want Back to behave like "Up" and go to the logical parent of the current screen. When being launched in someone else's task, "Up" should launch a new task at the logical parent and "Back" should perform the default behavior (usually, Activity.finish()).
- aaaaaaaaata 4y ago
  Build a PWA =^]

jkubicek 4y ago

> better off cutting with the grain of the underlying platform's abstractions That's a great little turn-of-phrase that I plan on stealing in the future. Apple's APIs will absolutely reward you for taking the time to step back, figure out how Apple wants you to use them, and try your hardest to use them in that way. An example from the olden days of iOS development: many of the apps I worked on went out of their way to avoid subclassing UIView, filling their view controllers with layout and interface updates that would have made much more sense in a view. If only they had read all the docs for UIView would they know that doing something like subclassing a button and tweaking a few methods would have done exactly what they wanted with a minimal amount of work.

bsaul 4y ago

i've been developping for 20 years, and 10 years on iOS as a freelance. I've seen all the horrors, and i can now safely claim that all the problems i've seen on iOS development come from not designing the model layer properly in their MVC app. Because most developers start by coding UIs and later end up wondering where to put that business logic and make it reusable. And now every time i see another pattern that claim to facilitate refreshing the UI upon model change ( and vice versa), i know it's going to be a failure.

JamesSwift 4y ago

UIKit isnt even deeply MVC. Its purely C. The Controller is the god object by design, but also because the first 10 years of iOS tutorials never took the time to even split out a single View. So that became the gateway for everyone learning the platform, and is what they imitated. Its not much better today overall, but is usually not an issue within companies themselves.