Garrick Toubassi, Google Inbox engineering director, has recently explained how his team could get to "sharing roughly two-thirds of their client code" across three platforms: iOS, Android, and the web. The key is a clear separation of concerns between UI code and UI-independent logic, and a couple of tools that Google developed through the years.
Google's approach aims to build "separate native apps that fit seamlessly into each of our respective target platforms," says Toubassi, in an efficient way. Indeed, in an app like Inbox there are a number of components, such as for network communication management, caching, local persistent storage, etc., that is not reasonable having to implement and maintain separately on all three platforms.
What Google does is implementing just once the data model and the application logic in Java, and on top of that a native UI layer for each platform. The data layer and application logic have a twofold responsibility:
-
Modelling concepts specific to Inbox, such as Conversations, Reminders, Contacts, and Labels.
-
Providing a fully observable data model allowing binding to the user interface (UI) layer.
Those foundations are then "transpiled" to native code for each platform using a couple of Google's own tools:
- Google Web Toolkit (GWT) to translate the Java data model into JavaScript for the web platform;
- J2ObjC to translate the Java data model into JavaScript for the iOS platform.
GWT is a long-standing open source set of tools that allow developers to develop and debug Ajax applications in Java. When the application is deployed, the GWT cross-compiler translates the Java code to standalone JavaScript. GWT also allows to embed JavaScript code directly into Java code, using Java comments.
J2ObjC is a more recent tool that Google describes as being "between alpha and beta quality". It does not include any cross-platform UI toolkit. As Toubassi remarks, a tricky point when going from Java to Objective-C is going from garbage collection to reference counting. This is handled in J2ObjC through autorelease pools: the equivalent of garbage-collecting a set of objects in Java is draining the pool they were allocated to in Objective-C. One specific problem with this, says Toubassi, is related to the possibility of reference cycles, which are effectively handled through specific Java annotations mapping to weak Objective-C properties.
Talking to Ars Technica's Ron Amadeo, Toubassi stated that this approach has no detectable impact on performance and that the J2ObjC-generated code has "roughly the same number of objects and the same object graph complexity" as a hand-built Objective-C version.