Posts Tagged ‘.net’

Cocoa/Objective C development tips for .Net Folks: Part I

No, this isn’t about using .Net to make iPhone apps!  It’s just a set of observations that might make it easier for people like me who currently use .Net (specifically, ASP.Net) at work, but want to start fiddling around with some Objective C, Cocoa, etc.

Keep in mind that this is from the perspective of someone who got into web development without traveling down the formal education route (when some of my buddies were learning C, COBOL and PASCAL in CompSci 101, I was sucking sand through a gasmask, patrolling some godforsaken ammo dump or airfield in the middle of nowhere).  I have no pure C language knowledge or insight, so all of this stuff is new to me.  I know many web developers in the same situation, so maybe this will help some people make the connections between Obj C and the types of languages they’re used to.

– “Actions” are event handlers.
– “Outlets” are properties that can be bound to your user interface widgets.  They are objects of the same type as the given widget. So if you have a RoundedButton on your UI, you’ll probably have a RoundedButton in your .h/.m code if you want it to actually do something.

From what I can tell, you don’t need to name the specific buttons in the UI part…you associate the button with its corresponding outlet via a drag-and-drop in the UI editor (“Interface Builder”).  I’m pretty sure you can do it manually/dynamically via code, too.  In the .Net world, you’d set the name of the button in the UI editor or in your HTML code, and Visual Studio would automatically make the corresponding code additions.  I haven’t seen that ability in XCode/Interface Builder, but I’m totally new to this so don’t take it to mean that it doesn’t happen.

You can think of the .xib file (known as a “nib” file by Cocoa vets to honor the former file extension) as needing a code-behind page.  The nib is your UI, and the .h and .m files need to be told “Hey, I have these do-dads on the UI.”  After all, if you dig through the code that ASP.Net automatically generates, you’ll find the same kind of definitions for each UI item in the code-behinds.  Same-same.  Don’t let the EXTREMELY WEIRD BRACKET-HEAVY SYNTAX scare you.

Speaking of which, here’s a brief bit of learnin’ about the syntax.  Let’s take apart this function…

-(IBAction) openThing: (id) sender
{
// code that does stuff
}

The hyphen is there on purpose.  (Don’t ask me why.)  (IBAction) is the return type, openThing is the name of the function.  (id) is the type of the argument and sender is the argument itself.  To call a function, use brackets like this:
[myObject doSomething:5];
myObject being the object, doSomething is the function being called, and 5 is the argument.

By the way, the “id” type in Obj C corresponds to Object in our world.  It could be anything.  You’ll need to cast it to whatever type actually sent the event if you want to use it.

If you ask me, the brackets clutter up things, and dot notation isn’t supported enough in Objective C.  They added it to 2.0, but I think it could be used more than it is.  You still need to use brackets for functions if I’m not mistaken.  Of course, you can’t just change the entire syntax of a language without peeving your developer base!

On a side note, I’ve found XCode to be a sweet IDE to work in.  At first I found it a little annoying to have to switch between two completely separate programs to do coding vs. UI work, but then I realized some benefits to it.  Unlike Visual Studio, you can open up just the stuff you want to work on.  VS gets more bloated and resource-hoggy with every iteration, and it would be nice if you could completely rip out the Design mode when you’re working on ASP stuff.  You know it’s lurking in memory somewhere, ready to reformat your clean, hand-written tags the moment that you accidentally summon it.

Another advantage to having two separate programs is that it reinforces the separation of concerns between code and UI.  This premise lies at the very heart of how iPhone programming works – it uses the Model-View-Controller pattern!  I have used this pattern extensively, and although I’m not a design patterns guy, I have to say that it makes for fairly clean distinctions between the various pieces in an app.  If you haven’t used it yet and you’re an ASP.Net developer, you’re in luck.  ASP.Net has an official MVC implementation!  Grab it, build some stuff with it.  Understand it. It’ll help you see how things work in the iPhone (“Cocoa Touch”) world.

The books I’m reading on the subject are Beginning iPhone 3 Development by Dave Mark and Jeff LaMarche, and Programming in Objective C 2.0 (2nd Ed.) by Stephen G. Kochan.  I’ve found both of them to be very, very good books.  I will say that getting about halfway through the Objective C book first will make your life a lot easier.  I’m currently switching back and forth between them.

I’ll be posting more stuff as I wrap my head around this.

Intellisense fix for Visual Studio 2008 ASP.Net pages

Somehow my settings got jacked up on VS 2008 and Intellisense didn’t work when viewing editing aspx pages in “source” mode (when you’re editing HTML and web form tags).  It coulda been a service pack install, it coulda been some of the paranoid junk that corporate America loads onto work computers nowdays, but regardless of the cause I was hosed.  I tried everything.

I finally found a post that led me to an answer while looking digging through the offical ASP.Net forums.  The proposed fix on the forum didn’t solve my particular issue (the topic was intellisense in XML files), but one poster mentioned switching the editor by right-clicking and selecting “Open with…”.  I remembered seeing that and tried out a couple of different editing modes.  It turns out that the “Web Form Editor” is the one to use.  I set that mother as my default and now I’m plugging away at aspx pages again.

Soooo…in VS 2008’s Solution Explorer, right-click on an aspx page you’d like to edit, then select “Open with…”.  Choose “Web Form Editor” and click the “Set As Default” button.  Done.

ActiveX weirdness will make you pull your hair out.

Note: Non-developers can skip this post completely.

If you’ve ever had to make an ActiveX application run within a web page, then you know how frustrating it can be to get it working, much less try to debug the $!&@# thing. If you’re building it with .Net, it’s even more of a pain.

What do you do in this situation: You’ve read through the available online tutorials (which I will not list, since they’re all somewhat incorrect in one aspect or another) and have had the app working at one time or another, you may still have the “missing/broken” section appearing on your web page instead of your nice new application after you’ve made a change. You’ve cleared your IE cache, restarted IE and may have even rebooted your computer trying to get your app to re-appear. You’ve done just about everything and it’s still broken.

Well, the simple answer is that there’s an error in the app itself. Apparently everything has to run super-smooth in order for IE to even display the app. Comment-out the stuff you’ve changed or throw some try-catch blocks in there. Rebuild the app, clear your IE cache, restart IE, and see if your app appears.