IOS Coding Tips for Beginners

1. Create view objects in Interface builder not in source code.

2. Flower brackets always be there in if conditions or while loops, even it has single statement.

3. Give one line space between @implementation and @synthesize

4. Open flower bracket “{” should start in next line.

5. Give one line space above conditional or loop statements like if, while, for.

6. The method name itself should resembles its behavior.

7. Remove unnecessary methods which are created by the file templates.

8. Use Edit->Format->Re-Indent to re-indent the selection of statements.

9. Don’t use string literals as keys, make the string literal as constant and use that. Place all constants in a common file.

10. Try to use property directly than calling the accessory method. for example Object.memberVariable than [Object memberVariable];

11. Try to define all literals in common file.

12. Instead of using literals, create meaningful constants for them in common file and use them.

13. Always group the things like constants, statements, etc.

14. The format for method signature should be like
– (void) methodName:(id) sender;

15. One line space between logical group of statements and two lines between physical groups.

16. Try to eliminate autorelease objects, instead use retain and release.

17. If you are declaring a UI object, please suffix the type to the variable. For example, if you are declaring a UILabel object with name ‘userName’, then name it ‘userNameLabel’.

18. Maintain all image names in lowercase with underscore dividing the inline words.

19. Directly access the variable instead of using property in the same class. For example, don’t access

UITableView mTableView;
@Property () UITableView *tableView;
//To reload the table in the same class use
[mTableView reloadData]; // correct
[self.tableView reloadData]; //wrong

Using C++ to access file from Documents folder on iOS and Print the contents

void printFileInfo()

char *home = getenv(“HOME”);
char *subdir = “/Documents”;

std::stringstream ss;
ss << home << subdir << “/file.txt”;
std::string s = ss.str();

s.erase(0, strlen(“/private”)); // Erase “/Private” from the final string

char sss;

char letter ;
int i ;
std::string line ;

std::ifstream reader(s.c_str()) ;

if (!reader) {

std::cout << “Error opening input file” << std::endl ;
return -1 ;


for (i = 0; !reader.eof() ; i++) {

getline( reader , line ) ;
std::cout << s.c_str() << std::endl;
std::cout << line << std::endl ;

reader.close() ;


iPv6 Network not available issue

+ (instancetype)  reachabilityForInternetConnection

Reachability *reach = NULL;
NetworkStatus status = NotReachable;

struct sockaddr_in zeroAddress;
bzero(&zeroAddress, sizeof(zeroAddress));
zeroAddress.sin_len = sizeof(zeroAddress);
zeroAddress.sin_family = AF_INET;

reach = [self reachabilityWithAddress: (const struct sockaddr *) &zeroAddress];

if  (reach != NULL)

status = [reach currentReachabilityStatus];

if (status != NotReachable)

NSLog(@”Connected to Ipv4 Environment”);

return reach;



if  ([[UIDevice currentDevice].systemVersion floatValue] < 9.0)

// check whether you are in iPv6 environment

struct sockaddr_in6 zeroAddress1;
bzero(&zeroAddress1, sizeof(zeroAddress1));
zeroAddress1.sin6_len = sizeof(zeroAddress1);
zeroAddress1.sin6_family = AF_INET6;

reach = [self reachabilityWithAddress: (const struct sockaddr *) &zeroAddress1];

if  (reach != NULL)

status = [reach currentReachabilityStatus];

if (status != NotReachable)

NSLog(@”Connected to Ipv6 Environment”);




return reach;


CoreTelephony CTCallCenter

The [[CTCallCenter alloc] init] must be run in the main queue. Is it thread safe ??? Better call it on main thread only.

There is an iOS bug that causes instances of the CTCallCenter class to sometimes get notifications after they have been deallocated. Instead of instantiating, using, and releasing instances you must instead retain and never release them to work around the bug.

static CTCallCenter *netInfo; static dispatch_once_t dispatchToken; if (!netInfo) { dispatch_once(&dispatchToken, ^{ netInfo = [[CTCallCenter alloc] init]; }); }


How to programmatically know Bluetooth headset is connected to iOS device

Call this method to find out the bluetooth headset is connected or not.


- (BOOL) isBluetoothHeadsetConnected
    AVAudioSession *session = [AVAudioSession sharedInstance];
    AVAudioSessionRouteDescription *routeDescription = [session currentRoute];

    DEBUGLOG(@"Current Routes : %@", routeDescription);

    if (routeDescription)
        NSArray *outputs = [routeDescription outputs];

        if (outputs && [outputs count] > 0)
            AVAudioSessionPortDescription *portDescription = [outputs objectAtIndex:0];
            NSString *portType = [portDescription portType];

            DEBUGLOG(@"dataSourceName : %@", portType);

            if (portType && [portType isEqualToString:@"BluetoothA2DPOutput"])
                return YES;

    return NO;

How to enable or disable Proximity sensor programmatically in iPhone

Use the following API to enable/disable the proximity sensor.

[UIDevice currentDevice].proximityMonitoringEnabled = NO; // Disables the Proximity Sensor

[UIDevice currentDevice].proximityMonitoringEnabled = YES; // Enables the Proximity Sensor

Not all iOS devices have proximity sensors. To determine if proximity monitoring is available, attempt to enable it. If the value of the proximityMonitoringEnabled property remains NO, proximity monitoring is not available.

Understand NSAssert (and its stdlib equivalent Assert)

Assert is to make sure a value is what its supposed to be. If an assertion fails that means something went wrong and so the app quits.

It is important to make sure that there is no data loss in any such situation.

Note that XCode 4 has NS_BLOCK_ASSERTIONS defined by default in release configurations. I guess if you don’t change that your released code will not contain NSAsserts. So, just put the macro in your distribution target [only].

NSAssert (and its stdlib equivalent Assert) can be very useful for debugging/unit testing, and also when you provide frameworks to stop the users from doing “evil” things. So not only does it safe-guard against potentially bad inputs but it logs them in a useful, standard way.

Assertions are commonly used to enforce the intended use of a particular method or piece of logic. They enforce that your code is used only as intended.

The value that’s passed is entered by the user, you need to do proper validation of the input rather than relying on the assertion. A user entering a value that is not allowed should be followed by a UI error, not NSAssert crashing the application.

NSAssert is to throw an exception, which you can catch and handle (try/catch).