Disqus - Latest Comments for Bluesman

Re: I finally found a Steve Jobs plush! He goes perfectly with my 1st Gen iPod.

Bluesman — Wed, 08 May 2019 09:57:29 -0000

Frank, I spoke too soon. I just saw that I got an email from Greg yesterday. He said, "The iGenius plush only included the doll itself. Unfortunately I just sold out of my inventory two days ago so the listing has been removed for now."

Re: I finally found a Steve Jobs plush! He goes perfectly with my 1st Gen iPod.

Bluesman — Wed, 08 May 2019 09:45:18 -0000

Frank, yes I did get mine last week and it's great. It didn't come with a little iPod like I thought so I went to the site to see if I was imaging that and saw that the product page is gone as well. I emailed them to ask if it should have come with an iPod and haven't heard back. Even so, I'm still really happy with it. Hope you get yours soon!

Re: I finally found a Steve Jobs plush! He goes perfectly with my 1st Gen iPod.

Bluesman — Thu, 25 Apr 2019 11:37:45 -0000

Damn you, Dave. There went $29 (plus $13 shipping) that I didn't really need to spend.

Re: Bixby Creek Bridge: Photos and History of this Iconic Bridge

Bluesman — Mon, 23 Apr 2018 20:18:38 -0000

Unfortunately, it's now been ruined by the city. They put up fences around each light pole to prevent suicide jumpers creating an eyesore around each one. Of course jumpers intent on ending it all would never think to go anywhere else so hats off to the city of Pasadena for ruining it for all.

Re: How to Correct Skin Tones Using Lightroom’s Color Curves

Bluesman — Sun, 22 Apr 2018 16:51:41 -0000

This is a fantastic tutorial!

Re: Updated: Protocol-Oriented MVVM in Swift 2.0

Bluesman — Mon, 15 May 2017 15:31:30 -0000

Hi Natasha,

Thanks for this great post. If your data was in an NSFetchedResultsController, what would be your dataSource? Would it be the viewModel or the NSFetchedResultsController or would you leave it as the UITableViewController?

Any suggestions you have about this would be super helpful.

Thanks!

Re: Demoing the Swift MVVM Design Pattern | Toptal

Bluesman — Thu, 20 Apr 2017 00:10:13 -0000

Thanks for the tips, Dino!

Re: Demoing the Swift MVVM Design Pattern | Toptal

Bluesman — Fri, 14 Apr 2017 17:04:37 -0000

Hi Dino, I've used what I've learned from this article and I finally got it to work. I learned so much from working through this on my project so thank you very much again. But of course, I have another question.

