Question

I’ve implemented a tabbed UITableViewController. There are some tabs on the top which reload the contents of the table. Based on the selected tab different cells are shown to the user. It all works nice, but I end up with a source file which contains 3 different implementations, and gets a little bit bulky and confusing, even using pragmas to mark sections of the source code.

I’ve thought of creating selectors at runtime from strings based on the selected tab, then splitting the .m file into several putting there the renamed methods, but then there’s the forced @end and the end of a file and the compiler telling you that there are missing methods to be implemented.

Really, it looks like objective-c wasn’t designed to split the source though several files. Is there any design pattern that can be used for this? Somehow I managed to emulate all this using #include <otherfile.m> before the @end of the main class, but it doesn’t look pretty. Also, Xcode gets confused as hell if I try to include that file into the project, since it tries to compile it separately (at least I can include the files in the project and disable their inclusion in the target).

Answer 1

In the end I have resorted to the basic preprocessor, meaning includes and some trickery. Here’s what I’ve done:

1. Given a table view controller filename.m, create one filename_functionality.m file for each tab/group of related functionality and put there the methods. Note that there is no @implementation, @end, #include, etc, in this file, just the methods.
2. In your Xcode project add the new files, but be careful to not mark them as required for any build targets. If you forget, select later the files and uncheck the mark which includes them into your target. This is to avoid Xcode trying to compile these rouge files alone.
3. At the end of your main filename.m and just before your @end marker, add the necessary #include "filename_functionality.m", which effectively tells the preprocessor to treat all the files as a single one.
4. For the cases where your main file is calling methods of your subordinate files, add to the top of your main file an anonymous interface and declare there the prototypes of the methods you moved to the other files.

At this point, it works! However, Xcode is still really annoying, despite being able to open the subordinate source code files, it doesn’t parse them properly, so you can’t use the quick navigation bar to jump between methods, for example. Again, to solve this more preprocessor trickery:

1. At the beginning of each subordinate file, add (yuck, wiki formatting is broken):

   #ifndef _INCLUDE_FILES

   @implementation BIEntity_view_controller

   #endif

2. At the end of your subordinate file repeat with ifndef enclosing an @end.

3. At the end of your main file and before the includes, define _INCLUDE_FILES.

What this does is trick XCode into thinking that this is a proper implementation file, so syntax highlighting, completion and navigation bars work as expected.

The only minor nit with this setup is that Xcode doesn’t properly report errors for lines in your subordinate files, it just points to the include and stays there. Now I have to right click on the line error and select Reveal in Log which sows the full console message where the correct line numbers are.

This is not a big problem if you don’t write bad code (hehe) or use an external text editor anyway, but will seriously hurt if you are used to the quick fix keys to jump from one error line to another.

With this trick I’ve split a 1151 line file into four of sizes 558, 342, 55 and 145 lines each. Now the functionality is better related and the code can still work as part of the same class, so I don’t need to write accessors as would be the case if using a language construct like classes or interfaces.