Porting application from Java to ObjectiveC/Xcode

Discussion in 'Mac Programming' started by Macula, May 7, 2010.

  1. Macula macrumors 6502


    Oct 23, 2006
    All over the place
    Hello everyone,

    We have an application here—not very large but not negligible, either—which was developed in Java/Eclipse (the GUI is based on the SWT libraries).

    For a number of reasons (aesthetic, strategic, performance, …) we are considering porting the software to ObjectiveC/xCode.

    Now, I am newly hired and do not know the Java code extensively. In fact, the first logical step would be to read through the Java code and document it. This is also what my boss wants me to do as a first step.

    However, he also suggests that I write the Xcode port "on the fly", in one pass, while producing the Java documentation.

    I would greatly appreciate any insights/advice/experiences with regard to this: Are the two environments (Java/Xcode) similar enough in design philosophy to allow such porting "in one pass"? Or should I try to convince my boss that I should finish the Java code documentation process first, and only then begin to port the code to Xcode?

    Any experiences or insights on such matters would be greatly appreciated.

    Thank you.
  2. gnasher729 macrumors P6


    Nov 25, 2005
    Ignoring whether you have documented Java code or not, it looks as if you are asked to write a Cocoa application without having a proper design in place. Not a good idea. On the other hand, why would you want a formal documentation of the Java code? It is going to be thrown away, isn't it?

    0. Start with the design documents that were created for the Java application (although I have an inkling that you will come up empty :D )

    1. Document _all_ persistent data, all interfaces to the outside (data sent to or received from the application), preferences setting etc.

    2. Decide whether you want to keep the same format for persistent data, or whether you just want to be able to import it once. In that case document how you want to store data in the future. You may decide to use CoreData for example if that is helpful from performance and scalability point of views.

    3. Document the user interface as it is, then decide which parts of the user interface need to stay as they are, which can change but don't have to, and which should change. It's completely pointless to document the Java code for this, because none if it will stay anyway.

    3. Design how you will represent the data in Cocoa.

    4. Start with code that reads and writes persistent data correctly. When that works perfectly start adding UI to manipulate this data. Management doesn't know how software development works, they believe that when they see something, that's the software. Manage their expectations by not having more percent of the UI finished than of the application itself.
  3. sanPietro98 macrumors 6502a


    May 30, 2008
    I also highly recommend that you document not just the design, but also the requirements. Once you and your stakeholders have a shared understanding of the requirements, you can prioritize them.

    Time and budgets are ALWAYS tight. So when you reach the limits of your alloted time and budget (and you know you will), all stakeholders should know ahead of time which features/requirements are highest priority (i.e., "must-have" features) and what can be added onto your new code base later (i.e., "would-like-to-have" features).
  4. Macula thread starter macrumors 6502


    Oct 23, 2006
    All over the place
    Thank you very much for the insightful responses!
  5. xStep macrumors 68000

    Jan 28, 2003
    Less lost in L.A.
    And if something is found, it may be out of date.

    He needs to write down business rules that may be revealed in the code.

Share This Page