Outwarians Jeames, Mahmudul, Tina and Tom (L-R) at WWDC AltConf where Mahmudul presented a talk on ResearchKit, ‘Less data, more research’.
Jeames gives us his update on all the latest news from WWDC Day 2 below:
CocoaTouch / UIKit
The new multitasking in iOS 9 on iPad allows 2 apps to run at the same time. The layout engine uses size classes to handle resizing your iPad app to work while in multitasking.
This means that when your app is in side-bar mode or split screen mode it uses a compact width (Similar to an iPhone application) to layout its views. This means for apps using size classes and that work on iPhone, this should be an incredibly straightforward process.
There is also a new picture in picture mode for apps that play video. This means you can watch your video on screen (move it around and resize) while using other apps. There are some new APIs for handling this.
A new UI component! The
UIStackView is a sort of “flow” layout similar to that on the apple watch. You add components to it and they are automatically stacked vertically or horizontally. The
UIStackView handles all of the constraints for you, and you can adjust the spacing and alignment as you wish. It fully supports nesting (Unlike
UITableView!) which means you can create complex interfaces using stack views.
iOS 9 adds a bar of assistant items above the keyboard alongside the word suggestions. These are customisable by apps creating a standard way to handle extra keyboard buttons in your app.
Linking! You can now move sections of your storyboard into separate files and link them via storyboard references. This should be great for complex storyboards that previously were large and unwieldy.
You can also now unwind segues via storyboards.
iOS now provides a built in touch prediction API, which will provide you with the predicted future location of the users touch, to allow smooth and responsive interactions.
Notification Text Input
Allow text input from users with a custom push notification. You can use this for a custom reply to a message, or any quick text input directly on the notification without opening your app.
Apple has included some great changes to objective-c to facilitate usage with swift, but I think these changes are really great for the language even without the swift compatibility. Video available here.
This was introduced in an earlier version of swift, but I strongly recommend that everyone use this in their Objective-C applications. Being clear and explicit of where a null value makes sense in your API is an incredibly powerful tool, and helps the compiler to pick up errors as you write them, instead of once it crashes.
We have already started using these on CabFare and find them incredibly useful!
Typed Collections allows you to specify the types allowed in your collection types, giving a sort of static type safety to objective c. eg.
NSArray<UIView *> subviews
We now know that this is a collection of UIViews, and if we try and put something else in there, it will show us a warning at compile time.
When using typed collections, KindOf types allow implicit downcasting of types where needed.
Here we are specifying that
subviews elements will always be a
UIView, or a subclass of
UIView. Here we can call the setTitle method of
UIButton without explicitly casting. This allows more explicit type information throughout your app, instead of relying on
id which could be anything!
The Swift language has been updated with some great new language features and tooling with version 2.0. Video available here.
A powerful way of explicitly handling edge cases in your functions, that works really well with Swifts if-let syntax. eg.
guards can be used with any condition, but also allows for optionals unwrapped with let to stay around for the rest of your method.
The defer statement will ensure that the code inside will be executed at the end of the current scope. eg.
This will ensure that doAThing() always runs at the end of the current scope, no matter where it exits. This is great for making sure clean up operations happen after throwing errors or exiting early from a function.
We all love to hate NSErrors and the pattern of passing references to them around our code. Swift 2 introduces a new paradigm for handling errors which is baked into the language, making writing code that can fail much cleaner and easier.
Here’s a small example of what the code looks like, see the session for a more in depth example of how it works.
The error handling employs an ErrorType protocol (Which NSObject conforms to), so you can create your own errors by implementing this.
Note that this is not like exceptions in java. You can’t throw an error from anywhere, it must be explicitly marked as
throws to allow the function to do this. This makes Swift error handling much easier to debug, and much more performant.
API Availability Checking
Checking for system versions is now super easy in swift.
#available(OSversion) can be used to switch out code based on the users device.
As an added bonus, the compiler will now show a warning if you try and use features and are unavailable for your current deployment target.
You can now extend protocols with functions! For example you may want to add a method that can be used on any collection type like array, dictionary etc. The example given in the session is adding a countIf method for conditional counting.
This functionality also allows many previously global functions such as map and filter to be chained with much clearer semantics. eg.