demo

Open Xcode and click on File->New->Project… to create a new project, choose Single View Application.

Select Swift for the language project and name it as you want, personally I called it “LocalizationTutorial”

Click on your project icon (the blue icon) in your directory hierarchy on the left hand side, to “Info”.

Now click on the “+” button in the “Localizations” section and select the language you want to add to the project.

When you got this screen, choose the default files listed and click Finish.

Alright, since now our project is synchronized with different languages, we have to create the files which will contain the different translated copies for our app.

Localizable.strings

Go to File->New->File… and add a new Strings File.

Call this file “Localizable.strings”.

Select this file in the project folder and click on “Localize…” in the Localization section (in the right utility panel).

Then, select English in the localization drop down.

Now if you click on the Localizable.strings file you should be able to see that the Localization section has been updated.

Each selected language item will create an alternative version of the file for this language. You got it, you have to select “English” and the other(s) language(s) you want to use in your app.

Localizable.strings (English)

Localizable.strings (Chinese (Simplified))

Create StringExtension.swift

ViewController

How to Run

Click the button to switch languages and display the Hello World string in different languages.

the compiler will infer the type of variable or constant, based on what is being assigned to it.

// MARK: this is viewable in the jump bar

// TODO: Do This

// FIXME: fix this

/// A Quick Help comment
///
/// – warning: integer must be > 0
/// – parameter integer: Integer to square
///
/// – returns ‘integer’ squared

func doSomething() {

}

ref – https://www.raywenderlich.com/112029/reference-value-types-in-swift-part-2

Mixing Value and Reference Types

You’ll often run into situations where reference types need to contain value types, and vice versa. This can easily complicate the expected semantics of the object.
To see some of these complications, you’ll look at an example of each scenario.

Reference Types Containing Value Type Properties

It’s quite common for a reference type to contain value types. An example would be a Person class where identity matters, that stores an Address structure where equality matters.
To see how this may look, replace the contents of your playground with the following basic implementation of an address:

All properties of Address together form a unique physical address of a building in the real world. The properties are all value types represented by String; the validation logic has been left out to keep things simple.

Next, add the following code to the bottom of your playground:

This mixing of types makes perfect sense in this scenario. Each class instance has its own value type property instances that aren’t shared. There’s no risk of two different people sharing and unexpectedly changing the address of the other person.
To verify this behavior, add the following to the end of your playground

Value Types Containing Reference Type Properties

Add the following code to your playground to demonstrate a value type containing a reference type:

Each copy of Bill is a unique copy of the data, but the billedTo Person object will be shared by numerous Bill instances. This simply does not make sense in maintaining the value semantics of your objects.

Using Copy-on-Write Computed Properties

Swift can give you the ability for your value type to spawn its own reference type. That way, when other objects wants to reference your value type’s reference object, it won’t simply point to it…as that would make one data object be changed by 2 or more references.

When other objects point to your value type’s reference object, your value type will spawn (create another instance) of the reference object for others. That way, your value type will have its own reference object with its respective address, and other object would have their reference object with its respective address.

1) declare a reference type
2) create a property (billedToForRead) to get the current reference
3) create another property (billedToCreateNewInstance) which re-assigns the reference to a new heap allocated Person object. When we create a new object on the heap, our property billedTo will re-point to that object. Thus, billedToCreateNewInstance will return a new object with a new address.

In Swift, we need to use the word mutating in order to let the value type know that its property will be changing.

If you can guarantee that your caller will use your structure exactly as you meant, this approach would solve your issue. In a perfect world, your caller would always use billedToForRead to get data from your reference and billedToCreateNewInstance to make a change to the reference.

However, callers will also make some mistakes in calling your API properties. Hence, what we can do is to hide our properties from the outside and create methods to

Defensive Mutating Methods

So as mentioned, we’ll hide the two new properties from the outside.

1) You made both computed properties private so that callers can’t access the properties directly.

2) You also added methods to mutate the Person reference with a new name or address. This makes it impossible for someone else to use it incorrectly, since you’re hiding the underlying billedTo property.

Also, take note that “Cannot use mutating member on immutable value”.

for example:

A More Efficient Copy-on-Write

