But then came the iPad.

The iPad uses Cocoa Touch, but it has much more screen real estate to work with than an iPhone or iPod Touch. The iPad is fully capable of supporting a table UI that has multiple columns. And indeed the view-based architecture supports the ability to customize table cells to your heart’s content, even on an iPhone.

Nevertheless, it doesn’t seem particularly easy to approximate the UI of a data-driven desktop app on the iPad, as there doesn’t seem to be any method for more complex table layouts on the iPad.

But that’s exactly what I need in writing Giftory for iPad.

So I wrote it.

And now I’ve released it for anybody else to use.

The primary UI for Giftory on the desktop is a display of gifts, including, for each listed gift, its name, the store it was bought from, its price, the names of its giver and receiver, its hiding place, and a couple of other relevant bits of info:

Table View for desktop version of Giftory

This UI utilizes text fields, popup boxes, combo boxes and check boxes to achieve its functionality.

Cocoa Touch table view cells are generally only fit to embed labels to customize the cell to display several pieces of information. Some table cells have been implemented with a label to provide the name of a data field, and an editable area where the user can enter a value for the field. But editing multiple data element values always requires utilizing another screen.

None of this is suitable for editing multiple data elements for a given data object displayed on a single table row.

I created “Reusable Dynamic Table Cell Classes” to solve this problem.

These classes provide a subclass of UITableViewCell that utilizes objects built to simulate the functionality of pop up boxes, combo boxes and check boxes, as well as standard text fields and buttons. Using these classes developers can programmatically define a row UI for their tables, associate the row with a data object, such as a dictionary or managed object, and manage the data through the generated interface:

Customized iPad table row using Reusable Dynamic Table Cell Classes

The classes aren’t currently suitable for situations in which the row itself needs to be selected, but they are ideal for situations in which the table rows simply display various elements of a data object, and those elements are editable.

In the next post I will go into detail about the design of the data cell classes and how to use them in code.

The open source project can be found at: http://github.com/ecrichlow/iPad-Dynamic-Table-Cells

At one time I thought that platform was going to be In-Flight Entertainment Systems, those little screens in the backs of some airplane seats that allowed you to do everything from watch movies to play games to search for restaurants in your destination city. Unfortunately, that endeavor failed to take off, no pun intended, to any significant extent.

Next I thought that games, especially casual games, would be the big thing on Linux, which was supposed to take off as a mainstream desktop OS. But then Linux never managed to get that desktop foothold. And regardless, others had started placing bets on that market much sooner than I ever thought they would anyway.

I’m ashamed to admit that the two new platforms that really DID take off, and which I was perfectly positioned to take early advantage of as a long-time Mac developer, I completely missed the early adopter boat on. When the iPhone was opened up to third party development, I thought, “so what?” I never imagined that it would become the Next Big Thing and that simple apps that you could write in a week could make a million dollars. So you would think that I would have learned my lesson in betting against Appl… Steve Jobs. Yet, when the iPad was announced, my response was, “niche product that will never amount to much.” Oops.

So now I know never to bet against Apple/Steve again. And this means that I’m now preparing for the possibility that the next big platform is on the horizon.

Rumors are again circulating that Apple is preparing to release its own line of HDTVs. IF this happens and IF such a device can run third party apps like the iPod/iPhone and iPad can, then maybe this is the Next Big Thing that I’ve been waiting years for.

Guess it’s time to start figuring out what kind of television apps I can write.

In my case, Apple isn’t copying anything, and they’re not adding anything that hurts me. Nor are they making a change to either of their OSes that impacts me.

No, Apple is discontinuing iDisk. And with that, ends Giftory’s ability to let users post a Wish List to their iDisk Public Folder and let other Giftory and GiftoryWLR (iOS) users read it from anywhere else in the world.

Hopefully something in iCloud will turn out to be a useful replacement. My fingers are crossed.

Maybe this will be the impetus for me to come up with a shared Wish List solution that will be compatible across the Mac AND Windows versions of Giftory, the iOS Giftory Wish List Reader, AND the upcoming iPad version of Giftory. Guess I’ll have to look at this as an “opportunity”. :)

The truth is, there isn’t very much code to write that hasn’t already been written a hundred times over. Every general programming “problem” has been solved, and there’s often a generally accepted “best” method to solve any such problem.

However, if you’re in this business because you enjoy the “art” of developing software, then you probably enjoy developing your own solutions to programming problems, even if canned solutions to those problems already exist, and even if the solutions you come up with aren’t necessarily as elegant or optimized as the solutions that already exist.

