Some basic questions to help understand Objective C better:
- Explain method swizzling. When you would use it? — Method swizzling is the process of changing the implementation of an existing selector. It’s a technique made possible by the fact that method invocations in Objective-C can be changed at runtime, by changing how selectors are mapped to underlying functions in a class’s dispatch table. (Method swizzling)
- Take three objects: a grandparent, parent and child. The grandparent retains the parent, the parent retains the child and the child retains the parent. The grandparent releases the parent. Explain what happens. — Here a retain cycle is established between parent and child. After releasing the Grandparent both the parent and child become orphaned but the retain count of parent will not be zero as it is being retained by the child and hence causes a memory management issue.Retain Cycle is the condition When 2 objects keep a reference to each other and are retained, it creates a retain cycle since both objects try to retain each other, making it impossible to release. (A child should never retain a parent. If anything, use a weak reference in the child to maintain a reference to the parent.) Retain Cycle
- What happens when you invoke a method on a nil pointer? —There are several patterns in Cocoa that take advantage of this fact. The value returned from a message to nil may also be valid: (Send message to nil)
- If the method returns an object, any pointer type, any integer scalar of size less than or equal to sizeof(void*), a float, a double, a long double, or a long long, then a message sent to nil returns 0.
- If the method returns a struct, as defined by the Mac OS X ABI Function Call Guide to be returned in registers, then a message sent to nil returns 0.0 for every field in the data structure. Other struct data types will not be filled with zeros.
- If the method returns anything other than the aforementioned value types the return value of a message sent to nil is undefined.
- Give two separate and independent reasons why
retainCountshould never be used in shipping code. — You should never use
-retainCount, because it never tells you anything useful. The implementation of the Foundation and AppKit/UIKit frameworks is opaque; you don’t know what’s being retained, why it’s being retained, who’s retaining it, when it was retained, and so on. (When to use -retainCount)For example:
[NSNumber numberWithInt:1]now has a
retainCountof 9223372036854775807. If your code was expecting it to be 2, your code has now broken.
- You’d think that
@"Foo"would have a
retainCountof 1. It doesn’t. It’s 1152921504606846975.
- You’d think that
[NSString stringWithString:@"Foo"]would have a
retainCountof 1. It doesn’t. Again, it’s 1152921504606846975.
Basically, since anything can retain an object (and therefore alter its
retainCount), and since you don’t have the source to most of the code that runs an application, an object’s
If you’re trying to track down why an object isn’t getting deallocated, use the Leaks tool in Instruments. If you’re trying to track down why an object was deallocated too soon, use the Zombies tool in Instruments.
But don’t use
-retainCount. It’s a truly worthless method.
- Explain your process for tracing and fixing a memory leak. — Use instrument, Allocation and Leak, to find the part use overwhelm memory and fix it. (i.e. use appropriate size image to fit UICollectionViewCell imageView)
- Explain how an autorelease pool works at the runtime level. — Autorelease pool blocks provide a mechanism whereby you can relinquish ownership of an object, but avoid the possibility of it being deallocated immediately (such as when you return an object from a method). Typically, you don’t need to create your own autorelease pool blocks, but there are some situations in which either you must or it is beneficial to do so. There are, however, three occasions when you might use your own autorelease pool blocks:1)If you are writing a program that is not based on a UI framework, such as a command-line tool. 2)If you write a loop that creates many temporary objects. You may use an autorelease pool block inside the loop to dispose of those objects before the next iteration. Using an autorelease pool block in the loop helps to reduce the maximum memory footprint of the application. 3)If you spawn a secondary thread. You must create your own autorelease pool block as soon as the thread begins executing; otherwise, your application will leak objects. (See Autorelease Pool Blocks and Threads for details.) Using Autorelease Pool Blocks (Objective C Memory Management)
- In C, how would you reverse a string as quickly as possible? — Switch characters with beginning and end pointers and macro until the middle. (Reverse a string in C)
- Which is faster: to iterate through an
NSSet? — Faster to iterate through an NSArray (ordered) than NSSet (unordered, unique elements). Faster to iterate through NSArray than NSSet
- Explain how code signing works. — Code signing is a security technique that can be used to ensure code integrity, to determine who developed a piece of code, and to determine the purposes for which a developer intended a piece of code to be used. Although the code signing system performs policy checks based on a code signature, it is up to the caller to make policy decisions based on the results of those checks. When it is the operating system that makes the policy checks, whether your code will be allowed to run in a given situation depends on whether you signed the code and on the requirements you included in the signature. (public and private keys) Code Sign: ref1 ref2 ref3 ref4
- What is posing in Objective-C? — Posing was declared deprecated in Mac OS X 10.5 and it’s not available for use thereafter. Objective-C permits a class to wholly replace another class within a program. The replacing class is said to “pose as” the target class. For the versions that supported posing, all messages sent to the target class are instead received by the posing class.NSObject contains the poseAsClass: method that enables us to replace the existing class as said above. (Objective C Posing)
- List six instruments that are part of the standard. — Time Profiler, Allocations, Leaks, Activity Monitor, Network, Core Animation, Core Data, GPU Driver, Counters, Energy Diagnostics, File Activity, Metal System Trace, OpenGL ES Analysis, System Trace, System Usage, Zombies, Automation, Cocoa layout. (Instruments)
- What are the differences between
retain? — Memory questions reveal a lot about a developer’s knowledge, especially since many people are leaning on ARC these days. (copy vs retain: ref1 ref2)
- What is the difference between frames and bounds? — The bounds of an UIView is the rectangle, expressed as a location (x,y) and size (width,height) relative to its own coordinate system (0,0). The frame of an UIView is the rectangle, expressed as a location (x,y) and size (width,height) relative to the superview it is contained within. (frames vs bounds)
- What happens when the following code executes?
Ball *ball = [[[[Ball alloc] init] autorelease] autorelease];— It will crash. (Why and when to crash while call autorelease twice)
[Ball alloc]: This creates a Ball object that we own (and thus need to release).
[[Ball alloc] init]: This initializes the Ball object we just created.
[[[Ball alloc] init] autorelease]: This adds the Ball to the current autorelease pool, so it will be released when that pool is drained. This is the right thing to do if, for example, we were going to return the Ball from a method.
[[[[Ball alloc] init] autorelease] autorelease]: This autoreleases the Ball object again. This is 100% wrong.
alloc is the only claim to ownership that we need to balance, so the Ball will now be released too many times. This could manifest in any number of ways, but it will probably just crash. (It’s undefined behavior. There are no guarantees. In general, it tends to get more likely to crash as more objects are allocated.)
- List the five iOS app states. — Not running, Inactive, Active, Background, Suspended. (iOS app states)