cdzombak + mvvm   28

[renaud _lienhart]; on Twitter: <thread> Developing an iOS app in 2018
Disregarding the limited utility of the app for most of you, I’d just like to quickly talk about how developing an iOS app from scratch in 2018 feels like.

First of all, the basic architecture of the app: we use MVVM-Rx layered in modules, and the only couple “real” dependencies we have is RxSwift and RxDataSources. The vast majority of the code is purely functional and reactive. It is a pleasure to read as well as to write.

Secondly, Swift. From Value Types to CaseIterable, passing by Decodable, Generics, Auto-Synthesised E&H conformances, Keypaths and the power of its Enums, Swift has become an essential pillar of the code we write. I love Objective-C, but I would never want to go back.

The Standard Lib is a pleasure to interact with and feels *almost* complete. I just wish its documentation was better, e.g. clearly enunciating the constraints on a Generic Type for a method to become available.

Xcode and LLDB still have some way to go to become reliable. Swiftc’s error messages are still very poor and require a lot of implicit knowledge of the language in order to decipher what the compiler is actually complaining about. The new build system is amazing.

Finally, UIKit and other related frameworks. It is _shocking_ how bad & buggy iOS <11 was. Since then however, the fundamentals got robust and behave exactly as expected. You can (mostly) trust UIKit now, and be confident that any bug is in your code rather than Apple’s.

I wish there were better Swift wrappers around the ObjC frameworks’ interface. Apart from sometimes adding default arguments, there is so much potential that could be unleashed by having access to Swift-only frameworks.

I am very excited by what may be unveiled in 2019.

Overall this was, and continues to be, an amazing codebase to work on. iOS development, thanks to technologies such as Swift and FRP, has come a long way from what it was just a few years ago. You don’t need a boatload of cocoapods anymore. You don’t need a team of 50 engineers to maintain a bunch of dynamic code and the thousands of unit tests it entails.

All you need is a fresh, modern, trustworthy approach to writing apps. And 2018’s iOS provides that.
ios  development  ios11  ios12  uikit  swiftlang  xcode  rx  frp  mvvm  reactiveprogramming  is:tweet 
10 weeks ago by cdzombak
Shades of MVVM | Big Nerd Ranch
Well, if you asked me to choose an architecture pattern up front today to guide my work on a new project, I’d go with the classic binding ViewModel approach. I’ve worked with it a little bit already, and I found it to be a good friend in improving my app’s testability. I’m really interested in integrations with RxJava, though—I’d love to be able to integrate that into my use of data binding somehow.

Even though that’s what I like, though, I do not recommend rearchitecting your existing app based on my recommendation, just because I said it is the “best”. Evaluating architectures in that way is misleading and and often frustrating. You can find opinions like mine easily, but head-to-head comparisons between different architecture patterns with working code are much harder to find, much less compare. The goodness or badness of architecture has everything to do with how your code grows and changes within that architecture, so these snapshot comparisons are almost useless as individual datapoints. That often makes discussions of architecture are extremely annoying.
mvvm  software_architecture  viewmodel  binding  reactiveprogramming 
november 2016 by cdzombak
Binding to a UITableView from a ReactiveCocoa ViewModel
There's a binding helper object which handles much of the logic, and the important part is that for this particular implementation, managing that object that is the VC's responsibility (the VM exposes an observable array of cell view models).
uitableview  uitableviewcell  mvvm  collections  viewmodel  reactivecocoa  reactiveprogramming 
august 2016 by cdzombak
MVVM Architecture Question · Issue #138 · thoughtbot/Tropos
A comment describing the use of MVVM architecture in a given application.
The whole point is to move as much code and logic out from anything View specific. This makes that code much easier to unit test. It can also lead to reusable Controllers and ViewModels.
testing  mvvm  bestpractices  software_architecture 
august 2016 by cdzombak
ReactiveViewModel/ at master · ReactiveCocoa/ReactiveViewModel
Although it seems similar to MVC (except with a "view model" object in place of the controller), there's one major difference — the view owns the view model. Unlike a controller, a view model has no knowledge of the specific view that's using it.

This seemingly minor change offers huge benefits:

• View models are testable. Since they don't need a view to do their work, presentation behavior can be tested without any UI automation or stubbing.
• View models can be used like models. If desired, view models can be copied or serialized just like a domain model. This can be used to quickly implement UI restoration and similar behaviors.
• View models are (mostly) platform-agnostic. Since the actual UI code lives in the view, well-designed view models can be used on the iPhone, iPad, and Mac, with only minor tweaking for each platform.
• Views and view controllers are simpler. Once the important logic is moved elsewhere, views and VCs become dumb UI objects. This makes them easier to understand and redesign.

In short, replacing MVC with MVVM can lead to more versatile and rigorous UI code.

## What's in a view model?

A view model is like an adapter for the model that makes it suitable for presentation. The view model is also where presentation behavior goes.

For example, a view model might handle:

• Kicking off network or database requests
• Determining when information should be hidden or shown
• Date and number formatting
• Localization

However, the view model is not responsible for actually presenting information or handling input — that's the sole domain of the view layer. When the view model needs to communicate something to the view, it does so through a system of data binding.
mvvm  software_architecture  reactiveprogramming  reactivecocoa 
august 2016 by cdzombak
Introduction to MVVM ·
There are three really important points I want you to take away from this article:
MVVM is compatible with your existing MVC architecture.
MVVM makes your apps more testable.
MVVM works best with a binding mechanism.
mvvm  mvc  software_architecture  ios 
august 2016 by cdzombak
ashfurrow/C-41: C-41 is an application to help people develop film at home by providing a series of "recipes" for photographers to use.
C-41 is an application to help people develop film at home by providing a series of "recipes" for photographers to use.

