iOS – Implementing Themes for View Controllers

Depending on your processing needs, I'd go with either:

a) A bitmap class that stores raw pixel data and format information; when loading, you resolve RLE compression, but otherwise leave the raw pixel values intact. Then add some methods to query the class for its pixel format, and possibly a getter/setter pair to transparently modify pixels in a format-independent way (i.e., convert to and from floating-point RGB representation on the fly). If you ever need to convert between pixel formats, you would do that in this model by loading the original bitmap, creating a new empty bitmap with the desired target format, and then copying pixels over through the floating-point RGB getters/setters. b) Store pixel data as RGB floats (or 16-bit integers, depending on the kind of transformations you want to do). When loading convert everything to that format, and then when saving, specify the target pixel format explicitly.

Method a) has the advantage that some filters can be implemented in a completely lossless way, by using raw data and adapting the filter to the actual pixel format; it is more complicated to write such filters though, and if apply do more than one floating-point filter, you'll get more rounding errors on each pass (because you convert to and from integer every time).

Method b) is easier to implement, especially because your filters only ever need to accommodate one pixel format, and it produces less rounding errors, but it does not allow for completely lossless filters (not even an identity filter: loading and then saving the same bitmap still introduces one round-trip's worth of integer-to-floating-point conversion errors).

I don't see a problem with the approach you outlined. Your problem is one of being able to persuade your colleague that your approach is preferable to theirs. You might try:

• it's less work, as the same filtering behaviour is needed more than once in different views;
• it's easier to test, as you don't have to configure a view controller and all its views just to test some search code.

I think the "reusable component" argument is premature. It's more persuasive to focus on the reuse problems you currently have (i.e. the two views in the same app), than on speculative future reuse. That can be deleterious, as your colleague might think you're promoting unnecessary gold-plating work for a problem you don't know you'll ever have.