Home/ Questions/Q 7993785
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T13:57:21+00:00

I’m using plain English here. I’ve got this great app with multiple tabs and

  • 0

I’m using plain English here. I’ve got this great app with multiple tabs and each tab (subclasses of UIViewController) has stuff on it. One of the tabs has a button inside (among other things) and has a lot of functionality.
The button is pretty (subclass of UIGlossyButton I found on the net) and shows a microphone
If you press the button it (the tab) records your voice and stops automatically (by detecting volume levels/a timeout)

  • While recording, the tab controller shows a LED meter on top of the button
  • After recording, the button is swapped out with anthor button showing a speaker
  • Tapping the speaker plays back your voice
  • Swiping across the speaker lets you “delete” which resets back to the microphone

This “widget” is great and I love it. Now I want to put this thing inside other tabs and whatnot across the app. This looks like a candidate for abstraction rather than copy/paste.

What’s killing me is: should I package all this functionality (logic to show/hide/swap buttons, record sound, analyze sound levels) together into a widget? If so, how many classes should I use and which classes should each subclass? And lastly, in Interface Builder which object should I drag onto my storyboard inside the tab and which of my classes should I type into the “Custom Class” box.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Sounds like a lot for a single UIView subclass to do. I would absolutely split this up over a series of classes, or at least between the an extended UIGlossyButton and an associated UIViewController.

    The button’s responsibility should be: able to draw itself, know when it’s pressed and do minimal logic about what to do when action is taken on it (like send a message to a UIViewController).

    Think of the button itself as the View of MVC. The Controller will then actually know what to do for all the smarts behind actually the action of the UI. Then things like the sound meter, or the voice file, optionally should be represented as model objects/classes. Sometimes I find it in iOS that creating explicit Model classes is overkill so I just use normal Cocoa classes like NSDictionary with polymorphism to handle the model stuff from the controller.

    • 0