views:

37

answers:

2

What is the best practice for storing font information of labels in Cocoa-Touch following the MVC paradigm?

In my data model I would like to store information that are displayed by a custom view as UILabels. It is evident that the label text belongs to the data model. But where should I store the corresponding font (and in my situation also color) information? Do they "belong" to the data model or rather to the view?

The reason I am asking is this: If I simply add a property of class UIFont to my data model, I will run into trouble when serializing and copying my data (since UIFont does not implement the NSCoding and NSCopying protocols), whereas the other classes that I typically use for my data models do. (The problem does not exist for UIColor since one already has NSCoding and can easily add NSCopying, although one could still ask if the color should "belong" to the data model.)

In general I would like to be able to serialize all properties of my data models and this seems to be a very common and general pattern in MVC. Of course, I could also write an abstraction of font information rather than use UIFont directly as a property in my data model. But I wonder what the best practice use of MVC on iOS is in such a case.


Update: Thanks for the answers. I have decided to go with the "style model" implementation in those cases where I believe it makes sense to store font information in models. In order to overcome the difficulty mentioned above I have simply written categories for the two classes, see this link.

+2  A: 

If the user (or external input) can select the font, it is part of the model.
You can store the font name

Benoît
+1  A: 

I will prefer not to store view related informations like font, color etc. in data model. Rather than I will use a separate class to store all styling information (That class may read from a plist file). In general the color and other styling properties of all labels, buttons etc. in the app will be same. So I want to change this information in single place and want to propagate it to every label. This styling information has nothing to do with the data the labels are showing.

The summary is I will prefer the separation of data and styling (You can call it StyleModel, if you want). Obviously other people can choose otherwise, and the decision may also depend on the application details. (Benoît's answer shows an example where style info might be a part of data model.)

taskinoor