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
