App ID in iOS / App ID in iPhone

An App ID is a two-part string used to identify one or more apps from a single development team. The string consists of a Team ID and abundle ID search string, with a period (.) separating the two parts.The Team ID is supplied by Apple and is unique to a specific development team, while the bundle ID search string is supplied by you to match either the bundle ID of a single app or a set of bundle IDs for a group of your apps.

An Explicit App ID Matches a Single App
Wildcard App IDs Match Multiple Apps

There are two types of App IDs: an explicit App ID, used for a single app, and wildcard App IDs, used for a set of apps.

For an explicit App ID to match an app, the Team ID in the App ID must equal the Team ID associated with the app, and the bundle ID search string must equal the bundle ID for the app. The bundle ID is a unique identifier that identifies a single app and cannot be used by other teams.

A wildcard App ID contains an asterisk as the last part of its bundle ID search string. The asterisk replaces some or all of the bundle ID in the search string.

The asterisk is treated as a wildcard when matching the bundle ID search string with bundle IDs. For a wildcard App ID to match a set of apps, the bundle ID must exactly match all of the characters preceding the asterisk in the bundle ID search string. The asterisk matches all remaining characters in the bundle ID. The asterisk must match at least one character in the bundle ID. The table below shows a bundle ID search string and some matching and nonmatching bundle IDs.

Read More

Object copying in iOS / Object copying in iPhone / copy function call in iOS iPhone / what will happen when we call copy on object

Object copying

Copying an object creates a new object with the same class and properties as the original object. You copy an object when you want your own version of the data that the object contains. If you receive an object from elsewhere in an application but do not copy it, you share the object with its owner (and perhaps others), who might change the encapsulated contents. 

Requirements for Object Copying

An object can be copied if its class adopts the NSCopying protocol and implements its single method, copyWithZone:. 

If a class has mutable and immutable variants, the mutable class should adopt the NSMutableCopying protocol (instead of NSCopying) and implement the mutableCopyWithZone: method to ensure that copied objects remain mutable. You make a duplicate of an object by sending it a copyor mutableCopy message. These messages result in the invocation of the appropriate NSCopying or NSMutableCopying method.

Copies of objects can be shallow or deep. Both shallow- and deep-copy approaches directly duplicate scalar properties but differ on how they handle pointer references, particularly references to objects (for example, NSString *str). A deep copy duplicates the objects referenced while a shallow copy duplicates only the references to those objects. So if object A is shallow-copied to object B, object B refers to the same instance variable (or property) that object A refers to. Deep-copying objects is preferred to shallow-copying, especially with value objects.

Memory-Management Implications

Like object creation, object copying returns an object with a retain count of 1. In memory-managed code, the client copying the object is responsible for releasing the copied object. Copying an object is similar in purpose to retaining an object in that both express an ownership in the object. However, a copied object belongs exclusively to the new owner, who can mutate it freely, while a retained object is shared between the owners of the original object and clients who have retained the object.

Read More

what is Selector in iOS / what is Selector in iPhone

 A selector is the name used to select a method to execute for an object, or the unique identifier that replaces the name when the source code is compiled.  A selector by itself doesn’t do anything. It simply identifies a method. compiler makes sure that selectors are unique.

What makes a selector useful is that (in conjunction with the runtime) it acts like a dynamic function pointer that, for a given name, automatically points to the implementation of a method appropriate for whichever class it’s used with.

Getting a Selector

At compile time, you use the compiler directive @selector.

SEL aSelector = @selector(methodName);

SEL aSelector = NSSelectorFromString(@"methodName");

Using a Selector

SEL aSelector = @selector(run);

[aDog performSelector:aSelector];

[anAthlete performSelector:aSelector];

[aComputerSimulation performSelector:aSelector];

At runtime, you use the NSSelectorFromString function, where the string is the name of the method:

You use a selector created from a string when you want your code to send a message whose name you may not know until runtime.

Compiled selectors are of type SEL. There are two common ways to get a selector:

You can invoke a method using a selector with performSelector: and other similar methods.

(You use this technique in special situations, such as when you implement an object that uses the target-action design pattern. Normally, you simply invoke the method directly.)

Read More

what is dispatch_once() in iOS / dispatch_once() in iOS

Executes a block object once and only once for the lifetime of an application.

This function is useful for initialization of global data (singletons) in an application. Always call this function before using or testing any variables that are initialized by the block.

If called simultaneously from multiple threads, this function waits synchronously until the block has completed.

The predicate must point to a variable stored in global or static scope. The result of using a predicate with automatic or dynamic storage (including Objective-C instance variables) is undefined.

dispatch_once() is absolutely synchronous. Not all GCD methods do things asynchronously (case in point, dispatch_sync() is synchronous). The use of dispatch_once() replaces the following idiom:

+ (MyClass *)sharedInstance {

    static MyClass *sharedInstance;

    @synchronized(self) {

        if (sharedInstance == nil) {

            sharedInstance = [[MyClass alloc] init];

        }

    }

    return sharedInstance;

}

The benefit of dispatch_once() over this is that it's faster. It's also semantically cleaner, because the entire idea of dispatch_once() is "perform something once and only once", which is precisely what we're doing.

Read More