I have a view model that's being used in two flows and has gotten to the stage where it should really be split out into a super class and two subclasses. However, I'm getting confused as the best way to go about performing some subclassing.
On creation of the view model, I pass in all the interactions that could happen from the view like so:
View
class SomeViewController: UIViewController {
#IBOutlet private weak var nextButton: UIButton!
private var presenter: SomeViewModel!
override func viewDidLoad() {
super.viewDidLoad()
presenter.configure(nextButtonTapped: nextButton.rx.tap.asDriver())
}
}
Then I can handle these actions within my view model like so:
ViewModel
class SomeViewModel {
private let normalFlow: Bool
private let diposeBag = DisposeBag()
init(normalFlow: Bool) {
self.normalFlow = normalFlow
}
func configure(nextButtonTapped: Driver<Void>) {
handle(nextButtonTapped: nextButtonTapped)
// call to any other input handlers here...
}
func handle(nextButtonTapped: Driver<Void>) {
nextButtonTapped.drive(onNext: { [unowned self] in
guard self.safetyCheckOnePasses(), safetyCheckTwoPasses() else {
return
}
if normalFlow {
// do some set of actions
} else {
// do another set of actions
}
}).disposed(by: disposeBag)
}
func safetyCheckOnePasses() -> Bool {
// perform some sanity check...
return true
}
func safetyCheckTwoPasses() -> Bool {
// perform another sanity check...
return true
}
}
I'm getting confused as to what the best way to override the handle(nextButtonTapped: Driver<Void>) is because I still want those sanity checks to happen at the start of the onNext for every subclass, but I want the body after that to be different for the different subclasses. What would be the best way to go about this without duplicating code?
Rx is part of the functional paradigm and as such, subclassing is not appropriate.
Move your safetyCheckOnePasses() and safetyCheckTwoPasses() functions out of the class (or at least make them static.) That way they can be reused without needing an instance.
Related
I use model view presenter architecture in my app and I wonder what's better for respect solid principles and reusability.
So I have 4 classes: View Controller, Presenter, Model and Service. But I have a doubt in connection between presenter and service. I am not sure if I don't break single responsibility principle.
Presenter:
class WorkoutPresenter() {
// some code
let workoutSettingsService = WorkoutSettingsService()
func changeUnitFromKGtoLBInHistory() {
workoutSettingsService.changeUnitFromKGtoLBInHistory()
}
func changeUnitFromLBtoKGInHistory() {
workoutSettingsService.firstFunction()
}
func changeUnitFromKGtoLBInCalendar() {
workoutSettingsService.secondFunction()
}
}
class WorkoutSettingService {
func firstFunction() {
// some code
}
func secondFunction() {
// some code
}
func thirdFunction() {
// some code
}
}
Now workout service has 3 responsibilities (first, second and third function)
Or maybe better option would be create different class for each function and then call them in WorkoutService, something like:
class WorkoutSettingService {
let firstFunctionClass: FirstFunctionClass
let secondFunctionClass: SecondFunctionClass
let thirdFunction: ThirdFunctionClass
init(firstFunctionClassClass: FirstFunction, secondFunctionClass: SecondFunctionClass, thirdFunctionClass: ThirdFunctionClass) {
self.firstFunctionClass = firstFunction
self.secondFunctionClass = secondFunction
self.thirdFunctionClass = thirdFunction
}
func firstFunctionCall() {
firstFunctionClass.function()
}
func secondFunctionCall() {
secondFunctionClass.function()
}
func thirdFunctionCall() {
thirdFunctionClass.function()
}
}
And then call it in Presenter like before. Or maybe better than accessing to this new three class is create a protocols and set delegates from service to this new specific classes?
I hope you understand what my problem is. If you have other idea how to connect presenter with service in clean way, go ahead.
The cleaner approach in my opinion would be to introduce protocols to your service class and segregate the responsibilities.
To make the example simpler, I am going to assume that func changeUnitFromKGtoLBInHistory() and func changeUnitFromLBtoKGInHistory() have to invoke a service with respect to some history data and the func changeUnitFromKGtoLBInCalendar() has to invoke current calendar data.
First we introduce 2 protocols to do that
protocol InHistoryServiceProtocol {
func firstFunction()
func secondFunction()
}
protocol InCalendatServiceProtocol {
func thirdFunction()
}
Then we update the class WorkoutSettingService to conform to protocol as below:
class WorkoutSettingService: InHistoryServiceProtocol, InCalendatServiceProtocol {
func firstFunction() {
// some code
}
func secondFunction() {
// some code
}
func thirdFunction() {
// some code
}
}
Now we use protocol composition to gracefully handle the service class in the presenter
class WorkoutPresenter {
// some code
typealias WorkoutServiceProtocols = InHistoryServiceProtocol & InCalendatServiceProtocol
let workoutSettingsService: WorkoutServiceProtocols = WorkoutSettingService()
func changeUnitFromKGtoLBInHistory() {
workoutSettingsService.firstFunction()
}
func changeUnitFromLBtoKGInHistory() {
workoutSettingsService.secondFunction()
}
func changeUnitFromKGtoLBInCalendar() {
workoutSettingsService.thirdFunction()
}
}
This way you have the flexibility to add/remove responsibilities in the Work out service class respecting the SOLID principles. It also becomes easy to mock the data and inject into presenter for testing.
I have VCs in an iOS app which have quite a lot of UI controls. I would now need to replace or "mock" some of these controls when in a specific state. In some cases this would be just disabling button actions, but in some cases the actions that happen need to be replaced with something completely different.
I don't really like the idea of having this sort of check littered all around the codebase.
if condition {
...Special/disabled functionality
} else {
...Normal functionality
}
In Android, I can just subclass each Fragment/Activity and build the functionality there, and then doing the if/else when inserting Fragments or launching activities.
But on iOS with Storyboards/IBActions and Segues, UIs and VCs are really tightly coupled. You either end up duplicating UI views or adding a lot of finicky code to already large VCs.
What would be the best way to handle this in iOS?
Sample code of what I want to avoid doing:
//Before:
class SomeViewController : UIViewController {
#IBAction onSomeButton() {
checkSomeState()
doANetworkRequest(() -> {
someCompletionHandler()
updatesTheUI()
}
updateTheUIWhileLoading()
}
#IBAction onSomeOtherButton() {
checkAnotherState()
updateUI()
}
}
//After:
class SomeViewController : UIViewController {
#IBAction onSomeButton() {
if specialState {
doSomethingSimpler()
} else {
checkSomeState()
doANetworkRequest(() -> {
someCompletionHandler()
updatesTheUI()
}
updateTheUIWhileLoading()
}
}
#IBAction onSomeOtherButton() {
if specialState {
return // Do nothing
} else {
checkAnotherState()
updateUI()
}
}
}
I'd suggest using the MVVM (Model - View - ViewModel) pattern. You pass the ViewModel to your controller and delegate all actions to it. You can also use it to style your views and decide if some of them should be hidden or disabled, etc.
Let's image a shopping app in which your pro users get a 10% discount and can use a free-shipping option.
protocol PaymentScreenViewModelProtocol {
var regularPriceString: String { get }
var discountedPriceString: String? { get }
var isFreeShippingAvailable: Bool { get }
func userSelectedFreeShipping()
func buy()
}
class StandardUserPaymentScreenViewModel: PaymentScreenViewModelProtocol {
let regularPriceString: String = "20"
let discountedPriceString: String? = nil
let isFreeShippingAvailable: Bool = false
func userSelectedFreeShipping() {
// standard users cannot use free shipping!
}
func buy() {
// process buying
}
}
class ProUserPaymentScreenViewModel: PaymentScreenViewModelProtocol {
let regularPriceString: String = "20"
let discountedPriceString: String? = "18"
let isFreeShippingAvailable: Bool = true
func userSelectedFreeShipping() {
// process selection of free shipping
}
func buy() {
// process buying
}
}
class PaymentViewController: UIViewController {
#IBOutlet weak var priceLabel: UILabel!
#IBOutlet weak var discountedPriceLabel: UILabel!
#IBOutlet weak var freeShippingButton: UIButton!
var viewModel: PaymentScreenViewModelProtocol
override func viewDidLoad() {
super.viewDidLoad()
priceLabel.text = viewModel.regularPriceString
discountedPriceLabel.text = viewModel.discountedPriceString
freeShippingButton.isHidden = !viewModel.isFreeShippingAvailable
}
#IBAction func userDidPressFreeShippingButton() {
viewModel.userSelectedFreeShipping()
}
#IBAction func userDidPressBuy() {
viewModel.buy()
}
}
This approach let's you decouple your logic from your views. It's also easier to test this logic.
One thing to consider and decide is the approach as to how to inject the view model into the view controller. I can see three possibilities :
Via init - you provide a custom initializer requiring to pass the view model. This will mean you won't be able to use segue's or storyboards (you will be able to use xibs). This will let your view model be non-optional.
Via property setting with default implementation - if you provide some form of default/empty implementation of your view model you could use it as a default value for it, and set the proper implementation later (for example in prepareForSegue). This enables you to use segues, storyboards and have the view model be non-optional (it just adds the overhead of having an extra empty implementation).
Via property setting without default implementation - this basically means that your view model will need to be an optional and you will have to check for it almost everytime you access it.
I have this view model in my code:
import RxSwift
protocol ViewModelInput {
func buttonTouched()
}
protocol ViewModelOutput {
var done : PublishRelay<Bool> { get set }
}
protocol ViewModelType {
var inputs: ViewModelInput { get }
var outputs: ViewModelOutput { get }
}
public final class ViewModel: ViewModelInput, ViewModelOutput, ViewModelType {
var inputs: ViewModelInput { return self }
var outputs: ViewModelOutput { return self }
internal var done = PublishRelay<Bool>.init()
init() {}
func buttonTouched() {
self.outputs.done.accept(true)
}
}
And I'm using it's "output" like this:
// Somewhere else in my app
viewModel.outputs.done
.asObservable()
.observeOn(MainScheduler.instance)
.subscribe(onNext: { [weak self] _ in
// whatever
}).disposed(by: disposeBag)
To be honest I don't need that Boolean value with PublishRelay. I don't even need onNext() event. All I need is to notify my coordinator (part of app that uses this view model) about onCompleted(). However there is still some <Bool> generic type added to my output. I don't need any of that. Is there any cleaner way to achieve that?
I though about traits like Completable but as far as I understand I need to emit completed-event inside create() method or use Completable.empty(). Or maybe I don't understand traits that good, I don't know.
Any ideas?
I haven't done any RxSwift in a while, but have you tried making the type PublishRelay<Void>? Once you do that you can just pass () to outputs.done.accept(()) in your buttonTouched() method and not have to worry about passing arbitrary information that isn't needed
I think #Steven0351 is right with the < Void> approach. Just 2 little things:
It should also work by terminating the subject instead of emitting a Void value. It looks cleaner in the subscription as well.
I guess you are subscribing your outputs.done subject in the UI. In that case you might want to use Drivers. That way there's no need to specify observation on main scheduler (among other Drivers advantages).
ViewModel
internal var done = PublishRelay<Void>.init()
func buttonTouched() {
self.outputs.done.onCompleted()
}
ViewController
viewModel.outputs.done
.asDriver()
.drive(onCompleted: { [weak self] in
// whatever
}).disposed(by: disposeBag)
Would such an approach be fine in Swift or is it a bad idea:
protocol Serializable {
func serealize()
}
class SomeBaseVC: UIViewController {
var serialisableObject: Serializable?
override func viewDidLoad() {
super.viewDidLoad()
serialisableObject?.serealize()
//Do some other generic stuff with serialisableObject
}
}
class JSONObject: Serializable {
func serealize() {
//serealize
}
}
class SomeChildVCWhichHasSomeGenericBehaviour: SomeBaseVC {
override var serialisableObject: JSONObject
override func viewDidLoad() {
super.viewDidLoad() //Now this would do serealisation of JSONObject
//And now do something specific to just this VC
}
}
So the point is to have some generic behavior that is shared by many of my view controllers implemented in my superclass using protocols. Say I have a lot of view controllers that need to serialize some object and save it in viewDidLoad method (this is obviously a hypothetical example). This could be a some JSON data or some XML data. Now I could everytime implement a different viewDidLoad method, depending on whether controller is working with XML or JSON, but as shown above I think I can encapsulate it in the base class, then I could just inherit from this base VC and just call super.viewDidLoad(). The only part that bothers me is:
override var serialisableObject: JSONObject
Am I allowed to do that? Is that a good idea?
You cannot change the type of serialisableObject since that would violate the LSP
You can use a setter/getter to effectively alias another property in your subclass to the superclass serialisableObject property. This would allow you to use the specific type in your view controller subclass whilst the superclass would use the alias:
class SomeChildVCWhichHasSomeGenericBehaviour: SomeBaseVC {
var jsonThing: JSONObject?
override var serialisableObject: Serializable? {
get {
return jsonThing
}
set {
self.jsonThing = newValue as? JSONObject
}
}
override func viewDidLoad() {
super.viewDidLoad() //Now this would do de-serealisation of JSONObject
print(self.jsonThing)
}
}
I'm creating an app and I have all the logic done, but I want to do a Code refactoring and create MVC pattern. But I dealing with some asynchronous informations, that came from API.
/MenuViewController
Alamofire.request(.GET, Urls.menu).responseJSON { request in
if let json = request.result.value {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0)) {
let data = JSON(json)
var product: [Product] = []
for (_, subJson): (String, JSON) in data {
product += [Product(id: subJson["id"].int!, name: subJson["name"].string!, description: subJson["description"].string!, price: subJson["price"].doubleValue)]
}
dispatch_async(dispatch_get_main_queue()) {
self.products += product
self.tableView.reloadData()
}
}
}
}
This is my code, already working. But I want to create a Model that will handle this and just return the array of Products to my MenuViewController.
Model/Menu
class Menu {
var products: [Product] = []
init() {
Alamofire.request(.GET, Urls.menu).responseJSON { request in
if let json = request.result.value {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0)) {
let data = JSON(json)
var product: [Product] = []
for (_, subJson): (String, JSON) in data {
product += [Product(id: subJson["id"].int!, name: subJson["name"].string!, description: subJson["description"].string!, price: subJson["price"].doubleValue)]
}
dispatch_async(dispatch_get_main_queue()) {
self.products += product
}
}
}
}
}
func totalOfProducts() -> Int {
return self.products.count
}
func getProducts() -> [Product]? {
return self.products
}
func getProductFromIndex(index: Int) -> Product {
return self.products[index]
}
}
But I got my self thinking, how I gonna get the main_queue to another class?
So I tried something like this:
class MenuViewControlvar: UITableViewController {
var products: [Product] = []
let menu: Menu = Menu()
// MARK: View Controller Lifecycle
override func viewDidLoad() {
super.viewDidLoad()
if let products = menu.getProducts() {
self.tableView.reloadData()
}
// rest of the code
But didn't worked. My TableView is never updated.
I was wondering if I can do this, or I've to keep my Alamofire code in my viewDidLoad() from my MenuViewController
Thank you.
I am just giving you a direction with the step I would follow (Not writing the code thinking you can work it out):
First, write a networking class that accepts network request along with a competition block. Completion block shall be executed as soon as networking is done. This is a wrapper class and can be used across classes.
Second, write a model class that has all the parameters necessary for view controller's functionalities/view drawing.
Third, from view controller, call the networking class. In completion block, pass the model setting, table reload code and any code to remove loading overlay/indicator. This block should get executed on main queue.
Fourth, add code to show loading overlay/indicator before you trigger networking.
Delegation is an ideal solution for this problem of updating your model data and your view based on an asynchronous network call and it’s pretty much the same technique that is implemented throughout the iOS SDK to solve the same problem. There are many benefits of delegation over observation, another viable solution.
First, move your networking code to a separate class
class NetworkingController {
Create a protocol that view controllers can conform to. This provides the loose coupling between your network operations and your views to effectively maintain separation between the MVC layers.
#protocol NetworkingControllerDelegate: class {
func menuDataDidUpdate()
}
Have the networking controller support a property for its delegate
weak var delegate: NetworkingControllerDelegate?
In summary your networking class now looks something like this:
#protocol NetworkingControllerDelegate: class {
func menuDataDidUpdate()
}
class NetworkingController {
weak var delegate: NetworkingControllerDelegate?
// Insert networking functions here.
}
Then, have your view controller conform to this protocol like so
class MenuViewController: NetworkingControllerDelegate {
and create a new network controller in your view controller
var myNetworkController = NetworkController()
and set the delegate of your network controller instance to be your view controller
myNetworkController.delegate = self
Then in your networking code, when the network request has completed and your model has been updated, make a call to the networking controller's delegate.
delegate.menuDidUpdate()
Create the implementation for this method in your view controller since it is now the delegate for your networking code.
func menuDidUpdate() {
// Update your menu.
}
This makes your view controller look something like:
class MenuViewController: NetworkingControllerDelegate {
var myNetworkController = NetworkController()
override func viewDidLoad() {
myNetworkController.delegate = self
}
// MARK: NetworkingControllerDelegate
func menuDidUpdate() {
// Update your menu.
}
}
This is just the outline of the implementation to give you the necessary information about how to proceed. Fully adapting this to your problem is up to you.