Category Archives: Objective-C

iPhone Device & Screen Sizes and Resolutions +Xr

To get the screen dimensions (in points) of the current device:

Objective-C: 
CGRect screenBounds = [[UIScreen mainScreen] bounds]; 
// Macros: 
#define screen_width [ [ UIScreen mainScreen ] bounds ].size.width #define screen_height [ [ UIScreen mainScreen ] bounds ].size.height 
Swift: 
let screenBounds = UIScreen.main.bounds 
let screen_width = screenBounds.width 
let screen_height = screenBounds.height 

To get the screen scale:

Objective-C: 
CGFloat screenScale = [[UIScreen mainScreen] scale]; Swift: let screenScale = UIScreen.main.scale

Non-retina devices have a scale of 1.0. Retina devices have a scale of 2.0 or 3.0.

Some dimensions common to all screen sizes:

Status Bar
20 pts
Navigation Bar44 pts
Nav Bar/Toolbar Icon20 x 20 pts (transparent PNG)
Tab Bar49 pts
Tab Bar Icon30 x 30 pts (transparent PNGs)

Points vs. Pixels

Apple introduced retina displays starting with the iPhone 4. You don’t have to modify your code to support high-res displays; the iOS coordinate system uses points rather than pixels, so the dimensions and position in points of all UI elements remains the same across all devices.

iOS supports high resolution displays via the scale property on UIScreen, UIView, UIImage, and CALayer classes. If you load an image from a file whose name includes the @2x modifier, its scale property is set to 2.0. Similarly an image with a @3x modifier has a scale of 3.0. Otherwise the scale defaults to 1.0.

Retina Graphics

To support high-resolution graphics on devices with retina displays, you need @2x and @3x sized images:

@1x:
button.png
60 x 20
@2x:
button@2x.png
120 x 40
@3x:
button@3x.png
180 x 60

To refer to an image in your code (or in Interface Builder), just use the filename of the standard sized image. iOS will automatically detect and use the @2x or @3x version if the device supports it:

Objective-C: 
<br>imageView.image = [UIImage imageNamed: @"button.png"]; Swift: imageView.image = UIImage(named: @"button.png") 

How to debug deep linking in iOS

What is deep linking?

Deep linking basically enables you to open an app from another app or a website while passing on parameters. This mechanism works with custom URL schemes which you can define in the .plist of your app.

Why deep linking?

If you have an app with lookup functionality (e.g. an app for finding song lyrics) you might want to perform a lookup without having to navigate to the designated screen and typing in the query. This can be achieved by opening the following example URL MyAppScheme://myAction=lookup&myQuery=What%20is%20the%20meaning%20of%20life in another app of the browser. In this case the app is programmed to read the ‘myAction’-parameter on startup to determine the action and the ‘myQuery’-parameter for the search query. Often, deep linking doesn’t go as planned and you might need to debug your app.

Why is debugging this difficult?

Deep linking might occur in three kinds of scenarios:

  1. The app hasn’t been installed yet
  2. The app is running in the background (or foreground for that matters)
  3. The app is installed but not running at all

Scenario 1 is irrelevant in this case, so we’ll skip this one. Scenario 2 should be no problem since the app is running on the device (or simulator) while in a debug session. Scenario 3 requires you not to have the app running, but you need the debug session to be able to debug. This is a problem because Xcode starts the app automatically when starting a debug session. Instead of letting Xcode start the app, you want to do it yourself using the deep link URL.

So… tell me how to do this

There is a convenient option which enables you to start a debug session by manually starting the app. To achieve this, go to the ‘Edit scheme’ screen and tick the ‘Wait for MyApp.app to be launched manually’ option on in the ‘Run’ configuration.

Image

Whenever you run the target in Xcode, the app doesn’t automatically starts and the debug session will only start when you manually start the app.

Sending an HTTP POST request on iOS

The following code describes a simple example using POST method.(How one can pass data by POST method)

You can use the following code snippet, as described in this article:

Here, I describe how one can use of POST method.

1. Set post string with actual username and password.

NSString *post = [NSString stringWithFormat:@"Username=%@&Password=%@",@"username",@"password"]; 

2. Encode the post string using NSASCIIStringEncoding and also the post string you need to send in NSData format.

NSData *postData = [post dataUsingEncoding:NSASCIIStringEncoding allowLossyConversion:YES]; 

You need to send the actual length of your data. Calculate the length of the post string.

