Today I'm happy to reveal the first details of M Cubed's next application, and our first iOS app: Storyboards. As you can probably guess, this is an app for storyboarding ideas. You will be able to draw boards, add information such as dialogue or a description and then play back sequences to get a feel for how they flow.

I'll be giving more details over the coming weeks building up to the release, but until then visit the new Storyboards page to watch the teaser video and sign up for updates

Comments (0)

---

Code Collector Pro 1.4.4 is now out and features a few improvements and bug fixes. The big public improvements are that you can now drag files to groups to create a snippet in that group and drag a snippet to the finder to create a file on disk.

The biggest improvement though isn't yet turned on by default. Ever since CCP 1.0, the syntax highlighting has been something I've been disappointed with. It was slow, it was buggy and it was inaccurate. It has also been the number one source of complaints about CCP. So obviously it needed to be re-written, which is what I've been working on recently.

The plan was to get improved syntax highlighting into CCP 1.5, and the plan still is for it to be public and turned on by default in 1.5. However, it could benefit people now, even in its relatively early state.

Turning On The New Engine

The new syntax highlighting engine is off by default, as at the moment it is classed as a beta feature (meaning it could be buggy and could crash the app). It also only works if you are running on Mac OS X 10.6, so if you enable it on 10.5 you will see no difference as it will still use the old engine. To turn it on you need to drop down to terminal and enter the following:

defaults write com.mcubedsw.codecollectorpro M3EnableNewSyntaxHighlighting -bool YES

If you then restart Code Collector Pro it should start using the new engine to colour some of your snippets.

Why only some though? Well the reason is performance. While the new engine is far more accurate and less buggy, it has not had one bit of performance optimisation done on it. As such is is limited in two ways. The first is that it doesn't render anything that contains a line longer than 500 characters. The main cause of this is condensed jQuery. This will be fixed before 1.5 but for now it just falls back to the old engine.

