colionel: I'm intrigued by your use of a service. I haven't seen this before, so I'm imagining how this would work. In the Apple sample code I've seen, the UIViewController subclasses access Core Data directly...I assume that each UIViewController subclass would import the service, then use it each time it wanted to read/write data.
If this is the basic paradigm, why couldn't a widget controller also access the service?
Quote:
Originally Posted by colionel
But why not simply have a skin property in your controller ? that's the normal way to do this.. in your viewDidLoad you set your skin to your view.. No need to subclass UIView.
|
As I said, these widget controller objects should be NSObjects with a view property and subviews, mirroring the UIViewController paradigm.
Quote:
Originally Posted by colionel
Imagine that the UITextField widget was reading and writing from core data. When you want to use it you need to edit the framework. That would be a nightmare. Your widget must not decide how your system is built, it's your system which decides how to use a widget...
|
I'm not building framework-reusable widgets, I'm building single-app reusable widgets. I have n screens, each of which is dynamically populated with any number of five types of widgets. Since the widgets function identically and are populated dynamically, I think reuse is served when they are separate objects.
Is there a reason not to have them access the service?
