#xcode7

[mobileappsdevelopmentservice]

xCode 7 with Swift 2 - Here’s All You Need To Know - Solution Analysts

xCode 7 with Swift 2 is available for update on the App Store and the Integrated Development Environment (IDE) is going to greatly aid developers worldwide in iPhone app development by allowing them to build apps and deploy them directly on the Apple devices.

[mobileappsdevelopmentservice]

xCode 7 with Swift 2 – Here’s All You Need To Know

xCode 7 with Swift 2 is available for update on the App Store and the Integrated Development Environment (IDE) is going to greatly aid developers worldwide in iPhone app development by allowing them to build apps and deploy them directly on the Apple devices. All that needs to be done is to sign in with the Apple ID, create an app out of the idea and use it on the iPhone, iWatch or iPad.

What’s with xCode 7:

You will find more xCode development tools that will extend support to Watch OS 2, iOS 9, and OS x El Capitan. These will support testing, debugging, development and deployment. You can even detect memory corruption and test the app UI to ensure it does not consume too many resources. The prominent features for Swift 2 include interface testing and updated playgrounds.

Features of xCode 7:

· Better UI testing with auto-generated tests that can be run as part of the test suite

· Includes migration tools and support features for Watch OS2

· StackViews are added to the Interface Builder for simplification of Auto layout UI construction

· There is an address sanitizer to pick up codes that are likely to crash at runtime

· Animation design timeline with 2D and 3D support added for gaming editors

· Better crash logs managements for OS X and app extensions

· All assets are uploaded to the App Store by app thinning for optimized UX

Original Source: All Need To Know About Xcode7 with Swift2

[for-the-user]

dismissing the keyboard with swift 2

class MyViewController: UIViewController, UITextFieldDelegate { @IBOutlet weak var someTextField: UITextField! override func viewDidLoad() { super.viewDidLoad() self.someTextField.delegate = self } func textFieldShouldReturn(textField: UITextField) -> Bool { self.view.endEditing(true) return false } }

Hiding the keyboard when touching somewhere on the screen.

class MyViewController: UIViewController, UITextFieldDelegate { @IBOutlet weak var someTextField: UITextField! override func viewDidLoad() { super.viewDidLoad() self.someTextField.delegate = self } override func touchesBegan(touches: Set, withEvent event: UIEvent?) { someTextField.resignFirstResponder() self.view.endEditing(true) } }

[for-the-user]

passing variables between view controllers and storyboards with swift 2

Technique 1. Between View Controllers

Make sure you have a segue between two view controllers and the segue has a name. Option drag the mouse to create a segue between two Views and then select the segue and its Attribute Inspector tab. You'll see some field named "Identifier" and you'll want to add a unique identifier for it. Let's call this identifier "someSegueID"

In the first view controller's class, right at the bottom after viewDidLoad(), place this code.

class 1stViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() . . . } override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) { if (segue.identifier == "someSegueID"){ let myDestinationViewController = segue.destinationViewController as! 2ndViewController myDestinationViewController.variable1 = "some string" myDestinationViewController.variable2 = 123 myDestinationViewController.variablex = someDict["someKey"] } } }

In the second view controller's class make sure the variables you are passing to it are declared right at the top of the class.

class 2ndViewController: UIViewController { var variable1:String! var variable2:Int? var variablex = [AnyObject:AnyObject]() }

Technique 2. Between Storyboards

You can put this anywhere in your code you want the app to move to your other view in another storyboard.

let storyboard = UIStoryboard(name: "Transactions", bundle: nil) let myView = storyboard.instantiateViewControllerWithIdentifier("secondView") as! 2ndViewController myView.variable1 = "some string" myView.variable2 = 123 myView.variablex = someDict["someKey"] self.presentViewController(myView, animated: true, completion: nil)

And similarly, make sure the second view controller has variables declared.

class 2ndViewController: UIViewController { var variable1:String! var variable2:Int? var variablex = [AnyObject:AnyObject]() }

Technique 3. Global variables

Ughh favourite way, no fuffing about. Somewhere, maybe in a dedicated file for all of your global variables, create them like this.

import UIKit public var variable1:String! public var variable2:Int? public var variablex = [AnyObject:AnyObject]() class class myViewController: UIViewController { . . . }

Now you can use these suckers from anywhere without having to override anything. Just keep in mind though that if you re-declare these in another class, the class will know about both of them.

public var variable1:String! class class myViewController: UIViewController { var variable1:String! self.variable1 = "hello" variable1 = "world" print(self.variable1) }

variable1 will hold the string "hello" when printed.

[macosten]

My life is a meme

[cubycode]

Check out the video preview of iLogin, a brand new app template to save logins from wesbites

[cubycode]

Stores Around #app video preview | soon on #codecanyon #startup #freelance #indeidev #ios93

[whatsaswift]

Absolutely Crashing: The Land of OO - ‘Orphaned Outlets’

Swift 2 (Swift 2.2), Xcode7

When you’re using Xcode to make your app, you’ll see errors and warnings pop up in the gutter of your code, letting you know where problems are, or could be in the future. But sometimes we run the app in Simulator and it crashes, even if the code looks fine. Broadly speaking, this is the difference between ‘Compiler Errors’ (errors that need to be fixed before the code can be run) and ‘Runtime Errors’ (errors that occur when we are running the app).

When this happens we open our debugger. At the top right of Xcode are the buttons shaped like rectangles with lines in them, which we use to show or hide the Navigator (left) and Utilities (right). The button with the line at the bottom shows the Debug area.

When our app crashes, it should come up with an error message in the right of the debug menu. These error messages, as you’ve probably got used to with Xcode, come in a wide range of usefulness, from telling you what the problem is, to spitting out gibberish and leaving you on your own.

We’re going to cover one of those confusing errors today. Specifically a thing called an ‘Orphan Outlet’. These are reasonably common, and cause your pretty top-tier crashes, before it even seems to be touching the code that you’ve written.

It might look something like: Terminating app due to uncaught exception ’NSUnknownKeyException’, reason: [insert specific for you information here]: this class is not key value coding-compliant for the key [name of Orphaned Outlet].

So, what is an ‘Orphaned Outlet’, and why do they happen so frequently?

Well when we make things in Main.storyboard (that’s our visual app interface), we get used to making Labels and Buttons and those sorts of things, pulling up the Assistant Editor (the bit that pulls your code up alongside) and ctrl-dragging one of these elements into our code, connecting them. All well and good.

However sometimes we think, ‘Actually, I don’t need that Label connected anymore’ or ‘I don’t really need that code’ and delete the lines of code that that process added.

This creates the ‘Orphaned Outlet’, because behind the scenes it’s still all connected, and the app gets cranky when trying to put things together that aren’t in the code anymore.

How do we check for them and get rid of them then?

We can use the ‘Connection Inspector’ (6th tab in your right-hand Utilities, or alt-cmd-6) to show all of our connections when we click on each element. It will be pretty obvious if the element has a connection - it will be ringed in darker grey. These tell you what it is known as in the code e.g. myLabel, and the section it relates to, e.g. View Controller. This means you should be able to fairly easily search through your code and see if it’s used if you’re not sure.

If you find an OO, then you can delete it. This means going to that grey ring and clicking the little grey X next to the section label.

Or you can right-click (/two-finger click) on the element in your app display (e.g. main.storyboard) and do all of that from there, without the Connection Inspector. Either’s good.

If you know you’ve been doing a lot of connecting, deleting and messing around with elements, and you’re getting a confusing sounding crash, then it might be worth having a check for some ‘Orphaned Outlets’.