There is only one small problem. Whenever we want to change the Person object’s attributes, we ALWAYS instantiate a Person object:

As you can see, whenever we get the billedTo attribute, we always return a newly instantiated object.

If another Bill object references this Person object, then yes, we should instantiate a new Person object for our own Bill object to reference, and change data with.

However, what if the Person object has no other references on it? ..and is only referenced by self?
In that case, we do not need to instantiate it. We simply use it as it, and change the attributes.

Hence here is what’s happening:

A Person object with “Ricky” (100c01fa0) is allocated on the heap. It is passed into the Bill object (100410438) to be initialized. This initialization is really about the Bill object creating its own instance of Person object (100c01fe0), and setting all its data the same as the passed in “Ricky” Person object. The original “Ricky” Person object created outside is not pointed to, nor affected.

We then want to change the data of our Bill object to Ivan. We do this through the property, and evaluate whether the Person object 100c01fe0 has any other references on it. Uniquely Referenced means it is referenced only by 1 object.

Thus, we see that IT IS only referenced once, by our Bill object. Thus, we don’t create an instance and just return the Person object. We then proceed to change the data.

Then say we have another Bill object reference our Person (100520008). Thus, we now have two references pointing to our Person object

Because we have 2 references on the Person object, isKnownUniquelyReferenced will fail, and we create another Person object. That way, we get our own unique instance of Person.

ref – https://www.raywenderlich.com/112027/reference-value-types-in-swift-part-1

Value types keep a unique copy of their data, while reference types share a single copy of their data.

Reference type

Swift represents a reference type as a class. This is similar to Objective-C, where everything that inherits from NSObject is stored as a reference type.

In Objective-C — and most other object-oriented languages — you hold references to objects. In Swift, however, you use class which is implemented using reference semantics.

The above class represents a pet dog and whether or not the dog has been fed. Create a new instance of your Dog class by adding the following:

This simply points to a location in memory that stores dog. To add another object to hold a reference to the same dog, add the following:

Because dog is a reference to a memory address, puppy points to the exact same address. Feed your pet by setting wasFed to true:

Therefore you’d expect any change in one to be reflected in the other. Check that this is true by viewing the property values in your playground:

Changing one named instance affects the other since they both reference the same object. This is exactly what you’d expect in Objective-C.

Value types

There are many kinds of value types in Swift, such as struct, enum, and tuples. You might not realize that Objective-C also uses value types in number literals like NSInteger or even C structures like CGPoint.

Clearly, a equals 42 and b equals 43. If you’d declared them as reference types instead, both a and b would equal 43 since both would point to the same memory address.

This shows a subtle, but important difference between reference and value types: setting kitty‘s wasFed property has no effect on cat. The kitty variable received a copy of the value of cat instead of a reference.

Although it’s much faster to assign a reference to a variable, copies are almost as cheap. Copy operations run in constant O(n) time since they use a fixed number of reference-counting operations based on the size of the data.

Mutability

For reference types, let means the reference must remain constant. However, you can still dereference them and change the data. In other words, you can’t change the instance the constant references, but you can mutate the instance itself.

For value types let means the instance must remain constant. No properties of the instance will ever change, regardless whether the property is declared with let or var.

It’s much easier to control mutability with value types. To achieve the same immutability/mutability behavior with reference types, you’d need to implement immutable and mutable class variants such as NSString and NSMutableString.

Which to Use and When

When to Use a Value Type

Generally speaking, use value types in the following instances:

Comparing instance data with == makes sense

“But of course,” you say. “I want every object to be comparable!”. But you need to consider whether the data should be comparable. Consider the following implementation of a point:

Does that mean two variables with the exact same x and y members should be considered equal?

It’s clear that these two Points with the same internal values should be considered equal. The memory location of those values doesn’t matter; you’re concerned about the values themselves.

Therefore, you’d need to conform to the Equatable protocol, which is good practice for all value types. This protocol defines only one function which you must implement globally in order to compare two instances of the object. This means that the == operator must have the following characteristics:

Reflexive: x == x is true
Symmetric: if x == y then y == x
Transitive: if x == y and y == z then x == z

If you have a custom struct, you’d implement the equal sign like so:

Copies should have independent state

Structs, being value types, have independent state.

Let’s instantiate two Shape structs.

