UISwitch for sound on/off

Discussion in 'iOS Development' started by hodgey87, Oct 6, 2010.

  1. hodgey87

    hodgey87 New Member

    Joined:
    Oct 21, 2007
    Messages:
    10
    Likes Received:
    0
    Hi everyone,

    Ive put a switch on one of my views to control the music, 'stop and start' i can get the music to stop with this code:

    But when i move the switch back to 'on' the music wont play again, anyone help at all?

    Cheers
  2. evilish2236

    evilish2236 New Member

    Joined:
    Mar 11, 2009
    Messages:
    54
    Likes Received:
    0
    Device:
    4G iPod touch
    Check that muteSwitch has the right connection in interface builder.
  3. Collateral

    Collateral Active Member

    Joined:
    Sep 23, 2007
    Messages:
    1,974
    Likes Received:
    6
    Device:
    iPhone 3GS (Black)
    This. It seems like you are flipping the switch, but the switch isnt "muteSwitch"
  4. SkylarEC

    SkylarEC Super Moderator Emeritus Staff Member

    Joined:
    Sep 19, 2007
    Messages:
    6,642
    Likes Received:
    129
    Use statements like this:
    [OBJC]muteSwitch.on ? [theAudio stop] : [theAudio play];[/OBJC]

    It's so much cleaner.

    Specifically, try something like this:
    [OBJC]- (IBAction)muteSwitchToggled

    Please Register or Log in to view images

    UISwitch *)theDamnSwitch{
    theDamnSwitch.on ? [theAudio stop] : [theAudio play];
    }
    [/OBJC]


    Now, why did I do this this way? Because there is ABSOLUTELY NO REASON WHATSOEVER to make theDamnSwitch an iVar. DON'T DO THAT! It is a terrible waste of memory on a device whose memory is limited. By sending a pointer in a method instead of storing an entire object in memory for the life of the view it's on, you are saving a ton of memory.
  5. lauNchD

    lauNchD Well-Known Member

    Joined:
    Jan 27, 2008
    Messages:
    1,844
    Likes Received:
    261
    Device:
    iPhone 5 (Black)
    I agree about the semantics and the 'cleanliness,' but I don't see why storing a (weak) pointer to an object in an ivar is such a waste of memory. It's only four bytes! If you need to store an ivar for an Interface Builder object that you need to interact with outside of IBActions, it's perfectly fine, IMO.
    For the OP's case, I'm not sure whether he/she needs an ivar. Maybe the switch's initial value should be set to the audio player's !isPlaying property. If the switch doesn't need configuring, they shouldn't store it in an ivar, though.

    This is approximately how I'd do it:

    [OBJC]@interface MyViewController : UIViewController
    {
    IBOutlet UISwitch *switchWhoseValueINeedToConfigure;
    // I don't need to retain it, since it already gets retained by my view
    // and if the view is released, the switch gets deallocated,
    // and once the view is reinstated, the switch is, too
    }

    - (IBAction) switchWhoseValueINeedToConfigureToggled;
    // I don't care which object this message is coming from; I just want to read the switch's value

    - (IBAction) doSomethingImportantThatAnyObjectCouldTrigger

    Please Register or Log in to view images

    id)sender;
    // Here, it's interesting to know where the message came from

    @end

    @implementation MyViewController

    - (void) viewDidLoad
    {
    [super viewDidLoad];
    switchWhoseValueINeedToConfigure.on = [[SomeSingleton sharedInstance] isServiceEnabled];
    // That's why I'm storing it in an ivar
    }

    /* … */

    @end[/OBJC]
  6. SkylarEC

    SkylarEC Super Moderator Emeritus Staff Member

    Joined:
    Sep 19, 2007
    Messages:
    6,642
    Likes Received:
    129
    Personally, I would never set up a switch in Interface Builder. It seems unnecessary to me. I ask you, is it better to, on a view with 30 switches, to have 30 different switches set up in Interface Builder, or to have one switch displayed 30 times, similar to table cells? Maybe for one switch in the middle of nowhere, it doesn't matter all that much, but when things get complicated, it makes a big difference.

    Also, I find your lackadaisical attitude toward memory management appalling. Why waste the space when you don't have to? Remember, once the ~25MB of RAM the application is allowed is used up, iOS will kill the application*. We don't know how large the audio file is or what else the application may be doing. On the iPhone, every little bit counts.

    Differing philosophies, I suppose, but I find it far better and much more productive to code efficiently the first time around.


    *I've had iOS kill my apps for using anywhere in a range of ~20 - ~45 MB. The magic number, though, seems to be ~25MB.

Share This Page