Questions 13 to 17 in 50
Page 3
What is notification in iOS?
The notification mechanism of Cocoa implements a one-to-many broadcast of messages based on the Observer pattern. Objects in a program add
themselves or other objects to a list of observers of one or more notifications, each of which is identified by a global string (the
notification name). The object that wants to notify other objects the observed object creates a notification object and posts it to a
notification center. The notification center determines the observers of a particular notification and sends the notification to them
via a message. The methods invoked by the notification message must conform to a certain single-parameter signature. The parameter of
the method is the notification object, which contains the notification name, the observed object, and a dictionary containing any supplemental
information. Posting a notification is an asynchronous procedure. The posting object doesn’t regain control until the notification center has
broadcast the notification to all observers. For asynchronous behavior, you can put the notification in a notification queue; control returns
immediately to the posting object and the notification center broadcasts the notification when it reaches the top of the queue. Regular
notifications that is, those broadcast by the notification center are intra-process only. If you want to broadcast notifications to other
processes, you can use the distributed notification center and its related API.
What is the difference between delegates and notifications?
We can use notifications for a variety of reasons. For example, you could broadcast a notification to change how user-interface elements
display information based on a certain event elsewhere in the program. Or you could use notifications as a way to ensure that objects in
a document save their state before the document window is closed. The general purpose of notifications is to inform other objects of program
events so they can respond appropriately. But objects receiving notifications can react only after the event has occurred. This is a
significant difference from the delegation. The delegate is given a chance to reject or modify the operation proposed by the delegating object.
Observing objects, on the other hand, cannot directly affect an impending operation.
What is posing in iOS?
Objective-C permits a class to entirely replace another class within an application. The replacing class is said to “pose as” the target class.
All messages sent to the target class are then instead received by the posing class. There are some restrictions on which classes can pose:
- A class may only pose as one of its direct or indirect superclasses.
- The posing class must not define any new instance variables which are absent from the target class (though it may define or override methods).
- No messages must have been sent to the target class prior to the posing.
- A posing class can call overridden methods through super, thus incorporating the implementation of the target class.
- A posing class can override methods defined in categories.
What is Controller Object?
A controller object acts as a coordinator or as an intermediary between one or more view objects and one or more model objects. In the
Model-View-Controller design pattern, a controller object (or, simply, a controller) interprets user actions and intentions made in view
objects such as when the user taps or clicks a button or enters text in a text field and communicates new or changed data to the model objects.
When model objects change for example, the user opens a document stored in the file system it communicates that new model data to the view objects so that they can display it. Controllers are thus the conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also set up and coordinate tasks for an application and manage the life cycles of other objects. The Cocoa frameworks offer three main controller types: coordinating controllers, view controllers (on iOS), and mediating controllers (on OS X).
When model objects change for example, the user opens a document stored in the file system it communicates that new model data to the view objects so that they can display it. Controllers are thus the conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also set up and coordinate tasks for an application and manage the life cycles of other objects. The Cocoa frameworks offer three main controller types: coordinating controllers, view controllers (on iOS), and mediating controllers (on OS X).
What is code signing?
Signing an application allows the system to identify who signed the application and to verify that the application has not been modified
since it was signed. Signing is a requirement for submitting to the App Store (both for iOS and Mac apps). OS X and iOS verify the signature
of applications downloaded from the App Store to ensure that they they do not run applications with invalid signatures. This lets users trust
that the application was signed by an Apple source and hasn’t been modified since it was signed.
Xcode uses your digital identity to sign your application during the build process. This digital identity consists of a public-private key pair and a certificate. The private key is used by cryptographic functions to generate the signature. The certificate is issued by Apple it contains the public key and identifies you as the owner of the key pair.
In order to sign applications, you must have both parts of your digital identity installed. Use Xcode or Keychain Access to manage your digital identities. Depending on your role in your development team, you may have multiple digital identities for use in different contexts. For example, the identity you use for signing during development is different from the identity you user for distribution on the App Store. Different digital identities are also used for development on OS X and on iOS.
An application’s executable code is protected by its signature because the signature becomes invalid if any of the executable code in the application bundle changes. Resources such as images and nib files are not signed; a change to these files does not invalidate the signature.
An application’s signature can be removed, and the application can be re-signed using another digital identity. For example, Apple re-signs all applications sold on the App Store. Also, a fully-tested development build of your application can be re-signed for submission to the App Store. Thus the signature is best understood not as indelible proof of the application’s origins but as a verifiable mark placed by the signer
Xcode uses your digital identity to sign your application during the build process. This digital identity consists of a public-private key pair and a certificate. The private key is used by cryptographic functions to generate the signature. The certificate is issued by Apple it contains the public key and identifies you as the owner of the key pair.
In order to sign applications, you must have both parts of your digital identity installed. Use Xcode or Keychain Access to manage your digital identities. Depending on your role in your development team, you may have multiple digital identities for use in different contexts. For example, the identity you use for signing during development is different from the identity you user for distribution on the App Store. Different digital identities are also used for development on OS X and on iOS.
An application’s executable code is protected by its signature because the signature becomes invalid if any of the executable code in the application bundle changes. Resources such as images and nib files are not signed; a change to these files does not invalidate the signature.
An application’s signature can be removed, and the application can be re-signed using another digital identity. For example, Apple re-signs all applications sold on the App Store. Also, a fully-tested development build of your application can be re-signed for submission to the App Store. Thus the signature is best understood not as indelible proof of the application’s origins but as a verifiable mark placed by the signer