Changing the gears to Generic Programming
Practical usage of generic programming can be narrowed down to two forms:
Practical usage of generic programming can be narrowed down to two forms:
UILabel
is one the most smart view in UIKit
family. It knows a lot
about itself. If you constraint it to a certain width, the UILabel can
calculate the height for itself. Another smart thing about UILabel
is
that is saves you machine cycles by not redrawing its content unless
something is actually modified. And if you use NSAttributedString
, you
can in fact draw a more sophisticated text content.
Today, I want to talk about a curious case I discovered while playing with generic programming with Swift.
I think we have covered most of the core concurrency concepts. With the
current knowledge we are good enough to tackle all real world
concurrency related problems. But this doesn’t means that we’ve covered
everything the thread libraries have to offer. And by thread libraries I
mean just the C++ standard thread library and libdispatch. For example,
we’re yet to see std::future
, std::promise
, std::packaged_task
,
dispatch_barier
, dispatch_source
in action.
The Safari for iOS has some very interesting perspective effect
built-in. You can check that when you’ve multiple tabs open. How about
building something like that? Those views are clearly UIView
right? You
can see the web content rendered, they have cross buttons. The content
even periodically updates without launching the app using the background
services probably.