The second is that it doesn't render anything that is longer than 120 lines. This is just an arbitrary number I've picked based on some timing tests. The good news is though that you can customise this number. While the line length issue can cause CCP's memory usage to balloon rapidly and possibly crash, the number of lines issue is simply one that may cause the app to hang for several seconds while it processes. If you don't mind this and want to try it on bigger snippets then you can modify it from terminal like so (this example sets the limit to 200 lines:

defaults write com.mcubedsw.codecollectorpro M3NewSyntaxHighlightingLineCountLimit 
-int 200

Extra Colours

Along with the new engine there are some extra options for colouring. These don't do anything in the old engine, but they allow you to set colours for pre-processor macros, variables and attributes in your code.

Examples

Below are before and after shots of some snippets in Ruby, Actionscript, HTML and Objective-C to show you the sorts of improvements in the new engine.

Ruby

As you can see, Ruby code is massively improved, with all the strings and keywords being correctly found and comments being coloured in.

Objective-C

The Objective-C snippet gets the comment properly coloured, the correct keywords highlighted, variables and classes highlighted and the preprocessors highlighted

HTML

Tags are properly highlighted now, and attribute names and values can also be coloured

ActionScript

ActionScript has variables and symbols correctly coloured in and fewer incorrect highlights (see the resizeHandler argument)

Feedback

As this is still a feature under development, I'm eager to hear any feedback and any bugs you find. It isn't yet perfect so if you find a snippet that it doesn't colour properly then send an email to support@mcubedsw.com and include the snippet, so I can try and fix it

Comments (0)

---

I'm happy to announce that the increased educational discount of up to 50% off our apps that has been running over the past few weeks will continue until the end of September. If you're a student or employee at an educational institution then visit our education store to get a large discount on all of our apps.

Comments (0)

---

Prior to Apple acquiring NeXT, Objective-C had had relatively little added to it since it became a fully fledge language rather than simply a C preprocessor back in the 80s. About the only thing added for many years after Apple acquired NeXT was the @try…@catch…@finally exception syntax.

Then in 2007 Apple released Leopard and with it Objective-C 2.0 and the modern runtime. This added features such as properties, fast enumeration, class extensions and garbage collection and improved areas such as protocols, while making the runtime far more flexible and less fragile to change. Last year with Snow Leopard, Apple added blocks and associative storage to the language in what can sort of be thought of as Objective-C 2.1.

At WWDC Apple announced a few more features, which I personally think of as Objective-C 2.2. These are "@synthesize by default" and "declare ivars in class extensions". These are features that I have wanted for quite a while and I am sure a lot of other Objective-C developers have wanted. So what are they and how do you get them?

Getting the Features

To get them there are two requirements:

• Your app must use the modern runtime (so no 32 bit Mac apps)
• You have to use LLVM 1.5 or higher as your compiler

If you fulfil those requirements then you're almost able to use them. All that is left to do is add these two flags to your "Other C Flags" build setting:

• -Xclang
• -fobjc-nonfragile-abi2

So now we're all set up, what the hell are these features?

@synthesize by Default

NB: This feature is no longer available and so should not be used. It may re-appear at some point but in the mean time we sadly have to write our @synthesize statements. I've left the section in for reference if/when it comes back

With the addition of properties, Apple was able to remove a lot of boilerplate code from our classes. If you are using the legacy runtime then you are able to write code like this:

==========MyClass.h==========

@interface MyClass {
    NSString *foo;
}

@property (copy) NSString *foo;

@end



==========MyClass.m==========

@implementation MyClass

@synthesize foo;

@end

It is a lot cleaner than what you had to write pre Obj-C 2.0, but it still has a lot of stuff to write. If you are using the modern runtime (ie are writing an iOS or 64 bit only Mac app) then you can get rid of the instance variable:

==========MyClass.h==========

@interface MyClass {}

@property (copy) NSString *foo;

@end



==========MyClass.m==========

@implementation MyClass

@synthesize foo;

@end

That's a bit cleaner, we're only having to sort out our property in two places rather than three, but it's still one too many. 95% of the time, you just want to synthesise the methods and instance variable and so the vast majority of property code in your implementation is the same. Well as you can probably guess, "@synthesize by default" means that this is done for you by the compiler by default. If you want to override it with an @dynamic statement or link it to a different instance variable you can, but for the rest of the time you can reduce your code to this:

==========MyClass.h==========

@interface MyClass {}

@property (copy) NSString *foo;

@end



==========MyClass.m==========

@implementation MyClass

@end

There is one slight gotcha with this. Due to what seems to be a compiler bug, you will get an error if you try to directly access the synthesised instance variable. Unfortunately the only ways to fix this are to either add @synthesize, add the instance variable or only access it via the property methods.

[Update] It seems that this isn't a bug but is instead expected behaviour. The @synthesize methods are generated at the end of the class if you don't specify them explicitly, as the compiler can't tell if the properties need to be default synthesised until it has got to the end of the implementation.

[Update 2] And now it seems the LLVM/Clang team are going to try and work around this and get it working as you would expect. Three cheers for the LLVM/Clang team!

Declare Instance Variables in Class Extensions & Implementations

So, we have got rid of the instance variables for our properties, but these are public anyway, it's not that big a deal if developers can see them in the header. However, what is left are the private instance variables, the ones only used internally in a class. We can hide methods we don't want as our public interface in our implementation file, but not our instance variables. Instead we end up with this:

==========MyClass.h==========

@interface MyClass {
    id internal1;
    id internal2;
}

@end



==========MyClass.m==========

@interface MyClass ()

- (void)internalMethod;

@end


@implementation MyClass

- (void)internalMethod {
    NSLog(@"%@ %@", internal1, internal2);
}

@end

Thanks to Objective-C 2.0 and class extensions we can put our internal method declaration into our .m file and also have the compiler check that it is implemented and warn us if it isn't (unlike if we added a simple category). What we haven't been able to do is do the same for our instance variables. Well we can now, so our code can now look like this:

==========MyClass.h==========

@interface MyClass
@end


==========MyClass.m==========

@interface MyClass () {
 id internal1;
 id internal2;
}

- (void)internalMethod;

@end


@implementation MyClass

- (void)internalMethod {
 NSLog(@"%@ %@", internal1, internal2);
}

@end

Our internal instance variables really are internal now, which makes the header effectively become purely our public interface. And if you are feeling really crazy, you can have multiple class extensions and maybe just put them in the @implementation:

==========MyClass.h==========

@interface MyClass
@end


==========MyClass.m==========

@interface MyClass () {
 id internal1;
}

- (void)internalMethod;

@end


@interface MyClass () {
 id internal2;
}
@end


@implementation MyClass {
    id internal3;
}

- (void)internalMethod {
 NSLog(@"%@ %@", internal1, internal2, internal3);
}

@end

These may only seem like small enhancements, but they help you reduce the code you need to write and make that which you do much neater. It is little enhancements like this that keep trickling out that makes the life of an Objective-C developer that much easier.

Comments (10)

---

Page 2 of 27 pages  <  1 2 3 4 >  Last »