If you haven’t seen a need for a new The New iPad (a.k.a. iPad 3), maybe this will change your mind…

iPad as a Mac Retina Display – Matt Gemmell

With the recently-released new iPad (3rd generation) being equipped with a Retina Display, there’s now only one major category of Apple device without a very high resolution screen: the Mac. We’re sure to get a Retina Display Mac before too much longer, but you can actually preview how OS X may look on such a device right now.

I’ve used KIF in the past but this also looks interesting.

Calabash iOS
Calabsh iOS is a new open source project for functional testing of iPhone and iPad apps based on Cucumber.

Good Stackoverflow thread on dimensions for the new iPad retina display (among others). See the Answer, not the question.

iOS 5.1 with Xcode 4.2 and retina in iPad 3

Presumably because of the iPad’s retina display causing apps to double in size, Apple raised the limit on over-the-air downloaded apps.

Higher Limit for Over-the-Air Downloads
Great apps come in all sizes. If you happen to offer a larger app, we’ve made it even easier for App Store customers to get your app wherever they are. We’ve raised the Wi-Fi download requirement from 20 MB to 50 MB so customers can download apps up to 50 MB in size over their cellular data network.

This really came in handy recently, when I wanted to see a stack trace in the console, and not from the result of an exception! Thanks to this tip found at Bynomial Code, I was able to accomplish this amazingly easily.

As mentioned in the blog, it requires iOS 4.0+, which, from my perspective, is everyone.

Bynomial Code » Print a stack trace anytime

Print a stack trace anytime Here’s how to print a stack trace from code at any point in your app – no need to wait for a crash report! -

NSLog(@"%@", [NSThread callStackSymbols]);

An interesting thing happened while doing routine runs of Analyze in Xcode 4.2. I was able to track down and solve all of the memory issues that Analyze was reporting except for one, and for the life of my I couldn’t figure out what was wrong with this code:

        if (![self.newBlahBlahBlah isEqualToString:anotherString])
        {
            //...
        }

 

Then, i happened upon this thread on StackOverflow:

Objective-C – NSString copy property memory management – Stack Overflow

“Figured out what was wrong. I used the property name newFoo which made the compiler think I returned a new object. So note to self: understand cocoa naming conventions.”

…and then it clicked: the property “newBlahBlahBlah” was basically a violation of convention, and was tripping up Analyze, which assumed that the property returned an object with a +1 retain count. It didn’t, in reality.

So what was the solution?

Simply give the property a new name that doesn’t cause problems!

        if (![self.awesomeNewblahBlahBlah isEqualToString:anotherString])
        {
            //...
        }

Thankfully this issue, which had baffled me for weeks, was finally put to rest… and with a good lesson learned!

Every once in a while, there’s a feature in Objective-C that I really appreciate — the kind of method that makes you think, “Yes! Of course that should be in there!”, but yet at the same time it is surprising, because because in the past I would pretty much always have to roll my own algorithm for dealing with the particular problem.

The instance of this that I had in mind is with regard to the lastPathComponent method of NSString.

It is so convenient to be able to just get the name of a file from a path just by doing the following:

NSString* fileName = [myPath lastPathComponent];

In the past, on other platforms and languages, I typically had to write a routine that would loop through and find the last path delimiter and grab the final part of the string based on that location.

Now?

One method. Awesome.

Just started experimenting with KIF and found this article by Stuart Gleadow, which provides a rundown on UI automation testing tools for iOS:

Which Automated iOS Testing Tool To Use – Stewart Gleadow’s Blog

It seems obvious that Apple really needs to build a tool (something better than UI Automation) that is easy to create & manage tests, which can also be deployed and run in a Continuous Integration environment. In the meantime, KIF looks like an interesting alternative…

In a much needed area of training for Xcode/Mac/iOS developers, iDeveloperTV and Graham Lee have put together a modestly-priced course on Unit Testing and TDD.

Unit Testing with Xcode

In this course Scotty and Graham Lee help you to not only understand the mechanics of unit testing in Xcode but also show you how you might design your code to be more testable. By working through a number of examples you will initially learn how to set up unit tests within Xcode 4 and perform basic unit testing before moving on to discover how you can test parts of your code that you previously might have thought were not possible to unit test such as code that uses singletons, networks, tableviews, user defaults and even core data. All the code we look at during the course in included so you can follow along and make sure you fully grasp and understand each aspect of what is being taught. The course ends with a general discussion of unit testing principles and examines how adopting a test driven approach to your development could end up saving you time and help you to produce more robust applications The course is suitable for both OS X and iOS developers

I was looking for a very straightforward and concise definition of static variables and how they can be used in Objective-C, since I had already been using them, but only considering their usage in the context of how they are used in other languages (like C# and Java) without really thinking about their purpose and usage in Objective-C.

Thankfully, one needs only look as far as the Apple Developer Library and the official guide for the language (navigate to: Objects, Classes and Messaging > Classes > Class Objects):

The Objective-C Programming Language: Objects, Classes, and Messaging

Declaring a variable static limits its scope to just the class—and to just the part of the class that’s implemented in the file. (Thus unlike instance variables, static variables cannot be inherited by, or directly manipulated by, subclasses.) This pattern is commonly used to define shared instances of a class (such as singletons; see “Creating a Singleton Instance” in Cocoa Fundamentals Guide).

and then a little further down…

Static variables help give the class object more functionality than just that of a factory producing instances; it can approach being a complete and versatile object in its own right. A class object can be used to coordinate the instances it creates, dispense instances from lists of objects already created, or manage other processes essential to the application. In the case when you need only one object of a particular class, you can put all the object’s state into static variables and use only class methods. This saves the step of allocating and initializing an instance.

Sometimes we just do things based on “clipboard inheritance” from examples on Stackoverflow, etc., but once in a while it’s good to actually dive into the reasons why those examples are the way they are, or how they can be changed to suit a different purpose.