Category: iphone

References

• Complex list of what’s required vs. optional vs. platform – http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/mobilehig/IconsImages/IconsImages.html

Building an app, the basics

iPhone launchimage/splash

Default.png		Default-568@2x.png
Model	Size	Model	Size
3 + 3GS	320×480
4 + 4S	640×960
		5	640×1136

iPad launchimage/splash

Default.png		Default@2x.png
Model	Size	Model	Size
1 + 2	768×1004 or 1024×748
		3 + 4	1536×2008 or 2048×1496

iPhone fullscreen

No status bar		with status bar		with status bar + navbar
Model	Size	Model	Size	Model	Size
3 + 3GS	320×480	3 + 3GS	320×460 or 480×300	3 + 3GS	320×416 or 480×268
4 + 4S	640×960	4 + 4S	640×920 or 960×600	4S	640×832 or 960×536
5	640×1136	5	640×1096 or 1136×600	5	640×1008 or 1136×512

iPad fullscreen

No status bar		with status bar		with status bar + navbar
Model	Size	Model	Size	Model	Size
1 + 2	768×1024	1 + 2	768×1004 or 1024×748	1 + 2	768×960 or 1024×704
3 + 4	1536×2048	3 + 4	1536×2008 or 2048×1496	3 + 4	1536×1920 or 2048×1408

iPhone app icons

App		iTunes		Spotlight
Model	Size	Model	Size	Model	Size
3 + 3GS	57×57	3 + 3GS	512×512	3 + 3GS	29×29
4 + 4S + 5	114×114	4 + 4S + 5	1024×1024	4 + 4S + 5	58×58

iPad app icons

REQUIRED

App		iTunes		NewsStand (if Newsstand app)
Model	Size	Model	Size	Model	Size
1 + 2	72×72	1 + 2	512×512	1 + 2	>= 512
3 + 4	144×144	3 + 4	1024×1024	3 + 4	>= 1024

OPTIONAL

Spotlight		Settings
Model	Size	Model	Size
1 + 2	50×50	1 + 2	29×29
3 + 4	100×100	1 + 2	58×58

I’m writing an iPad game that’s designed to be self-evident and trivial to use.

Today, I made a re-usable “tell the user how many fingers to use” animation that would work well with any app. So, I decided to open-source it and stick it on github.

Screenshot from my current app (NB: you need to photo YOUR fingers – not mine! – if you want it to look like this)

Usage

Instructions are in the source code, but my intention is for this to be ULTRA SIMPLE for you to use, so here goes:

[code]

// Add this to the main UIViewController for your app – the one that displays
// when you’re ready for user interaction
-(void)viewDidAppear:(BOOL)animated
{
VFingersHelp* helpView = [[[VFingersHelp alloc] init] autorelease];
/** This will position the helpview in bottom-left corner. Bottom left/right corners are where
users prefer to "touch" (c.f. Disney’s style guide for toddlers).
While they’re watching the help, we don’t want them touching, so we deliberately place in bottom corner.
(feel free to move to top corner if you prefer).
NB: it’s easy to take a photo of your fingers and display at bottom of screen…
*/
helpView.autoresizingMask = UIViewAutoresizingFlexibleTopMargin | UIViewAutoresizingFlexibleRightMargin;
helpView.center = CGPointMake( 0 + helpView.bounds.size.width/2.0, 2.0 + self.view.bounds.size.height – helpView.bounds.size.height + helpView.bounds.size.height/2.0);
[self.view addSubview:helpView];
}
[/code]

I’ve just updated my script that adds a missing feature to Xcode – making your libraries automatically work on Simulator and on Devices, with no manual intervention:

http://stackoverflow.com/questions/3520977/build-fat-static-library-device-simulator-using-xcode-and-sdk-4

…and I’ve also put the script itself into GitHub as a gist you can easily copy/paste:

https://gist.github.com/3705459

