Rob Fahrni

Objective-C and C++

CodFusion [via James Robertson]: "Can Adobe just port what they have into Objective-C or use Carbon. Unfortunately no, the Flash Player is written in C++ and going from C++ to Objective-C is not very practical. Objective-C is just another superset of C. It simply adds some OOP logic and a messaging and some of the syntax is similar to Smalltalk. You can compile any C program into Objective-C but that's not currently possible to do with a C++ program." - Emphasis is mine. I can assure you, having done it myself, you can use your current C++ code from Objective-C. I took a collection of pure C++ classes, unmodified, and used them from an Object-C/Cocoa based application. That collection of classes did not have any OS specific code, which made my job easier.

That's not to say Adobe doesn't face a huge uphill climb, it really does, but it can be done. Replacing Carbon with Cocoa is going to be tough. Since they're a cross platform shop I would hope they have a nice set of frameworks that abstract most of the platform specifics from the developer, but that of course is difficult to do. The Photoshop team is in the middle of the Carbon to Cocoa battle.

Bottom line - you can use your C++ with your Objective-C code.

P.S. - I have become a huge fan of Objective-C and Cocoa, I'm just sayin'.

Labels: Adobe, Apple, C++, Cocoa, Objective-C

Posted by Rob at 8:26 AM | 0 comments |

Click here for a permalink to this entry.

Great iPhone SQLite tutorial

dBlog: "I see many people asking for SQLite tutorials around, and since I am using SQLite for the next part in the Advanced RSS Reader Tutorial, I thought I would write up a quick tutorial on using SQLite with the iPhone SDK." - Now, couple that tutorial with Gus Muller's FMDB and you're off and running.

Thanks guys!

And yes, I am aware of Core Data. I even have Marcus Zarra's Core Data book, just need time to dig into it. I'll definitely be using that down the road some time.

Yes, there's a Mac application in my future, I can smell it.

Labels: Apple, Cocoa, Development, iPhone, Objective-C, Open Source

Posted by Rob at 11:33 AM | 0 comments |

Using Shrty

This simple example assumes a few things.
1) _shrty is a member variable.
2) shrtySvcWithName - We're creating a service instance that doesn't require a name or password. (E.G. IsGd)
3) self implements the ShrtyDelegateProtocol protocol.

First things first.

#import "Shrty.h"

Shrty.h will include everything you need to use Shrty.

Next you'll need to create a ShrtySvc instance. The code below illustrates how you may choose to do that. In this case we're passing the service name, Is.Gd, into a helper method to create our instance. There are constants defined in ShrtySvcConst.h for all the services supported by Shrty.


// Go create an instance of the IsGd service.
[self _createShrtyInstanceFromServiceName:kShrtyIsGdSvcName];
if (nil != _shrty)
{
	NSString* urlToShorten = @"http://rob.crabapples.net/";
		
	// Shorten the URL.
	[_shrty shortenUrl:urlToShorten];
}

In the example above I've removed some code for brevity's sake. Another thing to note is use of the helper method _createShrtyInstanceFromServiceName, included below. This method is part of ShrtyAppController.m, you'll find it in the Shrty source, it's part of the test project.


- (void)_createShrtyInstanceFromServiceName:(NSString*)serviceName
{
	[_shrty release];
	
	_shrty = [ShrtySvc shrtySvcWithName:serviceName userName:nil userPassword:nil delegate:self];
}

If all goes as expected you should expect to receive a callback to your didReceiveShortenedURL method.


- (void) didReceiveShortenedURL:(NSString*)shortenedURL 
	resultCode:(NSString*)resultCode
{
	if (nil == shortenedURL)
	{
		NSLog(@"GOT A NIL RESULT, DOH!");
	}
	else
	{
		NSLog(shortenedURL);
	}
}

Then you can do with that URL what you please, post it to Twitter, or Facebook, or whatever.

Labels: Cocoa, Development, Objective-C, Open Source

Posted by Rob at 12:45 PM | 0 comments |

Free Objective-C/Cocoa Code

I've been tinkering with some code off and on for a while, and thought I'd finally share it with the Mac Developer Community in hopes of getting some feedback as well as some users.

The project is called Shrty, short for "Shorty", and you can use it to shorten URL's in your Mac Desktop or iPhone application. The code is a work in progress, but I'm hoping folks will find it useful.

Shrty shorten currently supports bit.ly, j.mp, tr.im, ping.fm, and YOURLS based URL Shorteners. I have support for su.pr coming, the parsing required a bit more work and it's not quite finished.

Expand is not quite ready. I need to work on the parsing code for all of services.

