iirc, monotouch had similar(documentation, debugging, etc.) issues early in its lifecycle (1.0 didn't have breakpoints). Given some time, I think that this can be resolved. Wally
Date: Thu, 4 Aug 2011 13:37:35 -0400 From: [email protected] To: [email protected] Subject: Re: [mono-android] Java -v- C# mondroid Wally, I agree that the lack of examples isn't much and I enjoy the challenge. But, I have to list it as a concern so we add additional time into the project plan. So far, we've got enough help from people on this list to overcome issues. About the libraries, that's create news. The IDE performance isn't as much of an issue for an old mainframe guy like me. I remember the days where you spent more time in design and working through offline code instead of just compile and run and compile and run. In those days, you scheduled time and made sure things would work before you handed the operator your card deck to run. But, I've created some new habits like breakpoint testing that is now painfully slow. On another note, nothing to do with MonoDroid, I have a global error class that writes debugging information to a log file. We then just use notepad while developing on Windows to view this logging file. However, the Android emulator's lack of being able to view files is troublesome. Again, this has nothing to do with MonoDroid, but makes it frustrating when it comes to troubleshooting. For example, on our Windows version we can enable debugging and have the customer send us the file or view it. This on the Android is not going to be easy. Tim From: [email protected] [mailto:[email protected]] On Behalf Of Wally McClure Sent: Thursday, August 04, 2011 1:18 PM To: [email protected] Subject: Re: [mono-android] Java -v- C# mondroid 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: [email protected] To: [email protected] 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 [email protected] UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid _______________________________________________ Monodroid mailing list [email protected] UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
_______________________________________________ Monodroid mailing list [email protected] UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