NSString *postLength = [NSString stringWithFormat:@"%d",[postData length]]; 

3. Create a Urlrequest with all the properties like HTTP method, http header field with length of the post string. Create URLRequest object and initialize it.

NSMutableURLRequest *request = [[[NSMutableURLRequest alloc] init] autorelease]; 

Set the Url for which your going to send the data to that request.

[request setURL:[NSURL URLWithString:@"http://www.abcde.com/xyz/login.aspx"]]; 

Now, set HTTP method (POST or GET). Write this lines as it is in your code.

[request setHTTPMethod:@"POST"]; 

Set HTTP header field with length of the post data.

[request setValue:postLength forHTTPHeaderField:@"Content-Length"]; 

Also set the Encoded value for HTTP header Field.

[request setValue:@"application/x-www-form-urlencoded" forHTTPHeaderField:@"Content-Type"];

Set the HTTPBody of the urlrequest with postData.

[request setHTTPBody:postData];

4. Now, create URLConnection object. Initialize it with the URLRequest.

NSURLConnection *conn = [[NSURLConnection alloc] initWithRequest:request delegate:self]; 

It returns the initialized url connection and begins to load the data for the url request. You can check that whether you URL connection is done properly or not using just if/else statement as below.

if(conn) {
    NSLog(@"Connection Successful");
} else {
    NSLog(@"Connection could not be made");
}

5. To receive the data from the HTTP request , you can use the delegate methods provided by the URLConnection Class Reference. Delegate methods are as below.

// This method is used to receive the data which we get using post method.
- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData*)data

// This method receives the error report in case of connection is not made to server. 
- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error 

// This method is used to process the data after connection has made successfully.
- (void)connectionDidFinishLoading:(NSURLConnection *)connection

Also Refer This and This documentation for POST method.

And here is best example with source code of HTTPPost Method.

iOS Singletons – Objective-C

A singleton is a special kind of class where only one instance of the class exists for the current process. (In the case of an iOS app, the one instance is shared across the entire app.) Some examples in UIKit are [UIApplication sharedApplication] (which returns the sole instance of the application itself), and [NSFileManager defaultManager] (which returns the file manager instance). Singletons can be an easy way to share data and common methods across your entire app.

Rather than create instances of the singleton class using alloc/init, you’ll call a class method that will return the singleton object. You can name the class method anything, but common practice is to call it sharedName or defaultName.

Header

Implementation

Show animation when addsubview

If you want to add a subview with animation, try this simple snippet:

PS: Replace myView with the name of the view you want to replace.

CATransition *applicationLoadViewIn =[CATransition animation];
[applicationLoadViewIn setDuration:duration];
[applicationLoadViewIn setType:kCATransitionReveal];
[applicationLoadViewIn setTimingFunction:[CAMediaTimingFunction functionWithName:kCAMediaTimingFunctionEaseIn]];
[[myView layer]addAnimation:applicationLoadViewIn forKey:kCATransitionReveal];

Swift, Apple’s new programming language

If anyone outside Apple saw Swift coming, they certainly weren’t making any public predictions. In the middle of a keynote filled with the sorts of announcements you’d expect (even if the details were a surprise), Apple this week announced that it has created a modern replacement for the Objective-C, a programming language the company has used since shortly after Steve Jobs founded NeXT.

Swift wasn’t a “sometime before the year’s out”-style announcement, either. The same day, a 550-page language guide appeared in the iBooks store. Developers were also given access to Xcode 6 betas, which allow application development using the new language. Whatever changes were needed to get the entire Cocoa toolkit to play nice with Swift are apparently already done.

While we haven’t yet produced any Swift code, we have read the entire language guide and looked at the code samples Apple provided. What follows is our first take on the language itself, along with some ideas about what Apple hopes to accomplish.

Why were we using Objective-C?

When NeXT began, object-oriented programming hadn’t been widely adopted, and few languages available even implemented it. At the time, then, Objective-C probably seemed like a good choice, one that could incorporate legacy C code and programming habits while adding a layer of object orientation on top.

FURTHER READING

APPLE SHOWS OFF SWIFT, ITS NEW PROGRAMMING LANGUAGE
Successor to Objective C has “none of the baggage of C.”
But as it turned out, NeXT was the only major organization to adopt the language. This had some positive aspects, as the company was able to build its entire development environment around the strengths of Objective-C. In turn, anyone who bought in to developing in the language ended up using NeXT’s approach. For instance, many “language features” of Objective-C aren’t actually language features at all; they are implemented by NeXT’s base class, NSObject. And some of the design patterns in Cocoa, like the existence of delegates, require the language introspection features of Objective-C, which were used to safely determine if an object will respond to a specific message.