The app demonstrates how to use Core Data, unit tests, ReactiveCocoa, and Model-View-ViewModel. Pull requests are welcome.
coredata  software_architecture  reactivecocoa  mvvm  testing  is:repo 
august 2016 by cdzombak
Cocoa Samurai: Basic MVVM with ReactiveCocoa
In the MVVM pattern the View Model encapsulates data/properties that the view can bind to and any validation logic and actions that can be performed.
mvvm  reactivecocoa  reactiveprogramming  software_architecture 
august 2016 by cdzombak
MVVM is Exceptionally OK - Ash Furrow
This. 100%, this.
The post levels a few criticisms of MVVM:

MVVM is poorly-named.
MVVM invites many responsibilities.
MVVM doesn’t change your structure.
I actually agree with all of these.
Despite this, I argue that moving to MVVM (keeping the existing app structure, plus view models) is still a great idea. Separating as much code from the view layer as possible makes it way easier to further factor those components into smaller-yet objects.
mvvm  falsedichotomy  software_architecture 
august 2016 by cdzombak
For a while now, I’ve seen the term MVVM being used in the iOS world. At first I dismissed it since it wasn’t really popular and it reminded me of C# world, which I tend to dislike. But then it started to get a bit more popular so I took a very brief glance at it and didn’t quite get the point.

What I saw was that people were combining it with ReactiveCocoa and/or treating ViewModels as dumb objects holding transformed data from a Model, for a View to consume. I ignored the ReactiveCocoa part since I wasn’t familiar with it (still know just a bit about it).

So based on my observation, it lead me to think: “Why are people bragging about it? They’re just adding a new layer to further separate concerns. Big deal.”.

However, a few days ago I was listening to Build Phase and MVVM was brought up again. I can’t remember what exactly was said, but it triggered the need to reasearch this again and see what was the big deal about it. And so I did.
mvvm  viewmodel 
august 2016 by cdzombak
Simple static table views for iOS in Swift. Static's goal is to separate model data from presentation. Rows and Sections are your “view models” for your cells. You simply specify a cell class to use and that handles all of the presentation.
ios  uikit  uitableview  mvvm  viewmodel  is:repo 
december 2015 by cdzombak
Lenses in Swift | Chris Eidhof
This is another FP-inspired blogpost, this time about lenses. There's a lot of literature around lenses, but I wanted to show some simple examples.

One idea: this could be very useful when applied to the ViewModel pattern. You could have an immutable model X, create a lens to a mutable ViewModel Y that you pass around, and then once you're done, you can update the original model X with the new value in Y.
functionalprogramming  lenses  immutability  composition  mvvm 
february 2015 by cdzombak
ReactiveCocoa and MVVM, an Introduction · Sprynthesis
The term view-model really is quite poor for our purposes. A better term might be “View Coordinator”.2 You can think of it almost like the team of researchers and writers behind a news anchor on tv. It gathers the raw data from the necessary sources (database, web service calls, etc), applies logic, and massages that data into presentation data for the view (controller). It exposes (usually via properties) only the information the view controller needs to know about to do its job of displaying the view (ideally you are not exposing your data-model objects). It’s also responsible for making changes to the data upstream (e.g. updating models/database, API POST calls).

Also dives into child view-models:
A view-model doesn’t have to represent everything on the screen. You can use child view-models to represent smaller, potentially more encapsulated portions of the screen. This is especially beneficial if that bit of view (e.g. a table cell) could be re-used in your app and/or represent multiple data-model objects.

mvvm  reactivecocoa  reactiveprogramming  software_architecture 
december 2014 by cdzombak
MVVM, Swift and ReactiveCocoa - It's all good!
## andrewsardone added:
The extensions like subscribeNextAs helps work around some gross optional wrapping stuff, and I really like the RAC struct as a replacement to the RAC macro.
lang:swift  via:andrewsardone  reactivecocoa  interop  mvvm 
august 2014 by cdzombak
Model-View-ViewModel for iOS | Teehan+Lax
A discussion of what MVVM is, roughly, and the code complexity & testability arguments for using it.
mvvm  cocoa  ios  software_architecture 
may 2014 by cdzombak
Enemy of the State // Speaker Deck
iOS and Mac apps rely heavily on state to change their presentation and respond to input—it's hard to imagine writing an app without the use of properties and variables. However, state is a huge source of needless complexity, and responsible for most of the easily avoidable bugs that users encounter.

This talk will explain what state is, detail exactly why it's so harmful, and offer ways to minimize and avoid state, making the apps we develop simpler and more reliable.
ReactiveCocoa  state  immutability  cocoa  complexity  via:andrewsardone  viewmodel  functionalprogramming  reactiveprogramming  mvvm 
april 2014 by cdzombak
iPhone grocery list app, synchronized using GitHub
mvvm  reactivecocoa  reactiveprogramming  is:repo 
december 2013 by cdzombak
ReactiveCocoa essentials: Understanding and using RACCommand - SHAPE Code Blog
A good walkthrough of how to use RACCommand to send a network request and bind your UI to the various executing, completed, and error states.
reactiveprogramming  objective-c  ReactiveCocoa  MVVM  via:andrewsardone  via:iosdevweekly 
december 2013 by cdzombak

Copy this bookmark: