Search Your Question

Showing posts with label Difference. Show all posts
Showing posts with label Difference. Show all posts

Difference between App Bundle and File Directory

Ans : Although bundles and packages are sometimes referred to interchangeably, they actually represent very distinct concepts:

1.
A package is any directory that the Finder presents to the user as if it were a single file.
A bundle is a directory with a standardized hierarchical structure that holds executable code and the resources used by that code.

2.
The Finder considers a directory to be a package if any of the following conditions are true:
.The directory has a known filename extension: .app, .bundle, .framework, .plugin, .kext, and so on.
.The directory has an extension that some other application claims represents a package type; see Document Packages.

Difference between array, set and dictionary

Ans : 

Array :
Arrays are effectively ordered lists and are used to store lists of information in cases where order is important.
Cost of adding item in array is greater than set and dictionary if item is not appending first.

For example, posts in a social network app being displayed in a tableView may be stored in an array.

Set : 
Sets are different in the sense that order does not matter and these will be used in cases where order does not matter. Sets are especially useful when you need to ensure that an item only appears once in the set.

Dictionary : 
Dictionaries are used to store key, value pairs and are used when you want to easily find a value using a key, just like in a dictionary.


For example, you could store a list of items and links to more information about these items in a dictionary.


Difference between Core Data and Sqlite

Ans : Core-data is not database that we understand. Sqlite is Database. 

Lets have a look over difference between Core-data and Sqlite (or Database) :

Core Data:


  1. Primary function is graph management (although reading and writing to disk is an important supporting feature).
  2. Operates on objects stored in memory (although they can be lazily loaded from disk).
  3. Works with fully-fledged objects that self-manage a lot of their behavior and can be sub classed and customized for further behaviors.
  4. Non-transactional, single threaded, single user (unless you create an entire abstraction around Core Data which provides these things).
  5. Only operates in memory.
  6. Requires a save process.
  7. Can create millions of new objects in-memory very quickly (although saving these objects will be slow).
  8. Leaves data constraints to the business logic side of the program.


Database or SQLite:


  1. Primary function is storing and fetching data.
  2. Operates on data stored on disk (or minimally and incrementally loaded).
  3. Stores "dumb" data.
  4. Can be transactional, thread-safe, multi-user.
  5. Can drop tables and edit data without loading into memory.
  6. Perpetually saved to disk (and often crash resilient).
  7. Can be slow to create millions of new rows.
  8. Offers data constraints like "unique" keys.
Credit : http://www.cocoawithlove.com/2010/02/differences-between-core-data-and.html


difference between coredata and sqlite

Advantage of Core-data : 

  • Much better memory management. With a plist you must load the entire thing into memory; with Core Data only the objects you're currently using need to be loaded. Also, once objects are loaded, they're normally placeholder "fault" objects whose property data doesn't load until you need it.
  • Related to the above, when you have changes, you can save only the changed objects, not the entire data set.
  • You can read/write your model objects directly instead of converting them to/from something like an Dictionary.
  • Built-in sorting of objects when you fetch them from the data store.
  • Rich system of predicates for searching your data set for objects of interest.
  • Relationships between entities are handled directly, as properties on the related objects. With a plist you would need to do something like store an object ID for a relationship, and then look up the related object.
  • Optional automatic validation of property values.
More about Core-data : 

  • CoreData isn't a Database. It's an object persistence layer. There is no concept of primary keys or foreign keys in CoreData.
  • If you want to establish a relationship between two entities. You'll define a relationship, CoreData takes care of how that relationship is stored.
  • Select an entity, use plus button at the bottom of the entities attributes list, select add relationship, select the destination entity from the dropdown.
  • Select the destination entity and define an inverse relationship in the same way.

Difference between mutable array and immutable array?

Ans : 

Mutable Array content can be changed but Immutable Array content can not be changed.

You can insert, update, remove item from Mutable Array, but same is not possible in Immutable Array. There is no any methods like RemoveItem or ReplaceItem for Immutable Array, which are available for Mutable Array.

So in Immutable Array, content can not be changed after initialisation. It is either be initialised by content or by nil.

Use of Immutable array 

1. Used when we want to give array to other coder who can't be change array content.
2. Used when only fixed contents are there like array of months, days which can't be changed.

Difference between Swift Array and Objective C Array

Ans : Swift arrays (Array and for short, []) are passed by value which means
that every object contained will be copied.

NSArray are implemented as classes (and bridged from ObjC) so they're passed as references.

In Swift, we can declare three type of array.
One is Array or [],
Second is NSArray,
Third is NSMutableArray.

NSArray and NSMutableArray are coming from Objective C by bridge. So interviewer may ask what are difference between types arrays in swift?

Extract value from Array : 

Get 3rd Value from Array

Objective C : [arr objectAtIndex:2] // 2 due to index start from 0 in array

Swift : arr[2] 

Difference between blocks and completion handler in iOS

Ans :

Blocks:

Blocks are a language-level feature added to C, Objective-C and C++, which allow you to create distinct segments of code that can be passed around to methods or functions as if they were values. Blocks are Objective-C objects, which means they can be added to collections like NSArray or NSDictionary.

They can be executed in a later time, and not when the code of the scope they have been implemented is being executed.
Their usage leads eventually to a much cleaner and tidier code writing, as they can be used instead of delegate methods, written just in one place and not spread to many files.
Syntax: ReturnType (^blockName)(Parameters)

see example:

int anInteger = 42;

void (^testBlock)(void) = ^{

    NSLog(@"Integer is: %i", anInteger);   // anInteger outside variables

};

// calling blocks like
testBlock();
Block with argument:

double (^multiplyTwoValues)(double, double) =

                          ^(double firstValue, double secondValue) {

                              return firstValue * secondValue;

                          };
// calling with parameter
double result = multiplyTwoValues(2,4);

NSLog(@"The result is %f", result);





Completion handler:
Whereas completion handler is a way (technique) for implementing callback functionality using blocks.
A completion handler is nothing more than a simple block declaration passed as a parameter to a method that needs to make a callback at a later time.
Note: completion handler should always be the last parameter in a method. A method can have as many arguments as you want, but always have the completion handler as the last argument in the parameters list.
Example:
- (void)beginTaskWithName:(NSString *)name completion:(void(^)(void))callback;
// calling
[self beginTaskWithName:@"MyTask" completion:^{
    NSLog(@"Task completed ..");
}];
More example with UIKit classes methods.

[self presentViewController:viewController animated:YES completion:^{
        NSLog(@"xyz View Controller presented ..");
        // Other code related to view controller presentation...
    }];
[UIView animateWithDuration:0.5
                     animations:^{
                         // Animation-related code here...
                         [self.view setAlpha:0.5];
                     }
                     completion:^(BOOL finished) {
                         // Any completion handler related code here...
                         NSLog(@"Animation over..");
                     }];

Difference between viewdidload and viewwillappear?

Ans : 


ViewDidLoad - It is excecuted once. So writer settings like set label text in ViewDidLoad.
ViewWillAppear - It is called every time when view appear.


ViewDidLoad - It is called when view is begin constructed.
ViewWillAppear - When view is about ready to appear.


ViewDidLoad It is automatically called when view controller completely loaded into memory. Override this method to perform additional initialization on views that were loaded from xib.
I.e instance variable initialization, database access, network request
ViewWillAppear It is called when View is about to added on view hierachy. If we want to change some, then we have to override this method.Like change orientation, change screen data.


Suppose your tableview data will be changed periodically. Then you have to write [tableview reloaddata] in ViewWillApper.

Read UIViewController LifeCycle

What are join in sql? Explain Types of Join

Ans :

Join :
When we need data from more than 1 table, then we can fetch data from those table using joining those table. It will return only matching data from two tables.

Select * from table1 t1 inner join table2 t2 on t1.column1 = t2.column1

Types of Join :

1. Inner Join :
If we use inner join between two table, then only data exists in both table, are returned.

2. Outer Join :
    Left Outer Join : It returns all data from left table(table1) and only matching data from both table.
    Right Outer Join : It returns all data from right table(table2) and only matching data from both table.

3. Cross Join : It is like cartesian join. It returns all records from both table and it returns table1.count * table2.count records in returns. Suppose table1 has 4 records and table2 has 3 records and returns 4*3 records.

4. Self Join : If some column's reference has in same table then self join is used. It is same like inner join but here both left and right table are same. Its like if you table and Columns are such as MainID, Name, ParentID then you can make query like
Select * from table t1 join table t2 on t1.MainID = t2.ParentID

Difference between Strong and Weak in iOS

Ans : 


Strong
strong property means that you want to “own” the object. Only when you set the property to nil will the object be  destroyed. Unless one or more objects also have a strong reference to the object. This is the one you will use in most cases.
  1. Creates ownership between property and assigned value.
  1. This is default for object property in ARC so it does not let you worrying about reference count and release the reference automatically.
  1. It is replacement for retain. We use if and only if we need to use as retain.
  1. Retain count will be incremented.
  1. Creates non-ownerships between property and assigned value.
  1. Strong is used on parent object and weak is used on child object when parent is released then child object reference is also set to nil
  1. It helps to prevents retain cycles.
  1. It doesn’t protect the referenced object when collection by garbage collector.
  1. Weak is essentially assigned, un-retain property.
  1. Retain count will not be incremented.


Weak
Weak property means you don’t want to have control over the objects lifecycle. The object only lives on while another objects has a strong reference to it. If there are no strong references to the object then it will be destroyed. 
Weak reference is useful to avoid situation like retain cycle. Retain cycle occurs when two or more objects have strong reference to each other. This two object will never be freed in memory due to strong reference. So to avoid weak reference, One object has a strong ownership reference to another object, and another object should be have a weak reference to first object.

Strong references should be used when a parent object is referencing a child object and never the other way around. That is, a child class should not have a strong reference to the parent class.

Weak references should be used to avoid retain cycles and an object has the possibility to become nil at any point of it’s lifetime.

Good read : Click here




Difference between XIB and Storyboard

Ans : 


XIB :

1) Xib files are used with a single UIView.

3)It's utilizes more memory as compared to storyboard and quiet slow.

4) It is compatible from iOS5 and onwards

5) You can do localizations for different languages and countries using different XIBs .

6) It's difficult to use same Xib to support multiple devices.

Storyboard :

1)You can layout all your Scenes like View Controllers, Nav Controllers, TabBar Controllers, etc in a single storyboard.

3)Usually fast and allocates less memory.

4)It's not compatible prior to iOS 5 .

5)"Dynamic" and "Prototype" cells can be used easily.

6)Storyboards best to use for the apps with a small to medium amount of screens.

Difference between synchronous and asynchronous calls in Objective-C

Ans : 

Synchronous :
This call means task will be executed in order.
Asynchronous : This call means task may or may not be executed in order.

When call is called synchronously, then thread that initiated that operation will be wait to current task to be finished.
When call is called asynchronously, then it will not wait.

If we want to do some task without harassing UI, we can do those tasks in background thread. This goal is to keep free main thread, so it continuously respond UI event. So we can dispatch our task in background state asynchronously.

So for do task in background thread, we will divide in 2 parts.

1. GCD - Grand Central Dispatch. By using GCD, you have to grab one of global background queue or create your own background queue.

// one of the global concurrent background queues
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

// or you could create your own serial background queue:
// dispatch_queue_t queue = dispatch_queue_create("com.iosiqa.app.queuename", 0);

2. Dispatch your task to that queue asynchronously

dispatch_async(queue, ^{
    // task that to be done in background and it may be slow
});

The pattern for operation queues is very similar. Create an operation queue and add operations to that queue.

Lets see example :

Asynchronous call with Multithreading :

// Methods gets called in different thread and does not block the current thread.
[NSURLConnection sendAsynchronousRequest:request
                                   queue:queue
                       completionHandler:
    ^(NSURLResponse *response, NSData *data, NSError *error) {
}];

Synchronous call with Multithreading (not so useful):

//Do something
dispatch_sync(queue, ^{
    //Do something else // work in another queue or thread
});

//Do some more task


Difference between thread-safe and non-thread-safe in iOS

Ans : 

Thread-Unsafe -> If any object allow to modify by more than one thread at the same time.  (non-atomic property is thread-unsafe. Comments are welcomed)

Thread-safe -> If any object not allow to modify by more than one thread at the same time.Immutable objects are generally thread-safe. (atomic property attribute type. Comments are  welcomed)

In general, immutable classes like NSArray, let are thread-safe, while their mutable variants like NSMutableArray,var are thread-unsafe.



Access controls in Swift

Ans : 

Access controls
keyword enables you to hide the implementation details of your code, and to specify a preferred interface through which that code can be accessed and used.

Swift 3, Swift 4

There are 5 access controls.
1. open (most accessible, least restrictive)
2. public
3. internal (default)
4. fileprivate
5. private (least accessible, more restrictive)

1. open : It enable entity to be used in and outside of defining module and also other module. UIButton, UITableView is in UIKit. We import UIKit and make subclass of UITableView and use in our module in which we have imported UIKit. So tableview subclass of UITableView defined in UIKit is used in our module. Sot it is accessible in our module.

open class UITableView : UIScrollView, NSCoding { }

2. public : open allows us to subclass from another module. public allows us to subclass or override from within module in which it defined.

//module X
public func A(){}
open func B(){}

//module Y
override func A(){} // error
override func B(){} // success

So open class and class members can be accessible and overridden in which it is defined and also in which module it is imported.
public class and class members can be accessible and overridden only in which it is defined.


3. internal : Internal classes and members can be accessed anywhere within the same module(target) they are defined. You typically use internal-access when defining an app’s or a framework’s internal structure.

4. fileprivate : Restricts the use of an entity to its defining file. It is used to hide implementation details when details are used in entire file. fileprivate method is only accessible from that swift file in which it is defined.

5. private : Restricts the use of an entity to the enclosing declaration and to extension of that swift file or class. It is used to hide single block implementation. private entity can be accessible in swift 4 but it gives error in swift 3.




UITableviewDelegate and UITableViewDataSource Methods

Ans : 

UITableview's Delegate Methods :


The UIViewController in which UITableView you use must adopt the UITableViewDelegate protocol. Optional methods of the protocol allow the delegate to manage selections, configure section headings and footers, help to delete and reorder cells, and perform other actions.

Configuring Rows for the Table View

- tableView:heightForRowAtIndexPath:
- tableView:indentationLevelForRowAtIndexPath:
- tableView:willDisplayCell:forRowAtIndexPath:

Managing Accessory Views

- tableView:accessoryButtonTappedForRowWithIndexPath:
- tableView:accessoryTypeForRowWithIndexPath: Deprecated in iOS 3.0

Managing Selections

- tableView:willSelectRowAtIndexPath:
- tableView:didSelectRowAtIndexPath:
- tableView:willDeselectRowAtIndexPath:
- tableView:didDeselectRowAtIndexPath:

Modifying the Header and Footer of Sections

- tableView:viewForHeaderInSection:
- tableView:viewForFooterInSection:
- tableView:heightForHeaderInSection:
- tableView:heightForFooterInSection:

Editing Table Rows

- tableView:willBeginEditingRowAtIndexPath:
- tableView:didEndEditingRowAtIndexPath:
- tableView:editingStyleForRowAtIndexPath:
- tableView:titleForDeleteConfirmationButtonForRowAtIndexPath:
- tableView:shouldIndentWhileEditingRowAtIndexPath:

Reordering Table Rows

- tableView:targetIndexPathForMoveFromRowAtIndexPath:toProposedIndexPath:

Copying and Pasting Row Content

- tableView:shouldShowMenuForRowAtIndexPath:
- tableView:canPerformAction:forRowAtIndexPath:withSender:
- tableView:performAction:forRowAtIndexPath:withSender: 








UITableview's Data Source Methods : The NSTableViewDataSource protocol declares the methods that an instance of NSTableView that provides the data to a table view and allows editing of the contents of its data source object.

All the methods are described in the following.

Getting Values

- numberOfRowsInTableView: (Required)
- numberOfSectionInTableView:
- cellForRowAtIndexPath : (Required)
- tableView:objectValueForTableColumn:row:

Setting Values

- tableView:setObjectValue:forTableColumn:row:

Implementing Pasteboard Support

- tableView:pasteboardWriterForRow:

Drag and Drop

- tableView:acceptDrop:row:dropOperation:
- tableView:namesOfPromisedFilesDroppedAtDestination:forDraggedRowsWithIndexes:
- tableView:validateDrop:proposedRow:proposedDropOperation:
- tableView:writeRowsWithIndexes:toPasteboard:
- tableView:draggingSession:willBeginAtPoint:forRowIndexes:
- tableView:updateDraggingItemsForDrag:
- tableView:draggingSession:endedAtPoint:operation:

Sorting

- tableView:sortDescriptorsDidChange:

Tips : UITableViewDelegate has no any required methods.

Difference between the atomic and nonatomic attributes?

Ans : 

Atomic property give guarantee that valid value will be return. But valid does not mean that correct value.

This also not mean that atomic property are thread safe. Different threads can attempt to read and write value at same time. So one of two value will be return - value before change or changed value.

So atomic property is suffering from performance hit due to locking and unlocking before and after get or set value.

Non atomic property has no guarantee regarding correct value, a partially correct value or may be garbage value.
This is not thread safe this enhanced speed of access property.

Atomic property lock while setting value,

While non atomic property does not lock while setting value. 

Class, Structs and Enum

Ans : 

Structs are value type, Class is reference type.
Structs are stored in stack, Class are stored in heap.

So, Structs are faster than class because of its memory management. (Read why stack allocation is more faster than heap)

Similarity between Class and Struct: 

Define properties to store values
Define methods to provide functionality
Be extended
Conform to protocols
Define intialisers
Define Subscripts to provide access to their variables

Only class can do:

Inheritance
Type casting
Define deinitialisers
Allow reference counting for multiple references.

When to use class and when to use struct?

--> When we want to maintain reference, then we should use class due to class is reference type. When not, we should use struct.

i.e 

Here's an example with a class. Note how when the name is changed, the instance referenced by both variables is updated. Bob is now Sue, everywhere that Bob was ever referenced.

class SomeClass {
    var name: String
    init(name: String) {
        self.name = name
    }
}

var aClass = SomeClass(name: "Bob")
var bClass = aClass // aClass and bClass now reference the same instance!
bClass.name = "Sue"

println(aClass.name) // "Sue"
println(bClass.name) // "Sue"

And now with a struct we see that the values are copied and each variable keeps it's own set of values. When we set the name to Sue, the Bob struct in aStruct does not get changed.

struct SomeStruct {
    var name: String
    init(name: String) {
        self.name = name
    }
}

var aStruct = SomeStruct(name: "Bob")
var bStruct = aStruct // aStruct and bStruct are two structs with the same value!
bStruct.name = "Sue"

println(aStruct.name) // "Bob"
println(bStruct.name) // "Sue"

So for representing a stateful complex entity, a class is awesome. But for values that are simply a measurement or bits of related data, a struct makes more sense so that you can easily copy them around and calculate with them or modify the values without fear of side effects.

Another theory for what to choose : 

Structs are preferable if they are relatively small and copiable because copying is way safer than having multiple references to the same instance as happens with classes. This is especially important when passing around a variable to many classes and/or in a multithreaded environment. If you can always send a copy of your variable to other places, you never have to worry about that other place changing the value of your variable underneath you.

With Structs, there is much less need to worry about memory leaks or multiple threads racing to access/modify a single instance of a variable. (For the more technically minded, the exception to that is when capturing a struct inside a closure because then it is actually capturing a reference to the instance unless you explicitly mark it to be copied).

Classes can also become bloated because a class can only inherit from a single superclass. That encourages us to create huge superclasses that encompass many different abilities that are only loosely related. Using protocols, especially with protocol extensions where you can provide implementations to protocols, allows you to eliminate the need for classes to achieve this sort of behavior.

The talk lays out these scenarios where classes are preferred:
  • Copying or comparing instances doesn't make sense (e.g., Window)
  • Instance lifetime is tied to external effects (e.g., TemporaryFile)
  • Instances are just "sinks"--write-only conduits to external state (e.g.CGContext)

What is @escaping and @nonescaping in swfit?

Ans : 

Closure : Closure are self contained blocks of functionality that can be passed around and used in code.


In swift 1.x and 2.x, closure parameter is @escaping by default. It means closure can be escape during function body execution. If don't want to escape, we have to mention @nonescaping as parameter.

In swift 3.x and after, closure parameter is @nonescaping by default.
Life cycle of non-escaping closure
Basically, a non-escape closure can only run the contents inside of it’s body, anything outside of it’s closure cannot be used. A non-escape closure tells the complier that the closure you pass in will be executed within the body of that function and nowhere else. When the function ends, the closure will no longer exist in memory. For example, if we needed to extract any values within our closure to be used outside of it, we may not do so. During the earlier days of Swift, closure parameters were escaping by default. Due to better memory management and optimizations, Swift has changed all closures to be non-escaping by default.

var closuresArray: [() -> Void] = []
func doClosures(completion: () -> Void){
completionHandlers.append(completion)
}
//ERROR!!!
passing non-escaping parameter 'completion' to function expecting an @escaping closure

Here is an example of an non-escaping closure. Here we have an empty array of closure and a function that includes a closure. If we were to append the closure in the function to the array of closure, we cannot do so because it is defaulted to non-escape. One great thing about Xcode is that it will that you that you need an escaping closure and can implement it for you.
Escaping Closure : 
Essentially escaping closure is the opposite of non-escaping closure. An escaping closure grants the ability of the closure to outlive the function and can be stored elsewhere. By using escape closure, the closure will have existence in memory until all of it’s content have been executed. To implement escaping closure, all we have to do is put @escaping in front of our closure. If you are unsure whether your closure needs escaping, no worries, as I’ve said before the complier is smart enough to let you know.
There are several ways when we need to implement an escaping closure. One instance is when we use asynchronous execution. When we are dealing with dispatch queue, the queue will hold onto the closure for you, and when the queue is done completing its work, then it will return back to the closure and complete it. Since dispatch queue is outside of the scope, we need to use escaping closure. Another instance is when we need to store our closure to a global variable, property, or any bit of storage that lives on past the function.

Always remember to use weak self while using a closure.

Difference between Stack and Heap

Ans. 

1. Stack is used for static memory allocation, Heap is used for dynamic memory allocation.

2. Variables allocated on the stack are stored directly into memory and access memory very faster and its allocation dealt with compile time.
  Variable allocated on the heap have their memory allocated at run time and accessing their memory is bit slower.

3. Stack is always reserved in LIFO order, but you can allocate and release any element/block on heap anytime. So this is much complex to say about which block is free or allocated at given time.

4. You can use stack when you know how much data you need to allocate before compile time and they are not too big. You can use heap when you don't know how much data you need to allocate or they are too big.

5. Stack is thread specific and heap is application specific. In multi threaded, each thread has its own stack.

Stack allocation vs Heap allocation (Why stack is faster than heap)

Stack allocation means that assembly just needs to increment stack pointer and that’s it. How ever in case of heap, there is lot more going on. The memory allocator needs to ask kernel for some free page, needs to partition the page properly, with time fragmentation may occur, etc. Thus with one word to say, lot of work. Struct is stored in stack and class is stored in heap.

Optional, Optional Binding, Unwrapping and Optional Chaining

Ans : 

Optional : Optional is swift's powerful feature which come to solve problem of  non-existing value. It is just a type . There are two types as Int (which must has a value) and Int?(which may contain a Int value or may have nil value). It is declared as T? i.e Int?, String?

Forced Unwrapping : Exclamation mark ( ! ) is used to unwrap value.
i.e let optionalInt : Int? = 5
let intVal : Int = 2
optionalInt! + intVal

So we hvae forecfully unwrap optionaInt. That means we tell compiler that optionalInt has a value and extract and use it.

But this is not good practise. If sometimes optionaInt has not value and we try to unwrap, then app will be crashed. A good practise is to check with nil before unwrapping or use optional binding. It checks it has value or not and if and only if it has value extract it and use it.

Optional Binding : You use optional binding to check if the optional contains a value or not. If it does contain a value, unwrap it and put it into a temporary constant or variable.

Example :

var stockCode:String? = findStockCode("Facebook")

let text = "Stock Code - "

if let tempStockCode = stockCode {

    let message = text + tempStockCode

    println(message)
}

The “if let” (or “if var”) are the two keywords of optional binding. In plain English, the code says “If stockCode contains a value, unwrap it, set its value to tempStockCode and execute the conditional block. Otherwise, just skip it the block”. As the tempStockCode is a new constant, you no longer need to use the ! suffix to access its value.

Implicitly Unwrapped Optional : When we are very very sure about it has value after first time it is set, then we need not unwrap every time. So for this type of scenario, we have to use it with ! mark in their type.

// forced unwrapping
let optionalInt: Int? = 123
let forcedInt: Int = optionalInt!

// implicitly unwrapped optional
let assumedInt: Int! = 123
let implicitInt: Int = assumedInt

It may has nil value.

Optional Chaining :

The feature allows us to chain multiple optionals together with the “?.” operator.


if let sharePrice = findStockCode("Apple")?.price {

    let totalCost = sharePrice * 100

    println(totalCost)

}

FindstockCode method returns optional value. We can access multiple optional together using Optional chaining feature.

Difference between Swift and Objective C

Ans : 

1. Swift is easier to read :

Swift removes @ symbol which exists in objective C.
Swift removes also legacy convention like semicolon at end of  statement.
Swift's method and function are easily called and [[ ]] are removed which exists in Objective C.

2. Swift is easier to maintain :

There are only 1 file to maintain name.swift. In objective c, there are .h and .m file for one viewcontroller or any views. So in swift, we have to maintain less files.

3. Swift is safe :

Optional type make the possibility of nil value very clearly, which means it generate compiler error as you write bad code instead of run time. So it reduce programmer's time due to not run the program for checking and resolve it after error coming run time.

4. Swift is robust in memory management :

ARC is available in Objective C but it supports only for Cocoa API and object oriented code. It does not support for procedural C code and Core Graphics API. So its programmer responsibility to mange memory. So it may have memory leak issue. Swift supports ARC for both procedural and object orientated code.

5. Swift less code :

+ sign concatenate two string in swift.
No need to remember value type token as %d, %s, %c like objective C. Swift does not require this type of token.

6. Swift is faster :

7. Swift supports dynamic library :

iOS doesn't support dynamic library untill released of swift and iOS 8.

8. Swift has playground :

Useful when programmar want to test 5 to 10 lines of code, he can test on playground instead of creating new application.