For a couple of years now, Firefox has had a nifty feature where if it crashes – for ANY reason – the next time you run it, it gives you a “menu” of the windows you had open, and lets you selectively re-open them. As a bonus, this menu is just a plain window – you can ignore it (if you’re too busy right now), and open some other windows in parallel.

(even if it’s not Firefox that crashed – e.g. a laptop battery ran out, or someone tripped over your power cable – you still get this window. This is a huge help on OS X, which crashes quite a lot if you’re running Apple’s dev tools :))

I’d wondered a few times “what happens if it crashes again, before you’ve selected which things from that menu you want to re-open?”

I just found out the hard way: actually, it gives you a new menu, where one of the items is … the previous menu. It nests, all the way down (I had a crash-of-a-crash-of-a-crash – and I got everything back perfectly. Very useful, too – one of the deeply nested open windows was an important form I’d forgotten I’d not yet sent).

On the downside, if you close Firefox, and re-open it normally, the menu gets blown away – but that’s probably to do with the “five-years-and-counting still unfixed” bugs in Firefox where “remember open windows on startup” doesn’t work properly (there’s some epic threads in their bug tracker, many complaints, but no fix yet).

Still, for the most part, this is a very nice approach to application-crashing. One to remember when designing your own document-based applications…

Ever seen this hard to notice bug in an iPhone / Mac project? Caused by a flaw (bug?) in Apple’s own API:

NSDictionary * map;
…
NSObject * key;
NSObject * value;
…
// NB: next line will frequently crash at runtime
// …but even if doesn’t crash, it probably won’t do
// what you’d expect it to:
[map setObject:value forKey:key];

if( value != [map objectForKey:key] ) // HA!
{
NSAssert( 1 == 0, @”What the **** just happened??” );
}

NSDictionary is one of the nastier things I’ve seen in a programming language: in an Object-Oriented Language, it’s a class that refuses to take Objects as arguments, *but pretends to*. If you attempt it, it either crashes, or it invalidates your objects, breaking contracts all over the place.

ObjC’s bizarre design

In the days pre-OOP, a “dictionary” was something that mapped:

“a string”
to
“anything” (usually: basic datatypes – e.g. strings, integers, floats, etc).

In the days of OOP, the same thing is usually called a “map” (which is a better term) – although the terms are synonymous – and maps:

“an object”
to
“another object”

What did Apple/NextStep/Crazy-Guys-Behind ObjC do?

NSDictionary: maps:

“STRINGS ONLY” (no objects allowed!)
to
“OBJECTS ONLY” (no core datatypes allowed!)

But … I can use an NSObject as key?

Yep – but Apple’s internal implementation takes a *copy* of the object, and uses that as a key – rather than using the object that you gave it. This is a common problem in OOP languages and implementations of Map – e.g. Java does the same thing.

Unfortunately, this means that you can call “setObject:forKey:”, and then “objectForKey:” will return nil *for the same key*.

In Java and other OOP languages, you are required to implement a custom “isObjectEqualToObject” method. In ObjC too – except that that method is ILLEGAL if you’re using CoreData.

And ObjC will crash too, as a bonus

I’ve never seen this in other OOP languages, but in ObjC *additionally*: if you don’t manually add to the object you pass-in … it crashes at runtime. Yay!

How come? AFAICT, Apple’s header file is wrong:

– (void)setObject:(id)anObject forKey:(id)aKey // You lie!

it seems the implementation of that method is:

– (void)setObject:(id)anObject forKey:(id<NSCopying>)aKey; // the correct signature?

Net result? Code that happily compiles … will crash. ARGH!

Two reasons to beware…

…so what’s the other one?

Ah, just the one we see again and again on live projects, wasting hours and hours of time:

NSDictionary* dictionary = [NSDictionary dictionaryWithObjectsAndKeys:
object1, key1,
object2, key2,
nil];

NSLog( @”dictionary = %@”, dictionary ); // but it only has one key/value pair. ?!?!?

Ah, well … that nil … what happens when object2 is nil? Oh, damn.

What about if key2 is nil? Now we’re really nasty … we’ve given it “half” of key/value pair. Nice!