Class design

Discussion in 'Mac Programming' started by mmmdreg, Sep 2, 2010.

  1. macrumors 65816

    mmmdreg

    Joined:
    Apr 14, 2002
    Location:
    Sydney, Australia
    #1
    I have a working (Cocoa) application but I'm not happy with it from a structural point of view, so I'd like some input as to the 'accepted' way of doing things.

    The main points of the application are:
    - It is document-based
    - A bunch of parameters are set in a document.
    - There is a 'run' button that displays a modal sheet that gathers a final ID parameter
    - The application then goes and does stuff with the document parameters and the ID.

    To make this work, I created a SheetController that controls a separate NIB file that gets the ID parameter.

    The flow of is:
    1. 'Run' button is calls the action run1 in MyDocument.
    2. run1 calls the SheetController and makes it display the sheet.
    3. SheetController has a variable that stores the sender that started it as a NSPersistentDocument (I couldn't make a MyDocument variable).
    4. If NSOkButton is returned on sheetDidEnd, SheetController sends a message back to the sender that it stored (which is MyDocument), and calls the run2 method.
    5. run2 then goes and processes everything.

    This seems like a very silly way to achieve something that I could do in a few lines with Java. I could probably control the sheet from within MyDocument but it's probably ideal if it's separate.

    How should I structure this?

    For the record, all I want to achieve is the cocoa equivalent of:
    Code:
    String subjectID = JOptionPane.showInputDialog(null, "Enter subject identifier", 
            "Subject", JOptionPane.QUESTION_MESSAGE);
    
    if (subjectID != null) {
      // process...
    }
    
     
  2. macrumors regular

    Joined:
    Mar 5, 2004
    #2
    The reason is probably because Cocoa and Java have two different GUI threading models.

    It is possible to achieve something analogous to showInputDialog using runModalForWindow, but strange things might happen. See Question #22 from the Cocoa Programming FAQ.
     
  3. thread starter macrumors 65816

    mmmdreg

    Joined:
    Apr 14, 2002
    Location:
    Sydney, Australia
    #3
    Thanks for that... So would you go about the issue in the same way that I did?
     
  4. macrumors 603

    Joined:
    Aug 9, 2009
    #4
    It's difficult to visualize with only a description and no code.

    However, if I understand correctly, then it's possible to pass a target object and an @selector(targetMethod) as parameters for the SheetController to invoke on "OK" sheet-termination. This is a common pattern in Cocoa: target/action. Delegation is a related pattern.

    http://developer.apple.com/mac/libr...catingWithObjects/CommunicateWithObjects.html

    You could have other forms of sheet-termination action-methods, too. For example, it could take a MyDocument parameter and a boolean that indicates OK or Cancel. The SheetController's action would be responsible for translating the actual sheet-termination call into whatever conforms to your target-action method parameters. It's layered delegation, which is still delegation.

    Or maybe that's what you have now, but without seeing code I was unable to discern this from your description.
     
  5. thread starter macrumors 65816

    mmmdreg

    Joined:
    Apr 14, 2002
    Location:
    Sydney, Australia
  6. macrumors regular

    Joined:
    Mar 5, 2004
    #6
    Not sure; I've never actually written a Mac OS program, only iOS. I would probably follow the advice of the FAQ.
     

Share This Page