WWDC 2014. Wednesday News

On the third day, WWDC had more technical and less “intriguing” sessions (Integrating Swift with Objective-C, What's New in LLVM, Cross Platform Nearby Networking, Creating Custom iOS User Interfaces, etc.), passed master classes on using components and dive into swift.

Report by Arthur mc_murphy Sakharov, Redmadrobot



SESSION Integrating Swift with Objective-C

• Swift integrates very well into current objC projects. It is evident that Apple has been working very seriously on this issue - all so that developers would rather switch to Swift. The project can be simultaneously written in two languages. When the first .swift file is added to the objC project, Xcode creates a so-called Bridging Header - this is what will be seen from the custom objC classes in the Swift code. Very similar to the precompiled header in an objC project. All frameworks can be seen without it. Well, from objC-code you can see the whole Swift. Pretty simple and straightforward and easy to manage.
• When you call your own class method in Swift, you do not need to write self. That is, self.view turns into just a view. Finally. The entire syntax of objC classes is translated to Swift on the fly. We wrote a file with the MyClass class on objC, switched to another window with the Swift-code, and the MyClass hint will immediately look like it is written in Swift. Without recompilation, everything is on the fly.
• It comes to the fact that the translation on the fly gets up such things automatically: InitWithData: (NSData *) data type: (NSString *) type ⟷ init (data: NSData, type: String), that is, automatically removed / substituted with With in the init-structures .
• Finally, the general rule is that from the objC code, the entire Swift code looks like objC. From the Swift code, the entire objC code looks like Swift. Documentation, comments, syntax - everything is translated automatically.

Session Building Adaptive Apps with UIKit

• iOS 8 simplifies the layout for an extended family of devices (iphone 4/5, ipad, different orientations).
• All layout cases on all devices are reduced to 4 types: horizontally and vertically can be either Compact or Normal layout (this parameter is called sizeClass). That is, for each view I can separately provide a view in these four cases:

compact width, normal height
compact width, compact height
normal width, compact height
normal width, normal height
And this is enough for all devices and all orientations. And all this can be done in one storyboard with the mouse.

• Navbars are automatically hidden or reduced when there is not enough space; in the landscape, the status bar is completely hidden.
• A resizable ipad and a resizable iphone appeared in the simulator - that is, you can simply set the screen size in pixels, and everything will immediately be reversed on the fly. Convenient for debag. Apple is obviously plotting something with different screen sizes for iOS ...
• In the UIImage asses, special collections (TraitCollections) have been added to this case, from where the picture is selected according to the current size of the element on the screen. That is, we forget about @ 2x, now the layout is dynamic, in addition to retina / neretina there appeared an ipad / neipad and horizontally / vertically. And based on all this, the texture will be selected.
• In IB, they added all sorts of things that allow you to create constraints separately for different sizes / orientations. Thus, elements can now be placed vertically in portrait and horizontally in landscape orientations, without adding a single line of code. In general, the interface to create all of this looks quite understandable and convenient.
• All this can be perfectly viewed in IB on the fly. Open at once a lot of devices and watch how constraints behave when changing, without compiling and running.

Swift Playgrounds
Playgrounds are generally a breakthrough in the development process. Playgrounds in themselves a lot of things collected in a convenient form.
We want to check something, some feature. Instead of creating an empty project and writing something in it, setting it up and running it many times - this is how to open a notepad and check everything interactively.
')

What is the Swift Playground?

1. Playground is such a document format for Xcode. It includes code files and resources.
2. Each time the code changes, it automatically starts and the result immediately appears.
3. Both the code and the result are displayed in one window, side by side.

Why do we need playgrounds?

1. Learn a new language
2. Get acquainted with online documentation.
3. Teach newbies development in general
4. Quickly prototype algorithms and test them
5. Write code that draws something, without running it every time
6. To visualize any code that computes something.
7. For experiments with APIs and framework games.

What can playgrounds do?

1. You can see objects in QuickLook in any line of code.
2. UITableView is rendered in them, and when the code changes, changes are immediately visible.
3. If something in them is not rendered, you can write a custom QuickLook for any of its class.
4. You can debug asynchronous operations and view data from all threads at once.
5. There was a demo of how to develop the insertSort algorithm in the playground and illustrate all the steps of the algorithm. Impressive.

What not to do in the Playgrounds?

1. They do not support user interaction in any way; everything can be changed only through code.
2. This is performed only in the simulator, not on the device.
3. You can not import your frameworks (however, you can copy the code from them).

WWDC 2014. First impressions of the witness
WWDC 2014. Second Day Slice
WWDC 2014. Report for Thursday