Modern Objective c

Use 'Modern Objective-C Syntax'

Objective-C makes heavy use of the @ operator, which generally denotes Objective-C objects. For example, "string" is a char*, while @"string" is an NSString. These have been standard in Objective-C for a long time, but only recently, in Objective-C 2.0, did Apple add in definitions for NSDictionary, NSArray, and NSNumber, all using literals specified with @ directives.

-----------------------------------------------------------------------------------------------------

NSNumber *number = [NSNumber numberWithInteger:7];

NSNumber *modernNumber = @(7); // or @7

-----------------------------------------------------------------------------------------------------

NSArray *array = [NSArray arrayWithObjects:number, modernNumber, nil];

NSArray *modernArray = @[number, modernNumber];

-----------------------------------------------------------------------------------------------------

NSDictionary *dictionary = [NSDictionary dictionaryWithObjectsAndKeys:number, @"number"];

NSDictionary *modernDictionary = @{@"number" : number};

-----------------------------------------------------------------------------------------------------

It's more concise, and still somehow more readable.

Enum 

Replace your enum declarations, such as this one:

enum {

UITableViewCellStyleDefault,

UITableViewCellStyleValue1,

UITableViewCellStyleValue2,

UITableViewCellStyleSubtitle

};

typedef NSInteger UITableViewCellStyle;

with the NS_ENUM syntax:

typedef NS_ENUM(NSInteger, UITableViewCellStyle) {

UITableViewCellStyleDefault,

UITableViewCellStyleValue1,

UITableViewCellStyleValue2,

UITableViewCellStyleSubtitle

};

But when you use enum to define a bitmask, such as here:

enum {

UIViewAutoresizingNone                 = 0,

UIViewAutoresizingFlexibleLeftMargin   = 1 << 0,

UIViewAutoresizingFlexibleWidth        = 1 << 1,

UIViewAutoresizingFlexibleRightMargin  = 1 << 2,

UIViewAutoresizingFlexibleTopMargin    = 1 << 3,

UIViewAutoresizingFlexibleHeight       = 1 << 4,

UIViewAutoresizingFlexibleBottomMargin = 1 << 5

};

typedef NSUInteger UIViewAutoresizing;

use the NS_OPTIONS macro.

typedef NS_OPTIONS(NSUInteger, UIViewAutoresizing) {

UIViewAutoresizingNone                 = 0,

UIViewAutoresizingFlexibleLeftMargin   = 1 << 0,

UIViewAutoresizingFlexibleWidth        = 1 << 1,

UIViewAutoresizingFlexibleRightMargin  = 1 << 2,

UIViewAutoresizingFlexibleTopMargin    = 1 << 3,

UIViewAutoresizingFlexibleHeight       = 1 << 4,

UIViewAutoresizingFlexibleBottomMargin = 1 << 5

};

Alternatively, you can use the modern Objective-C converter in Xcode to make this change to your code automatically. 

iOS 7.1 App Life Cycle

Launching an app into the foreground

Launching an app into the background 

iOS regulates background processing very tightly, and offers three approaches to implement it:

• Register a Background Task - If an application needs to complete an important task, it can ask iOS not to interrupt the task when the application moves into the background. For example, an application might need to finish logging in a user, or finish downloading a large file.
• Register as a Background-Necessary Application - An app can register as a specific type of application that has known, specific backgrounding requirements, such as Audio, VoIP, External Accessory,Newsstand, and Location. These applications are allowed continuous background processing privileges as long as they are performing tasks that are within the parameters of the registered application type.
• Enable Background Updates - Applications can trigger background updates with Region Monitoring or by listening for Significant Location Changes. As of iOS 7, applications can also register to update content in the background using Background Fetch or Remote Notifications.

Change of App State in iOS 

The App Launch Sequence on iOS

In the beginning was main()

The execution of every C program starts with a function called main(), and since Objective-C is a strict superset of C, the same must be true for an Objective-C program. If you create a new iOS project from one of the default templates, Xcode places this function in a separate file called main.m in the Supporting Filesgroup. Usually, you never have to look at that file but let’s do. This is the entire code of main():

1 2 3 4 5 6 7

int main(int argc, char *argv[]) { NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; int retVal = UIApplicationMain(argc, argv, nil, nil); [pool release]; return retVal; }

The function’s arguments argc and argv contain info about the command-line arguments passed to the executable on launch. We can safely ignore them for this discussion. Let’s have a look at what the function does, which seems to be very litte:

1. It creates an autorelease pool because in every Cocoa app one must exist at all times (otherwise, anautorelease call would fail).
2. It calls a function named UIApplicationMain(). We will take a deeper look at it below.
3. It drains the autorelease pool it just created.
4. It returns the return value of UIApplicationMain() to its caller (which is the shell that launched the executable).

When an (Objective-)C program reaches the end of main(), it ends. So this looks like a very short program indeed. Nevertheless, this is how all iOS apps work, so the secret must be the UIApplicationMain()function. Should it ever return, our program would end immediately.

UIApplicationMain()

Looking at the documentation for UIApplicationMain(), we find this:

This function instantiates the application object from the principal class and and instantiates the delegate (if any) from the given class and sets the delegate for the application. It also sets up the main event loop, including the application’s run loop, and begins processing events. If the application’s Info.plist file specifies a main nib file to be loaded, by including theNSMainNibFile key and a valid nib file name for the value, this function loads that nib file.

Despite the declared return type, this function never returns.

Let’s take this apart step by step:

Flowchart of the app launch sequence on iOS 4. Feel free to share this image under a Creative Commons Attribution license (CC-BY).

1. First, the function creates the main application object (step 3 in the flowchart). If you specify nil as the third argument to UIApplicationMain() (the default), it will create an instance of UIApplication in this step. This is usually what you want. However, if you need to subclass UIApplication (for example, to override its event handling in sendEvent:), you have to pass a string with the name of your subclass to UIApplicationMain().
2. The function then looks at its fourth argument. If it is non-nil, it interprets it as the name of the class for the application delegate, instantiates an object of this class and assigns it as the application object’sdelegate. The default for the fourth argument is nil, though, which signifies that the app delegate will be created in the main NIB file.
3. Next, UIApplicationMain() loads and parses your app’s Info.plist (step 4). If it contains a key named “Main nib file base name” (NSMainNibFile), the function will also load the NIB file specified there (step 5).
4. By default, the main NIB file is called MainWindow.nib. It contains at least an object representing the application delegate, connected to the File’s Owner’s delegate outlet (step 6), and a UIWindow object that will be used as the app’s main window, connected to an outlet of the app delegate. If you used a view-controller-based app template, the NIB file will also contain your app’s root view controller and possibly one or more view child controllers.
   It is worth mentioning that this is the only step where the UIKit-based app templates (Window-based, View-based, Navigation-based, Tab-based, etc.) differ significantly from each other. If you started out with a view-based app and later want to introduce a navigation controller, there is no need to start a new project: simply replace the root view controller in the main NIB file and adjust one or two lines of code in the app delegate. I noticed that many newbies to the iOS platform struggle with this problem and assume a huge difference between the different project templates. There isn’t.
5. Now, UIApplicationMain() creates the application’s run loop that is used by the UIApplicationinstance to process events such as touches or network events (step 7). The run loop is basically an infinite loop that causes UIApplicationMain() to never return.
6. Before the application object processes the first event, it finally sends the well-knownapplication:didFinishLaunchingWithOptions: message to its delegate, giving us the chance to do our own setup (step 8). The least we have to do here is put our main window on the screen by sending it a makeKeyAndVisible message.

Entry points

You see, there is no magic here. Besides application:didFinishLaunchingWithOptions:, there are several more entry points for custom code during the launch sequence (none of which are usually needed):

• Directly in main() before UIApplicationMain() is called.
• The init method of a custom UIApplication subclass.
• The initWithCoder: or awakeFromNib methods of our application delegate if it is created from a NIB file (the default).
• The +initialize methods of our application delegate class or a custom UIApplication subclass. Any class receives an +initialize message before it is sent its first message from within the program.

Note that this sequence only happens at the actual launch of an app. If the app is already running and simply brought back from the background, none of this occurs.

Regards or Taken from : http://oleb.net/blog

June 27, 2011

Working with UIRefreshControl

             The class reference of UIRefreshControl is short, hinting at how easy it is to get started with this addition of the UIKit framework. The UIRefreshControl class directly descends from UIControl, which means that setting up an instance ofUIRefreshControl is not much different from creating and configuring any other UIKit control. After instantiating an instance of the UIRefreshControl class, you assign it to the new refreshControl property of a table view controller object (UITableViewController or a subclass of it). The table view controller takes care of properly positioning and displaying the refresh control. As with any otherUIControl subclass, you attach a target-action pair to a specific event,UIControlEventValueChanged in the case of UIRefreshControl.

      If you run the application in the iPhone Simulator, you should see an empty table view. Take a look at the implementation of the viewDidLoad method shown below. We initialize the refresh control and add a target and action for the UIControlEventValueChangedevent of the refresh control. Finally, the refresh control is assigned to therefreshControl property of the table view controller. Of course, therefreshControl property is also new for iOS 6.

- (void)viewDidLoad {

    [super viewDidLoad];

    // Initialize Refresh Control

    UIRefreshControl *refreshControl = [[UIRefreshControl alloc] init];

    // Configure Refresh Control

    [refreshControl addTarget:self action:@selector(refresh:) forControlEvents:UIControlEventValueChanged];

    // Configure View Controller

    [self setRefreshControl:refreshControl];

}










Before we build and run the project once more, we need to implement therefresh: action in the view controller's implementation file. The idea behind the refresh control is in some ways similar to UIKit's activity indicator view (UIActivityIndicatorView), that is, you are responsible for showing and hiding it. Hiding the refresh control is as simple as sending it a message ofendRefreshing. 







- (void)refresh:(id)sender

{

    NSLog(@"Refreshing");


// End Refreshing

    [(UIRefreshControl *)sender endRefreshing];

}







There are many libraries that try to mimic the original "pull to refresh" functionality, but it is nice to see that Apple has finally embraced this neat concept and included it in the UIKit framework.