Mobile Cross-Platform Development : RoboVM

Transcript

1. Mobile Cross-Platform Development : RoboVM Nickolay Moskalenko
2. Nickolay Moskalenko Traditional native development: • Several independent apps with the same logic • Several codebases • Several separate teams • Multiplied development/support costs
3. Cross Platform development: • Unified app logic • Unified Look&Feel • One team, one codebase • Possible reduce of Development/ QA/Support costs Nickolay Moskalenko
4. Approach 1: • Fully Cross Platform Solution • Cross Platform UI layer,
 most often Web or OpenGL based Nickolay Moskalenko
5. Approach 2: • Split “business logic part” and UI part. • Move “business logic” into separate module and use it from traditional mobile app. Keep UI native. Nickolay Moskalenko
6. PhoneGap • Approach 1 – fully cross platform • WebView based app: HTML, CSS, JavaScript • Good for simple apps • Good for web developers • Would not recommend for solid apps Benefits: • Fast development, especially for devs familiar with web development Drawbacks: • Its own sandbox, platform specific features implemented as plugins • Not native Look&Feel • Possible performance issues Nickolay Moskalenko
7. Qt • Approach 1 – fully cross platform (QML based UI) • Well known solution for desktop cross platform (Windows, MacOS, Linux) • Good for not only mobile cross platform solutions • Could be good for C++ developers • Known apps: 2GIS Benefits: • Compatibility with desktop solutions Drawbacks: • Its own sandbox • Complicated development for mobile developers Nickolay Moskalenko
8. Xamarin Benefits: • Most solid cross-platform approach right now • Uses modern technology stack : .NET/C#, lots of tools/libraries from .NET world • Pretty big community Drawbacks: • Paid • Uses C# and .NET libraries that could be complicated for Android/iOS devs Nickolay Moskalenko • Both 1st and 2nd approaches • Provides .NET framework(Mono) in mobile world • Deep integration with Microsoft, Visual Studio, etc.
9. C++ shared library • Approach 2 – split Core/UI • Move application logic into single C/C++ library • Most known applications: Dropbox Carousel, Mailbox, 
 Facebook Moments • Good for apps with solid “business logic” layer Benefits: • No sandbox, full control of app development Drawbacks: • Slow and complicated development • Lack of good “helper” libraries Nickolay Moskalenko Useful links: • https://code.facebook.com/posts/498597036962415/under-the-hood-building-moments/ • https://channel9.msdn.com/Events/CPP/C-PP-Con-2014/Practical-Cross-Platform-Mobile-CPP- Development-at-Dropbox
10. J2ObjC • Approach 2 – introduce “Core part” • Move app business logic into pure java library, 
 translate java code into objC before iOS compilation • Most known applications: Google Inbox, Calendar, Docs, etc • Just released 1.0 version! On January 21, 2016 Nickolay Moskalenko Useful links: • http://gmailblog.blogspot.com/2014/11/going-under-hood-of-inbox.html • http://google-opensource.blogspot.com/2016/01/j2objc-10-release_21.html
11. RoboVM • Approach 2 – split Core/UI • Provides Java/Android development to iOS • Mostly known by libGDX game engine, 
 but also available for business apps development • Already acquired by Xamarin (no longer open source) Nickolay Moskalenko Benefits: • Allows to use Java/Android tools and libraries to speed up development • Good for Android developers Drawbacks: • Paid (125$ per dev per month for companies) • Doesn’t support Windows Phone
12. Let’s play with it! Nickolay Moskalenko
13. How RoboVM works? Nickolay Moskalenko On iOS: • Wrap all iOS SDK with java bindings by their own Java/C/ObjC bridge (Bro) • Use Java to compile code into JVM bytecode • Convert JVM bytecode into LLVM IR (intermediate representation) • Compile it for iOS target (ARM) by LLVM as regular iOS apps do • No Virtual Machines used in runtime • Provides RoboVM runtime (GC, Class Library, etc) On Android: • Absolutely native app on Java • Full Android SDK support directly, without any additional layer Tools: • RoboVM Studio – a branch of well known IntelliJ IDEA • Gradle for both Android and iOS
14. Nickolay Moskalenko
15. Shared code restrictions Nickolay Moskalenko • We can use all Java API (based on Android SDK), except Android specific features, like: • android.* • com.android.* • dalvik.* • javax.microedition.khronos.* (OpenGL) • You can use any Java third-party library which support Android, but doesn’t depend on Android specific API listed above • Can’t use runtime bytecode loading/manipulation. All Java code should be present on compilation time (Restrictions of Apple's App Store Terms of Service)
16. iOS specific Nickolay Moskalenko • Storyboard support: temporary XCode project generated with Storyboards, to edit it manually • Thirdparty iOS libs: by roboPODs only • Performance: nearly the same as native apps • IPA size: +~10Mb – RoboVM runtime Useful links: • https://medium.com/@harrycheung/cross-platform-mobile-performance-testing- d0454f5cd4e9#.ddpjo9t5t
17. RoboPODs Nickolay Moskalenko • Java bindings for popular third-party 
 libraries • Ships as JARs via Maven Central • We can create our own roboPODs if need
18. Advanced topics Nickolay Moskalenko • C/C++ libs consumption – YES, using their own bridge BRO • Retrofit – YES • RxJava – YES • Kotlin – YES • Cupboard / realm.io – NO, depend on Android SDK Useful links: • Intel is doing something very similar: https://software.intel.com/en-us/multi-os-engine
19. Thank you! For any questions:
 Twitter: @MoskalenkoNick Email: nick.moskalenko@gmail.com
 Skype: nick.moskalenko