In my app, the user starts on view controller A that has a view model and that view model has a model object and I have it all wired up using your method taught here. On this view controller is a button and the button title comes from a property of the model object (which happens to be another object's property). The user can tap it to go to view controller B where they can make a selection from a list (UITableView), and the selection they make changes the value of that property (to a different object). View controller B is dismissed after the selection is made and the button title changes to reflect the change that was made to the object's property (using the property from the new object the user selected).

I've gotten it to work, but I'm pretty sure the way I did it is a terrible hack plus, when view controller B is dismissed, you can see the button title change from the old value to the new value on view controller A. Here's how I've done it:

1. User taps the button and in prepareForSegue I create a view model for view controller B by passing the model object to it.
2. When the user makes a selection from the list on view controller B, the didSelectRowAtIndexPath method calls a method on the view model which then calls a method on the model object to update itself with the selection.
3. After that (still in didSelectRowAtIndexPath) the view controller's delegate is called telling it to dismiss the view controller like this:

func selectionDidFinish(controller: UIViewController) {
self.dismissViewControllerAnimated(true, completion: nil)
viewModel.refreshUI() <-- this essential does what your fillUI() method does
}

I hope that's easy enough to understand. Unlike your score keeper example app that has nested view controllers, mine has multiple view controllers the user can transition to and I'm not sure how to properly use your concepts when I have to pass an object between view controllers and the make the view controllers refresh themselves at the right times.

If you have any words of advice I'd really appreciate your thoughts.

Thanks

Re: Demoing the Swift MVVM Design Pattern | Toptal

Bluesman — Sat, 18 Mar 2017 19:42:57 -0000

Thank you for the advise, Dino. That's a very interesting approach to using CoreData you've suggested. I hadn't thought of hiding Core Data entirely like that but it sounds like a pretty good idea.

Re: Demoing the Swift MVVM Design Pattern | Toptal

Bluesman — Fri, 17 Mar 2017 11:59:17 -0000

Dino, this tutorial has been so helpful. Thanks again for posting it. There's one piece of the puzzle that's missing for me - persisting data. if you needed to persist data to Core Data, where would you typically do that in an MVVM pattern? Let's say you want to save the Game information so your Game object is an NSManagedObject. We don't want our view controllers to have any idea what Core Data is so they shouldn't save the context in which Game object lives. It doesn't seem like the view model should be doing that kind of thing either. So that leaves the object itself or perhaps a service class that handles all Core Data actions (like I have in my app).

My idea is to have my view model call a function in my data handler class (let's call it 'CoreDataHelper') and pass the model to the function to save its context. What do you think of that approach?

Re: Demoing the Swift MVVM Design Pattern | Toptal

Bluesman — Wed, 15 Mar 2017 11:22:25 -0000

HI Dino, I figured out it didn't do anything by putting a breakpoint on the 'self.listener = listener' line of the .bind function.

I have one other related question for you. What value does the '$0' represent in the closures? Is it the Dynamic value that called the close? In other words, in 'viewModel.score.bindAndFire { [unowned self] in self.scoreLabel.text = $0 }', does $0 = 'viewModel.score'?

Re: Demoing the Swift MVVM Design Pattern | Toptal

Bluesman — Mon, 13 Mar 2017 11:00:58 -0000

Hi Dino, this is a really great post about MVVM! Every example I've found in the past only explains how to get data from the model to the UI. They never seem to explain how you get user input from the UI to the model.Could you please explain a little more about how the .bind and .bindAndFire methods work? In particular, the .bind function doesn't seem to ever be called. I've stepped through the code of the finished project and it never stops at a breakpoint I've set there.

Re: Using MVVM In the Settings View | Cocoacasts

Bluesman — Thu, 09 Feb 2017 18:26:23 -0000

Hi, did you get a chance to create this tutorial that talks about options other than making the computed properties of the view model settable? Not trying to rush you, I just want to make sure I didn't miss it.

Re: Adding Categories to the Mix | Cocoacasts

Bluesman — Wed, 08 Feb 2017 21:05:16 -0000

Hi Bart, my understanding is NSFetchedResultsController is strictly for use with a UITableView and that people typically get into trouble when they try to use it for other things. This lesson will come in handy for a few situations in my app, but of course I have one view which is different.

I have an NSManagedObject called 'LiftEvent' and one of its properties is another NSManagedObject called 'Lift'. A LiftEvent always has one Lift while a Lift can be associated with many LiftEvents.
https://uploads.disquscdn.c... There are a number of available Lifts to choose from (e.g. Bench Press, Incline Bench Press, Overhead Press, and more). When a new NSManagedObject is created, many of its properties will be empty, but I want to set the Lift to the current user default. So, rather than a user selecting a row in a table and using that indexPath to set the relationship, I believe I'll need to fetch that default Lift from the persistent store and set the LiftEvent.lift property with it. The only way I see to do that is to get the default Lift name from NSUserDefaults and use that as a predicate to fetch the Lift. That will return an NSSet with (I hope) the single Lift object I want, then I can associate them. That seems so not elegant, especially compared to an NSFetchedResultsController, but is this a sensible way to do it?

Re: Rinse and Repeat | Cocoacasts

Bluesman — Thu, 02 Feb 2017 08:43:40 -0000

That sounds terrific, Bart! And I would appreciate it very much.

For what's it's worth, I don't think the screencasts are rough at all. Quite the opposite in fact. They're very professional and I've learned a lot. For me, I just that last piece of the MVVM puzzle to tie it all together.

Re: Rinse and Repeat | Cocoacasts

Bluesman — Thu, 02 Feb 2017 02:01:21 -0000

Since you couldn't see the image, I edited my post and added the code.

I kind of took the approach you're suggesting. My app was working pretty well and then I've slowly broken it apart into the MVVM components. Getting data from the Model to the ViewModel to the ViewController to the View was relatively straight forward (even if I didn't do it perfectly). It's the other direction that's been problematic for me. The 'how' to get data from the View to the ViewController and the 'how' to get it to the ViewModel and the 'how' to get it to the Model - just when I think I've got it working, I discover that I don't. This is the big thing I really hoped I'd learn in this course.

I've done a lot of research and tried a lot of things so it's like I've got all the necessary ingredients in my head, I just need a clear example of how to use those ingredients.

You're certainly correct about the lack of native binding making it harder than it should be. And while RxSwift might be a good solution, I'd like to learn how to do it without adding a new framework into the mix. My app really is quite simple and because of this, it seems like a good time to learn the fundamentals without relying on framework. When I take on something bigger, maybe that would be a better time.

Re: Rinse and Repeat | Cocoacasts

Bluesman — Wed, 01 Feb 2017 10:16:39 -0000

I'm sure you're not missing anything. It's my code that is the problem.

I'm attempting to take the input from the user when they change a numerical value and ultimately update that value in the appropriate property of the Model - all of course while sticking to the rules of MVVM.

The 'func updateWeight( )' method is called when the user changes the weight value. That calls the 'weightLiftedDidChange(weightLifted)' method in the ViewModel If there's a value in the weight field, it updates the 'weightLifted' property of the Model object, then the ViewModel updates itself with that value with 'self.weightLifted = String(model.weightLifted!)' so it has the value the user entered. What I'm trying to do there, and where I think you mean I'm storing weightLifted twice, is update the weightLifted value in the ViewModel without it having a reference to the View. Finally it calls `self.calculatorViewDidChange?(self)' so the View updates itself with the new ViewModel value(s):

private func updateView() {
self.viewModel?.calculatorViewDidChange = { [unowned self] viewModel in
self.weightLiftedField.text = viewModel.weightLifted
self.repetitionsField.text = viewModel.repetitions
self.oneRepMaxLabel.text = viewModel.oneRepMax
self.units.text = viewModel.unitsTextField
self.liftNameButton.setTitle(viewModel.liftName, forState: .Normal)

guard self.oneRepMaxLabel.text != "0.0" && self.oneRepMaxLabel.text != "0" else { return }

if viewModel.weightPercentagesViewData != nil {
self.weightPercentages = viewModel.weightPercentagesViewData!
self.percentagesTableView.reloadData()
}
}
}

I'll try it with computed properties because I see how that makes a lot of sense. And if you want to tell me where I'm going wrong in the code I've shown here, please do.

I've learned a lot from your MVVM series (https://cocoacasts.com/seri..., but I'm sure I've made mistakes. I'm also learning a lot from this course, but as you can see, I'm trying to do something that you haven't yet. That is, getting the user's input from the View all the way to the data store in an MVVM paradigm.

Re: Rinse and Repeat | Cocoacasts

Bluesman — Tue, 31 Jan 2017 10:04:32 -0000

That's a great talk by Andy. Thanks for the link.

I'm trying to see if I can get this to work by keeping it a struct. I'll learn a lot even if I can't ultimately do it. But I am running into a lot of errors telling me 'Cannot assign to property: 'self' is immutable' on the methods in my view model that are called when the user changes a value on the UI:

In my view controller:

func updateWeight() {
viewModel.weightLiftedDidChange(weightLifted)
}

In my view model:

func weightLiftedDidChange(weight: String) {
if let weight = Double(weight) {
model.weightLifted = weight
self.weightLifted = String(model.weightLifted!) <-- Cannot assign to property: 'self' is immutable
}
self.calculatorViewDidChange?(self) <-- this calls a closure which causes the view to update itself with the values now in the view model. This seems circular, but perhaps that's a different question.
}

So I did my research and learned about protocol usage with classes and structs and it looks like I'll need to make these method mutating like so:

mutating func weightLiftedDidChange(weight: String)

This makes the errors go away but my question for you is, "am I doing this correctly?"

Re: Rinse and Repeat | Cocoacasts

Bluesman — Sat, 28 Jan 2017 18:25:50 -0000

Hi, I'm refactoring a view model that I originally created as a class into a struct because, well, I see you using structs so I figure that can't be a bad thing to try. The problem I'm having is with two addObserver methods:

NSNotificationCenter.defaultCenter().addObserver(self, selector: #selector(self.defaultsDidChange), name: NSUserDefaultsDidChangeNotification, object: nil)

NSNotificationCenter.defaultCenter().addObserver(self, selector: #selector(self.newLiftEvent), name: "LiftEventDidSave", object: nil)

Xcode is complaining: "Argument type 'CalculatorViewModel' does not conform to expected type 'AnyObject'"

I figured out that it doesn't like me passing 'self' in the first argument because it's expecting an 'AnyObject' and a Struct is not an object. So, does this mean my view model should be a class or does this mean these methods belong somewhere else in MVVM land?

Re: Time to Create A View Model | Cocoacasts

Bluesman — Sat, 28 Jan 2017 12:35:05 -0000

Perfect. Then it all makes sense. Thanks!

Re: Time to Create A View Model | Cocoacasts

Bluesman — Sat, 28 Jan 2017 10:32:12 -0000

I should have asked my question in the last lesson, 'A Quick Recap' because that's where you address this. But, let me be clear about the kind of formatting I mean. In the example you used, the model provide a date in its raw value and the view model formats it into a format humans understand like January 28, 2017. That makes sense. But I'm talking about formatting like specifying the font, the font-size, the color, and things like that. Would you say that also belongs in the view model?

Re: Time to Create A View Model | Cocoacasts

Bluesman — Fri, 27 Jan 2017 20:46:10 -0000

Hi Bart, where should formatting of data be done in the world of MVVM? From what I understand, formatting code should live in the view in most cases. I believe one reason for this is that a given view knows how the data it's given should be displayed but another view may want to display it differently. I think this would keep the responsibilities of the view and the view model independent and improve testability. Cloudy doesn't do much formatting, but the formatting it does do is in the view models. Is my understanding about the view usually being the proper home for it incorrect?

Re: Adding Categories to the Mix | Cocoacasts

Bluesman — Wed, 25 Jan 2017 15:15:57 -0000

Bart, this lesson answered several questions that I've been seeking clear answers to for a long time. The whole course is great, but this lesson just by itself makes the course worth every penny.

Re: Using MVVM In the Settings View | Cocoacasts

Bluesman — Mon, 23 Jan 2017 09:24:55 -0000

That sounds great. Looking forward to it.

I completely agree that there is no one solution. That's why when I learn about a solution to a problem, I always want to hear the reasoning behind it as well as the pros and cons because every solution has important trade offs to consider.

Re: Using MVVM In the Settings View | Cocoacasts

Bluesman — Sun, 22 Jan 2017 15:57:22 -0000

I'd be happy to help. While I anxiously await for an addition to the course that covers this, can you tell me the general idea of how you would approach it? More specifically:

1) the view models in Cloudy provide the data for the view via computed properties but they are gettable only. In an application in which the user could change the presented values, would you make those properties in the view model settable too? Is seems like the obvious thing to do.

2) in my app, the view controller tells the view model to update itself when its values change with:

self.viewModel?.calculatorViewDidChange = { [unowned self] viewModel in
self.weightLiftedField.text = viewModel.weightLifted
etc...
}

and calculatorViewDidChange in the viewModel class is defined as: 'var calculatorViewDidChange: ((CalculatorViewModelProtocol) -> ())? { get set }'

Is that a good approach or way off base?