Develop Reference

how to use mono in my cross platform project

I've been searching solutions for my enterprise apps, at least 3 platforms need to be supported, which are iOS, Android and Window Phone. After a whole day's search, I finally set my eyes on 2 promising cross platform solutions, one is monocross and the other phonegap.
monocross seems to use c# and .net at all, is it possible to access native libraries and languages? I read somewhere it's compiled directly into binaries that can execute on target platforms.
And about phonegap, it uses webviews on each platform to provide the capabilities of presenting user interfaces to final users. As it's implemented via interpreted language and high level apis, the performance may not meet our needs.
Finally, we(my team) decide to give it a try with mono, the architecture is illustrated as bellow:
+++++++++++++++++++++representation layer++++++++++++++++++++++++++
[monotouch,monodroid,silverlight]or [native gui calls] or [html5/js/css]
+++++++++++++representation controller/business logic layer+++++++++++++++
[ mono/c# ]
++++++++++++++++++++++++++++server side+++++++++++++++++++++++++++
[ the cloud ]
I want to use mono/c# to write some common purpose business logic and data structures, and when it comes to some common platform features, like storage service, notifications, I'd like to wrap them up on each platform and expose uniform apis for c#(business logic layer) to use. As to the representation layer, we decide to choose from the 3 optional solutions listed above.
To make this happening, first I have to figure out if it is possible to call native frameworks.
So, my questions are:
1, How does mono work, I mean, are the c# codes compiled into binaries that can be executed directly on iOS, Android and Windows Phone?
2, Is there a mechanism to make native invocations? Like in cocos2d-x, I can call java methods via JNI, and in iOS, c++ can call oc directly. Can I call cocoa touch stuffs in mono with c#?
3, Is it possible to manage all these stuffs in one single project, and how to build them?
4, Are there any better solutions?
Any suggestions will be appreciated, thanks for your patience!

I wonder why Xamarin does not land on the first page of your search result,
http://xamarin.com/features
But that's what the Mono guys created for the C# developers that want to target mobile platforms. MonoTouch and Mono for Android are there each featuring a common library base with Microsoft .NET, and also platform specific bindings.
Your non-UI code should be able to be used in portable libraries and share among them. Microsoft's portable library is Windows specific, and right now I am not sure how much Mono guys can embrace that, but even if PCL fails, you can create multiple platform specific projects based on the same copy of source files (which I did in #SNMP). The remaining task is to develop platform specific UI for Windows Phone, iOS, and Android.
There are tons of articles showing the features,
http://docs.xamarin.com/
and also many successful apps
http://xamarin.com/apps
The best way to learn a product is to try it out (for free in Xamarin's case). This also applies to MonoCross (which is a framework built upon Mono).
I am not familiar with PhoneGap, so you need someone's advice on that.

Disclaimer: this is not a complete answer - but I do hope it answers at least part of your question
I encountered a similar problem when I started cross-platform dev using the Mono products 18 months ago.
The approach I've built since is called MvvmCross - it forked off of MonoCross a long time ago - now shares no code with it (but maybe we'll team up again one day!).
The approach uses PCLs to share code. This is not entirely painless, but is easy after you've done a few setup steps - http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
You can learn more about this approach on this video: http://slodge.blogspot.co.uk/2012/12/mvvmcross-video-presentation-xaminar.html

MonoTouch / MonoDroid Service Layer incompatibilities?

We've begun to build Cross platform Android/iOS apps, having built exclusively in MonoTouch before. We're evaluating MonoDroid.
Our apps need to consume JSON and we'd like to use ServiceStack. Xamarin has a ServiceStack branch which we're using - https://github.com/xamarin/ServiceStack
We'd like to have a common project responsible for GETting and POSTing JSON. ServiceStack by Xamarin has different DLLs for Android and iOS. How do we have a single project and use ServiceStack to get at our JSON?
We're open to other options to get at JSON in a unified way?

By and large, managed *.dll's compiled for MonoTouch that don't have a dependency on MonoTouch specific types are compatible with Mono for Android projects.
ServiceStack is a great example of this. I've personally used it for multiple projects across the Xamarin mobile framework offerings.
As a general rule I tend to encapsulate all invocation to my web services using a partial class with async methods, like FooProjectRestClient. And then if there ever is any sort of segmentation that needs to occur it can happen in a shared class using #if defs.

The reason why there are MonoTouch and Mono for Android specific libraries is often because of the (smaller, Silverlight-like) profile available (e.g. things that depends on new FX4.0 features needs to be cut out). They are often the same code re-compiled with SILVERLIGHT (or MONOTOUCH, MONODROID) defined.
The reason for MonoTouch only specific librairies are generally because its environment (iOS devices) do not allow JIT'ing. So there's no code generation (e.g. System.Reflection.Emit) or dynamically (down)loading code... However it's often possible to provide (less performant) workarounds or skip a few features and keep a special version of the library for MonoTouch.
Now back to having a single shared assembly/project. The special MonoTouch assembly (generally the same code re-compiled with MONOTOUCH defined) is still a valid .NET assembly and often can be used in Mono for Android, Mono or .NET (once recompiled, even with MONOTOUCH). It's definitively not optimal but it's something you can try.
Another one is having the same projects (e.g. MyLib), across several solutions (e.g. MonoTouchApp, M4AndroidApp) and use special configurations (just like there's an iPhone|Debug one) to set different defines (e.g. MONOTOUCH on iPhone*|*). That can allow you to keep the best feature implementation in each platforms (e.g. in case the same feature is implemented differently).
I would try the later first (config), then sharing the MonoTouch special assembly and finally (if it really does not work) look for other alternatives.

Building Peer to Peer photo sharing on Android

I am planning to do a project on Peer to Peer photo sharing on Android. My professor wants me to do that using some language other than Java or C/C++. Is any of Erlang, Haskell, Ocaml,
Scala, Go helpful to build an android app with following functionality?
Ability to design a GUI for android to view the pictures to be shared
Support for socket communications to transfer the pictures?

Since Android relies heavily on Java, Scala would be a good choice here. Scala makes interoperating with Java code easy and runs on the JVM. On top of this, it is a nice functional language with an interesting type system, so it will be a good learning experience. (So will your other languages, but Scala is probably easier to use on Android.)
Check out Scala Programming for Android, which describes how you can make Android applications in Scala.

You can compile and execute Go programs on Android (or ARM in general), but you can't actually use the Android libraries. So, writing services or GUI applications for Android in Go is currently not that easy. I am not sure about the other languages, but I think Erlang, Haskell, Ocaml, etc. have similar problems (if they even provide an ARM compiler).
Therefore it's probably best to focus on a JVM based language. Most of the examples and other applications are written in Java, but Scala is also able to access all those APIs. So, I would either use Java or Scala.

There's also this JVM-based functional, dynamic, lisp-like language Clojure, which some people seem to like a lot. It should be possible to use it to write Android Apps.

Well, in my view, it depends on what you want to really use the language for as regards your project. Photo Sharing: are you planning on using Web based tools for the client, i.e. JavaScript, HTML5, CSS3, JQuery Mobile (http://jquerymobile.com/), sencha Touch (http://www.sencha.com/products/touch), Phone Gap (http://phonegap.com/),Titanium Appcelerator OR you want to use native stuff like Java, J2ME, e.t.c. Then if its web based (which would make things easier in my view), the language you are referring to in this case would be on the Server side. So in my view if you just need the language to web-serve photos and stuff, then it would not matter which one you use: really depends on your liking. I am pretty sure that Erlang, Scala, Java and the others all have capability for developing great web services. However, the conditions you put as below:
1) Ability to design a GUI for android to view the pictures to be shared 2) Support for socket communications to transfer the pictures?
Suggest that you were referring to a Front-End technology to use. You cannot use Erlang to create GUIs on Android, if i am right, you may not also be able to use Haskell and OcamL as well because these technologies cannot run on the device. For GUIs on Android, you can only use Java, OR you can use Widget Technologies like Opera Widgets OR you use Web based stuff like i mentioned above. However, you should know that using JavaScript Libraries, HTML5, CSS3, e.t.c. is the quickest and more manageable way of developing Apps on any Device. I even wonder why you are talking of Socket Communications !! Am i getting you right ? you want to develop a Photo Sharing App which transfers Photos over raw Socket Communications ? Well, i am NOT sure how many apps out there for Android are doing raw Socket stuff, but i am pretty sure that many (http://androidapplications.com/) are using HTTP Protocol, as in Web Services. Consider looking into web services than raw Sockets. I am pretty sure that even apps developed using native Java, uses HTTP (Web Services like SOAP) to communicate with a remote Server, be it weather apps, location-based stuff e.t.c. Otherwise i guess you should concentrate on Java, for now.

how can we implement CAN Application Layer(CAL) protocol in iphone/android

I need to interface a device which is supporting CANBus ,So for communication with that I need to follow CAL,So can any one help that ho can I implement
CAN Application Layer(CAL) protocol in iphone/android .
Please help i am not getting any way to solve it

"I need to interface a device which is supporting CANBus ,So for
communication with that I need to follow CAL"
The second part of that statement doesn't follow necessarily from the first. There are plenty of devices and systems that communicate via a CAN bus that don't use a formal higher level application framework.
First, you need to be able to communicate with the can bus from your application. Your mentioning iphones suggests you'll be targeting consumer handsets, none of which will have a CAN interface. So you need to incorporate some adapter hardware (there are usb adapters, and android at least has usb hardware access baked into the SDK).
If you do then also need to communicate with components that implement a higher level application framework like CANopen on top of the CAN layer, your options are:
Get your hands on the specification from whatever group maintains
it, and implement it in your language and framework of choice. This is likely a substantial effort.
Purchase or find an open source implementation. If you purchase the source code for a C implementation, you can compile it into a shared library for your target architecture, and, using android as an example, write a native wrapper for that shared library using the Android NDK to expose it to your java code. If you could purchase the source code for a java implementation, you might be able to port it so that it works natively on android.
Then you need to glue the data layer together with the application layer, and this will likely be custom development no matter what.

You need the hardware to support it. I've found Gwentech's GT1026 to work well for can bus to android, but it only works on Android using USB.

Sharing code between iOS & Android projects

I've been hired to develop a mobile framework for a webservice created by my employer. Ideally management would like to have some reusable components that can be shared across mobile platforms (initially iOS & Android, probably Windows Phone 7 at some later point).
I've been wondering how feasible this is. One of the requirements is a native interface, so we would use Cocoa Touch on iOS & whatever (Java-based) toolset is used to create a native UI for Android. The application will interact with webservices, mainly the ones that we've been creating internally. The webservices have been developed in .NET.
As far as reusable components go, I guess we could use some C++ code to make webservice calls and perhaps even more of the backend of an application, yet I wonder if this would be a good approach. Apple's Foundation Framework has some excellent capabilities build-in to access webservices, not to mention other open-source libraries, e.g. ASIHttpRequest, SBJSON, etc... I guess the same would be true for Android (though I have no real Android experience for now). Also, when looking at projects done by companies like Google, Twitter & Facebook, each of these companies offers native libraries built for the major mobile OS platforms. If the big companies take this approach, it seems logical for us to follow suit.
Perhaps we should focus more on a general architecture that we should offer across platforms instead of an implementation that can be shared.
Would anyone advise us to make use of C/C++ to develop such a framework (shared library) for the mobile site of our webservices? If so, why?

It really depends on what level of customized code you want to have. I worked at a game company previously, and we made two games for both iPhone and Android, and at least 90% of the codebase was shared between the two platforms in c++ code. Sometimes it is significantly easier to implement elements with specialized third-party libraries, like for Facebook and the like, but maintaining that code means continually doing it for both platforms. That was one of the reasons why we even implemented our own UI objects in c++ for our games. Because even though the initial setup would have been easier to do with Interface Builder and Android's XMLs, the maintenance and tweaking necessary ended up being significantly less because we went with a shared codebase.
In short, I would highly recommend writing any shared customized code in C/C++, and things that are significantly easier in their native codebases (java for android, or obj-c for iphone) and you don't expect to change much, to keep separate.

Depending on which WS protocol you use it may be more or less hard to do, but anyway I see little advantage in doing that in C/C++ for a mobile platform.
If you were using SOAP, I'd never consider C/C++, even for a desktop app. I already used SOAP libraries for C++ and they are a lot harder to use than their Java/.net counterparts, and the way they are implemented (mapping SOAP objects to C structs) is very prone to crashes if the format changes. Not to mention that you have to recompile your client when the WSDL changes.
As I understood in your case you plan to use REST. I never found a good REST library for C/C++, but recently I did a desktop project in which I implemented a C++ REST client using simply WinHTTP (in Windows) and libCURL (in Linux). Of course, they provide just the HTTP part, so I had to add cppdom for XML parsing. If you use JSON, there are many good libs like jsoncpp, libjson.
I'd say to you that even in a desktop environment it was harder to do than would be in .net or java, and was only done this way because it was part of a larger application already written in C/C++.
Anyway, you'll have more work and not much advantage since all those modern mobile platforms provide rich libraries that do the same thing, and probably the user of your API will develop in the platform's main language, so you'll have the double extra work of implementing the WS access code AND the binding code. As I assume all (or at least most) of your logic is in your server, not the client, there's not much common code between the platforms to justify using C/C++.