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'.

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.

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.

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.

Matt Gemmell: "Ship a mac software product. Being a self-employed contractor is wonderful compared to being an employee, but being a software vendor has always been the goal. Three years from now I'd like to be self-sufficient with my own software, and the first step is to release a 1.0 product." - Matt has contributed some really great code to the Mac community. In fact his Open Source contributions inspired me to write some small, free, source code and give it to the Mac community.

Good luck Matt, we'll be looking for some cool stuff to come out of Instinctive 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!

Jonathan Dann: "Lets make our code more robust, we all like robust. Blocks are anonymous functions, we can write them in-line and the can capture variables from their enclosing scope." - A great little example of using Blocks in Objective-C, restoring state after a change to a Quartz context. Handy.

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.

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.

jobs.joelonsoftware.com: "We are looking for a software engineer who has a passion for creating innovative high quality software using the latest tools and technologies. You must be a self starter who loves solving problems in a logical self-disciplined manner. We are looking for someone who will fit well with our development team and remain courteous and friendly with both staff and customers at all times." - I also love the the following bullet points...

Want to work with the latest tools and a 30 inch screen?

Want to work for a company where innovation and software development is taken seriously?

Want flexible working hours and no silly dress code?

Want a career where what you achieve really matters?

Are you a clever problem solver with an enthusiastic and positive attitude?

Armin Ronacher: "I just recently started using C++ for university (about two months ago) and still have a hard time accepting some of the weird syntax rules and semantics. For someone that mainly does Python development C++ feels very unnatural. In Python the syntax is clean and there are no ambiguities. C++ is drastically different in that regard. I know there are tons of resources on the net about C++ pitfalls already, but I thought I have to add my own for people switching to C++ with a background in Python and/or C." - I forgot how daunting C++ can be coming from another language. I struggled with C pointers for the longest time after coming from BASIC, then a dear friend said these words to me.

Python is one of those languages high on my list of languages to learn, which also includes Ruby and Smalltalk. Objective-C wasn't on there, but I'm knee deep in it now. I believe Objective will be a good sprintboard to learning Smalltalk, either that or a hinderance.

I've been working on my iPhone application again, it's been months, and I've been making good progress. Cocoa Touch and Objective-C are beginning to slowly sink into my thick skull, which is a very good thing. I have a bunch of experiences to share and I really need to sit down and write them up, with hopes is helps another poor Win32/C++/COM guy make the leap into Cocoa/Objective-C land.

What are some of the things I hope to talk about? Glad you asked. The application I'm working on is very table oriented. It's really about data collection, so I've formed some very good patterns for dealing with it. Another thing I'd like to address is my view of reference counting with Cocoa, from a COM developers perspective. I'd also like to dive into is comparing Win32/C++/COM to Objective-C/Cocoa to .NET/C#/pick a language. I think Apple used to have a leg up with Objective-C/Cocoa, now I honestly believe .NET may have the edge in the rapid development department.

Hopefully I'll get around to writing about it some day, but you never know, this tease may be the final word.

As of this writing it's still my goal to become a full time Objective-C/Cocoa/Mac/iPhone developer, that's how much I'm enjoying the experience.

I've been listening to a lot of podcasts lately, Adam Corolla, Core Intuition, and my latest find, Developer Lives. Monday, on the drive into work, I listened to the latest Core Intuition, great discussion guys, and on the way home I grabbed the latest Developer Lives. Both podcasts featured Daniel Jalkut, Daniel is the co-host of Core Intuition, and was the featured developer on Developer Lives. The stage is now set...

In my dream I'm working on my Mac only drawing and diagraming desktop application, think Visio. In the dream I'm doing the thing I like to do above all other development jobs, I'm adding scripting capabilities. Mind you, I'm not coding yet, I'm working through what to expose to the outside, and trying to make a scripting environment/language choice. My two choices were AppleScript and Python, because you can embed it in you application, great example Acorn.

I pick up the phone and call Daniel. We're having a nice discussion about the plusses and minuses of both approaches, and the idea of supporting both, then my wife's alarm clock goes off; it's 5:30AM, my dream of a Mac only, highly extensible, drawing and diagramming engine is just that, a dream.

Wired: "Sepulveda's comment is focused on what sets webOS apart from other mobile environments: It only requires programmers to know JavaScript and CSS, which are simpler and easier to learn than other mobile programming languages. That's in contrast to iPhone's Objective C based Software Developers Kit (SDK) or Android's Java based tools." - There you go. Everybody can now be a developer. I can imagine the Dancing Hamsters application for the Pre. Wink, wink. I'd rather learn Objective-C, but I have a definite Mac lean these days. They're playing to the web designer, not developers, which will open the doors to a lot of folks that otherwise wouldn't be able to develop. You can create web apps for the iPhone but the serious applications are written in Objective/Cocoa, why's that?

I hope this works for Palm, I really do. It's a huge risk. But as we all know, with huge risk comes huge reward, if you hit the mark.

BTW, have you, as a traditional developer, ever had to work with CSS? It's harder to learn than a new development language, like C++, or Ruby, or Python, or Objective-C. It's really quite strange to work with. I think the place to be is at Palm, as a developer on the OS, that would be fun!

Guy English: "In Objective-C the lifetime of an object is not governed by the scope in which it appears - it is managed manually by the programmer." - Nice talk on Objective-C object scoping and how to force the garbage collector to do your bidding.

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.

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.

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!

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!

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.

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."

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."

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."

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.

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.

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."

Cocoa Dev Central: "Objective-C is the primary language used to write Mac software. If you're comfortable with basic object-oriented concepts and the C language, Objective-C will make a lot of sense. If you don't know C, you should read the C Tutorial first." - Very nice, easy to follow, tutorial for the beginning Objective-C developer, like your truly.

Here's a VERY simple example. The Objective-C file, main in this case, is using the C++ class named CPPClass. Please note I had to rename the main.m file to main.mm so the compiler would treat it properly. I've also heard you can name the file '.M', or find a specific compiler setting that'll do the same trick for you. I don't know what that setting is, sorry.

About

Rob Fahrni has been a Software Developer for 20 years. He's developed DOS, Windows, Linux, iPhone, and Palm based applications in C, C++, Objective-C/Cocoa, C#/ASP.Net, and, yes, even BASIC...
About >>