Apple’s first GitHub-released open source project is a big thing. There’s much to learn here - I’ve spent some time reading through the source, here are my observations.
In UIKit, unlike AppKit on the Mac, there’s currently no public way to detect the first responder. There are several clever and less clever workarounds (like iterating over all views) or using a weak variable and UIApplication’s sendAction:. Of course Apple hit this issue in ResearchKit as well and their solution also uses sendAction:. If you feel like there should be an official
firstResponder method much like there is in AppKit, please help and file a radar or dupe mine (rdar://20549460). (If you wonder, of course this method exists as private API)
Apple uses a nifty macro to ensure the class is of the expected type:
#define ORKDynamicCast(x, c) ((c *) ([x isKindOfClass:[c class]] ? x : nil))
Apple added Dynamic Type in iOS 7 to give the user more control about how large text in apps should be. We’re now less than two months away from iOS 9 yet many apps still ignore this, and almost no app properly reacts to changing this setting at runtime. The system sends a
UIContentSizeCategoryDidChangeNotification, however there’s no easy way to re-build the UI with a different font. Apple’s way of solving this is subclassing common view classes like
UILabel with their
ORKLabel, which fetches the new font and then invalidates its intrinsic content size to trigger a new Auto Layout pass. Similar patters are in
ORKTextButton. This pattern however makes it hard to set custom font sizes. One could extend these classes to accept a font text style like
UIFontTextStyleHeadline to make this more flexible. Apple instead uses subclasses like
ORKTapCountLabel to customize the font size.
In Apple’s initial release, there are two radars referenced.
19528969 to work around an Auto Layout issue and
19792197 to work around an issue with tinting animated images. Of course there are no detailed entries on OpenRadar but it’s easy to read and at least the workarounds are marked as such. It will be interesting if these radars are a priority on being fixed…
All views are created in code. Apple uses a Storyboard for the example catalog, but that’s it. Apple uses the standard pattern of overriding
viewDidLoad to build UI in combination with Auto Layout and the visual format language, whenever possible.
Creating PDF from HTML
This was particularly interesting, since my main job is working on PSPDFKit - a PDF framework for iOS and Android.. In there we have code that allows converting HTML to PDF via (ab)using
UIWebView and the printing subsystem. This is marked as experimental as we were under the impression that it’s not intended usage and more likely works by accident. However Apple’s now using the exact same technique (ORKHTMLPDFWriter) in ResearchKit, so this seems to be an acceptable way of converting HTML documents.
It’s really great to see that every class is fully annotated with
NS_ASSUME_NONNULL_BEGIN/END. This makes usage much nicer, especially with Swift, but also is great documentation in general. Time to annotate your classes as well!
Since we’re at Swift… ResearchKit is 100% Objective-C. And I’m sure this was started when Swift was already post 1.0 so time is not the reason. Then again, the example catalog is completely Swift. Objective-C is a great choice for frameworks as you can decide selectively which methods should be public and which ones private - with Swift, this is currently not yet possible.
Update: Access control actually is in Swift since 1.0, so this isn’t the reason they went with Objective-C. Maybe because of the still immature tooling? (and SourceKit crashes)
There’s no clear pattern when Apple uses
_Internal and when
_Private for private class extensions, however it’s great to see that they do try to keep the API small and only expose the necessary parts.
Large text like the consent review language is displayed by view controllers that embed web views. This is all based on
UIWebView - so far no
WKWebView is being used here. For regular text, that’s perfectly ok and probably even preferred since it’s a lot simpler to use and doesn’t spin up a separate process. On the other hand, Apple consistently uses
UIAlertController - there are no references to the legacy
UIActionSheet APIs anymore.
It’s great to see Apple adopting secure coding everywhere. They’re using a set of macros to make the code less repetitive but overall there’s nothing special about it.
There’s a bunch of interesting details on how Apple approaches accessibility support here. Notable is the
ORKAccessibilityStringForVariables macro which allows string concatenation, ignoring empty or nil strings. (sample usage)
ResearchKit contains a few checks for iOS 8.2. Why? Because HealthKit really didn’t work before that release. However instead of checking for the foundation version (fast) or using the new
isOperatingSystemAtLeastVersion method on
NSProcessInfo, they’re converting the version to float and then compare - the worst way of version checking. I went ahead and wrote a pull request to fix that. We’ll see if that gets merged :)
Yes, there are unit tests. They don’t use a Host Application, so they’re all purely model-tests. I’d love to see view/integration tests as well, but it’s a start.
If you’re wondering how Apple pulled of these nifty animations and were expecting some advanced path animation code, I have to disappoint - it’s just a set of videos. However, there’s a lot more to it. They are coordinated by
ORKVisualConsentTransitionAnimator which is powered by
ORKEAGLMoviePlayerView - complete with custom shaders. This is a lot of code to tint a video on the fly!
Overall, ResearchKit is very well done. You could critizise some naming inconsistencies, indentation or spacing, but the overall structure is good, and I’m very excited how much better it’ll get once Apple starts merging the onslaught of Pull Requests.. Writing a framework is certainly a challenge - many shortcuts one can do with writing Apps don’t apply. Follow me on Twitter for even more updates. Oh, and if you would love to work on frameworks full-time, we’re hiring.