C# -> Mono proof of concept

I have a C# app that compiles to Windows and WindowsCE. I want this app to run, using the same code base, on iPad and Android tablets. I believe Mono will do the trick for us, and I want someone with extensive experience in the Mono environment to create a proof-of-concept. The final product should have all the basic functionality of our current app, but I don't expect everything to be solved. This project may later be expanded to take the solution all the way to production. ## Deliverables Candidate must have extensive experience with C# and Mono, creating apps for both iPad and Android. Here are some more details on the app: It's a moving map that displays raster and vector images. It has approx 30 forms and 100k lines of code. There are 15 projects that compile to libraries, and 1 Startup winform project. It is multi-threaded, using thread timers to manage periodic events, and a thread to render map images independent of the user interface. The app was designed to run on a Windows CE device. Compiler switches are found periodically through the code to account for differences in the Compact Framework. A couple of libraries are used for fast Jpeg decoding and some other low-level graphics stuff. At the completion of the port, the following core features should be working: 1) Maps should render and paint, at least 1 Frame per Second. (Currently maps render 5-10 FPS on a fairly slow CE device, so I don't anticipate this being a problem. 2) The user is able to interact with the map - pan, zoom, touch for more details, etc. This should all be working. 3) We have forms to handle pop-up alerts, settings, displaying details, etc. These should be ported and function correctly. The following will be excluded from the port: 1) We use SqlServer Compact Edition as a read-only database. It has about 12 tables of data. This will not be ported. Instead, you will hard-code static data to simulate db activity. 2) In our CF project we have external C++ DLLs for some low-level graphic functions (alpha blending, JPEG decoding, etc). We use these because they are specilized and much faster than the [login to view URL] version of these functionsuse And I'm presuming we'll use built-in libraries for most image processing (ie [login to view URL])- we don't use the CF versions of these because of performance reasons) 3) There is about 3gb of data that this app consumes, which changes often and we have a website and several methods of deploying new data to our customers. For this release, we're not going to worry about deploying and updating this data; we'll just include a few hundred meg of expired data for the proof of concept.