
Writing a cross-platform library - best practices
Posted Sunday, 23 September, 2012 - 21:47 by james_lohr inHello,
I would like to modify my QuickFont library to work on Android (Mono Android), and I have a few questions on how best to go about this.
My first thought is to refactor out everything that is truly platform independent into a separate parent project, and then to have a separate child project for each platform.
My first question is how best I should be using OpenTK. Presumably I want one child library using ES11, and the other using OpenGL; however, I'll only be using functions that are duplicated in both... so is there a clean way of doing this without duplicating the code in both child libraries with the only difference being the import?
I also suspect that the OpenTK included with Mono Android is not complete (auto-complete seems to indicate only ES11, ES20, but no OpenGL). So perhaps my parent library is going to need to be independent of OpenTK (which will be a massive pain, since I can't even use the maths functions!). Perhaps I should be using the preprocessor to get around this?
My next question is how I should go about structuring this in terms of solutions and namespaces.
Should I just shove it all (parent and child projects) into a single solution? And what about namespaces? Presumably they would tie up with the child project names? (perhaps QuickFont.Andriod, and QuickFont.Something)...
Perhaps I shouldn't even be creating multiple projects, and should instead simply be implement the missing bits of C# using the android tools (e.g. System.Drawing.Bitmap is missing, but there is Android.Graphics.Bitmap which I could wrap to look like a System.Drawing.Bitmap..), and include these either as a separate library, or ... using the preprocessor?
I would really appreciate some guidance on what the best solution is.
Kind regards,
James L.


Comments
Re: Writing a cross-platform library - best practices
I'd go for #pragma too if you only have 2 codepaths, but I don't work with Android so I really cannot give you the "best practice" advice that you asked for. (But I guess some reply beats no reply)