I’m planning the development of a cross-platform SDK that will also have a Unity plugin (currently for Android and iOS).
Currently i’m thinking of the best option for doing so. The SDK will already be implemented natively for each platform.
the options possible i am considering are :
Create a C# wrapper around both existing SDKs. simply call the existing functionality from Unity.
Create a new implementation in C# from scratch, without using the existing SDKs.
Which is the way to go? what parameters should i consider when deciding this? (there isn’t a clear answer on this i believe - having a wrapper that calls existing SDKs can sometimes be a bit limited and requires more work to achieve what’s needed).
Unless there’s a really good reason to re-implement the SDK in C# (perhaps you want to support all of Unity’s platforms, bypassing the restrictions of native SDKs which only target one platform), wrap your native SDKs. Unity plugins can be a pain to write, and you’ll need to make sure your native APIs are coordinated so they can be wrapped nicely in all platforms, but if your SDK uses native facilities even moderately, it’ll save you lots of time.
The issue is, coding something purely in C#, and coding some C# wrapper that calls a set of existing “native” code (i.e: using JNI for Android) are two different things.
Sometimes, the nature of the interoperability between unity/mono to the underlying platform is not so convenient to work with.
My question was whether this is favorable to re-implementing…
It depends on your SDK. If you want native UI, for example, then using pure C# is not an option at all. If it’s a math library, on the other hand, then using just C# becomes an option.
If you can elaborate on the nature of the SDK you’re writing, perhaps I can give a better answer.
I work for a company called Nextpeer. We have an iOS and Android SDKs involving client, server and native UI. We took the wrapping approach. Consider the following points:
Native UI forces you to use native code, no (good) way around it.
Sockets are a Pro feature (IIRC).
Our code bases are substantial and updated constantly. Duplicating it in C# will require considerable effort (many man-months).
FWIW, Facebook Google have client/server/UI requirements, and their plugins are wrappers around native SDKs.
So it seems a wrapper is the right way to go in your case.
Taking it one step further - is the logic for the Android/iOS SDKs written once or implemented once per platform? what was the reason to design it in that way?
It is implemented per platform. Some parts could have been implemented in C or C++, but they are too small to justify the overhead of wrapping them into Java (and Objective C, to a lesser extent).
Again, the actual code that can be written in C(++) is small relative to the code base, and there is the upside of having full flexibility and decoupling between the two codebases. I’m leaning towards the current state of affairs (not having a shared code base), but maybe it’s just my status quo bias. I think the best suggestion I can give here is to design your SDK first, and see if there are big parts that naturally and easily fall into the “shared code” category. If yes - go for it. If not - well, that’s platform fragmentation for you.
Another suggestion people gave me was to use Python or lua as means to get “cross platform” code.
I am not a lua expert – have you ever heard of any product that uses lua (or some scripting layer) to provide its core functionality, simply because it is cross platform?
to me that sounds like adding more friction and risk to the process, but i may be completely off here.
Sounds like another level on indirection, and not an appropriate one on mobile devices (at least, I’ve never heard of a mobile SDK that was written in either Lua or Python). Would make more sense to go with HTML5 and Javascript. But for easier integration with Unity, the platform’s vanilla language will be the best choice IMO.