Graham Lee:
The key part is that you don’t actually need to build the collaborating object. In fact, you don’t need to worry at all yet about how it will be implemented. All that matters is that you express the messages it responds to, so that the mock object can test whether they’re sent. In effect, the mock lets you say, “I know that at some point I’ll want this, but I don’t want to be distracted by thinking about it.” It’s like a to-do list for TDDers.
[…]
The other way in which we can use mock objects is to investigate integration with external code, such as Apple’s frameworks or third-party libraries. The mock object can remove all of the complexity associated with using the framework, so the test doesn’t need to create a full-blown environment just to ensure a small part of our app’s connection to that environment. This use of mock objects follows a test pattern called the Humble Object.
[…]
A nice mock records the messages it receives, just like a regular mock, but it doesn’t worry about receiving messages that it wasn’t told to expect.
[…]
Partial mocks act as proxies to real objects, intercepting some messages but using the real implementation for messages they weren’t told to replace.
Objective-C OCMock Programming Testing
Ole Begemann:
Because the current progress is thread-specific, it is important that the worker object creates its progress object on the same thread it was invoked on. Otherwise, the parent-child relationship will not be set up correctly. Once created, NSProgress objects are thread-safe. The worker object can later update properties on the progress from any thread/queue.
The view controller observes the progress using KVO, but the observer method is called on the worker’s thread/queue, so it has to tell the main thread to update the user interface. It seems like this could perhaps be simpler, but overall it looks like NSProgress has a pretty clean API. It’s definitely one of the more interesting new Cocoa features.
Cocoa iOS 7 Key-Value Observing (KVO) Mac OS X 10.9 Mavericks NSProgress Programming
Florian Mueller:
A damages expert will argue on Apple’s behalf that, if the parties had acted reasonably and rationally in a hypothetical negotiation, Samsung would have agreed to pay $40—forty dollars!—per phone or tablet sold as a total royalty for the five patents-in-suit, which relate to (but don’t even fully monopolize) the phone number tapping feature, unified search, data synchronization, slide-to-unlock, and autocomplete. The theory is that Samsung would simply have raised its prices accordingly. (You can find the final list of Apple’s patents-in-suit here; that post also lists Samsung’s patents-in-suit, but three more patent claims have since been dropped).
[…]
Apple’s royalty-type damages claim for five software patents is also far out of the ballpark of anything that has ever been claimed or rumored to be paid in this industry for entire portfolios. After Apple and Nokia settled in 2011, the highest per-unit royalty estimate I heard about (and this was just an analyst’s claim, not official information) was in the $10 range—for Nokia’s huge portfolio of SEPs and non-SEPs, not for a handful of patents. Guesstimates of what various Android device makers pay to Microsoft—again, for a portfolio license, not a five-patent license—that have appeared in the media did not exceed $15–20 per unit, at least the ones I’m aware of. (And Microsoft has a stronger software patent portfolio than Apple.)
Android Apple iOS Legal Patents Samsung