The project basically contains a sample application that exercises Shrty, and the Shrty Library Code. The test application is nothing fancy, and in fact is pretty darned ugly, but if you decide to make use of the code I'm sure you'll make a great UI for it.

If you have any feedback please drop me a line, rob.fahrni@gmail.com. In the meantime, Merry Christmas!

Christmas Present Icon by Icon Drawer, www.icondrawer.com

Labels: Cocoa, Development, Indie, Objective-C, Open Source

Posted by Rob at 12:53 PM | 0 comments |

What's challenging in Cocoa?

Theocacao: "I sent out a general request on Twitter, asking what specifically the biggest obstacle was when you first started learning Cocoa. Out of the roughly 118 responses I got back, no one topic completely dominated." - If I'd responded to this I'd have said...

#1 Interface Builder
#2 Cocoa is big

Interface Builder had been the biggest hurdle for me, and Cocoa, like most frameworks I've switched between, takes some time to figure out. I really like the feel of Objective, but it's a bit strange looking the first time you see it.

Labels: Cocoa, Development, Objective-C

Posted by Rob at 2:53 PM | 4 comments |

Finding and fixing iPhone/Mac memory leaks

Mobile Orchard: "Some memory leaks are easy to see by looking at your code. Some are much more difficult. This is where Instruments comes in. Instruments has a 'Leaks' tool that will tell you exactly where you're leaking memory so that you can get in there and fix it!" - These are the types of tools every developer should learn. Hard as we try to write clean code we will, on occasion, forget to release a reference to an object and you get the dreaded memory leak. I must admit the Cocoa reference counting mechanism is a bit odd to an "old-school" Windows/COM developer, but I've learned to deal with the oddness.

Oh, there is a great tutorial for Windows COM guys to explore if they're coming over to Objective-C/Cocoa to help with the ref counting mechanism.

Labels: Apple, Cocoa, Debugging, Development, iPhone, Mac, Objective-C, Tools, Tricks and Tips

Posted by Rob at 1:39 PM | 0 comments |

Gifts for the beginning Mac developer

The Unofficial Apple Weblog: "Whether you've just started writing your first lines of code or you've just moved over to the Mac/iPhone platform as a developer, this guide is sure to please." - Looks like a great list to me.

Labels: Apple, Cocoa, Development, iPhone, Mac, Objective-C

Posted by Rob at 4:00 PM | 0 comments |

Making room for the keyboard

Cocoa with Love: "The iPhone's onscreen keyboard occupies the bottom 216 pixels on screen (140 in landscape mode). That's around half the screen, so if you ever have a text field you want to edit in the bottom half of the screen, it needs to move or it will get covered." - Nice tip for any iPhone developer. There is also a nice example of this in Apple's UIShowcase sample application.

Labels: Apple, Cocoa, Development, iPhone, Objective-C, Tricks and Tips

Posted by Rob at 8:55 AM | 0 comments |

Cocoa on Windows?

The Unofficial Apple Weblog: "Cocotron is a potentially exciting open-source project that 'aims to implement a cross-platform Objective-C API similar to that described by Apple Inc.'s Cocoa documentation.' What this means is that, in principle, Cocotron would allow an OS X Cocoa app written in Xcode to be easily cross-compiled for other OSes, particularly Windows." - This is pretty interesting. The question is, will Mac developers feel the need to go to Windows? There are a lot of Grandaddy applications on the Mac that are written in C/C++ because they run on multiple platforms, like Photoshop and even Apple's very own iTunes. Those applications use Carbon and Carbon isn't moving into 64-bit land, which is causing grief for folks like Adobe with gigantor codebases written against it. Would it be in Apple's best interest to contribute to Cocotron so they have a viable framework to get their own applications like iTunes fully Cocoa?

Labels: Apple, Cocoa, Windows

Posted by Rob at 9:23 AM | 0 comments |

Question for Mac developers

So, is there any way to make XCode not default to K&R style bracing. It's just plain ugly, and quite honestly, I can't believe people still use it. When I got my first professional C job way back we didn't use it then, but it seems to have holdouts in the hacker world, namely the Unix style derivatives.

Anywho, I digress, is there a way to make the braces lineup by default? Thanks!

Labels: Apple, Cocoa, Development, Mac, Objective-C, Tools, XCode

Posted by Rob at 12:39 PM | 2 comments |

iPhone development tutorial

Cocoa Is My Girlfriend: "Similar to one of my first blog posts on building a basic application for Mac OS X using xcode 3.0, I am going to explain for beginning iPhone/iPod Touch developers how to build the most basic Cocoa Touch application using Interface Builder and an application delegate in xcode 3.1." - Excellent!

Labels: Apple, Cocoa, Development, iPhone, Objective-C

