Now that the Windows version of Giftory sits as a Release Candidate, with its official release imminent, I want to take a few minutes to look back on the last 12 months’ development experience with Windows, C# and .net 3.5.
Right to the point: C# is a very decent programming language and .net is a very decent framework to develop with.
Entity Framework turned out to mostly be a pleasure to work with and greatly contributed to my being able to get this project done this year.
I was greatly surprised at how much less code the Windows version has needed vs. what I had to write for the Mac version.
Years ago I inherited a Visual Basic 6 project. After working on it for a while, I thought, “this visual development stuff is nice for small projects like this PowerPoint add-in that I’m working on, but I wouldn’t want to try to use it to develop a full-fledged application.”
I was wrong.
Visual development works quite well for full-fledged applications.
For a person, like me, who hates Microsoft and everything they have to do with with such a passion, it’s surprisingly easy to give them the credit that they’re due for all of this.
But it isn’t ALL rosy in Windows Development World. There are still some great(er) things about developing on the Mac, in Cocoa.
Now, let me lay out in more detail the pros and cons I found for each.
This isn’t going to be a REAL post-mortem. Maybe I’ll do one of those later on.
The things that are better in developing on/for Mac OS X:
- Core Data has built-in undo/redo support. Entity Framework doesn’t. I wasn’t even gonna think about trying to implement this support manually on .net, so the Windows version doesn’t “do” undo/redo.
- Table Views: When I first started developing in Cocoa, I wasn’t a fan of Apple’s implementation of tables. “I want to put value ‘a’ in the table at position x,y. Why can’t I just do that?!?” But after getting used to the hows and whys of Cocoa table views, I’ve really come to appreciate them. It gets a little more complicated when you want to do special things, like putting popup boxes or other UI controls in a table cell, but it’s still pretty well supported. And, most importantly, binding Core Data values to table views works pretty well. Windows also has a pretty decent implementation of table views. And they certainly offer more customizability in their tables by way of many more events on their tables that can be intercepted. But greater flexibility isn’t always better. Multiple times I found myself having to experiment with which event was more appropriate to put code into for the given situation. And sometimes it seemed like, despite ALL of those events, there was something about each one that was problematic for what I was trying to do, or none of them had my objects in the needed state when they fired. Especially when it came to Entity Framework’s integration with tables, I spent a lot of time, more time than I should have had to, trying to get things to work right, mostly when it came to putting popup boxes or other UI controls in a table cell.
- Sheets: Well-designed Mac apps just look better than well-designed Windows apps. One reason: sheets. If you’re going to have a modal dialog anyway, it looks a lot better if the “window” is attached to its parent window and just slides down out of the title bar than putting a whole new, floating, movable modal dialog window on the screen.
- One has never needed to know much about databases to set up a Core Data model. Model your entities and their relationships, and Xcode/Core Data handles most of the setup. This may be similar to Entity Framework in Visual Studio 2010, but not so with Entity Framework in Visual Studio 2008. I don’t DO databases. I shouldn’t have to know much, if anything, about databases or how to set them up. But, to get Entity Framework working, I had to divert my development efforts for a month or so to learn about the various types of databases available on Windows, which one was best for my purposes, how to set it up, how to modify it after integrating it with Entity Framework, etc… That sucked.
- Built-in UI controls make apps easier to develop, better looking and easier/more pleasant to use. There’s no built-in UI element in .net to denote ongoing processing in which you can’t map it to a percentage complete? Really?!? My app is contacting a server, making a request and waiting for/receiving a response. There’s no built-in UI control to let the user know this is all going on so they can sit tight without wondering whether or not anything’s happening or if the app has locked up? Would seem like a no-brainer to have in your toolbox.
- Exceptions: try/catch blocks are ugly. Honestly, I hate seeing them in my code. I only put them in when absolutely necessary. Frankly, they should almost NEVER be absolutely necessary. It is perfectly acceptable to have a call return an error code if it fails (or populate an error object) instead of throwing an exception. Giftory for OS X doesn’t have a single try/catch block in the code. Giftory for Windows has several.
- Packaging apps in OS X is a thing of beauty. Many (most?) apps don’t need to be anything other than a single executable file. Okay, as developers we know OS X apps are actually folders, but to users they appear to be a single file. Windows would do well to copy this. Having to have a folder – a folder that can be seen as such by users – with files that, if they accidentally move/delete them could ruin the whole app, openly available on the user’s system is just plain bad. Open the “Applications” folder on a Mac. You see a bunch of pretty application icons that you can double-click to launch. Open up the “Program Files” folder on a Windows box. You see a bunch of folders. Ugly. Just. Plain. Ugly.
- Core Data was introduced in OS X version 10.4. If I want to use Core Data, all I have to know is that the user is running OS X 10.4 or later. Apple does a wonderful job of integrating technologies into the operating system and making it easy for developers to utilize technologies with a minimum amount of effort. Microsoft could learn a HUGE lesson from this. I just spent the last week+ trying to figure out how to deploy an app to end users that is written in .net 3.5, uses Entity Framework, and uses SQL Server Compact Edition. Thankfully, LOTS of other developers have had the same problems I did, so there were always answers to my various questions available online. Unfortunately, often the “answers” were more like suggestions for things that worked for one person but not for another. Nevertheless, utilizing and deploying technologies that are provided by the OS vendor should not be this difficult.
The things that are better in developing on/for Windows:
- Sometimes when developing for OS X, you want to know when a certain “event” happens so that you can base an action off of it. You then search the documentation to see if said “event” calls a method in a delegate, or triggers a notification. Often it does, but sometimes it doesn’t. In .net, however, you can almost guarantee that your event is already defined in the framework and you can write code against it. Often, there’s two or three similar events that you can use to accomplish the same task. Yes, that may seem to contradict something I said earlier, and it can be unnecessary to have too many events, but it’s still better to have too many than to have an occasion where you need an event but it isn’t there.
- Data passing between objects: Cocoa has something called an application delegate that I use as sort of a repository for global variables, values that might be needed by disparate parts of my application. I didn’t find that .net had a similar methodology, but, surprisingly, I found that I didn’t need it. Data passing between objects somehow seemed to be either much easier, or mostly unnecessary. I’m still not sure how that worked out, but it did.
- Creating custom views/controls is a much more pleasant experience in .net than in Cocoa. That’s possibly due to the integration of the form designer into the code editor, something which the next release of Xcode will also have, but it doesn’t yet. So, in .net, no dealing with xib files and no init’ing new controller objects with those xibs.
- Even though I think Cocoa’s usage of sheets is much better than .net’s usage of dialogs, creating and using dialogs in .net is much easier than creating and using sheets or child windows in Cocoa. The integration of parent windows with their child windows is fantastic.
- Customizability: This should come as no surprise. Apple is known for “forcing” adherence to their way of doing things. Microsoft is known for giving huge amounts of flexibility in the way things can be done. .net offers a lot more ways to do things the way you want them or to make controls work the way you want them to.
- I don’t know much about databases, and I don’t want to have to. But I do know a little, and that little bit of knowledge went a long way in dealing with Entity Framework. Querying in Entity Framework turned out to be quite a bit easier than fetching results with Core Data. With Entity Framework you can write a simple query. With Core Data you have to build components that you use to construct a fetch request.
- To this day I don’t know what most of the options for data bindings mean in the Interface Builder data bindings section. Data binding in .net, on the other hand, is much simpler. Maybe Cocoa’s implementation has more flexibility and more power, but for what I was doing I generally didn’t need it. I could bind controls to Entity Framework entities or query results with a couple of lines of very simple code.
- As stated above, Giftory for Windows version 1.0 has most of the same features as Giftory for Mac OS X version 3.5, yet there’s a lot less code in the .net project than there is in the Cocoa project.
I would note that I still spent my fair share of time lamenting that “I hate Windows” because of some thing or another that didn’t work the way I thought it should, whereas, in Cocoa, things usually worked the way I thought they should, even if I had to write more code to get to the finished product.
I guess this may not turn out to be my only Windows product in the long run, but I still think I can safely say that I enjoy working in Cocoa enough that a Cocoa version will always come first and always be my favorite.