Resolved Programming Design Problem

Discussion in 'Mac Programming' started by Blakeasd, Jun 30, 2014.

  1. Blakeasd, Jun 30, 2014
    Last edited: Jul 1, 2014

    Blakeasd macrumors 6502a

    Dec 29, 2009

    I am having a problem with designing a certain aspect of a program I have written. The aspect I am referring to is storing objects created by the user for later use when the program is reopened. I would simply populate an array with created objects and then archive the array, but unfortunately the way I have designed the program does not allow me to do so. The basic layout of the project is as follows:

    1. Program starts: "Welcome"-type Screen with a "new" button

    2. User selects "new" button and a window controller (ConfigureWindowController) displays a window with options that the user can configure.

    3. A custom object is created once the user clicks "create" inside the configure window (Done in the ConfigureWindowController)

    4. This newly made custom object is then passed to an object that is an instance of another class (declared inside the Configure Window Controller), which translates that object with the properties set by the user into the "final product."

    I need to be able to store these new objects (the ones configured in the ConfigureWindowController) for later use when the user reopens the project. My idea is to add the objects to an array and then archive the array. But the problem is that I can't create an array anywhere because I'll end up with instances having an array with just one object in them. For example, let's say I put an array in the ConfigureWindowController:

    When the user selects create, the object will be added to the array in that specific instance of ConfigureWindowController -- great!. Flash forward to the future and another instance of ConfigureWindowController displays a configure window after the user selects "new" in the welcome window and another instance of ConfigureWindowController is created and added to that specific instance's array. So now I have two instances with two separate arrays and no real way to archive them. There is no way to have a central array that can store every new object that is created and then have that one central array archived like I would have liked to do.

    Could someone help me understand how to fix a design flaw like this? I tried following MVC the best that I could, but it clearly ended up crumbling.

  2. lee1210 macrumors 68040


    Jan 10, 2005
    Dallas, TX
    There are plenty of solutions. Either you instantiate an instance of an archiver/dearchiver that pulls the current array from disk (plist or SQLite, most likely) and you can choose one of these for the user, or append to the list and write back. Alternately, keeping a singleton object around to manage this would work, too. It would be scoped to the application, and manage the stored copies, keeping them in memory and managing what goes to and from the disk.

    This is your "backend logic". Your controllers can interact with this. Technically these objects may be models, but the controller has to fetch them and persist them somewhere.


    P.S. Your custom objects will need to support some way of serializing them to disk. Being able to persist an array requires being able to persist its elements.
  3. chown33 macrumors 604

    Aug 9, 2009
    Your "array" object needs to be global to the program as a whole. So if there are 3 objects, there's a single array in the app (Singleton pattern), and it contains 3 items.

    I have no clear idea what the user perceives for each of these objects you've created. You talk about the model object, but you don't really describe the user experience. The user experience is important, because it creates the user's mental model of what happens. If you don't know exactly what the user's mental model should be, or you're confused about it, then you need to decide that before anything else.

    I think you really need to nail down exactly what the user experience and perception is. That will determine what objects are sensible.

    The one-window-per-object model is basically the NSDocument model.
    The NSDocument abstract class defines the interface for OS X documents. A document is an object that can internally represent data displayed in a window and that can read data from and write data to a file or file package. Documents create and manage one or more window controllers and are in turn managed by a document controller. Documents respond to first-responder action messages to save, revert, and print their data.
  4. Blakeasd thread starter macrumors 6502a

    Dec 29, 2009
    Thanks, lee1210 and chown33. I ended up using the Singleton pattern and that worked well. Object storing now works!

Share This Page