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.
We’ve explored so much with our concurrency experiments and yet there’s one fundamental topic we haven’t touched so far. Deadlocks. Whenever we think of concurrency, we can’t help thinking of locks for protecting shared resources, managing synchronization and what not. But, as Uncle Ben has said, with great power comes great responsibility, similarly with great locks comes great deadlocks.