Thanks Dan,
I also found that communications was a 'bitch' in Java whereas .Net we consumed web services which was easy. However, during our testing we came to realize that web services probably is a bad idea because of the overhead and limited resources on Smartphone's. Trying to get Java Bean's running on the Android was a nightmare. We then looked a serialized objects, which too was a nightmare in Java versus .Net and making them compatible with each other. So, we came up with the fact that our communication layer should change no matter what we do. So, what we did was to built our own xml record <tag>data| where the '|' is the same as </tag>. We then take this sting and add SOH + BLOCK + STX + our data + ETX + CRC32 and then encoded (utf8 or whatever you want) and post it to the sever (yes it's the old xmodem protocol). The server grabs the data. convents it back to ascii and makes sure the SOH + STX + ETX are there. It then calculates the CRC32 and checks for a match. If good, then it processes the command (or whatever it needs to do with the data). The idea would be to also support coming over a port etc. Also, the xml is encrypted, for security, before being encoded. We also only serialize data into the message that is not the default. So, if a number is zero then it is not sent. The same is for strings. This is because the server has the default values when it builds the object. Now on the server, we build the new object with the defaults. We then take the xml that was sent and apply anything that is not a default. When you want to send data back, you just reverse the process. Since we wrote these classes, all we have to do is support a http post/get in any language we write with. Also they are extremely lightweight so my network team will love it because they're not going to have buy more bandwidth. Tim ________________________________ From: monodroid-boun...@lists.ximian.com [mailto:monodroid-boun...@lists.ximian.com] On Behalf Of Dan Russell Sent: Thursday, August 04, 2011 1:48 PM To: Discussions related to Mono for Android Subject: Re: [mono-android] Java -v- C# mondroid Hi Tim, I've found much of the same thing in my playing around with Mono for Android. I've mostly adopted the Java approach for client applications on the Android platform. Web/Restful Services are implemented in .NET/WCF/C#. Although there are different stacks available, I've adopted Android/MOTODEV Studio -> Restlet -> Jackson for accessing and serializing/deserializing to/from POJO (plain old Java objects). Regarding differences between Eclipse and Visual Studio, I've found the following: 1) Eclipse offers better refactoring capabilities. Visual Studio offers the very basics. 2) Intellisense/Code Completion is much better in Visual Studio 3) Code formatting is much better in Visual Studio. Eclipse provides more options, but there are some scenarios where the options don't allow what I'd like to do. This is especially so with XML formatting. Visual Studio just works. 4) Device management is much better in the Android/MOTODEV Studio stack. You have options like starting and stopping devices/emulators, take screen shots, change startup options, etc., which make for a more pleasant experience. 5) When porting applications to Mono for Android, I've found some Java code constructs that simply do not have equivalents in C# like anonymous interface implementations. You can get the job done otherwise, but in more code is required. Also, you'll find some Android platform items not implemented at all. In cases like this, it's not just a simple port, you have to find another way to do it. It's not that it cannot be done. It just require more work. Best regards, Dan From: Tim Kelly <tim.ke...@designerware.com> To: Discussions related to Mono for Android <monodroid@lists.ximian.com> Sent: Thursday, August 4, 2011 9:12 AM 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