If we are to change their state, it would be unique.

Each Shape needs its own copy of a Point so you can maintain their state independent of each other.

The data will be used in code across multiple threads

This one’s a little more complex. Will multiple threads access this data? If so, will it really matter if the data isn’t equal across all threads at all times?
To make your data accessible from multiple threads and equal across threads, you’ll need:

1) to use a reference type and
2) implement locking as well

Thus, if threads can uniquely own the data, using value types makes the whole point moot since each owner of the data holds a unique copy rather than a shared reference.

When to Use a Reference Type

Although value types are useful in many cases, reference types are still useful in the following situations:

Comparing instance identity with === makes sense (this is where it compares the reference address)
=== checks if two objects are exactly identical, right down to the memory address that stores the data.

To put this in real-world terms, consider the following: if your cubicle-mate swaps one of your $20 bills with another legitimate $20 bill, you don’t really care, as you’re only concerned about the value of the object.

However, if someone stole the Magna Carta and created an identical parchment copy of the document in its place, that would matter greatly because the inherent identity of the document is not the same at all.

You can use the same thought process when deciding whether to use reference types; usually there are very few times when you really care about the inherent identity — that is, the memory location — of the data. You usually just care about comparing the data values.

You want to create a shared, mutable state

Sometimes you want a piece of data to be stored as a single instance and accessed and mutated by multiple consumers.

A common object with a shared, mutable state is a shared bank account. You might implement a basic representation of an account and person as follows:

If any joint account holders add money to the account, then the new balance should be reflected on all debit cards linked to the account:

Since Account is a class, each Person holds a reference to the account, and everything stays in sync.

swift 3.0

Given

should now be written as

If you were to follow swift 3 guidelines for declaring functions

in that case, we’ll have to declare our selector like so:

In a Single View App

If you want to pass in additional information into the sample function, you can over-ride UIButton with your custom button class and set a property there.
Then, when you get your button object in sample function, just access that property.

ref – http://www.appcoda.com/grand-central-dispatch/

Queue

A queue is actually a block of code that can be executed synchronously or asynchronously, either on the main or on a background thread.

Once a queue is created, the operating system is the one that manages it and gives it time to be processed on any core of the CPU.

Multiple queues are managed accordingly, and that management is something that developers don’t have to deal with.

Queues are following the FIFO pattern (First In, First Out), meaning that the queue that comes first for execution will also finish first (think of it like a queue of humans waiting in front of the counter, the first one is served first, the last one is served last).

Work Item

A work item is literally a block of code that is either written along with the queue creation, or it gets assigned to a queue and it can be used more than once (reused). It’s the code that a dispatch queue will run. The execution of work items in a queue also follows the FIFO pattern.

This execution can be synchronous or asynchronous.

In the synchronous case, the running app does not exit the code block of the item until the execution finishes. Thus, when the execution is happening, the running app does not exit, and this results in the UI being frozen for a little while.

On the other hand, when queues are scheduled to run asynchronously, then the running app calls the work item block and it returns at once and continue with its main thread. Thus you will not see pauses on the UI.

Example 1

The sync will process its display of 0 to 10, and you’ll notice that you won’t be able to click on the UI button. That’s because the block of code is being processed by the queue in a sync fashion. You’ll have to wait until it completes. Then you’ll notice that your button presses will take effect.

Result:

–viewDidLoad–
button created
view hieararchy added button
— SLEEP! —
 0
— SLEEP! —
 1
— SLEEP! —
 2
— SLEEP! —
 3
— SLEEP! —
 4
— SLEEP! —
 5
— SLEEP! —
 6
— SLEEP! —
 7
— SLEEP! —
 8
— SLEEP! —
 9
Button Clicked
Button Clicked
Button Clicked
Button Clicked
Button Clicked
Button Clicked
Button Clicked

source code

Change sync to async

Now let’s change the sync into an async. You’ll see that your button now has effect while the tasks are being processed.

Output:

–viewDidLoad–
button created
view hieararchy added button
Button Clicked
 0
Button Clicked
Button Clicked
Button Clicked
 1
Button Clicked
Button Clicked
 2
 3
Button Clicked
 4
 5
 6
 7
