philkmills: Phil and guitar (Default)
While 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.

April 2012

S M T W T F S
1234567
891011121314
15161718192021
2223 2425262728
2930     

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 25th, 2017 12:45 am
Powered by Dreamwidth Studios