WWDC Session Notes-unification for iOS interface development

One of the more emphasized themes in IOS 8 and OS X 10.10 is unification, Apple's desire to seamlessly switch and integrate with Hand-off and a variety of experiences to stick users in an ecosystem of Apple devices. For developers, a major theme for Swift this year is the unity of the platform. At the beginning of what's New in Cocoa Touch Seesion, UIKit's engineer Luke pointed out that the most important keyword for the IOS 8 SDK is adaptive (adaptivity).

This article is an article in my WWDC 2014 note that involves a Session that has

What's New in Cocoa Touch

Building Adaptive Apps with UIKit

What ' s New in Interface Builder

View Controller Advancements in IOS 8

A look Inside Presentation Controllers

One of the more emphasized themes in IOS 8 and OS X 10.10 is unification, Apple's desire to seamlessly switch and integrate with Hand-off and a variety of experiences to stick users in an ecosystem of Apple devices. For developers, a major theme for Swift this year is the unity of the platform. At the beginning of what's New in Cocoa Touch Seesion, UIKit's engineer Luke pointed out that the most important keyword for the IOS 8 SDK is adaptive (adaptivity). This is a very exciting word, the first adaptation is a design philosophy, as far as possible to keep things simple, we can censor from the elegant, on the other hand, perhaps this is the change Apple has to do. With the advent of the legendary bigger screen and the IPhone 6, developers seem to be having problems with Android-like device size when developing for IOS. And what IOS 8 is focused on is the problem.

Size Classes

First of all, the IOS 8 app in the interface design, ushered in a can be said to be a revolutionary change-Size Classes.

Basic concepts

IOS devices have only one size before the IPad and IPhone 5 appear. The only thing we need to consider when making screen adaptations is the direction of the device. Many applications do not support steering, so there is no screen-fit job at all. With the launch of the IPad and iphone 5, and the next iphone 6, the screen size has become an object to consider. Before IOS 7, when making UI for an application, especially for universal, we would first think about the length and width of our target device, how the layout should change after the direction transformation, and then layout. IOS 6 introduces Auto layout to help developers lay out with constraints, which allows us to focus on using constraints to specify locations in some cases when we no longer have to consider dimensions.

Since we have Auto Layout, it is no problem to specify the location and size of the view through constraints, and in this regard, the specific size and orientation of the screen is less important. But in combat this is not enough, Auto layout as its name, is only a constraint to the layout of the scheme, and in the specific circumstances of the corresponding device for the experience is still missing. One of the most obvious problems is that it cannot determine different interaction experiences based on the type of device. Many times you still need to determine whether the device is an iPhone or an iPad, and whether the device is in a vertical or horizontal direction. In this case, it is still difficult to get rid of the judgment and reliance on the equipment, and then, if there are new sizes and devices, the dependency is obviously very fragile (think of IWatch). ）。

So in IOS 8, Apple overturned the original design philosophy and introduced a new set of ideas to adapt to the constant development of the device. This is Size Classes.

They are no longer differentiated according to the specific size of the device screen, but are divided into normal (Regular) and compact (compact) two categories (class) through their sensory performance. Developers can ignore the specific size, but rather the two types and their combination of adaptation. In this way, both at design time and in code, we can no longer be limited to the specific dimensions, but instead become the visual senses that follow the dimensions to fit.

To put it simply, the IPad is Regular in two directions, regardless of whether it's horizontal or vertical, and for the IPhone, the vertical is Regular in the vertical, the compact in the horizontal, and the compact in two directions across the screen. It is important to note that here and the equipment and direction mentioned are just to give everyone an intuitive impression. It is believed that this classification will be changed and updated as the device changes. Size Classes's design philosophy is dimension-independent, in practice we should try to put the specific size behind the brain, and to get accustomed to and adapt to the new system as soon as possible.

Uitraitcollection and Uitraitenvironment

To characterize Size Classes,apple introduced a new class--uitraitcollection in IOS 8. This class encapsulates information such as the Size class in horizontal and vertical directions. The basic classes of most UIs in IOS 8, including Uiscreen,uiwindow,uiviewcontroller and UIView, implement the Uitraitenvironment interface, through which the Traitcollec of UIKit tion This property, we can get the corresponding Uitraitcollection object, so that we know the current Size Class, and further determine the layout of the interface.