Button Clicked
Button Clicked
Button Clicked
Button Clicked
 8
Button Clicked
 9

The important here is to make clear that our main queue is free to “work” while we have another task running on the background, and this didn’t happen on the synchronous execution of the queue.

Qos – Quality of Service (enum)

output:
–viewDidLoad–
button created
view hieararchy added button
Π0
Á 0
Π1
Á 1
Á 2
Π2
Á 3
Π3
Á 4
Π4
Π5
Á 5
Π6
Á 6
Π7
Á 7
Π8
Á 8
Π9
Á 9

It’s easy to say by looking at the above screenshot that both tasks are “evenly” executed, and actually this is what we expect to happen.

Now change priority of queue2 to DispatchQoS.utility

The first dispatch queue (queue1) will be executed faster than the second one, as it’s given a higher priority. Even though the queue2 gets an opportunity of execution while the first one is running, the system provides its resources mostly to the first queue as it was marked as a more important one. Once it gets finished, then the system takes care of the second queue.

Make sure you change the index i and j to 100, instead of 10. Then run it, you’ll see that are about the same…until when the index gets into the 20s. For my machine, at around index 25, 26, queue1 runs twice, which hints that queue1 gets more of attention.

Now let’s change queue1 to background. Let’s change queue2 back to userInitiated.

If you were to run the code again, you’ll see that queue2 (having the higher priority) will finish a full 6 indexes faster than queue1.

The common thing to all the previous examples is the fact that our queues are serial. That means that if we would assign more than one tasks to any queue, then those tasks would have been executed one after another, and not all together.

Concurrent Queues

There’s a new argument in the above initialisation: The attributes parameter. When this parameter is present with the concurrent value, then all tasks of the specific queue will be executed simultaneously. If you don’t use this parameter, then the queue is a serial one. Also, the QoS parameter is not required, and we could have omitted it in this initialisation without any problem.

We have one concurrent queue (called anotherQueue), and it runs 3 tasks. All three tasks are executed at the same time (concurrently), running through their own perspective for loops.

User Activated

The attributes parameter can also accept another value named initiallyInactive. By using that, the execution of the tasks doesn’t start automatically, instead the developer has to trigger the execution.

Delaying the Execution

You can activate when you want your queue to start executing. This is done by creating a dispatch queue, then assigning a property reference to it. Once you do that, you can use the property reference to call the activate method wherever you like in your class.

Notice that you assign serial, concurrent, and initiallyInactive characteristics via an array on the attributes property when creating DispatchQueue.

Accessing the Main and Global Queues

In all the previous examples we manually created the dispatch queues we used. However, it’s not always necessary to do that, especially if you don’t desire to change the properties of the dispatch queue. As I have already said in the beginning of this post, the system creates a collection of background dispatch queues, also named global queues. You can freely use them like you would do with custom queues, just keep in mind not to abuse the system by trying to use as many global queues as you can.

Using or not global queues, it’s almost out of the question the fact that you’ll need to access the main queue quite often; most probably to update the UI.
Global queue let’s you run tasks in the background. Once you are ready to update the UI, do so by using the main thread.

WorkItem

A DispatchWorkItem is a block of code that can be dispatched on any queue and therefore the contained code to be executed on a background, or the main thread. Think of it really simply; as a bunch of code that you just invoke, instead of writing the code blocks in the way we’ve seen in the previous parts.

Basically A workItem is a block of code that is executed by a queue. Right before execution it will notify via the notify method any other queues. In our example, we notify the main queue to run a block of code that simply prints out the value.

output:

–viewDidLoad–
button created
view hieararchy added button
–> useWorkItem()
create temp var ‘value’
DispatchWorkItem.perform()
—-executing DispatchWorkItem—–
value is has been changed to: 15
get global queue
execute DispatchWorkItem via async
DispatchWorkItem notify queue via main, print out value
<-- useWorkItem() workItem about to be executed!, its current value is: 15 ----executing DispatchWorkItem----- value is has been changed to: 20 ----executing DispatchWorkItem----- value is has been changed to: 25 ----executing DispatchWorkItem----- value is has been changed to: 30 ----executing DispatchWorkItem----- value is has been changed to: 35 ----executing DispatchWorkItem----- value is has been changed to: 40