Swift

TDD In Practise

When it comes to Testing In Swift, there are 3 keys,

1 – Design your code for clear testability.

Unified Input & Output: In the functional programming world there is this talk about pure function which simply means that same input will always produce the same output no matter where it is called. You don’t have to become Haskell programmers and change all your code according to pure functionality, yet, you may want to inspire by them to make your code easier to test.

Keep Our State Local: In the Apple Community a lot of people are using singleton patters simply because they are used to. We have seen Apple do it like, UIScreen, UIDevice, Bundle, etc. So we as IOS Devs, tend to use it by default even when we really don’t need it. As singletons can be nice for sharing some apis they can also lead you a dangerous paths such as undefined state. So before using it we must think that whether we really need it or not. In summary, my humble suggestion would be try to keep states in local so that we are gonna end up with less bugs and also easier to test the code.

Dependency Injection: When you are testing a state or functionality, all the needs to create output must be declared as you call the testing function, so try not to put variables in the class itself but try to create them while calling the function via putting those variables in initializers. So that, all the needs will always generate the same output with the same input no matter when or where.

2 – Remember that you are going to write a test against all your public api. So keep caution on access modifiers.

Always keep going with framework oriented programming, so that your codes will be easy to test and easy to reuse them.

3 – We all need mocks when it comes to testing, yet be very careful while using them. Remember your only purpose is writing tests to check your real code. Mocks come with a cost and more complexity. And you can end up instead of testing your api, testing too much of your implementation.

Memory Management

Swift uses ARC memory management model.
Retain Cycles Problem: When two objects reference each other, or when capturing in closures may cause a retain cycles.

1. Referencing object increments object’s retain count: For example, lets say we have a Stationery.swift class and Notebook.swift class, and both these classes includes object of one another. Imagine that we have both instances of these classes, in that case retain cycles occur. For solution, we must break the retain cycle by making notebook’s instance to “weak”.
2. Closures: Another example could be about closures, just like how referencing an instance using a property increment its retain count, so does capturing instance in closure.
For example, if we are using a closure to observe a notebook instance whenever its being sold in stationery object, and using the same stationery object within that closure will again cause the retain cycles.

Closures in Swift

Closures are blocks of code that defines functionality in your code. Closures can capture and store references to any constants and variables from the context. Basically, swift handles all of the memory management of capturing. Yet, when building hierarchies of objects and closures you have to be very careful in considering which type that will act as the owner for each given instances. With a clear hierarchy, parent instances will be responsible in retaining their children in which, children instances will be “weak” references, and a lot of memory related problems will be avoided.

@Escaping: When the passing argument defined in outside of the closure and will be executed later this argument must be defined as @escaping. When the execution ends, the scope of the passed closure will exist in the memory till it gets executed. In such, asynchronous functions like waiting API response, or calling Grand Central Dispatch – like doing animation, will cause the @escaping argument to be stored in memory until the animation is done, or api delivers response. In those cases, we must explicitly  define self’s as “weak” properties to avoid memory issues.

@Non-Escaping: When the passing argument is already a in a function, closure executes the argument in the function itself and returns it to back the compiler. In those cases, once the execution ends, the passed closure goes out of scope and have no more existence in memory. (Default one)

Github links for starters

Skeleton Project with mvc, shared folders & Obj C UI libraries:

https://github.com/rozeridilar/Quizzler—London-App-Brewery

Bitcoin Ticker in Swift:
https://github.com/rozeridilar/BitcoinTicker/blob/master/README.md

Common Auto Layout Issues both programmatically and Main Board Solutions:

https://github.com/rozeridilar/AutoLayoutWorkSpace

https://github.com/rozeridilar/Dicee—AutoLayoutIssues

HTTP Status Codes: 
https://www.restapitutorial.com/httpstatuscodes.html

To Design Custom Icon for IOS App

Hey Guys! In android, we developers are really lucky to copy/paste the icons to our app. In IOS However, Apple makes you add very specific sizes. We need different sizes, because devices are different. Ipad, different versions of Iphone… They all display different resolution of icons. Of course, newer models have high resolutions. But we have to think all devices.:)

Sooo, Lets Begin!

When we take a look at image.xassests for our AppIcon there will be Iphone — Iphone Spotlight — Iphone App and so on… The important thing is below this pictures there is “pt”(points). Also, there will be 2x or 3x or whatever for each different size. So All we gotta do is to multiply points with this sizes. For example, In the first picture there is an iphone with 29 pt and 2x size so we must have icon with (29 x 2 = 58) 58 pxs. For other devices you should also have 58pxs, 80pxs, 87pxs, 120pxs, 180pxs…
Also, As you might noticed all icons should be SQUARE. But you can change the image with insets to rectangle or whatever you want.:)