Programming 101 -- Refuted
Jan. 10th, 2012 03:45 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
philkmillsWhile working on customization of the application's general appearance today I discovered some very annoying behavior in Apple's "Cocoa Touch" software development kit. A couple of commonly-accepted programming guidelines are: 1) in OOP, a subclass extends the behavior of its parent class; it doesn't restrict it, and 2) side-effects are bad; a routine should do what it claims and little else.
In this library, the class UIToolbar is a subclass of UIView, which leads to the expectation that a toolbar should do anything a view can plus whatever extra its designer thought necessary. Nope. For example, a view allows you to set its background color but a toolbar quietly ignores such a request. A Google search reveals a great number of people questioning their own code because of this breaking of a basic assumption.
While experimenting with this, I discovered the second problem: that of unexpected results having nothing to do with the documented purpose of various routines.
- Toolbars exist as a way of letting a user select actions relevant to some other information on a screen. Changing the translucency of one changes the *size* of the related content.
- Toolbars contain optional buttons as trigger points for these actions. Changing the alpha (transparency) of the toolbar changes it for all the embedded buttons.
- Setting a toolbar translucent and then changing its "tintColor" -- or vice versa -- cancels the translucency.
Some operating systems are designed to give access to computer features in a useful way. iOS, on the other hand, was designed to prevent access except in Apple-approved ways. Some days the difference really shows.
In this library, the class UIToolbar is a subclass of UIView, which leads to the expectation that a toolbar should do anything a view can plus whatever extra its designer thought necessary. Nope. For example, a view allows you to set its background color but a toolbar quietly ignores such a request. A Google search reveals a great number of people questioning their own code because of this breaking of a basic assumption.
While experimenting with this, I discovered the second problem: that of unexpected results having nothing to do with the documented purpose of various routines.
- Toolbars exist as a way of letting a user select actions relevant to some other information on a screen. Changing the translucency of one changes the *size* of the related content.
- Toolbars contain optional buttons as trigger points for these actions. Changing the alpha (transparency) of the toolbar changes it for all the embedded buttons.
- Setting a toolbar translucent and then changing its "tintColor" -- or vice versa -- cancels the translucency.
Some operating systems are designed to give access to computer features in a useful way. iOS, on the other hand, was designed to prevent access except in Apple-approved ways. Some days the difference really shows.
