macOS Porting application from Java to ObjectiveC/Xcode

[Macula]

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.

 

[gnasher729]

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.

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 )

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.

 

[sanPietro98]

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).

 

[Macula]

Thank you very much for the insightful responses!

 

[xStep]

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

And if something is found, it may be out of date.

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.

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