In other words, lots of us like reinventing the wheel. It’s part of what we enjoy about what we do.

When we’re working on our own independent projects, this isn’t an issue. We’re free to do as we please.

But when we’re taking a paycheck from an employer or charging a client for our time, their ultimate goal is to get the desired finished product, as quickly and cheaply as possible. Our desire to spend extra time developing our own solutions to problems is usually incompatible with their goal.

But there has to be a balance.

Yes, it may be unreasonable to decide you want to write your own xml parser on your employer’s/client’s dime when so many other canned solutions already exist.

However, keeping you engaged, challenged and interested in the project and your work is also a very important factor, for both parties.

So if someone suggests that you use Framework X to make web service calls, library C to process the returned results and open source project N to display the results in a nice, pre-fabricated UI, if that’s the majority of the application’s functionality, then they’re asking you to become a puzzle assembler, a code monkey, a paint-by-numbers “resource” who likely won’t take any joy out of the work you’re doing.

Find the balance. Determine which wheels would be unreasonable for you to reinvent, which wheels you will learn the most from reinventing and which wheels you can bring something new to the table for.

Then have at it!

But most of all, don’t get trapped assembling coding jigsaw puzzles for the rest of your career, which likely won’t be very long if that’s all you’re stuck doing.

Coincidentally, just yesterday I took part in a debate that typified the whole reason I decided to start this blog in the first place.

Be it specific to Cocoa development or more generally applied to the profession of software development, there’s a segment of our profession that only respects those with the utmost of programming skill, or at least those who strive to attain such.

In no field is EVERYONE “elite”. By definition that would be impossible. There will always be those who are “average”. In fact, by definition, the MAJORITY of people in any field will be “average”. But average doesn’t mean “mediocre”, (I just looked it up to be sure.)

A lot, if not most, of the software out there in the wild was developed and is maintained and extended by “average” programmers. These programmers are perfectly capable and competent. And they should be respected, even if they aren’t always striving to be elite, to learn all of the ins and outs of the SDK/platform/language that they’re using; even if they do things in non-standard ways; even if they buck platform conventions by trying to develop software on one platform using conventions and design patterns that they brought over from another platform.

The goal, for most programmers, is to produce a finished, working application.

Users of that application couldn’t care less how it was developed, if it “just works”.

There are programmers out there, hmmm… what did I refer to them as a year ago? Oh, yeah, “Hotshot Superstar Software Engineers“… who desire to have the most pristine, optimized, streamlined code that always uses the most appropriate aspect/feature of the language/SDK in its implementation.

Good for them. More power to them. I don’t begrudge them anything.

But personally, I would MUCH rather release a program that does something unique and is adored by users, but was implemented with code that was ugly, unoptimized and inefficient, than to write the most beautiful, optimized, streamlined, efficient routine to implement a feature 20% faster than anyone else ever has, and have users go, “meh, there’s a dozen other apps out there that do the same thing.”

So while Hotshot Superstar Software Engineers continue to degrade and belittle “average” programmers, I’ll continue to stand up for them, and proudly declare myself as a member of that group.

Much like the iPhone originals, rewriting them for Android didn’t take long, and gave me a good chance to assess Android development and compare it to the experience of iPhone development.

What did I find?

Well, first off, I almost hate to say this, because I know that one gets used to what they know, and something unfamiliar can often be perceived as frustrating, poorly designed, garbage, etc…

That said… I really, really am not a fan of Eclipse, which is the IDE that the official Android development pages tout as the de-fact Android development IDE.

When the T-Mobile G1 first came out, we dabbled a bit in Android development.

It was hard to get past the fact that there was no visual layout tool for Android that was even in the same ballpark as Interface Builder for iPhone.

It’s been a couple of years. I figured that they MUST have improved the layout tool by now.

Ummm. NO.

Sorry, but it’s absolutely terrible.

On top of that, I think the Android emulator leaves a lot to be desired compared to the iPhone/iPad simulator.

But I could live with those. I actually, at times, found myself enjoying Android development.

Except for one little thing.

Almost every time I wanted to figure out how to do something with my UI, and I searched online to find the answer, most, if not all of the answers started with something to the effect of: “in the layout xml, you…”

I’m not a fan of Java’s layouts. I’m also not a fan of performing tasks in xml. Lacking a good Interface Builder equivalent, I do most of my UI creation in code. Therefore I need answers for how to accomplish things IN CODE. I’m amazed at how hard it can be to find such answers for Android.

But the real problem is, it’s not just that the answers are hard to find, sometimes they don’t exist. Android is a very nice mobile OS, with some very nice features. However, the SDK seems kind of half-baked, because a lot of the features aren’t available programmatically, or at least are unnecessarily hard to get to programmatically.

