Friday, September 11, 2015

Swift 2.0 Strings


After functional coding I feel the biggest change from Obj-C world to Swift was in support of Unicode string.

Then again the huge change from Swift 1.2 to Swift 2.0 might be in String.
In someway its a dramatic change !
As stated in Swift Blog

Swift provides a performant, Unicode-compliant string implementation as part of its Standard Library. In Swift 2, theString type no longer conforms to the CollectionType protocol, where String was previously a collection of Character values, similar to an array. Now, String provides a characters property that exposes a character collection view.


var letters: [Character] = ["c", "a", "f", "e"]
var string: String = String(letters)

print(letters.count) // 4
print(string) // cafe
print(string.characters.count) // 4


let acuteAccent: Character = "\u{0301}" // ´ COMBINING ACUTE ACCENT' (U+0301)

string.append(acuteAccent)
print(string.characters.count) // 4
print(string.characters.last!) // é



https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/StringsAndCharacters.html


NOTE
Extended grapheme clusters can be composed of one or more Unicode scalars. This means that different characters—and different representations of the same character—can require different amounts of memory to store. Because of this, characters in Swift do not each take up the same amount of memory within a string’s representation. As a result, the number of characters in a string cannot be calculated without iterating through the string to determine its extended grapheme cluster boundaries. If you are working with particularly long string values, be aware that the count(_:) function must iterate over the Unicode scalars in the entire string in order to calculate an accurate character count for that string.


The character count returned by the count(_:) function is not always the same as the length property of an NSString that contains the same characters. The length of an NSString is based on the number of 16-bit code units within the string’s UTF-16 rpresentation and not the number of Unicode extended grapheme clusters within the string. To reflect this fact, the length property from NSString is called utf16Count when it is accessed on a Swift String value.

Reference - 

Tuesday, September 1, 2015

Catching generic Exceptions in Swift 2.0

Erro handeling is always a chalange in any development enviroment.


In general, we will never spot an error if we log or catch. Only developers will see those, and if you're muffling to avoid user-visible behavior, succeeding means nobody will notice!

So our guideline is: 
"if it's something wrong that we want to fix, let it crash, find and fix before release. "

If it's something wrong that might seriously impact the user experience, or is not indicative of a programming error, then muffle but make sure we have a test or some other way to find the problem. 

Or make sure that failure propagates around the application through some other kind of logic — return values, fall through, whatever. 

Also: if you write 'catch Exception', consider writing 'Throwable' instead. I often see this:

  // This might run out of memory. 
  catch (Exception e) {

which won't work — Exception and Error are siblings, and OOMs are OutOfMemoryErrors. That'll catch everything but an Error!

I am a huge fan of open source Firefox iOS Developed in Swift and consider it as an inspiration.
I found the following discussion on bugzilla 

Inspired by buzilla form - 

Richard Newman 
https://mail.mozilla.org/pipermail/mobile-firefox-dev/2015-August/001451.html

Bugzilla - https://bugzilla.mozilla.org/show_bug.cgi?id=1191067#c25
Github - https://github.com/mozilla/firefox-ios