Converting an Android application to an iPhone one using Xcode & Eclipse

[Miguel Angel Chueca]

Hi everybody,

We have developed a project in Android and I would like to convert it into an iOs application.

These are the installed and/or downloaded elements on our iOS 10.11:
- Xcode 7.*
- Eclipse
- Apache Maven
- Eclipse IDE for Java EE Developers
- Eclipse for Android Developers, whish I have to configure if necessary
- J2ObjC extension for Eclipse
- J2ObjC 1.0.2
- Our Android entire project

I would like to know if I am going to be able to keep on cnverting the *.java files with these programs.

I have been looking for information around Internet and I have not found any tutorial. I just want to convert the *.java files because I imagine that is the only aaptable part. In case the entire project is translatable, I would like to know how. I have tied reading http://j2objc.org and some videos, but they seem to be presentations rather than manuals.

Thank you very much for this helpful source.

Looking forward to yur help, really kind regards!

[Lukhnos Liu]

You probably want to start with something small to get familiar with the tools first. The command line tool j2objc is designed to work like javac, but instead of .class it gives you Objective-C .h and .m files. The j2objcc can compile the .m files and produce a binary (targeting OS X by default), but it's just a wrapper to supply things like include and library paths to clang. When I first came to J2ObjC, I wrote a simple Java "Hello, world" (and tried a few things, such as collection classes and file IO) and got the translated files with j2objc. I then used j2objcc to get a working a.out. My next step was to set up an Xcode project that has the correct settings (Header Search Paths, Library Search Paths, the Link Binary with Libraries build phase, and so on). Those steps told me a lot about the toolchain and how much setup I'd need for a real app project.

One thing to know is that J2ObjC does not convert Android apps, projects, or Android-specific Java code to iOS. You'll still need to set up your own iOS app project and UI. J2ObjC will help you share the common, platform-neutral code (such as business logic and data models) written in Java.

[Mangel]

Hello Lukhnos,

Thank you very much for your answer. Taking into account that our starting project is quite simple (3 files only), I thought that I was going to get the translated code easily but  I got  nearly an error per  line.

So, as I see that my problems could be common to other users, I thounght I was going to find other examples and guides.

Thank you for your advice. How did you get the informaticon?

Sincerely,

[Tom Ball]

J2ObjC is best suited for "fat-client" apps that have a lot of non-UI code; after all, it was developed by Google's Inbox by Gmail team. Like the other apps who had the most success with j2objc, sharing code across platforms was an initial requirement, so designing and developing code that is platform-independent was always important. The chances of success are much lower when porting an existing an Android app, as the platform-specific code is frequently interleaved with anything that can be shared. A quick test is to search for Java files that don't have "import android" statements -- approximately 70% of Inbox's Java code is shared, so 2 of those 3 files in your sample app should not have "import android" in them.

Even if your app mixes Android calls all over its source, there are still good reasons to refactor your app to extract portable code. First, shared code provides consistent behavior across platforms. New features can be released on all platforms at the same time, and documenting them is easier (docs can be shared, too). And because your team didn't need to rewrite the logic behind those new features (just their UI), these features can go public more quickly than if you had separate Android and iOS teams.

Quality is better, too. For example, if you find a bug in the Google Sheets calculation engine (good luck, as it's very well tested :-), that bug is very likely to be present across all platforms. That sounds like a weird benefit, but it means the bug will be noticed, reported, and fixed more quickly. Shared code is easily tested with JUnit, since the difficult test areas like database and UI interaction are separated out. Those JUnit tests should also be translated, built and run on iOS, to verify behavior doesn't change across platforms. One nice synergy is that portable code is easier to test, so investing in unit tests encourages separation and isolation of shared code.

Finally, once an app is refactored to be more portable between two platforms, it's much easier to add a third. Many Google apps that use j2objc also use the GWT compiler to port the platform-independent code to run in browsers. Because the UI wasn't included, they are then free to pick whatever web compilers and frameworks they want to finish the app, such as Polymer and Closure.

So I personally discourage developers of existing Android apps from using j2objc, unless they plan on converting their platform-specific app into one that is largely portable. It hard to realize the benefits of tools like j2objc unless your development team is fully committed to cross-platform design, development and execution. There is no quick hack to get an Android app running as a quality iOS app (or vice versa), and we can't pretend there is to our community.

--
You received this message because you are subscribed to the Google Groups "j2objc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to j2objc-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mangel]

Hi Tom,

Thnk you for your answer, It was just what I wanted to know too. I was doubting about what decission was the most suitable (converting vs developing). I found  some advices of translating it through Internet but, sadly, I think that a lot of sources have recommended to use it without knowing concretly all the points to take into account. Once more, it seems that tools are recommended without using them...

Now I have discovered that, appart from Objective C, the community develope tools in swift. What would you recommend? I can imagine that J2ObjC doesn't support the new language, but in the other hand as I have unerstood in your answer, is not recommendable to use the tool to convert Android projects.

Finally, we can say that this tool is recommended to be used in Java files which are addapted to be translated, can't we? Is there any other case?

Very kind regards,

[Tom Ball]

Swift gets better with each release, and once its binary format is locked down, we'll be able to support it better. Since it supports Objective C importing, j2objc generated files can be referenced from Swift, but it's ugly (though casts can be reduced with Java nullability annotations).

Only your team knows whether a cross-platform design is better for your app than independent implementations. If the app is mainly a UI for your server, then j2objc probably won't buy you much. If there's a lot of local logic, though, it may.