Here’s one example:

I have a button. I have two graphics files for that button. One for the up state and one for the down state.

I expect that for any SDK for any OS that I’m using, I can find a call such that I can set those up and down images in a couple of lines of code like this:

setImageForState (img, BUTTON_STATE_UP);

setImageForState (img, BUTTON_STATE_DOWN);

Done.

And sure enough, on the iPhone, we have:

[button setImage:upImage for State:UIControlStateNormal];

[button setImage:downImage for State:UIControlStateSelected];

So how do we accomplish the same thing in an Android app?

Would you believe:

button.setOnTouchListener(new View.OnTouchListener() {

public boolean onTouch(View v, MotionEvent event) {

if(event.getAction()==MotionEvent.ACTION_DOWN)

button.setImageResource(R.drawable.buttonpressed);

if(event.getAction()==MotionEvent.ACTION_UP)

button.setImageResource(R.drawable.buttonup);

return false;

}

});

No, I’m not kidding, and it took a while to find this solution, most answers just said, “in the layout xml…”

Sorry, but that’s ridiculous.

So the bottom line is, Android is a perfectly fine mobile operating system, and it may one day be a pleasure to write for if they actually develop a decent layout design tool for it and give developers simple programmatic access to all of the functionality available through layout xml.

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.

As the year started winding down, I devoted some time back to the Mac version, trimmed down the new feature set, and came up with version 3.5.

Finally got that version done and tested a couple of weeks back.

Then I had to sidetrack things again to get a version built to put on Apple’s Mac App Store.

Finally, last week, I got it packaged up and put on the website.

So it’s been publicly available for a week now… but I haven’t “officially” announced it yet, because that’s waiting for the Windows version to be ready to be announced.

But if all goes well, everything will happen in the next couple of days.

I always knew that there were people out there who really did like Microsoft and their technologies. But W-O-W! Being here, I’m absolutely amazed at the degree of Microsoft adoration! I’ll admit that it does turn my stomach just a bit, but I have come to find that, as JavaEE, Apple, Google, Open Office, Facebook and others have become more relevant, Microsoft has become less relevant, and thus I don’t thoroughly despise them as much as I used to.

Besides, this is a really good group of people that I’m working with now. And even better, I get to be an insurgent having a Macbook Pro on the company network and making iOS development contribute more and more to the company bottom line.

Perhaps my selling out is nearing a point of no return…

Nah.

I must admit, C# is a pretty nice language and .net is a pretty nice framework. It helps that I did some work in VB6 a few years back, so the whole visual development thing is familiar to me.

So the first big issue I dealt with in developing the Windows version was creating the data and linking it to UI elements.

On the Mac, we’ve had Core Data and bindings for years. I figured Windows MUST have something equivalent.

Spent some time looking… bindings was easy enough… but Core Data… not so much.

Eventually I came to understand that the closest thing Windows has to Core Data is the Entity Framework. Now Entity Framework isn’t so bad… except that, unlike Core Data, Entity Framework is intimately tied into using a database. Core Data, on the other hand, is storage mechanism agnostic.

I don’t DO databases.

With Core Data, you design your data objects and their relationships, and Core Data handles the setup for you. While I read that the 2010 version of Visual Studio will do just that, 2010 was still in beta when I started this project. Honestly I can’t believe that Microsoft was that far behind Apple for an object-graph management and persistence framework. But apparently Steve Jobs was right when he described how revolutionary it was when he first unveiled it years ago.

Now that I’ve spent some time in Entity Framework, I would say it’s a pretty decent system. It was harder than Core Data to just pick up and run with without reading a ton of documentation first, primarily because it required way too much of an understanding of databases. But once your database is set up, it’s pretty usable, and integrates very well with data binding.

I remember with Core Data I just read a little bit, started experimenting, and even though I didn’t fully understand what I was dealing with, when things SEEMED to work, I banged on them a little more to be comfortable that I had it right… and ran with it. With Entity Framework I seem to have more confidence that things are going to work as expected and the data integrity is safe. Not sure why, though.

Too bad Visual Studio 2010 wasn’t available a year ago. Would have saved me a lot of time and trouble.

So now that I’m considerably behind schedule for getting the Windows version done well in time for this holiday season, we’ll see just how rapid this rapid application development system is.

I will say this, getting Giftory for Windows to the same state as Giftory for Mac version 1.0 has taken considerably less code in Windows than it did on the Mac. So maybe I’ll actually make this release afterall!