We are getting closer to the truth. At least my version of the truth…
Very soon we will be able to share code between iOS and Android. Without commercial libraries. With 100% of source available. With only some pain.
Yes, there will be pain, so prepare!
I’d say about 4 or 5. Your pain tolerance may be different.
In future posts I will outline a less painful way to share, but it’s a good idea to go though details of this post to see what elements are at play.
But the the gain is real and valuable. Before jumping into details you should asses the potential gain from this endeavor.
It’s easy. Considering your app is of “pull to refresh” type and you intend to have an iOS and Android versions and possibly beyond.
See how many of these points you are hitting:
- Your app is either brand new code or it’s well structured as far as separation of business logic and model from the UI code
- You believe in unit testing. At least at the model and business layers. You don’t need to be a complete TDD freak
- The app you are writing does not have a trivial model. It’s a whole bunch of related objects, persisted and queried in various use cases depending on user interaction
- You are comfortable with SQL
- You are not scared of a little C++. Today’s C++ is not your grandfather’s C++. It’s modern, performing, and has a huge open source ecosystem around it. So it’s like Objective-C, really…
If you are hitting most of these, congratulation! Read on, it may be worth your while!
What functionality are we going to reuse?
We are going to completely disregard “out of the box” technologies such as Core Data on iOS side and SQL Cursors on Android side and we are going to roll our own solution. It’s going to be simple, reusable and shared across platforms.
Here you go:
http://codingsimplicity.com/shared-c-layer-with-objective-c-and-java-using-jni-tutorial-part1/ – the iOS and OS X, part I
http://codingsimplicity.com/shared-c-layer-with-android-using-jni-tutorial/ – the Android, part II