The downside of narrow Objective-C adoption was that it forced the language into a niche. When Apple inherited Objective-C, it immediately set about giving developers an alternative in the form of the Carbon libraries, since these enabled a more traditional approach to Mac development.

Things changed with the runaway popularity of the iPhone SDK, which only allowed development in Objective-C. Suddenly, a lot of developers used Objective-C, and many of them already had extensive experience in other programming languages. This was great for Apple, but it caused a bit of strain. Not every developer was entirely happy with Objective-C as a language, and Apple then compounded this problem by announcing that the future of Mac development was Cocoa, the Objective-C frameworks.

What’s wrong with Objective-C?

Objective-C has served Apple incredibly well. By controlling the runtime and writing its own compiler, the company has been able to stave off some of the language limitations it inherited from NeXT and add new features, like properties, a garbage collector, and the garbage collector’s replacement, Automatic Reference Counting.

But some things really couldn’t be changed. Because it was basically C with a few extensions, Objective-C was limited to using C’s method of keeping track of complex objects: pointers, which are essentially the memory address occupied by the first byte of an object. Everything, from an instance of NSString to the most complex table view, was passed around and messaged using its pointer.

For the most part, this didn’t pose problems. It was generally possible to write complex applications without ever being reminded that everything you were doing involved pointers. But it was also possible to screw up and try to access the wrong address in memory, causing a program to crash or opening a security hole. The same holds true for a variety of other features of C; developers either had to do careful bounds and length checking or their code could wander off into random places in memory.

Beyond such pedestrian problems, Objective-C simply began showing its age. Over time, other languages adopted some great features that were difficult to graft back onto a language like C. One example is what’s termed a “generic.” In C, if you want to do the same math with integers and floating point values, you have to write a separate function for each—and other functions for unsigned long integers, double-precision floating points, etc. With generics, you can write a single function that handles everything the compiler recognizes as a number.

Apple clearly could add some significant features to the Objective-C syntax—closures are one example—but it’s not clear that it could have added everything it wanted. And the very nature of C meant that the language would always be inherently unsafe, with stability and security open to compromise by a single sloppy coder. Something had to change.

But why not take the easy route and adopt another existing language? Because of the close relationship between Objective-C and the Cocoa frameworks, Objective-C enabled the sorts of design patterns that made the frameworks effective. Most of the existing, mainstream alternatives didn’t provide such a neat fit for the existing Cocoa frameworks. Hence, Swift.

Is it any good?

Swift isn’t a radical departure in many ways. Apple likes certain design patterns, and it constructed Objective-C and Cocoa to encourage them. Swift does the same thing, going further toward formalizing some of the patterns that have been adopted in a somewhat haphazard way (like properties). Most of the features Swift adds already exist in other programming languages, and these will be familiar to many developers. The features that have been added are generally good ones, while the things that have been taken away (like pointer math) were generally best avoided anyway.

In that sense, Swift is a nice, largely incremental change from Objective-C. All the significant changes are in the basic syntax. Use semicolons and parentheses—or don’t, it doesn’t matter. Include the method signature in the function call—but only if you feel like it. In these and many other cases, Swift lets you choose a syntax and style you’re comfortable with, in many cases allowing you to minimize typing if you choose to.

Most of the new features have been used in other languages, the syntax changes get rid of a lot of Objective-C’s distinctiveness, and you’re often able to write equivalent code using very different syntax. All of this enables Swift to look familiar to a lot of people who are familiar with other languages. That sort of rapport has become more important as Apple attracts developers who’d never even touched C before. These people will still have to learn to work with the design patterns of Apple’s frameworks, but at least they won’t be facing a language that’s intimidatingly foreign at the same time.

In general, these things seem like positives. If Apple chose a single style, then chances were good that a number of its choices wouldn’t be ones we’d favor. But with the flexibility, we’ll still be able to work close to the way we’d want.

Close, but not exactly. There are a couple of specific syntax features I’m personally not a fan of and a number of cases where a single character can make a radical difference to the meaning of a line of code. Combined, the syntax changes could make managing large projects and multiple developers harder than it has been with Objective-C.

What’s Apple up to?

