Nash Equilibrium Nash Equilibrium - 5 months ago 20
iOS Question

Efficiency and Swift coding etiquettes

I had a few questions regarding what is right and what is wrong in terms of structuring a well coded application in XCode and Swift 2.

Example:
Is it okay to initialize Views and Fields as so in a class?

var name_field: UITextView?
var user_field: UITextView?
var email_field: UITextView?
var pass_field: UITextView?


And then customizing them in the viewdidload() or a func as so:

user_field = UITextView(frame: CGRectMake(20, sub_pad_1, fixed_width, fixed_height/2))
user_field!.textAlignment = NSTextAlignment.Center
user_field!.font = UIFont.systemFontOfSize(15)
user_field!.autocorrectionType = UITextAutocorrectionType.No
user_field!.keyboardType = UIKeyboardType.Default
user_field!.returnKeyType = UIReturnKeyType.Default
user_field!.delegate = self


I feel the exclamation points and question marks add potential risk of memory leaks and simply inefficiency to the structure of the code. Is there a way around it, as the sole reason why I have variables defined in such a way is to add the flexibility of accessing the objects class-wide within all the functions.

Answer

Example: Is it okay to initialize Views and Fields as so in a class?

None of the examples given are initialization (aka definition). Those are all declaration. For example, var name_field: UITextView? declares "There will exist a variable named name_field, of type Optional(UITextView). It does not initialize (or define) it to have any value.

I feel the exclamation points and question marks add potential risk of memory leaks and simply inefficiency to the structure of the code.

Memory leaks are not the issue when it comes to force unwrapping (!). A memory leak occurs when an object persists in memory when no more references exist to it. It's memory that can't be accessed (thus, can't serve any useful purpose), but isn't freed. It's completely unrelated to force unwrapping.

In this case, there's no reason at all to have those fields be optional. Something like this should still work, so long as the values are all set in the initializer:

struct Example {

    var name_field: UITextView
    var user_field: UITextView
    var email_field: UITextView
    var pass_field: UITextView

    init() {
        user_field = UITextView(frame: CGRectMake(20, sub_pad_1, fixed_width, fixed_height/2))
        user_field.textAlignment = NSTextAlignment.Center
        user_field.font = UIFont.systemFontOfSize(15)
        user_field.autocorrectionType = UITextAutocorrectionType.No
        user_field.keyboardType = UIKeyboardType.Default
        user_field.returnKeyType = UIReturnKeyType.Default
        user_field.delegate = self

        name_field = something
        email_field= something
        pass_field= something
    }
}

There's an even better approach, that better encapsulates the UITextView instantiation:

struct Example {

    var name_field: UITextView
    var user_field: UITextView
    var email_field: UITextView
    var pass_field: UITextView

    init() {
        user_field = {
            let uitv = (frame: CGRectMake(20, sub_pad_1, fixed_width, fixed_height/2))
            uitv.textAlignment = .Center
            uitv.font = UIFont.systemFontOfSize(15)
            uitv.autocorrectionType = .No
            uitv.keyboardType = .Default
            uitv.returnKeyType = .Default
            uitv.delegate = self

            return uitv
        }()

        name_field = something
        email_field= something
        pass_field= something
    }
}

P.s. you don't need to state the enumeration type explicitly. The compiler can infer it. For example, UIReturnKeyType.Default can be just .Default