TipsApp is a tip calculator application for iOS.
Submitted by: Akrm Almsaodi
Time spent: +30 hours spent in total
The following Required functionality is complete:
The following Optional features are implemented:
The following Additional features are implemented:
Notes and thoughts:
Higher resolution GIF: https://media.giphy.com/media/l1J3OU3vElH8Na3ks/giphy.gif
GIF created with GIF Brewery 3 (http://gifbrewery.com).
As part of your pre-work submission, please reflect on the app and answer the following questions below:
Question 1: "What are your reactions to the iOS app development platform so far? How would you describe outlets and actions to another developer? Bonus: any idea how they are being implemented under the hood? (It might give you some ideas if you right-click on the Storyboard and click Open As->Source Code")
Answer: As a firmware developer, I found working in the iOS app development platform is very intuitive and fun. Also, a lot of the hard work is already implemented by Apple’s folks in form of Frameworks that allow us to utilize the device hardware resources. Xcode makes development very fast and less buggy by suggesting name of functions and properties and always suggest corrections during the development stage. Also the simulator is very handy during the first stage of development. Also being able to run and debug the app on the device directly without a need for an external debugger is very impressive and makes the work simpler. Regarding Swift, I can’t compliment this language enough; it is very powerful and offers everything I need with flexibility and beautiful syntax.
In terms of describing outlets and actions, I would simply say that they are referencing objects and methods that allow us to programmatically interact with the components implanted in the linked nib or storyboard files. The keywords @IBOutlet and @IBAction indicate to the interface builder that these variables and methods are accessible; and thus it will allow for links between them and its views. In other words, IBOutlet variable is an UI output, and IBAction is an UI input’s handler. So for example if a user creates an action by clicking a button, the interface builder will execute the linked IBAction method.
Question 2: "Swift uses Automatic Reference Counting (ARC), which is not a garbage collector, to manage memory. Can you explain how you can get a strong reference cycle for closures? (There's a section explaining this concept in the link, how would you summarize as simply as possible?)"
Answer: A strong reference cycle occurs when two objects have strong retained reference to each other. Now since closures in swift are objects, Automatic Reference Counting apply to them. With this being said, we can get a strong reference cycle if we have a property of a class that has a closure (calculated property), which captures self to access one of the other class prosperities. In this case, the closure and the instance of the class will have a strong reference to each other, and the ARC will never be able to get rid of them; in another word, we will have a memory leak!
We can avoid this condition by making a weak or unowned reference to self. However, using weak reference will capture self as an optional type, and it will need to be unwrapped. In our case, it is safe to reference self as unowned because it can never be nil during the life of the closure!