I don't want to have duplicated code, it is too much maintenance. Yet we have it across most of the Menu plugins. Yikes, how to keep it all the same?! (Perhaps with coding techniques such as blocks, categories, sub-classing, etc.) We have a predicament as outlined in this forum post with bt_cellMenuList. The RSS Plugin is (accidentally) using the bt_simpleMenu Class from the Simple Menu plugin. Yet, that class has not been updated for iOS 7 in relation to spacing within a table cell. That is a good approach, reuse, don't duplicate. However, it causes a dependency on code that is not under the control of the RSS Plugin developer. Eventually, that Simple Menu plugin will get updated. In the meanwhile, the RSS Plugin users can include the Simple Menu plugin and make the necessary code change. A pain yes, and patience is essential. https://www.buzztouch.com/forum/thread.php?tid=CA057C991F0DBD4C63391F4 I know the BT Core is being slimmed-down with plugins taking up the slack. Yet, TableViews are fundamental to iOS apps. As such, the BT Core should provide core TableView capabilities that are tied to the Web Control Panel. One thing is guaranteed, the BT Core will indeed evolve. Plugin updates are at the mercy of the Developer and Darwin. My suggestion is for the BT Core to re-assimilate the bt_cellMenuList code. -- Niraj

I don't disagree that we have a ton of duplicated code. But, not sure there's much getting around it with 90 plugins and counting. You made two statements that struck me: "I don't want to have duplicated code, it is too much maintenance. " "However, it causes a dependency on code that is not under the control of the RSS Plugin developer. Eventually, that Simple Menu plugin will get updated. " It seems that these are in conflict. Either we have one mega class for cells (and other objects), or each plugin has their own subclass. I tend to lean toward subclasses, as it is more in line with object-oriented programming, is generally easier to understand, and allows for more customization. Plugins like the one you mentioned should probably have their own cell class, unless they truly need no customization at all.

Thanks for the dialogue, Chris! It helps to converse through this predicament. Minimal duplication is essential. Reusing via the BT Core is a good thing. Knowing what should be in the BT Core is a delicate balance and often an intuitive (judgement) decision. We already depend on many things: on the Core, on the Control Panel, on Plugins, etc. Dependency is necessary to stand on the shoulders of giants (Mr. David Book and Plugin Devs :-) Many of the Menu plugins don't need their own Cell class. Sub-classing is a good well-known approach. (I am not fully informed on the value of blocks and categories as a solution to this problem space) Perhaps the RSS Plugin should solve by sub-classing the Cell class. Yet it will need to inform the User to be sure to include the Simple Menu plugin as part of the project download. Thus, we need the fundamental TableView code to remain in the BT Core. -- Niraj

Not sure I fully understand when you say "Many of the Menu plugins don't need their own Cell class. Sub-classing is a good well-known approach." None of the plugins have their own cell class per se. They're all subclasses. Some may be subclasses of the Buzztouch cell class, many are not. But even the Buzztouch cell is a subclass of the UITableViewCell. When you subclass something, you are necessarily duplicating code. You take all the existing code (whether you show it in the class file or not) and then add your own stuff to it. Fortunately, iOS and Android are really really good at keeping it all straight and optimized. A "block" is like a normal method, but written in C. It's part of an existing class file. A "category" is an alternative (to subclassing) way of extending the functionality of a class. For most plugins, subclassing is the appropriate way of doing things. In fact, each plugin itself is a subclass of the BT_viewController class, which is in turn a subclass of the UIViewController class.

I meant that not every Menu plugin needs to have it's own Cell class file. Instead, they should leverage a BT Core-based Cell class. That is just one example. Then extend it via sub-classes or categories for the unique needs of that particular Menu plugin. For the move to BT v3 and iOS 7, notice how many of the same changes were implemented across all the Menu plugins because they all have the same Cell files. With that kind of maintenance, there is a price to pay in timeliness, quality and accuracy. While that BT v3 journey is still fresh in our minds, let's use this opportunity to have a purposeful dialogue and an architectural decision on how to structure BT for a robust and maintainable future. -- Niraj

The very nature of 'plugins' shows us that duplicate code is inevitable. And I'm creating a menu plugin that needs it's own cell. ;) How about 'no duplicate code within a single plugin' ? :) Cheers! -- Smug

The issue is that the core BT cell is doing a ton. Let's say I need a cell that will have an image and a title label, but no description label. It would be excessive to subclass the BT cell, which creates all three, then remove out the description label and resize the other two appropriately. Better would be to just subclass the UITableViewCell, in a similar fashion as does the BT cell, but with the implementation specs I need. The BT cell was primarily created with the Menu Simple plugin in mind, not as a superclass for all other plugins. It sits in the core because it does have some extendable properties that some plugins might want to make use of, but not because all should use it. Really, the decision to subclass is more for ease of developers making plugins. It's simpler and cleaner to subclass usually, but it depends on the needs of the developer and their familiarity with the language. For the user of the plugin, it shouldn't really matter. It's easy enough to modify either, and by subclassing you run the risk someone will try to do a mod for your plugin and inadvertently mess up the rest of their app.