Navigation controller and custom segues

http://www.cmumobileapps.com/2011/11/04/a-short-tutorial-on-custom-segues/

its All about Gestures

Gestures are swipe,pan,zoom

Difference between Pan and Swipe

By definition, a swipe gesture is necessarily also a pan gesture -- both involve translational movement of touch points. The difference is in the recognizer semantics: a pan recognizer looks for the beginning of translational movement and continues to report movement in any direction over time, while a swipe recognizer makes an instantaneous decision as to whether the user's touches moved linearly in the required direction.

By default, no two recognizers will recognize the same gesture, so there's a conflict between pan and swipe. Most likely, your pan recognizer "wins" the conflict because its gesture is simpler / more general: A swipe is a pan but a pan may not be a swipe, so the pan recognizes first and excludes other recognizers.

You should be able to resolve this conflict using the delegate methodgestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer:, or perhaps without delegation by making the pan recognizer depend on the swipe recognizer withrequireGestureRecognizerToFail:.

With the conflict resolved, you should be able to simulate a one-finger swipe by quickly dragging the mouse. (Though as the mouse is more precise than your finger, it's a bit more finicky than doing the real thing on a device.) Two-finger pan/swipe can be done by holding the Option & Shift keys.

Pinch and Rotate

Just like we could get the translation from the pan gesture recotnizer, we can get the scale and rotation from the UIPinchGestureRecognizer and UIRotationGestureRecognizer.

Every view has a transform that is applied to it, which you can think of as information on the rotation, scale, and translation that should be applied to the view. Apple has a lot of built in methods to make working with a transform easy such as CGAffineTransformScale (to scale a given transform) and CGAffineTransformRotate (to rotate a given transform). 

Simultaneous Gesture Recognizers

 By default, once one gesture recognizer on a view “claims” the gesture, no others can recognize a gesture from that point on.

However, you can change this by overriding a method in the UIGestureRecognizer delegate.

- (BOOL)gestureRecognizer:(UIGestureRecognizer *)gestureRecognizer shouldRecognizeSimultaneouslyWithGestureRecognizer:(UIGestureRecognizer *)otherGestureRecognizer { return YES; }

This method tells the gesture recognizer whether it is OK to recognize a gesture if another (given) recognizer has already detected a gesture. The default implementation always returns NO – we switch it to always return YES here.

UIGestureRecognizer Dependencies

requireGestureRecognizerToFail is a method we can use of to negate one gesture

Topics

1.Difference between frame and bounds
The frame of a rectangle is a view expressed as a location(x,y) and size(width,height)relative to its super view whereas the bounds of a view is expressed as a location(x,y) an size  relative to its own co-ordinate system

2.Class hierarchy of UIButton
UIButton->UIControl->UIView->UIResponder->NSObject

3.KVC and KVO

KVC (Key Value Coding)
KVO (Key value Observing) is built on top of KVC.It allows you to observe a KVC path on an object to see when the value changes

4.Objective C
Is a SuperSet of C,Built on top of C.Everything C can do Objective C can do too.But not the other way around.
       Methods
So we have an “instance” of a car, now that what do we do with it? Well, we drive it and fill it with petrol, among other things. Driving and filling with petrol apply only to the cars that we use, meaning that when we fill up a car or drive a car, we are only impacting one instance, and not all the cars in the world. Therefore, filling up the car instance is considered an instance method. Itʼs something we do to our instance and only our instance.

On the other hand, if we ask the original car class how many colors of car are available, this is a class method because we are no longer only talking about the car we drive around but all cars in general.

5.Difference between a target and a project in XCode

An XCode project is a container that contains all the files and required resources to build one or more software products

A project may contain one or more targets which specify how to build product.

A target defines a single product.Project contain one or more targets each of which produces one product.

6.Difference between categories and Subclassing

categories only add methods, you can't add variables to a class using categories. If the class needs more properties, then it has to be subclassed.(edit: you can use associative storage, I believe).

Categories are a nice way to add functionality while at the same time conforming to an object oriented principle to prefer composition over inheritance.

There are three uses of a category, each of which add methods to a class (note: methods only, not iVars)

Extending an existing Cocoa class

This lets you add your own methods to an existing class. For example, if you want to extend NSString to apply special capitalization, you could create a new class called, say NSString+Capitals. in the NSString+Capitals.h you would have:

@interface NSString (Capitals)

-(NSString *)alternateCaps:(NSString *)aString;

@end

and in NSString+Capitals.m you would implement the method

@implementation NSString (Capitals)
-(NSString *)alternateCaps:(NSString *)aString
{
    // Implementation
}

Private methods on a class

This is the same as above, except that the extra methods are declared and defined in the implementation file (.m) Usually a way of having private methods - because they are not in the .h file (which is the one #imported by other classes) they are simply not visible. In this case, the implementation of the methods are done in their own implementation block. e.g

// someClass.m
@interface someClass (extension)
-(void)extend;
@end

@implementation someClass
    // all the methods declared in the .h file and any superclass
    // overrides in this block
@end

@implementation someClass (extension)
-(void)extend {
    // implement private method here;
}

Class Extension (New for 10.5 Leopard)

A simpler way of having private methods. In this special case, the category name is empty and the private methods are implemented in the same block as all the other class methods.

// someClass.m
@interface someClass ()
-(void)extend;
@end

@implementation someClass
    // all the methods declared in the .h file and any superclass
    // overrides in this block
    // Implement private methods in this block as well.
-(void)extend {
    // implement private method here;
}

@end




Refer

http://stackoverflow.com/questions/360968/category-usage-in-objective-c?rq=1







You can't add instance variables in categories.

However, you can add storage for your attribute to an object using associative references. Note that if you need to add more than one attribute, rather than adding an associative reference for each, you're probably better off adding a single reference to (say) an NSMutableDictionary, CFMutableDictionaryRef, or NSMapTable and using that for all of your attributes.

Here some Code:

Filename: NSObject+dictionary.h

#import <Foundation/Foundation.h>
#import <objc/runtime.h>
@interface NSObject (dictionary)
- (NSMutableDictionary*) getDictionary;
@end

Filename: NSObject+dictionary.h

#import "NSObject+dictionary.h"
@implementation NSObject (dictionary)
- (NSMutableDictionary*) getDictionary
{
  if (objc_getAssociatedObject(self, @"dictionary")==nil) 
  {
    objc_setAssociatedObject(self,@"dictionary",[[NSMutableDictionary alloc] init],OBJC_ASSOCIATION_RETAIN);
  }
  return (NSMutableDictionary *)objc_getAssociatedObject(self, @"dictionary");
}

Now every instance (of every class) has a dictionary, where you can store your custom attributes. WithKey-Value Coding you can set a value like this:

[myObject setValue:attributeValue forKeyPath:@"dictionary.attributeName"]

And you can get the value like this:

[myObject valueForKeyPath:@"dictionary.attributeName"]

That even works great with the Interface Builder and User Defined Runtime Attributes.

Key Path                   Type                     Value
dictionary.attributeName   String(or other Type)    attributeValue

userInterfaceIdiom

The style of interface to use on the current device. (read-only)

@property(nonatomic, readonly) UIUserInterfaceIdiom userInterfaceIdiom

For Universal applications you can use this property to tailor the behavior of your application for a specific device.iPad and iPhone have different screen sizes so we need to load specific view controller depending on the device.

UIRequiredDeviceCapabilities

This lets iTunes and App store know which device related features required for an app to run.iTunes and App store uses this info to prevent the users from installing the app on the device that does not support the required capabilities.

Key	Description
telephony	Include this key if your app requires (or specifically prohibits) the presence of the Phone app. You might require this feature if your app opens URLs with the tel scheme.
wifi	Include this key if your app requires (or specifically prohibits) access to the networking features of the device.
sms	Include this key if your app requires (or specifically prohibits) the presence of the Messages app. You might require this feature if your app opens URLs with the sms scheme.
still-camera	Include this key if your app requires (or specifically prohibits) the presence of a camera on the device. Apps use theUIImagePickerController interface to capture images from the device’s still camera.
auto-focus-camera	Include this key if your app requires (or specifically prohibits) auto-focus capabilities in the device’s still camera. Although most developers should not need to include this key, you might include it if your app supports macro photography or requires sharper images in order to do some sort of image processing.
front-facing-camera	Include this key if your app requires (or specifically prohibits) the presence of a forward-facing camera. Apps use theUIImagePickerController interface to capture video from the device’s camera.
camera-flash	Include this key if your app requires (or specifically prohibits) the presence of a camera flash for taking pictures or shooting video. Apps use the UIImagePickerController interface to control the enabling of this feature.
video-camera	Include this key if your app requires (or specifically prohibits) the presence of a camera with video capabilities on the device. Apps use the UIImagePickerController interface to capture video from the device’s camera.
accelerometer	Include this key if your app requires (or specifically prohibits) the presence of accelerometers on the device. Apps use the classes of the Core Motion framework to receive accelerometer events. You do not need to include this key if your app detects only device orientation changes.
gyroscope	Include this key if your app requires (or specifically prohibits) the presence of a gyroscope on the device. Apps use the Core Motion framework to retrieve information from gyroscope hardware.
location-services	Include this key if your app requires (or specifically prohibits) the ability to retrieve the device’s current location using the Core Location framework. (This key refers to the general location services feature. If you specifically need GPS-level accuracy, you should also include the gps key.)
gps	Include this key if your app requires (or specifically prohibits) the presence of GPS (or AGPS) hardware for greater accuracy when tracking locations. If you include this key, you should also include the location-services key. You should require GPS only if your app needs more accurate location data than the cell or Wi-fi radios might otherwise allow.
magnetometer	Include this key if your app requires (or specifically prohibits) the presence of magnetometer hardware. Apps use this hardware to receive heading-related events through the Core Location framework.
gamekit	Include this key if your app requires (or specifically prohibits) Game Center (iOS 4.1 and later.)
microphone	Include this key if your app uses the built-in microphone or supports accessories that provide a microphone.
opengles-1	Include this key if your app requires (or specifically prohibits) the presence of the OpenGL ES 1.1 interfaces.
opengles-2	Include this key if your app requires (or specifically prohibits) the presence of the OpenGL ES 2.0 interfaces.
armv6	Include this key if your app is compiled only for the armv6 instruction set. (iOS v3.1 and later.)
armv7	Include this key if your app is compiled only for the armv7 instruction set. (iOS v3.1 and later.)
peer-peer	Include this key if your app requires (or specifically prohibits) peer-to-peer connectivity over Bluetooth. (iOS v3.1 and later.)
bluetooth-le	Include this key if your app requires (or specifically prohibits) the presence of Bluetooth low-energy hardware on the device. (iOS 5 and later.)