How to Build a Successful iOS Application from Java Code in Two Months

The challenge

Enjoy a challenge? Our mission in early Spring 2016 was to develop a live prototype of the OTC flex-options trading application in a very short space of time. Join the Devexperts Mobile Development team on a journey of discovery as we set to work at finding the ultimate solution.

In a not so distant past it used to be the norm to essentially perform all trading operations manually – with a phone in one hand and a spreadsheet with your positions in the other. The teams’ overall goal was to automate current workflow allowing traders to monitor their options portfolio on the fly and simultaneously analyse risks.

Phase one of this exciting project involved developing a desktop application and a mobile solution – iPad app. Working closely with designers and the UI/UX team to implement as much functionality as possible, the overall achievement of delivering this comprehensive product on time was impressive. The project started in early April and had to be completed by the designated date in late May – and not a single day later. In total, the team had only had 6-8 weeks pure development time.

Looking for solutions

So what did Devexperts discover during the development of this project? Fascinatingly, the team figured out a solution to the rarely solved engineering problem in cross platform development of using Java code in the iOS application. Using business logic code translation from Java to Objective-C, we skillfully embedded it into the purely native UI application.

In recent years many speakers at the JavaOne conference have covered the topic of using Java code in the iOS application. In general, they mostly recommend so-called “hybrid application development”, which means that you are re-using your existing JavaScript codebase from your web application inside the native or native-looking environment. In practice, this is usually quite an unpleasant experience only suitable for big and complex enterprise solutions where the application is just a tiny window to a huge corporate network and systems. The applications for these purposes are usually slow and non-interactive, while the mass customer is expecting something of a much higher standard. People are used to a nice and smooth mobile experience these days.

Crosscompiling Java to iOS – dxByte translator

In order to achieve a high-end user experience to meet the demands of developing a trading application, the Devexpets Mobile team utilized their homemade translator – dxByte. It is common knowledge that all code translators have their issues. dxByte is no exception. We are required to use Java language version not higher than 1.4. We can translate only plain java classes, which in turn can use a limited part of a standard library. It may sound unusual but we are quite happy with that. After almost seven years in operation we can be confident that this tool does its job and does it well.

Overcoming issues

So what issues did the development team have to overcome? Firstly, one of the apps key advantages was the Risk Profile screen. We needed to make it possible for the user to simulate different market situations, something like a “what-if?” mode. Secondly, the team needed to produce a quick and smooth mobile application experience. Everything needed to be as fast and responsive as your fingers. To achieve both of these objectives the solution was to incorporate the whole computation model code inside the iPad app. The server would be the provider of raw data (volatility, portfolio, current market state, etc), but all the calculations would be done by the mobile device itself. Devexperts already had a library for calculating the required model – dxPrice Lib Options, but it is written in Java, and we were obliged to use native Objective-C code in iOS.

The team wisely recognised we needed to have a reliable foundation on which to kickstart our prototype development. And we had it in the form of – dxMobile. It is an application which has been designed to be deeply customized for different purposes since day one.

Devexperts Mobile team had everything we needed – the library with calculation model, the template application and the Java to Objective-C translator. The next hurdle to overcome, was that the dxPrice library had been designed without taking into consideration dxByte’s restrictions. After considerable investigation the decision was made to use the outside translator Google’s j2objc instead.

In order to integrate Google’s j2objc, we removed a number of modules from dxPrice leaving only the pure-math part. In a bid to pass objects of quite complex structure, which were required for this model, we had to simulate Java Serialization mechanism over their proprietary mobile transport. Java Serialization is one of those things which are not supported by j2objc, so we had to write custom external serialization.

Devexperts Mobile team made an interesting observation at this point. Since we needed serialization only on the back-end side, but deserialization only on the client-side, we decided not to write them both in Java. The idea of writing the client-side part directly in Objective-C seemed good at first glance until we realized that we were missing a testing part. In order to cover bi-language codebase with tests you have to apply a greater effort than testing a homogenous environment. So everything was done in Java and at some point we had seen a “green light” of Unit-tests output.

After that, upon all that codebase we had written a model (in Java again, reasons were the same) which would be used directly by the mobile app. The model takes those data objects, transferred from back-end side, as input, and gives theoretical profit/loss values and position metrics as output. This model happened to be so handy that we started to use it at both back- and client-side. In first case the real portfolio data was computed and in second – the simulated one.

Interesting fact: all those steps took up almost 4 weeks of continuous work, and we couldn’t demonstrate any intermediate result. All this stuff – codebase preparation, start of prototype development, code translation, serialization mechanism and model development – can be considered as literally an atomic operation. Either they complete everything and calculate risk profile, or could basically show nothing. It is impossible to calculate the left part of the graph while the right one is not done yet. At some point even the ideologist of the whole approach – started to doubt whether it was a good idea at all. Wasn’t it better to just calculate everything on the back-end sacrificing the user experience for demo purposes?

Chasing all fears away we tripled the development pace. And four weeks later we saw a first graph on the iPad screen, which not only showed simulational data but was absolutely interactive – all your favourite pan-to-scroll and pinch-to-zoom gestures were there (thanks to the dxMobile charting codebase which was easily adopted for the new approach). But it wasn’t the finish line, just a first milestone. Devexperts Mobile team had to do a lot of optimizations, write a lot of UI around the new model and add new features into the app, but that’s a different story.

Conclusions

What did the team learn from this sprint run? Now we have answers to some interesting questions:

Is it possible to make complex mobile applications?

The answer is “yes”. Forget about those “oh, wait, we won’t implement this feature in mobile apps since it is too complex for them”. Those times have passed. Now mobile devices are powerful enough to handle almost everything, more than that – many tasks could be performed in an even more efficient and natural way. The only drawback is that you have to have a strong UX team, capable of suggesting usable approach. The responsibility of this decision is higher as well.

Can any Java code be translated to Objective-C nowadays?

The answer is “yes” as well, but with a few restrictions. J2objc has become a really mature, out-of-the-box solution. The output code is not easily readable indeed, but what you get is a working code, instantly, which is much more valuable. Yes, it works with performance overheads compared to the code you write yourself, and yes, it still has bugs, but you can work around those issues. You will save a lot of time. Forget about “hybrid app” approach and JavaScript in mobile development.

What else is important? The Devexperts Mobile team became wiser.

Here are few tips:

• Don’t be afraid of translating more code. It is better to write the whole codebase from A to Z on, say, Java and cover it with lightweight unit-tests rather than operating with heterogeneous environment. You will be 100% sure that you are translating working code and you won’t be spending man-years searching for a bug.
• If you want to write a proper model, imagine that you will need to translate it into iPhone app compatible library. You will immediately get a notion of how it should look.