For starters, it’s doing the obvious. Swift makes a lot of common errors harder and a number of bad practices impossible. If you choose, you can write code in Swift pretty tersely, which should make things easier for developers. It adds some nice new features that should make said developers more productive. All of those are good things.

More generally, though, Apple is probably mildly annoyed with people like me. I spent time getting good at using autorelease pools, my apps didn’t leak memory, and I didn’t see the point in learning the vagaries of the syntax required to make sure Automatic Reference Counting didn’t end up with circular references that couldn’t be reclaimed. I wasn’t a huge fan of the dot notation for accessing properties, so I only used it when it couldn’t be avoided. In short, I was a dinosaur in waiting.

People like me are why the runtime and compiler teams can’t have nice things. If everybody’s using the same features, it’s easier to get rid of legacy support and optimize the hell out of everything that’s left. A smaller memory footprint and better performance mean lower component costs and better battery life, which are very good things for the company.

Apple promised better performance with Swift, and you can see some places where it might extract a bit. Constants are a big part of Swift, which makes sense. If you make a stock-tracking app, the price may change every second, but the stock’s name and symbol change so rarely that it’s just as easy to make a whole new object when this happens. Declare the name and symbol constants, and you can skip all the code required to change them in a thread-safe manner. Presumably, the compiler can manage some optimizations around the use of constants as well.

Unlike the dinosaurs, we can see Chicxulub coming. Two or three years from now, when Apple announces that the future is Swift and it’s ready to drop Objective-C, we won’t be at all surprised. And I won’t be at all upset, because I’ll have spent the intervening few years making sure I know how to use the new language.

Recursion – The basics

Recursion – The basics

 

COMPUT: a programming technique where a routine performs its task by delegating part of it to another instance of itself.

Introduction
For new computer science students, the concept of recursive programming is often difficult. Recursive thinking is difficult because it almost seems like circular reasoning. It’s also not an intuitive process; when we give instructions to other people, we rarely direct them recursively.

For those of you who are new to computer programming, here’s a simple definition of recursion: Recursion occurs when a function calls itself directly or indirectly.

A classic example of recursion
The classic example of recursive programming involves computing factorials. In mathematics, the factorial of a nonnegative integer, n (denoted n!) is the product of all positive integers less than or equal to n. For example, 5! is the same as 5*4*3*2*1, and 3! is 3*2*1.

An interesting property of a factorial is that the factorial of a number is equal to the starting number multiplied by the factorial of the number immediately below it. For example, 5! is the same as 5 * 4! You could almost write the factorial function as:

int factorial(int n)
{
   return n * factorial(n - 1);
}

Listing 1. First cut factorial function

However, there is a small problem with this; it will run forever because there is no place where it stops calling itself. It therefore needs a condition to tell it to stop. Since a factorial is for positive numbers only it makes sense to stop the recursion when the input is 1 and return 1 as the result. The modified code will look like this:

int factorial(int n)
{
   if(n == 1)
   {
      return 1;
   }
   else
   {
      return n * factorial(n - 1);
   }
}

Listing 2. better factorial function

As you can see, as long as the initial value is above zero, this function will terminate. Note that more work will need to be done to guard again invalid initial values.

The point at with the recursion is stopped is called the base case. A base case is the bottom point of a recursive program where the operation is so trivial as to be able to return an answer directly. In the case of a factorial 1! = 1. All recursive programs must have at least one base case and must guarantee that they will hit one eventually; otherwise the program would run forever or until the program ran out of memory or stack space.

recursion

Basic steps of recursive programs
All recursive programs follows the same basic sequence of steps:
1: Initialize the algorithm. Recursive programs often need a seed value to start with.
2: Check to see whether the current value(s) being processed match the base case. If so, process and return the value.
3: Redefine the answer in terms of a smaller or simpler sub-problem or sub-problems.
4: Run the algorithm on the sub-problem.
5: Combine the results in the formulation of the answer.
6: Return the results.

 

Advantages and drawbacks of recursion

Main advantage of recursion is programming simplicity. When using recursion, programmer can forget for a while of the whole problem and concentrate on the solution of a current case. Then, returning back to the whole problem, base cases (it’s possible to have more than one base case) and entry point for recursion are developed.

On the other hand, recursion has a serious disadvantage of using large amount of memory. Moreover, for most programming languages, recursion use stack to store states of all currently active recursive calls. The size of a stack may be quite large, but limited. Therefore too deep recursion can result in Stack Overflow. To resolve this problem recursion can be simulated, using loop and stack data structure.