In contrast to the responder chain in UIKit, Traitcollection will be delivered from top to bottom in view hierarchy. For a UI part that does not specify Traitcollection, the traitcollection of its parent node is used. This can be quite useful when the layout contains the Childviewcontroller interface. Another very useful uitraitenvironment in this interface is-traitcollectiondidchange:. This method will be called when the traitcollection is changed. In practice, we tend to rewrite-traitcollectiondidchange in Viewcontroller: or-willtransitiontotraitcollection: Withtransitioncoordinator: Method (for Viewcontroller, the latter may be a better choice because the transition context is provided for easy animation, but for normal View there is only one way), The current traitcollection is then judged and re-laid and animated. The code will look something like this:

(void) Willtransitiontotraitcollection: (Uitraitcollection *) newcollection Withtransitioncoordinator: (ID<UIViewControllerTransitionCoordinator>) Coordinator {[Super Willtransitiontotraitcollection:newcollection Withtransitioncoordinator      : Coordinator]; [Coordinator Animatealongsidetransition:^(ID<UIViewControllerTransitionCoordinatorContext>context) {          if(Newcollection.verticalsizeclass = =uiuserinterfacesizeclasscompact) {              //To do:modify something for compact vertical size}Else {              //To do:modify something for other vertical size} [Self.view setneedslayout];  } Completion:nil]; }  

In two to do, we should delete or add or change the Auto Layout constraints under different conditions (of course, you can do anything else you want), and then call-setneedslayout to trigger the transfer animation in context. If you stick with the code, you may have to face the problem of removing the old constraints and adding new constraints for different Size Classes, which can be a lot of trouble (at least I think it's going to be a problem). But if we use IB, these things and code can be omitted, we can very easily specify the various size Classes constraints in IB (we will show how to use IB to correspond to size Classes). In addition to the use of IB can not only save hundreds of lines of layout code, but also from the new Xcode and IB to get a lot of design can be real-time monitoring, viewing and debugging features. It can be said that the time-consuming and cost gap between the handwritten UI and the IB design has been further widened, and many of the handwriting UI has not been implemented, but IB can do it without hesitation. In this sense, the new IB and Size Classes system can be said mercilessly to the handwritten code sentenced to a reprieve.

In addition, the introduction of new APIs and systems also sentenced the death penalty to many of our familiar uiviewcontroller of rotating old friends, such as the following API deprecated:

ReadOnly ) uiinterfaceorientation interfaceorientation     - willrotatetointerfaceorientation:duration:  - willanimaterotationtointerfaceorientation:duration:  - didrotatefrominterfaceorientation:   -Shouldautomaticallyforwardrotationmethods  

Now all is unified to the Viewwilltransitiontosize:withtransitioncoordinator: the concept of rotation is no longer advocated for use. In fact, think about, the so-called rotation, but it is a change of Size, we have been Apple for many years, is not it?

Farewell, I'll not miss.

Use Size Classes in Interface Builder

The first time you touch Xcode 6 and open IB you may exclaim why my canvas has become a square. When I first opened it in the canteen of Moscone Center at the end of the first day of Keynote, I thought I had found the solid evidence of the iWatch square display. It was later learned that this is the new Size Classes corresponding to the editing method.

Since we don't need to be concerned about the actual size, then there's absolutely no need to use an iPhone like 3.5/4 in IB or a 10-inch IPad to edit the interface separately. Using a generic size that has a "representative" nature is certainly less confusing in the new system.

Just below the current IB interface, you can see a wany hAny button (because this year's NDA is a clear limitation that cannot be sent related software, although it may not be much problem, but still respect license better), which means that the current IB is corresponding to any height and any width. After clicking, you can choose which Size Class you want to edit. By default, any modification under any will take effect on any device and in any direction, and if you make a selection and then edit it, the edits take effect only on the selected settings. This makes it easy to adapt different devices in the same storyboard file: Add or edit certain constraints as required by the device, or hide some view under a certain size (added with the plus sign of the installed marquee in the Attribute Inspector). This makes it easy to make generic programs using IB, and we no longer have to prepare two sets of storyboard for the IPhone and IPad.

Can play the imagination space is too large, a set of interface layout-take all the device's picture is too beautiful, I dare not think.

Size Classes and Image Asset and Uiappearence

Image Asset also adds support for size Classes, which means that we can specify different images for different size classes. Select a picture in the edit panel of image Asset, Inspector now has a combination of Width and Height, add the size Class we need, and then drag the appropriate graph up so that the SDK will pick the corresponding size from the runtime. The diagram is replaced. Moreover, in IB we can also choose the corresponding size to see the changes directly at the time of editing (new Xcode and IB have added a lot of editing visual features, I have a plan to write a separate article on visual development to explain).

One of the most useful aspects of this feature is that the size of the images we need may vary for different screen sizes. For example, we want to have a higher button on the iphone's vertical screen or iPad, and when the iphone is flat, we want a flat button because the screen height is limited. For solid-color buttons we can do it with simple constraints and stretching, but for patterned buttons, we may need to write some dirty code in the VC to deal with. Now, just to specify a specific Image Asset, and then configure the appropriate (such as without the size limit) constraints, we can do a line of code does not write, to complete the various models and the direction of this complex adaptation.

Actually it is too simple to do. But take a demo to explain it, such as the following this implementation of the Compact in the vertical direction when the smiley face changed to cry--of course, a line of code is not required.

In addition, UIImage adds a Renderingmode property in IOS 7. We can use Imagewithrenderingmode: and pass in a suitable uiimagerenderingmode to specify whether the image should be rendered in the same way as the Template. In the new Xcode, we can specify whether it needs to be used as a template directly in the Render as option in Image Asset. and accordingly, in Uiapperance, Apple also added the appropriate method for our Size Classes. Using the +appearancefortraitcollection: method, we can make very simple settings for the apperance of applications under different trait. In the example above, we want to make the smiley face green, and the cry is red, not too simple. First, the render option in image Asset is set to Template Image, and then the two lines are added directly to the appdelegate:

Uiview.appearancefortraitcollection (Uitraitcollection (verticalsizeclass:. Compact)). Tintcolor = uicolor.redcolor ()            

Complete, just drag and drop the mouse, two lines of simple code, and then also can rejoice color change, is really big fast all people's big good.

How the Uiviewcontroller behaves

Uisplitviewcontroller

After unifying the design of the IB interface with the Regular and Compact, Apple's engineers may have found a dilemma in the history of Uisplitviewcontroller. Children's shoes, which have been making iphones and not too involved with the ipad, may not be familiar to the class because they are ipad only. Apple has designed the Viewcontrolle container for the master-slave relationship for the ipad, in an attempt to adapt to a sudden-changing screen and away from the "ITouch" of the larger version. The fact that this design is really widely used on the IPad has proved to be very successful.

The question now is, if we only have a set of UI canvases, how do we handle and represent this IPad only class on this single canvas?

The answer is, make it available on the IPhone as well. Yes, now you can use Splitviewcontroller directly on your iPhone. When the width of the Regular, it remains the original feature, in the Detailviewcontroller display content, there is no doubt about it. In the Compact, our first idea is to show it in the form of push. In the past, we might need to write a lot of code to deal with these things, such as in Appdelegate at the outset to determine whether the device is an iPad, and then set two sets of completely different navigation for the application: a set based on Uinavigationcontroller, and another set based on Uisplitviewcontroller. And now we only need a set of Uisplitviewcontroller, and set its masterviewcontroller to a navgationcontroller can easily take care of everything.

You might think, even so, whether I still need to judge whether the device is an iPad, or whether the Size Class is the Compact, to decide whether to do NAVVC push or change SPLITVC viewcontrollers. In fact, we can now painless without judgment, directly in a unified way to complete the two forms of expression. The trick is that we don't need to use (in fact, Apple is no longer advocating it after IOS 8) Uinavigationcontroller's pushviewcontroller:animated: Method (another old friend wants to say goodbye to us). In fact, it is often used, but this method has been discussed by the community: because it is the existence of this method makes Viewcontroller the coupling characteristics of a grade. The existence of this method in a viewcontroller means that we need to ensure that the current viewcontroller must be in the context of a navigation stack, which is a way of fully and context-coupled (though we can also use judgment in a very painful manner. Navcontroller is not nil to bypass, but after all, really ugly, isn't it).

We now have a new way of showing Viewcontroller,-showviewcontroller:sender: and-showdetailviewcontroller:sender:. When these two methods are called, they are followed by a response chain that includes invoking the VC itself, looking for the most recent implementation of the method's Viewcontroller to execute the corresponding code. In the default implementation of the IOS SDK, there are already implementations of these two methods in a container class such as Uisplitviewcontroller, and Uinavigationcontroller also implements the-showviewcontroller: Sender: The version. For VCs in the Navcontroller stack, the push mode is called for display, while for Splitvc,showviewcontroller:sender: Push is performed in Masterviewcontroller. The Showdetailviewcontroller:sender: will be selected according to the Size of the horizontal direction: for Regular, the new VC will be displayed in Detailviewcontroller, and for the Compact case, The navcontroller that are sent back to the subordinate by the context in which they are located, or are presented directly in a modal manner. For the specifics of this section, you can take a closer look at this sample project and the associated documentation (beta version).

The benefits of this design are obvious, first of all, to release the original coupling, so that our viewcontroller can not be confined to the navigation controller context, and these methods are public, that is to say our Viewcontroller can implement both methods, Truncate response chain responses and implement our own rendering methods. This is useful when customizing the Container Controller.

Uipresentationcontroller

IOS 7 Adds a set of ways to implement a very nice custom transition animation (if you don't know or remember, take a look at my note last year). Apple's efforts to decouple and reuse are truly breathtaking. This year, along with the development of the United East of the Adaptive Peace Platform, Apple has made the biggest change since the advent of the IOS SDK in the Viewcontroller way. A very important class Uipresentationcontroller is added to IOS 8, and this nsobject subclass will be used to manage the rendering of all viewcontroller. In the implementation, this class is completely decoupled from several classes of last year's custom transitions. Apple is also using this class completely in its own various viewcontroller presentation.

Bye, Uipopovercontroller.

Similar to Splitviewcontroller, Uipopovercontroller was originally used by the IPad and is now available on the IPhone. To be precise, now we are no longer using the Uipopovercontroller class (though the document has not yet been labeled as deprecated, but it is also a matter of time), instead of a new class Uipopoverpresentationcontroller. This is a subclass of Uipresentationcontroller, specifically designed to render content in popover form, and is the class used in IOS 8 to replace the original Uipopovercontroller.

What are the advantages of the new approach compared to the original class? The biggest advantage is adaptive, which is similar to Uisplitviewcontroller's performance under IOS 8. Under the Compact width, the uipopoverpresentationcontroller will become modal directly. That way we don't have to judge the IPhone or the IPad at all (in fact, the relevant decision method has been marked as deprecated), so that it can correspond to different devices. Previously we might have to write code like this:

if Uidevice.currentdevice (). Userinterfaceidiom = = . Pad {        = Uipopovercontroller (CONTENTVIEWCONTROLLER:NEXTVC)      true)    else  {      true

And what needs to be done now is:

Nextvc.modalpresentationstyle = . Popover    = nextvc.popoverpresentationcontroller    = arect    = . Any    true, Completion:nil)  

There is no abominable condition to judge, everything is well-organized and readable.

In addition to adaptive, another advantage of the new approach is that it is very easy to customize. We can implement the presentation we want by inheriting Uipopoverpresentationcontroller. In fact, more precisely, we should inherit the Uipresentationcontroller, mainly by implementing-presentationtransitionwillbegin and-presentationtransitiondidend: From defining our presentation. As before we want to achieve only half of the screen, the back of the original view of the modal, or to the bottom to the top of the animation to the blinds or fade out, it is a very cost-consuming thing. And with the help of Uipresentationcontroller, everything becomes very natural and simple. In your own Uipresentationcontroller sub-class:

 override   func Presentationtransitionwillbegin () {Let transitioncoordinator  = Self.presentin Gviewcontroller.transitioncoordinator () transitioncoordinator.animatealongsidetransition ({context  in  // do animation here  }, Completion:nil)}  override   func PR Esentationtransitiondidend (completed:bool) { // do clean here } 

The specific usage is similar to the custom transitions in IOS 7, setting the Viewcontroller transition delegate that need to be rendered, in the Uiviewcontrollertransitioningdelegate- Presentationcontrollerforpresentedviewcontroller:sourceviewcontroller: Use-initwithpresentedviewcontroller in the method: Presentingviewcontroller: Generate the corresponding Uipresentationcontroller subclass object back to the SDK, then you can have tea to see the play.

Goodbye Uialertview, Goodbye Uiactionsheet

Another big change that adaptive and Uipresentationcontroller bring to us is the demise of the two classes of Uialertview and Uiactionsheet (well, it's not really the end of the story, it's deprecated). Now, the presentation of Alert and Actionsheet is also implemented through Uipresentationcontroller. There is no Size Class and need to deal with the Dark Age of rotation (sorry to use the word here, but I really do not miss the time of the processing equipment rotation), the two view is displayed in fact, behind the scenes is a heap of disgusting things: Create a new window, handle the new window Size and direction, then add the alert or action sheet to the window in the appropriate size and direction, and then consider handling the turn and finally show it. While Apple has helped us do these things, it is often our turn to use them only to meet the most basic needs. When it comes to the IPhone and IPad, Uialertview is fine, but for uiactionsheet we often have to deal with it differently to choose whether we need to popover.

Another deadly place is because these two classes are the grandfather class that started in IOS 2.0, and there has been no big update lately, and the design pattern is also using a traditional delegate set of things. In fact for this very light very clear use logic, block handler is the best choice, you don't see full of GitHub block Alert View Code, but there is no way, 4.0 blocks have been for a variety of reasons, in these two classes have not been officially recognized and use.

And as a substitute for the uialertcontroller is to solve these problems, it is worth noting that this is a uiviewcontroller subclass. Maybe you would ask Uialertcontroller to replace Uialertview, which is good, but what about Uiactionsheet? Ha.. The answer is also with Uialertcontroller, there is a Preferredstyle attribute in Uialertcontroller, which gives us two options Actionsheet and Alert for the time being. In actual use, this class of API is very simple, using the factory method to create the object, the configuration is directly present out:

Let alert = Uialertcontroller (title:"Test", Message:"MSG", Preferredstyle:. Alert) Let Okaction= Uialertaction (title:"OK", Style:. Default) {[Weak alert] actioninchPrint ("OK Pressed") Alert!. Dismissviewcontrolleranimated (true, Completion:nil)} Alert.addaction (okaction) Presentviewcontroller (Alert, animated:true, Completion:nil)

There is not much to say in use except to be careful about circular references. Adding text input to Alert is also very simple, using-addtextfieldwithconfigurationhandler: Add a text input to it each time, and then get the data in the handler.

Keep in mind that, behind the scenes, the presentation is still uipresentationcontroller.

Uisearchdisplaycontroller-Uisearchcontroller

Finally, I would like to briefly mention the same similar changes when doing the search bar. Doing a search bar before IOS 8 is a uisearchdisplaycontroller thing, and now we don't need to hate it anymore, and there's no way to force a view in the views tree (if you've done the search bar, you should know what I'm saying). All of this is replaced by a uiviewcontroller subclass Uisearchcontroller, just like the alert and Actionsheet mentioned earlier in IOS 8. The rendering mechanism behind it is naturally also uipresentationcontroller, and the importance of this new class in IOS 8 is visible.

Summarize

For the majority of IOS developers rely on the survival of the UIKit, the biggest change is the introduction of Size Classes and the new Presentation system. On Keynot, Craig tells us that the iOS 8 SDK will be the biggest change since the advent of iOS. While the IOS 8 SDK's extensive use is estimated to have a two-year period, the unification of APIs for the development of different devices has taken a step forward, and that is exactly what Apple is going to do. Just as the Auto Layout two years ago is shining today, size Classes and the new Viewcontroller will become the main tool for daily development.

Programmers, it is necessary to keep learning every year to keep up with the times.