You like that UIAlertView contentView property have been removed from iOS 7?
You will love this!
In iOS 7, tint color plays a major role in your app. With the abandon of button’s borders, tint color indicates strongly (if not exclusively) that a control is interactive.
From the iOS 7 UI Transition Guide:
When an alert or action sheet appears, iOS 7 automatically dims
the tint color of the views behind it. To respond to this color change,
a custom view subclass that uses tintColor in its rendering should override
tintColorDidChange to refresh the rendering when appropriate.
When an UIAlertView is shown, all controls under the UIAlertView are greyed to emphasise the alert and re-colored on the UIAlertView dismiss. I find this default behaviour kind of cool and like it.
A best practice very often advertised by Apple with UIAlertView is to dismiss an UIAlertView when your app goes into background. This is to insure not to present an UIALertView out-of-context the next time a user launch your app.
Doing this, from iOS 4 to iOS 6 has been really simple and straightforward. Given a view controller that has a IBAction showing an UIAlertView:
- (IBAction)tap:(id)sender
{
self.alertView = [[UIAlertView alloc] initWithTitle:@"Hello"
message:@"A standard UIAlertView"
delegate:nil
cancelButtonTitle:@"OK"
otherButtonTitles:nil];
[self.alertView show];
}
One has just register to UIApplicationDidEnterBackgroundNotification in viewDidLoad :
- (void)viewDidLoad
{
[super viewDidLoad];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(applicationDidEnterBackground:)
name:UIApplicationDidEnterBackgroundNotification
object:nil];
}
and dismiss the UIAlertView when handling UIApplicationDidEnterBackgroundNotification:
- (void)applicationDidEnterBackground:(NSNotification *)theNotification
{
NSInteger cancelButtonIndex = self.alertView.cancelButtonIndex;
[self.alertView dismissWithClickedButtonIndex:cancelButtonIndex
animated:NO];
}
On iOS 7, this code should have worked flawlessly. The alert view is dismissed when the app goes into background. But when the app is activated again into foreground, all controls that have been automatically dimmed by the system while the alert view was shown are still dimmed. Not only are they dimmed but they are also active and enable!
The code is so simple that I’m pretty sure this is a bug of iOS 7 (or at least 7.0 to 7.0.4). You can download the sample code for this bug here and I’ve filled a bug rdar://15582862 for it.
Let’s hope it will be fixed soon!
From jc.
In Automating Terminal Tasks on OSX, I was describing how I used a combination of iTerm 2, AppleScript and Automator to launch a batch of shell commands in iTerm 2 tabs.
This solution was useful but not very configurable: if I wanted another set of commands or another configuration, I had to duplicate my Automator application, modify the AppleScript, and save the application. Not a big deal, but quite tedious.
Introducing panes
So now, let me present you panes!
panes.py is a Python 2.7+ script to configure an iTerm 2 window.
panes.py reads a configuration file at ~/.panesrc and creates a new iTerm 2 window.
Based on the configuration file, panes.py creates additional horizontal or vertical split panes inside this window and can launch additional commands at the startup of the shell pane.
The configuration file uses Microsoft Windows INI files format. All configurations are described in one only file, ~/.panesrc, and each configuration is a section in this file.
For instance, the default config file is:
[Default]
panes: [
{
"name": "Pane 1",
"split": "v",
"cmds": [
"echo pane 1",
"ls -ltr",
],
},
{
"name": "Pane 2",
"split": "h",
"cmds": [
"echo pane 2",
"ls -ltr",
],
},
{
"name": "Pane 3",
"split": "h",
"cmds": [
"echo pane 3",
"ls -ltr",
],
},
]
To launch this config, simply type panes.py default or panes.py. This will create a new iTerm 2 window with three panes labeled ’Pane 1’, ’Pane 2’ and ’Pane 3’. Each pane will launch an echo command followed by a ls -ltr command. For instance, you can use it to ssh to your server and output some logs in a pane.
You can add another configuration by adding a section to ~/.panesrc:
[default]
…
[prod]
panes: [
{
"name": "Pane 1",
"split": "v",
"cmds": [
"ssh prod.example.com",
"tail -f /var/log/example.log",
],
}
]
[preprod]
…
And launch your prod environment like this: panes.py prod.
I now use panes to setup my various Django projects, or connect to a server and watch some logs. If at any point I need to reboot my Mac, or if one of my shell session is broken-pipe, I just have to relaunch my panes session.
It’s a kind of very very simple tmux or Screen, but it is completely sufficient for my needs. And it can be perfectly integrated with Alfred for instance…
How does it work?
panes.py works by creating a temporary AppleScript script to pilot iTerm 2. This script is totally based on Luis Martin Gil iTerm 2 scripts that you can have at https://github.com/luismartingil/per.scripts/blob/master/iterm_launcher02.applescript. Kudos to Luis for mastering AppleScript which I have not the courage to do! Without Luis’ work, I wouldn’t be able to do what I wanted.
The Python script does the following:
- reads the configuration file in
~/.panesrc,
- constructs a temporary AppleScript script for piloting iTerm 2,
- executes this AppleScript with the OSX built-in command
osascript.
I’ve chosen to do this because I wanted to have my configuration described in a simple text file and I didn’t want to spend time doing this in AppleScript. Moreover, I find it rather cool to script an OSX app in Python. Seriously, who likes AppleScript? Imagine you could script all your OSX apps in a decent language, like Python, Ruby or Javascript… Wouldn’t it be super cool?
panes is available on GitHub! If it can be useful to someone else, I would be happy. In the meantime, I’m ready for the pull requests!
Thanks _oho for the debugging 
!
From jc.
When I installed few days ago the iOS 7 revamp version of Apple podcast app, it made me remember how much I dislike the iOS 7 new design. From the first version of iPhone OS to iOS 6, I believe one of the key strength of the platform was achieving a consistency in the UI, while having some freedom with color, textures, animations etc… The transitions between views were strongly coherent from apps to apps, buttons were instantaneously recognisable as tappable element, interactions were or intuitive either easily learnable, always enjoyable. With every developer/designer gaining experience, apps become a field of UI innovation, while remaining coherent and consistent.
With iOS 7 new design principles, I feel this consistency has become too strong, and now we have uniformity.
Quoting Matt Gemmell’s iOS 7 first impressions
Breathable whitespace is everywhere, and is used to unify and homogenise
previously disparate interface styles
Here is a batch of (not randomly choosen) iOS 7 Apple and third parties apps screenshots. Yes the interface is homogeneous. In fact, everything is white! Everything is dull, identical, uniform.
In a word, boring.
New iOS 7 version of Podcast app
Mail and Calendar
Contacts
Music and Notes
Alarm and Maps
Phone and Game Center
This white plague has also spread through third parties apps:
Tweetbot and Nike
Kickstarter and Ted
Frankly, I miss the days were differences between apps were not limited to some tint color, or bold font.
Of course, we are just at the beginning of a new area, designers and developers need to learn the new UI paradigms and invent new designs. But, I’m already fed-up with this white, flat minimalism: if you’re updating your app for iOS 7, at least don’t go with the stock white appearance like a tons of others apps.
Frankly, do you think Apple is going to wait this time 6 years before introducing a new radical change?
From jc.
If you’re developing on your shiny new iPhone 5s or iPad Air with Xcode 5.0.1, you may have encounter strange "screens of death" on your device.
These issues have been reported multiple times on Apple Developer forum [1][2] and there is a solution: Xcode 5.0.2 GM.
From the release notes:
Issues Resolved in Xcode 5.0.2 GM seed
Launching a 64-bit application on a device from Xcode multiple times causes
the device to stop responding (and require a soft-reset). This has been
resolved. (15338361)
If you’re developing with Xcode 5.0.1, trash it and go download Xcode 5.0.2 GM right now!
From jc.
Whouah! A bargain at $9.99 (or 7€59) (via Michael Tsai) !
Exedore is very fast to launch, totally native and has the same look as Xcode 4.x. This is a pretty strong 0.1.1 version which includes:
- A full-featured Python text editor with syntax highlighting, code auto-completion,
- An integrated Python debugger with graphical breakpoints and a console for stepping through and debugging scripts,
- Python documentation integrated
I’ve tested some of my Python scripts and I’m impressed by this editor/debugger. This is going to be my go-to IDE for Python scripting. I’m currently using PyCharm which is a rock solid Python IDE, with lot of features (like PEP 8 live validation, support for virtualenv, etc..). But for little projects, PyCharm seems a bit overkill (and also have a small smell of Java apps…).
Exedore is in its enfancy, but it shows a lot of promises. I really hope Todd Ditchendorf will keep improving it and add features while keeping it simple and fast.
Exedore single window
Fast Python documentation access
What I would like to have for the next versions:
- possibility to set a page column guide,
- virtualenv support (I’ve tried to set a different
python executable in the project settings but I have the impression that it is not working),
- the same key bindings for step-in, step-out and continue as Xcode,
- a Xcode 5 look-and-feel (currently, it’s more a 4.x look-and-feel),
- a side window for the doc.
Overall, I strongly recommend you to try Exedore, if you’re in the Python Way of Life.
From jc.
My local Django setup
Part of my setup to work locally on my Mac with Django includes always the same tasks:
- task 1: Activate the virtualenv of the project on which I’m working,
- task 2: Start the Django development server locally,
- task 3: Start Redis, as a broker for my Celery asynchronous tasks,
- task 4: Start the Celery worker server
I usually have an open Terminal window dedicated to one Django project, and each task has its own tab.
Each task is launched with one or two command lines, very simple but tedious to remember. This way, I’ve output of Redis, Celery, and Django HTTP server in each tab and I can see live if something is not working.
On the first tab, task 1 commands are:
# Activate the virtual env for this project
source ~/Documents/Dev/VirtualEnv/venv-python-2.7-example/bin/activate
# Go in the Django project directory to commit/push/run manage.py etc…
cd ~/Documents/Dev/example_project/example
On the second tab, task 2 commands are:
# Activate the virtual env for this project, cd in the Django project directory
source ~/Documents/Dev/VirtualEnv/venv-python-2.7-example/bin/activate
cd ~/Documents/Dev/example_project/example
# Launch the Django developement server
./manage.py runserver --insecure
On the third tab, task 3 commands are:
# Start Redis, and wait for task
redis-server /usr/local/etc/redis.conf
On the fourth tab, task 4 commands are:
# Activate the virtual env for this project, cd in the Django project directory
source ~/Documents/Dev/VirtualEnv/venv-python-2.7-example/bin/activate
cd ~/Documents/Dev/example_project/example
# Start the Celery worker.
./manage.py celery worker --loglevel=info
It’s not so complicated, not too long, but each time I’ve to restart my Mac or when I accidentally kill my terminal window, I’ve to relaunch each task. It’s sufficiently boring that I’ve wanted to automated all this.
Automator and Terminal.app
All this sounds a perfect Automator use’s case. Automator allows you to create workflows for automating repetitive tasks, using a wide variety of programs like Finder, Safari and … Terminal! Basically, you can drag and drop predefined application actions and/or use Applescript for more complex tasks.
If you launch Automator, and look at the Library (View > Show Library), you can have the list of drag & drop commands exposed by applications. If you look for the commands with the Terminal.app icon, you will see the followings available commands:
- Apple Versioning Tool
- CVS Add
- CVS Checkout
- CVS Commit
- CVS Update
- Run Shell Script
The later command ’Run Shell Script’ seems interesting but unfortunately there is no ’Open a new tab’ command. To confirm this, we are going to check the Terminal AppleScript scripting interface. This interface exposes how we can interact with an application using AppleScript (and by extension how we can interact with an application using Automator since we can include any AppleScript script in Automator).
Launch AppleScript Editor, go to ’File > Open Dictionary…’. You can select any application to open its dictionary interface. This dictionary lists all the objects and commands your application understands. For instance, we can browse to Terminal.app:
And open it’s ’scripting definition’:
In the dictionary viewer, you can view these elements:
represent a suite, ie a container for objects, commands and events;
represent a class, ie an object that can be used in an AppleScript script;
is a property of the object;
is an element contains by a class.
So we can see that there is only one command specific to Terminal, that is do scrip. That can be useful, but it will be difficult to do what we want to do: open tabs programatically in a Terminal window.
A quick search on the web shows thats, to open new tabs in AppleScript, people are either sending keystroke to the Terminal:
-- Open a new tab.
tell application "System Events" to tell process "Terminal" to keystroke "t" using command down
if (the (count of the window) = 0) or (the busy of window 1 = true) then
tell application "System Events" keystroke "n" using command down
end tell
Or are trying to play with Terminal user saved settings. The best answer is this StackOverflow answer, that presents three different ways of opening terminal tabs.
iTerm2 to the rescue
In all these solutions, I find the AppleScript scripts either fragile or too complicated. Fortunately there is a great and free alternative to the stock Terminal app on OSX: iTerm2.
iTerm2 is a replacement for Terminal and the successor to iTerm. It works on Macs with OS 10.5 (Leopard) or newer. Its focus is on performance, internationalisation, and supporting innovative features.
The best part is that iTerm2 has a first-class AppleScript support.
Once you have downloaded iTerm2, take a look at the iTerm2 AppleScript dictionary:
iTerm2 has much more commands and classes than Terminal. In particular, it has a launch command that can launch a new session i.e a new tab! With this command, we can now write an AppleScript script that opens 4 tabs, each tab launching a task of the Django setup.
tell application "iTerm 2"
make new terminal
tell the current terminal
activate current session
-- Go to my Django project
launch session "Default Session"
tell the last session
write text "source ~/Documents/Dev/VirtualEnv/venv-python-2.7-example/bin/activate"
write text "cd ~/Documents/Dev/example_project/example"
end tell
-- Launch Django server
launch session "Default Session"
tell the last session
write text "source ~/Documents/Dev/VirtualEnv/venv-python-2.7-example/bin/activate"
write text "cd ~/Documents/Dev/example_project/example"
write text "./manage.py runserver --insecure"
end tell
-- Launch Redis
launch session "Default Session"
tell the last session
write text "redis-server /usr/local/etc/redis.conf"
end tell
-- Launch Celery
launch session "Default Session"
tell the last session
write text "source ~/Documents/Dev/VirtualEnv/venv-python-2.7-example/bin/activate"
write text "cd ~/Documents/Devexample_project/example"
write text "./manage.py celery worker --loglevel=info"
end tell
end tell
end tell
Now that we have our AppleScript that automates the Django setup, we can use Automator to create an application that runs this script. To setup Django, all I will have to do is launching this app!
- Launch Automator
- ’File’ > ’New’
- Choose Application
- From the library, search for ’Run AppleScript’
- Drag and drop ’Run appleScript’ to the main windows,
- Under the ’Options’ segmented control, select ’Ignore this action’s input’
- In the script, replace
(* Your script goes here *) with our AppleScript script
- Click
Save to create your application and that’s done.
Conclusion
iTerm2 is really a perfect replacement for Terminal and I use it now exclusively. It has really improved my productivity, and I’m sure you can reuse this example with a Rail setup for instance.
iTerm2 is free so please consider donating to support this great product!
From jc.
If you like iOS 7 and find that the new UI has gained in legibility you should read Cpt. Obvious compares the iOS7 and iOS6 weather app by Nat!:
That this is the prominent example of the "iOS Human Interface Guidelines" for
iOS6 to iOS7 conversion, leaves me wondering…
If you prefer the iOS 7 version, I don’t know what to say to you (by way of Michael Tsai, great links provider).
From jc.
If you want to send or receive dates and times in your iOS app, you will need to insure that you’re parsing or creating the right format string. Let’s take an example: assume we’re creating some NSDate object and we need to send a JSON representation of this NSDate to some web service. In this example, we want to format the date with the RFC 3339-style, a common format used by many Internet protocol.
A first naive approach looks like:
- (NSString *)dateString
{
// Create our date formatter.
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateFormat:@"yyyy’-’MM’-’dd’T’HH’:’mm’:’ssZ"];
// We will upload the date at UTC 0.
dateFormatter.timeZone = [NSTimeZone timeZoneForSecondsFromGMT:0];
// Format our date object to a suitable string.
NSDate *date = [[NSDate alloc] init];
NSString *dateString = [dateFormatter stringFromDate:now];
return dateString;
}
For instance, if we call this method in France (GMT+2), at 2:02 PM the 3 October 2013, dateString will be 2013-10-03T12:01:07+0000. As you can see, one central class in Cocoa for dates and times handling is NSDateFormatter. NSDateFormater will be your companion when going to/from NSDate and NSString; given NSDateFormater the right format string (in case of RFC 3339-style, you can use @"yyyy’-’MM’-’dd’T’HH’:’mm’:’ssZ"), and you’re good.
Or not… In fact, this innocuous sample code has some issues.
First of all, there may be a performance problem. NSDateFormater can be expensive to create each time you need to format a string. A better approach would be to create an ivar and cache it in order to reuse it each time we need it.
- (NSDateFormatter *)dateFormatter
{
if (_dateFormatter){
return _dateFormatter;
}
_dateFormatter = [[NSDateFormatter alloc] init];
[_dateFormatter setDateFormat:@"yyyy’-’MM’-’dd’T’HH’:’mm’:’ssZ"];
[_dateFormatter setTimeZone:[NSTimeZone timeZoneForSecondsFromGMT:0]];
return _dateFormatter;
}
- (NSString *)dateString
{
NSDateFormater *dateFormatter = [self dateFormatter];
NSDate *date = [[NSDate alloc] init];
NSString *dateString = [dateFormatter stringFromDate:date];
return dateString;
}
But there are still some issues. On his iPhone, the user can have chosen a different calendar (Settings > General > International > Calendar), for instance the Buddhist one. Running the example, dateString will return 2556-10-03T12:20:20+0000 simply because in the Buddhist calendar we are in 2556!
You can force your date formatter to use the Gregorian calendar simply by setting the calendar property like this:
_dateFormatter.calendar = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar];
And no matter what calendar the user has chosen, your NSDateFormatter will always return the Gregorian year.
But there is still an issue with this code! On iOS, the user can override the default AM/PM versus 24-hour time setting (via Settings > General > Date & Time > 24-Hour Time), and cause your formatting to failed. Arrgghhhh…
The real solution to this problem is addressed by Apple in the Technical Q&A QA1480 NSDateFormatter and Internet Dates. To format a date to a fixed format regardless of both user and system preferences, you should use an particular local en_US_POSIX that is designed to be independent and fixed between machine. Using en_US_POSIX, you even don’t need to specify to use the Gregorian calendar.
Now our fixed example is:
- (NSDateFormatter *)dateFormatter
{
if (_dateFormatter){
return _dateFormatter;
}
_dateFormatter = [[NSDateFormatter alloc] init];
NSLocale *enUSPOSIXLocale = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"];
[_dateFormatter setDateFormat:@"yyyy’-’MM’-’dd’T’HH’:’mm’:’ssZ"];
[_dateFormatter setTimeZone:[NSTimeZone timeZoneForSecondsFromGMT:0]];
[_dateFormatter setLocale:enUSPOSIXLocale];
return _dateFormatter;
}
- (NSString *)dateString
{
NSDateFormatter *dateFormatter = [self dateFormatter];
NSDate *date = [[NSDate alloc] init];
NSString *dateString = [dateFormatter stringFromDate:date];
return dateString;
}
Who said handling dates was easy?
If you need more information about how to deal with dates on Cocoa, be sure to read Ole Begemann’s epic serie on Working with Date and Time in Cocoa:
You can also check the Data Formatting Guide on Apple Developer Library to get some additional informations on formatting datas.
From jc.
If you need to develop with Xcode 4 alongside Xcode 5, here is a simple icon replacement for Xcode 5. I use it to discriminate my two Xcode on the sidebar or in the tab switcher.
Xcode.icns (modified)
Just copy the modified Xcode.icns file into /Applications/Xcode.app/Contents/Resources/ and go!
You will need, of course, to have your two versions of Xcode at different places, as I describe it in Xcode 4.5 and 4.4.1 Cohabitation. If you want to revert to the original Xcode icon, just use Xcode.icns (original).
And if you want to celebrate the new shiny iPhone 5c, here is some variations with the Xcode 5c icons:
Xcode.icns green
Xcode.icns blue
Xcode.icns yellow
Xcode.icns pink
Xcode.icns white
Xcode.icns black
Rename the icon file name to Xcode.icns and drop it in /Applications/Xcode.app/Contents/Resources/. Happy coding!
From jc.
So cool! See the rest of the story in Man’s First Try at Mario Paint Composition Results in Perfect Cover of ‘Get Lucky’
From jc.
Python developers have PEP 8 and Go devs have gofmt but iOS developers have no Apple official convention for style. There is the official Coding Guidelines for Cocoa, but it has not been updated very often, and do not cover indentation, use of objects literals etc… For a while, I was using Google Objective-C Style Guide, but recently I come over two others guidelines for Objective-C that I’ve begun to follow:
New York Times Objective-C Style Guide
You can get it here. I globally like this coding style, and it feels moderns. Here is some interesting extracts:
Use dot-notation syntax
Always used dot-notation for accessing and mutating properties.
Good:
view.backgroundColor = [UIColor orangeColor];
[UIApplication sharedApplication].delegate;
Bad:
[view setBackgroundColor:[UIColor orangeColor]];
UIApplication.sharedApplication.delegate
I always use dot syntax when possible (i.e when properties are declared and public), the code is much more elegant and simpler. In this example, sharedApplication is a class method and should not be used with dot notation (even if dot syntax is purely a convenient wrapper around accessor method calls). Still, I use sometimes dot syntax with some selectors that make sense for me like count on NSArray.
Spacing
Method braces and other braces (if/else/switch/while etc.) always open on the
same line as the statement but close on a new line.
Good:
if (user.isHappy) {
//Do something
}
else {
//Do something else
}
Methods
In method signatures, there should be a space after the scope (-/+ symbol).
There should be a space between the method segments.
Good:
- (void)setExampleText:(NSString *)text image:(UIImage *)image;
Variables
Asterisks indicating pointers belong with the variable
Good:
NSString *text;
Bad:
NSString* text;
Naming
Long, descriptive method and variable names are good.
Good:
UIButton *settingsButton;
Bad:
UIButton *setBut;
Properties should be camel-case with the leading word being lowercase.
If Xcode can automatically synthesize the variable, then let it.
If you used to write
Sprite.h:
@interface Sprite : NSObject
{
NSString *_imageName;
}
@property(nonatomic, copy) NSString *imageName;
@end
Sprite.m:
@implementation
@synthesize imageName = _imageName;
…
@end
You can write now
Sprite.h:
@interface Sprite : NSObject
@property(nonatomic, copy) NSString *imageName;
@end
Sprite.m:
@implementation
…
@end
And the _imageName ivar will be automatically create by Xcode. Huge win, you can find more information on automatic synthesis ivar here.
Underscores
When using properties, instance variables should always be accessed and
mutated using self.
I’m not really sure about this one. I follow the guideline to always access an ivar by a property when an allocation is involved, but I find the code less clear with this NYT rule.
This code:
self.sprite = [[Sprite alloc] init];
_sprite.x = 10.0;
_sprite.y = 10.0;
_sprite.frameCount = 30;
_sprite.imageName = @"Dragon.png"
Should be changed to:
self.sprite = [[Sprite alloc] init];
self.sprite.x = 10.0;
self.sprite.y = 10.0;
self.sprite.frameCount = 30;
self.sprite.imageName = @"Dragon.png"
I don’t like…
init and dealloc
dealloc methods should be placed at the top of the implementation, directly
after the @synthesize and @dynamic statements.
Mmm… I see the rational behind this, (minimal distance between your properties declared in your .h, your internal properties declared in your .m and your dealloc method), but I prefer to have the init and designated initializer at the beginning of the .m files.
Literals
NSString, NSDictionary, NSArray, and NSNumber literals should be
used whenever creating immutable instances of those objects.
Good:
NSArray *names = @[@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul"];
NSDictionary *productManagers = @{@"iPhone" : @"Kate", @"iPad" : @"Kamal", @"Mobile Web" : @"Bill"};
NSNumber *shouldUseLiterals = @YES;
NSNumber *buildingZIPCode = @10018;
Bad:
NSArray *names = [NSArray arrayWithObjects:@"Brian", @"Matt", @"Chris", @"Alex", @"Steve", @"Paul", nil];
NSDictionary *productManagers = [NSDictionary dictionaryWithObjectsAndKeys: @"Kate", @"iPhone", @"Kamal", @"iPad", @"Bill", @"Mobile Web", nil];
NSNumber *shouldUseLiterals = [NSNumber numberWithBool:YES];
NSNumber *buildingZIPCode = [NSNumber numberWithInteger:10018];
Clearly, my favorite feature of modern Objective-C. A huge win in clarity.
Enums
When using enums, it is recommended to use the new fixed underlying type
specification […]
Good:
typedef NS_ENUM(NSInteger, NYTAdRequestState) {
NYTAdRequestStateInactive,
NYTAdRequestStateLoading
};
Bad:
typedef enum {
NYTAdRequestStateInactive,
NYTAdRequestStateLoading
} NYTAdRequestState;
If you use this new macro, Xcode will have better autocompletion. You can use also a new macro, NS_OPTIONS, for bitmask. For instance in iOS 7, UIViewAutoresizing is declared as:
typedef NS_OPTIONS(NSUInteger, UIViewAutoresizing) {
UIViewAutoresizingNone = 0,
UIViewAutoresizingFlexibleLeftMargin = 1 << 0,
UIViewAutoresizingFlexibleWidth = 1 << 1,
UIViewAutoresizingFlexibleRightMargin = 1 << 2,
UIViewAutoresizingFlexibleTopMargin = 1 << 3,
UIViewAutoresizingFlexibleHeight = 1 << 4,
UIViewAutoresizingFlexibleBottomMargin = 1 << 5
};
Mattt Thompson has more information on NS_ENUM and NS_OPTIONS.
Singletons
Singleton objects should use a thread-safe pattern for creating their shared
instance.
Here is the official snippet for singleton:
+ (instancetype)sharedInstance {
static id sharedInstance = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
sharedInstance = [[self alloc] init];
});
return sharedInstance;
}
GitHub Objective-C style guide.
You can get it at https://github.com/github/objective-c-conventions. Some interesting points:
Documentation and organization
Comments should be hard-wrapped at 80 characters.
Comments should be Tomdoc-style.
Use #pragma marks to categorize methods into functional groupings […]
I love to hard-wrapped my code (hard-wrapping is also present in Google Objective-C Style Guide and PEP 8), I find my code more clear, more organized and easier to diff against another file. To organise my implementation files, I also use constantly #pragma mark Something or better #pragma mark - Something which insert a separator line like:
Declarations
Great presentation of instancetype by Mattt Thompson again…
- Always surround if bodies with curly braces if there is an else. Single-line
if bodies without an else should be on the same line as the if.
- All curly braces should begin on the same line as their associated
statement. They should end on a new line.
- Put a single space after keywords and before their parentheses.
- Return and break early.
- No spaces between parentheses and their contents.
Love return and break early, remind me of Zen of Python “Flat is better than nested.”
If you don’t have a style guide, go pick one, your code will magically become beautiful!
From jc.
All Posts