Posted by Rob at 12:27 PM | 0 comments |

Video intro to Cocoa

The Unofficial Apple Weblog: "Over at Theocacao Scott Stevenson has posted the video of his Introduction to Cocoa talk (entitled "Best of Both Worlds") aimed at those who want to learn a bit about Apple's preferred API for building OS X applications." - For later.

Labels: Apple, Cocoa, Development, Mac, Objective-C

Posted by Rob at 4:21 PM | 0 comments |

Random Cocoa Links

Cocoa Is My Girlfriend: "...in this post I am going to demonstrate a few things that can be done with NSError objects that have been received. Specifically, how to add options to an NSError and how to (hopefully) recover from one."

Theocacao: "The third edition of Aaron Hillegass's Cocoa Programming for Mac OS X is now shipping. I talked about it in some detail previously, but the summary is that this is one book I can easily recommend to new Mac programmers."

Both via Brent Simmons.

Labels: Cocoa, Development, Mac, Objective-C

Posted by Rob at 11:20 AM | 0 comments |

Random Cocoa Links

Random Cocoa Links
Cocoa Is My Girlfriend: "...in this post I am going to demonstrate a few things that can be done with NSError objects that have been received. Specifically, how to add options to an NSError and how to (hopefully) recover from one."

Theocacao: "The third edition of Aaron Hillegass's Cocoa Programming for Mac OS X is now shipping. I talked about it in some detail previously, but the summary is that this is one book I can easily recommend to new Mac programmers."

Both via Brent Simmons.
Labels: Cocoa, Development, Mac, Objective-C

Posted by Rob at 11:17 AM | 0 comments |

iPhone experimentation continues
I've been exploring the iPhone SDK lately, it's been fun. I've finally figured some stuff out so it's really starting to get exciting. My "big" hurdle had been understanding how to take advantage of Interface Builder. I finally figured out how to hookup events now that seems pretty obvious, I knew that would happen, light bulb on, bing!

Here's a question for any Mac developers. Do people actually use the Interface Builder to design visually and hookup events, or do they draw the interface and hookup events in code, or do they build the UI all in code? I know, it's a strange question, and I'm sure I'll get a strange mix of answers, if any at all, but I had to ask. I'd love for Daniel Jalkut, or Brent Simmons to chime in.

Doing Windows C/C++ stuff for years had led to a certain expectation with Mac tools. In Windows I only used the graphical tools to create dialogs (at Visio we didn't even do that), then I'd go hook up event handlers in code. It was very straight forward and after using Interface Builder once I can see how easy it would be to hookup events in code instead of letting Interface Builder generate code for me.

I was very happy to discover a hunk of old C++ code compiled and worked like a charm when mixed with Objective-C. It was a pharmacokinetics library my brother and I created a long time back, and it just built and worked. That is a HUGE leg up for me. I can use my bad habit of writing C++ and slowly move into Objective-C. Very nice.

Next hurdle, gaining a better understanding of Objective-C.

It sure would be nice to build a Cocoa version of the Endura WS5000 software, hint, hint.
Labels: Apple, C++, Cocoa, Development, iPhone, Mac, Objective-C

Posted by Rob at 9:12 AM | 4 comments |

Win32 to Cocoa
ars technica: "This is the second part of a three-part series describing how one developer became disillusioned with the Windows platform and was reinvigorated by the bright lights of Mac OS X." - Stash for later, I'm having a bear of a time getting used to "The Cocoa Way." Anything that'll help make that transition, I'm all for it. Currently my biggest problem is figuring out how to use Interface Builder and hooking up events so my code actually receives them. This is the most difficult platform change I've ever made. I've worked with a bunch of different platforms and frameworks and I've never struggled this much. Eventually the light bulb will go on and I'll be fine, for now I'm very frustrated with the entire exercise. Objective-C is pretty interesting and I'm sure will pose some problems for me, but I can only burn one bridge at a time, and that bridge is the Interface Builder bridge. More to come.
Labels: Apple, Cocoa, Mac, Objective-C

Posted by Rob at 9:50 AM | 2 comments |

I really, really, want to go to this
Apple.com: "The groundbreaking innovations of Mac OS X Leopard and iPhone OS offer two revolutionary development platforms for developers and IT professionals. The Apple Worldwide Developers Conference (WWDC) is the only place you can receive technical information on these sophisticated platforms from the engineers who created them. Bring your code to the labs and work one-to-one with Apple engineers, applying development methods and best-practices you gain from sessions to enhance your application."
Labels: Apple, Cocoa, Development, iPhone, Mac, Objective-C

Posted by Rob at 9:48 AM | 0 comments |