Re:Google j2objc, a Java to iOS Objective-C translation tool...
by MarkMc on Friday October 24, 2014 @08:50AM
(#8503379)
I think you're underestimating the amount of platform-independent code in a typical app.
Looking though a random sample of non-game apps on my iPad, I'd guess that about half would have a significant chunk of code which is not OS-specific, including: Gmail, Spotify, Anki, Google Maps, Facebook, Twitter, Penultimate.
I also don't think that the choice between C and Java as the common language is so clear cut. C would get you some speed benefit but Java has GWT for porting Java to Javascript, and and a huge range of other tools and libraries. In the end I think it would come down to how comfortable your development team was in each language.
(Disclaimer: I'm a Java developer)
Re:Google j2objc, a Java to iOS Objective-C translation tool...
by RussianCow on Friday October 24, 2014 @11:01AM
(#8503999)
> C would get you some speed benefit but Java has GWT for porting Java to Javascript
You can compile C to JavaScript with emscripten[0].
Re:Google j2objc, a Java to iOS Objective-C translation tool...
by cromwellian on Friday October 24, 2014 @11:45AM
(#8504202)
Emscripten's good for games, but I don't think it's good for an app like Inbox.
Re:Google j2objc, a Java to iOS Objective-C translation tool...
by cromwellian on Friday October 24, 2014 @06:26AM
(#8502963)
Case in point: Inbox by Gmail. It is not just a thin skin over AJAX calls, but actually a fairly sophisticated client side application.
Re:Google j2objc, a Java to iOS Objective-C translation tool...
by akrymski on Friday October 24, 2014 @07:42AM
(#8503154)
> a fairly sophisticated client side application
is it actually an full blown IMAP client? Most likely it uses AJAX to fetch JSON from Google's proprietary APIs
Re:Google j2objc, a Java to iOS Objective-C translation tool...
by cromwellian on Friday October 24, 2014 @12:01PM
(#8504270)
It works offline, that should give you a clue that it is not just a request/response app. Yes, it does make requests to Google's servers, but it can run completely offline with no connection as well.
Re:Google j2objc, a Java to iOS Objective-C translation tool...
by betteringred on Friday October 24, 2014 @07:16AM
(#8503084)
Does Google Inbox use J2ObjC? You seem to be alluding to that but not explicitly saying it.
Re:Google j2objc, a Java to iOS Objective-C translation tool...
by bookwormAT on Friday October 24, 2014 @10:24AM
(#8503786)
Google Inbox is indeed written in J2ObjC:
See https://groups.google.com/forum/#!topic/j2objc-discuss/5lMZN...
Re:Google j2objc, a Java to iOS Objective-C translation tool...
by suchire on Friday October 24, 2014 @08:53AM
(#8503394)
Dropbox has some mobile apps that have some fairl complex client-side logic with multithreading (https://tech.dropbox.com/2014/04/building-carousel-part-i-ho...), so they use a cross-platform C++ library with bindings to Obj-C and Java with their Djinni library (https://github.com/dropbox/djinni/)
Re:Google j2objc, a Java to iOS Objective-C translation tool...
by king_jester on Friday October 24, 2014 @10:21AM
(#8503766)
A lot of apps are just API consumers, but apps with any kind of moderately advanced functionality will require some kind of entity model and business rules that need to be captured. Having those things go out of sync between platforms can be a source of bugs or slower development. For shops invested in Java or with a lot of Java engineers, something like this can be be useful so that the entity model and business rules can be encapsulated in a single code base.
I agree that it's a noble goal, but I'm curious about places where that sort of logic is actually common enough to justify the overhead of maintaining a cross-platform library.
Most of the applications on my phone are ultimately native UI skins over web services. There might be some logic in there to handle other features, but in most cases it's tied into OS-native features anyway.
I can see cross-platform libraries being useful for games using GL, maybe for media applications that require formats not supported by the OS, and for applications that do heavy image or audio processing – in short, the sort of thing where the value-add is specifically high-performance processing. Maybe that's enough to justify the existence of these tools, though I'd imagine it's almost always a better option to write your library in C in the first place.