Class X has three properties, left, right, and sum. Left + Right = Sum. They store precise value, for example, Left is 51.2584165861, Right is 55.8155984388, and Sum is 107.07401502496.
But on UI, I have to round them into two precision decimal. They will show Left = 51.26, Right = 55.82 and Sum = 107.07, which are incorrect. 51.26 + 55.82 should be 107.08.
I think it would be good to calculate one value of other two, for example, Sum - Left and then we get Right to show on Ui.
If I create a new class for Ui, I will move all properties to base class then change current class and ui class to derive from it. They will have only one difference, the original class with store precise value while ui class will store 2 precision value. Maybe I apply rounding in ui class constructor.
My question is, is it good to create class for Ui in this sample? What are pros and cons of create a class only for Ui?
is it good to create class for Ui in this sample?
Yes.
What are pros and cons of create a class only for UI?
Pros: You're managing the UI data in one place. Your controller, in a model, view, controller architecture, deals with the UI model, rather than the UI components individually.
You can change the UI components without necessarily changing the UI model. As an example, you could change a check box to a toggle button without changing the model.
Cons: Your UI data model tends to be global across the UI. By definition, your UI model is a singleton.
Related
I'm currently thinking of project, which is basically interpreting data from many abstract data sources.
So the communication within application is like this
[UI] <-> [Controller / Delegate] <-> [Subclass of Abstract Data Source]
which is basically the MVC pattern. What is my problem, that each [Subclass of Abstract Data Source] can use only limited amount of [UI], so the flow is basically this:
Create instance of Data Source (DS)
Get list of possible UI's from DS
Create UI chooser and instantiate preset UI
Let DS modify UI
Fill UI from DS by predefined handler method
Example UI's are NSTableView, NSOutlineView, NSCollectionView, etc.
So I basically need to change column names, order, style of controls, ... without possibility of having unique NSWindow designed for each Data Source
Now the question:
If I need dynamic UI creation and custom data handling logic (no bindings to Core Data, or so), should I (and is it even possible to) use InterfaceBuilder or should I implement all view logic programatically?
Use whichever you favor. Any variations/dynamic areas can be represented/handled by the controllers. In a way, that means that I recommend moving the dynamic portions to code to controllers -- but you can still use XIBs for common high level design, if you choose.
Therefore, when a view is not suitable for a singular data representation and is used for multiple, the implementation/variations can be moved to the controller domain. When an implementation/definition applies to all, then you can define that in the XIB or in the program -- wherever you prefer to put it. In that case, you can use XIBs (or code) for invariant (skeletal) views.
I'm starting a small project that displays circles having random radii, random color and random position on the screen. I want to implement this using the MVC paradigm in Objective C.
I have a class Circle that contains the following instance variables:
CGFloat radius
CGPoint center
UIColor radiusColor
This class doesn't contain methods, it just holds data. It is put in a separate file. (Circle.m & Circle.h)
I have a myModel class that is supposed to be the model for my MVC. It contains methods that randomly generate centers inside bound of my view, where the bound dimensions are requested from the View throughout the controller.
Every time a random property (that is center, color and radius) is generated, an instance of the Circle class is created within the myModel class, and stored in an NSMutableArray.
When the generation is done, this NSMutableArray is passed to the controller, which in turn passes it to the view, thus displaying the circles.
My question is that if I am to implement the MVC paradigm correctly, should :
The Model (myModel) hold instances of Circle, or the instances of Circle should be held by the controller?
My model be made of 1 class, or is it legal to be made of several classes?
The model know the bound size of the view or is that something that a violation in the MVC philosophy?
One last question. If I have made the implementation as I have stated above, are myModel and Circle separate models or both classes constitute one model?
Thank you!
[Should] The Model (myModel) hold instances of Circle, or the
instances of Circle should be held by the controller?
The model should hold the data. That's it's job. Imagine what would happen if you wanted to change the interface to your program. Instead of (or in addition to) drawing circles on the screen, you might want to display a list of circles and their locations. You'd might want to change or replace the view controller to do that, but you wouldn't need to change the model that stores the circles. Likewise, you might want to change the way that circles are generated, but keep displaying them the way you are now. In that case, you'd change the model, but the view controller and view could probably stay the same.
[Should] My model be made of 1 class, or is it legal to be made of several classes?
A data model is typically a whole graph of objects, very often of different types. You might have one object that manages the rest (although you don't have to). For example, your MyModel class contains an array that stores Circle objects. You could add Square objects, Group objects, etc.
[Should] The model know the bound size of the view or is that
something that a violation in the MVC philosophy?
The model shouldn't know specifically about the view, but it's fine for the view controller to tell it to produce circles within a given range of coordinates. That way, if the view changes size or orientation, the view controller will likely know about it, and it can in turn give the model new info.
If you have other components to your model than just circles, wrap everything in myModel. Even if you don't, you might still want to do so to allow for future additions.
Depends on your design. If you are writing a "document based" application (regardless of whether you are using UIDocument) you normally would have a single class that contains the others. Even if you aren't, having a single root class for archiving purposes, etc., is usually convenient.
The model should definitely not know anything about the view hierarchy. (Note that this is different from knowing something like "canvas size" - it would be legitimate to store such a property in the model, and let the view display the canvas however it wishes, such as in a UIScrollView.)
Btw, kudos for thinking about this ahead of time!
I have a class that instantiates a hierarchy of classes. The interface should hide all of the internal hierarchy by presenting a single class reference. (An the interface to the classes at intermediate levels should hide internal implementation details the same way.) I am having a little difficulty deciding how to flow the interface parameters down to the lowest levels and to flow state changes up to the top level. What I have come up with gets messy.
I have seen some discussions of the blackboard pattern but, from what I have seen, it looks ad hoc and flat rather than hierarchical. (Although flat vs hierarchical may not be important.)
The class I have is a calendar view, subclasing UIView. The hierarchy includes a header class, a grid class (instantiated more than once), a tile class (instantiated many times), plus some helper classes. It's based on Keith Lazuka's kal calendar in Objective C. I've decided to reorganize it for my needs, and wanted to rethink this part of it before I introduce problems with flexibility.
My question is in the title.
I have decided that the KVO (Key Value Observer) design pattern makes sense for bubbling state information from the lower levels to the top. Only that state information that needs to flow up is observed at each of the corresponding layers.
In this application, a tapped tile event is sent to the observer at the next level up (the grid level), telling it that the user has selected a date, which is a property of the tile class.
At the grid level, it changes its state based on its current state and the new information that it's observer receives from the tile. (In my calendar, the user can select a range of dates by choosing start date and end date, and can continue tapping tiles to change his date range selection.) This changes state at the grid level translates into a change in the start and/or the end date, so an NSDictionary property is updated.
At the calendar level, an observer sees the startDate/endDate dictionary change. Regardless of which grid this came from (there are two grids, and only one of them is active at a time. The tiles and the calendar do not need to be aware of this) the calendar's start and end dates are updated.
The calendar is a view that is planted into one of the other views of the application, initialized with a month to be shown, and with a selected date range (start and stop dates). Information is flowed down from the top though the pointers to each of the immediate subviews at any layer. Those subviews take care of keeping their subviews configured. I have eliminate the need to add explicitly add delegate methods or callbacks, and that has simplified the connections from top to bottom. Connections only go the the immediate level above or below in the hierarchy.
This may not seem like much after all, because it looks rather straightforward. But it wasn't clear until I spent awhile thinking about it. I hope it gives others some ideas for their own code. I would still like to know if there are other suggestions responding to my question.
I have class A which is a NSView which contains a remove method, this method removes items from an array that is pulled from a Model class.
Class B is also an NSView, it draws some stuff depending on this Model class.
My issue is that when class A modifies the model collection Class B is not notified of the change and its view is not updated correctly.
I thought I could register Class B to the notification center but I dont think Im doing right.... thanks for any help.
Without seeing your code it's hard to figure out what the best solution is. I think the best way (depending on the complexity of your app) would be to have a controller class between your model and views that would update the model and alert the views to the change in a single method. This is sort of an Observer pattern. Alternatively, you could have an update method in the model that calls a method in Class B to let it know that there's a model update. This would require the model to hold pointers to your instances of Class A and Class B.
I am confused about how to go adding objects (images,etc) into an app. I will keep my example very basic so I can get a grasp on this. Let's say I want simple objects in an app. Say they are the smilies like the ones that are available in this forum software. If you wanted to add a bunch (like 4 not 400) to a view, is it better to just add them with using a UIImage or should you create a "smilieGuy" class with the various smiley face images (happy, sad, mad) and a method to change their mood (image to reflect mood). From what I understand, with the class you could create a happy object, a sad object, etc in your view based off of the class and then at anytime you could say changeMood and change the image to whatever mood you wanted.
Is the class approach actually possible and is it a better approach?
The class approach is preferable.
It allows you to separate the interface ([userFace setHappy]) from the implementation (self.image = [UIImage imageNamed:#"Happy.png"]). You can then change the logic, or create further variations without having to change any of the other display code.
I would also suggest creating an Emoticon class as a subclass of UIImageView. Inside the class, you could load your multiple images and use them to set the image property of your superclass.
You might also want to check out the animation properties of UIImageView to achieve Skype style smilies.