A few comments:I agree on the debugger, item #1. I demo'd this at monospace, and they are working on it. Hopefully, they can provide some type of info regarding timeframes. The mono4android libraries that you mention are for development only. by breaking the libraries up in development, it makes development and repeated deployment faster. When an app is built in release mode, the libraries necessary for the program to run are bundled with the final apk file.I have found it fairly easy to take some java code and convert it to C#. The lack of documentation hasn't been a big deal for me, however, I can see where it would be a problem. I think that Bryan and Chris are working on this. Also, Jonp has some great examples on github. Wally Date: Thu, 4 Aug 2011 12:12:30 -0400 From: tim.ke...@designerware.com To: monodroid@lists.ximian.com Subject: [mono-android] Java -v- C# mondroid
If anyone is interested, we're doing a proof of concept with C# and Java/Eclipse to determine if we can meet business requirements with VS/C#. We prefer to use C# and take advantage of cross platform development. Overall, both products offer the same capabilities and functionality so what I'll discuss here is what we've noticed and are from my notes for our design meeting. I thought I'd share them here for others. 1. Debugging an application in Java is faster and easier because breaks and restarts are noticeable quicker. In VS/C#, it is almost impossible to use a breakpoint and step through the application because it too painfully slow. Java, stops and steps through like you'd expect. 2. Monitoring the event log in Eclipse is much better than VS/C#. Eclipse does a continual logging so you can watch the logs as events appear. In VS you have to refresh which is painfully slow. 3. Making a program auto start cannot be done in the emulator for C# however, in Java it works fine. Supposedly, if you deploy the C# application to a real device this behavior is not seen. I cannot confirm this and do not understand why the Java App works as expected and the C# doesn't. 4. Running the application takes 5 times longer using VS/C# than in Eclipse/Java. If you press the run button in Eclipse the application starts relatively fast however on VS there's time for coffee. 5. Sizes of the programs are different. The C# application is 732kb while the Java application is 104k. Maybe this is why starting and building the application in the development environment is at least 5 times longer. 6. There are less examples and discussions on MonoDroid versus Java. So if you are looking to do something, you'll be hard pressed to find an example. However, in Java you'll find lots of examples and people claiming to be experts. Worst case, you'll be left trying to figure out how to convert it to the C# world. 7. We did find a few things in C# not working in MonoDroid that C# supports. For example C# supports network hardware calls. In our business requirements we need to get the MAC Address and even though C# supports it, the MonoDroid has issues with certain calls, basically enumeration of generic interfaces is not supported. 8. After an application service runs for a while it just stops running whereas Java it does not. Not sure what or why this happens. Not sure if this is an emulator problem, but it doesn't happen with Java in the emulator. 9. MonoDroid requires two Mono libraries. "Mono Android-8 Support"-12KB and "Mono Shared Runtime"-18MB get loaded and seem to be needed at least for development. Not sure how this works for a production application. But, the same application would be "huge" if these are also deployed with each application. Not a real concern, but if the user deletes these libraries then the application breaks. So, instead of having just 1 file to worry about, you now have framework files. Overall, this is what I've got so far. We did not try to deploy anything so I cannot speak to deploying applications and what size applications would be or how they perform. In the emulator, the Java program starts faster, but they both respond the same once started. The only concern we have so far are #3 and #8 which would be show stoppers for us. The bigger files and libraries are a little concerning, but not that much. The huge positive is if this works we'd have an easy portable platform for Windows7 phones and iPad (which is a most have!). Anyway, just my 2ยข Tim _______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
_______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
