3. Our case
• Product: iOS, Android Apps; Backend; Desktop coming
• Communication protocol; API; security; client-server
• A lot of non-trivial code to be duplicated
Android
iOS
Symbian
The whole solution brakes down, because somethings
takes too much time to implement on Android
4. Why should we re-write the same code
and fix the same bugs 2-3 times?
5. Goals
1. Less developers, optimize efforts, cost saving
2. Streamline and speed up the development and bugfixing
3. Increase stability and quality of the product
8. Decision
In 2013 we decided to re-design the product architecture and write the
core in C++
OS abstraction layer
Protocol Media
High-level SDK: business login, etc.
iOS
Android
Desktop
JNI
Symbian
C++
More to come
9.
10. Our results
• Learning curve
• Are we happy? Definitely yes: 70% of code is shared in C++ and
support is much easier
• Streamlined development: we get all the new features
simultaneously
11. Lesson Learned
• Choose solid and convenient OS abstraction library
• We had to re-write timers routine 3 times!
• Encapsulation and polymorphism
• Understand what should remain native
• Unless 100% sure keep the networking part native
• Get a tool for interface between native language and C++
13. When to use
Use Don’t use
Long running project/product Short projects, outsourcing
Cost and effort optimization is a
key
Projects are not so complicated
Familiar and ready for C++ and
cross-platform C++ libraries
Don’t have enough C++ expertise
14. Embrace C++11/14
C++11/14 makes replacing ObjC/Java feasible:
• shared_ptr, unique_ptr
• new containers
• atomics and threading
15. Define where to put the line
• UI – not a good candidate for C++
• Business logic, Data, Model – perfect candidates
• Define what should remain native: e.g. networking
16. Choose solid OS abstraction library
• Choose it carefully
• Choose mature only solutions
• It will become your framework to provide you with primitives like
Thread, Timer, File access, etc. etc.
• Options: Qt, Boost, Poco, self-made
17. Interface
• Define how your Apps will speak to C++ part
• Think this through at the very beginning
• Easy on iOS; relatively easy on Windows (directly or PInvoke)
• JNI – default NDK option for Android. Try to avoid it.
18. Interface: options
Possible ways to build interfaces:
1. Traditional:
ObjC ↔ C++
Java ↔ JNI ↔ C++
2. Protocol Buffers + ZeroMQ
3. Djinni
4. http://google.github.io/flatbuffers/
19. Interface: Protocol Buffers + ZeroMQ
Benefits:
1. Your C++ part will act as “local server”
2. Thread safe
3. Language independent interface: don’t
have to define bindings and types for each
platform
20. Setup build/run process
• Be ready to test your code on Android/iOS which implies in having
both Desktop and Mac
21. Data layer
• A good candidate for cross-platform C++ implementation
• Many great libraries exists: SQLite, SQLCipher, Realm.io / Poco
• For simple structures use plain SQLite C implementation