Archive for December 13, 2014

Saturday, December 13, 2014 [Tweets] [Favorites]

Fox: a QuickCheck-Inspired Testing Framework

Jeff Hui (via Ole Begemann):

Test generation can provide better coverage than example-based tests. Instead of having to manually code test cases, Fox can generate tests for you.

What is Fox?:

Property-Based Testing Tools, especially ones inspired from QuickCheck, are test generators. These tools allow you to describe a property of your program that should always hold true instead of writing hand-crafted test cases.

[…]

In the mathematical sense, Fox is a weak proof checker of a property where the tool tries to assert the property is valid by randomly generating data to find a counter-example.

[…]

The benefit of Fox over purely random data generation is Shrinking. An informed random generation is done by size. This allows the tool to reduce the counter-example to a smaller data set without having a user manually separate thes signal from the noise in the randomly generated data.

We Need a “Safari View Controller”

Bryan Irace (via Marco Arment):

It’d be wonderful if Apple provided a “Safari view controller” that developers could present directly from within their applications. This controller would run out of process and work almost exactly like MFMailComposeViewController and MFMessageComposeViewController already do for composing emails and text messages respectively. The app would provide the controller with a URL (and optionally, a tint color), but otherwise what the user does in it would remain secure and isolated from any third-party code, yet fully integrated with Safari.app and Safari controllers presented by other applications.

Update (2015-07-24): Federico Viticci:

For a long time, iOS apps have been able to open links as web views. When you tap a link in a Twitter client, an RSS reader, or a bookmark utility, it usually opens in a mini browser that doesn’t leave the app, providing you with the convenience of not having to switch between Safari and the app. For years, in spite of some security concerns, this worked well and became the de-facto standard among third-party iOS apps.

With iOS 9, Apple wants this to change – and they’re bringing the power of Safari to any app that wants to take advantage of it.

[…]

In a technical session at WWDC, Apple detailed how Safari View Controller has been closely modeled after Safari with consistency and quick interactions in mind. Safari View Controller looks a lot like Safari: when users tap a web link in an app that uses Safari View Controller, they’ll be presented with a Safari page that displays the address bar at the top and other controls at the bottom or next to it – just like the regular Safari on the iPhone and iPad. There are two minor visual differences with Safari: when opened in Safari View Controller, the URL in the address bar will be grayed out to indicate it’s in read-only mode; and, a Safari button is available in the toolbar, so that users will be able to quickly jump to Safari if they want to continue navigation in the full browser.

What Happened to NSMethodSignature?

Apple:

Bringing the Cocoa frameworks to Swift gave us a unique opportunity to look at our APIs with a fresh perspective. We found classes that we didn’t feel fit with the goals of Swift, most often due to the priority we give to safety. For instance, some classes related to dynamic method invocation are not exposed in Swift, namely NSInvocation and NSMethodSignature.

We recently received a bug report from a developer who noticed this absence. This developer was using NSMethodSignature in Objective-C to introspect the types of method arguments, and in the process of migrating this code to Swift, noticed that NSMethodSignature is not available.

[…]

With a combination of protocols and generics, we have written Swift code to elegantly create and register HTTP handlers of varying types. This approach also lets the compiler guarantee type safety, while ensuring excellent runtime performance.

David Owens:

Seriously, someone asks for the functionality for dynamic dispatch and you say you can do the same thing with static code! No, you cannot. You can mimic the behavior.

Instead, you showed someone how to build a static registration table. Then you make the statement that it’s “type-safe” while using Any as the arguments to the public API for dispatch and using type coercion… that’s not type-safety. And let’s be honest, it’s really not that different then the validation one does for dynamic dispatch either.

[…]

You see, and this is the trade-off that you never mention. You paint an extremely biased position without covering the full gambit of what is really needed to build and maintain a system like you are proposing. The reality, it sucks.

Not to mention the other things you can do with NSInvocation that can’t be mimicked with static code.

Update (2014-12-13): Daniel Luz:

I can only infer the use case from what was presented, but it seems to me you solved the wrong problem here