I am interested in how Mono for Android (by Novell) works.
My biggest question is around the actual runtime's that are used. Is MfA providing a Mono runtime that wraps and calls down to the Dalvik runtime or is the Dalvik completely bypassed in this operation? Is it something else completely?
I am curious because I hear that the Mono runtime has better performance on mobile devices (not that I believe anything I read on the internet...), and really I am just trying to understand the whole thing.
Any other general knowledge on the topic of comparing and contrasting Mono/Dalvik runtimes would be appreciated.
Thanks!
It's both! Some things are run directly in Mono on the kernel and some things get passed into the Dalvik system.
http://mono-android.net/Documentation/Architecture
Link to site provided by #trutheality is already dead.
Newest version of Mono for Android would be found here: https://developer.xamarin.com/releases/android/mono_for_android_4/mono_for_android_4.4/
It's seems to be a bit out-of-dated version as it has support for earlier Jelly Bean Android version. Nowadays, MonoDroid is called Xamarin.Android and now it's in 6.0.1 version.
but there are no official information how compatible is it with MonoDevelop IDE or how it works on Linux.
I sent today a message about it to Xamarin. Hope they would explain me clearly how it nowadays looks like.
Related
I want to use Android for a system I have in order to use it as an embedded system that would run a specific application (which runs in chrome browser). However, this will not use Android in ordinary way, but rather hack around it so that libraries like OpenCV and packages like Chromium can be installed on the Android's Linux kernel. In addition, I would also need to figure out a way that would allow a USB camera to be supported.
I have done some research on this, but I am getting nowhere. Would somebody recommend resources that are relevant to this issue, or suggestions on how to approach it? Your feedback would be much appreciated.
Edit1: I am not intending for this question to be too broad. I only want to get more ideas on how you add libraries like OpenCV to Android, and whether there is a way to install the chrome browser as well.
Edit2: the Android system is on the Snapdragon platform.
Both Chromium and OpenCV can be built on Linux, have you tried compiling them from source on Android and failed? What error did you get? Here's a link for cross-compiling Chrome for ARM processors:
http://code.google.com/p/chromium/wiki/LinuxChromiumArm
I would use http://www.android-x86.org/ first and see if it works there before trying to run it on ARM so that you can fail faster if it doesn't work.
You might want to spend some time with ROM hackers to get more insight. Ideally, you want to find some people who are doing something similar so you can work with them. Take a look at:
http://forum.cyanogenmod.com/
http://forum.xda-developers.com/
A lot of what those guys are doing does not apply to what you are looking for, but they do get much deeper into the OS than most programmers. You might get lucky, and not have to modify the Android source code yourself as thinksteep mentions.
I know C# rather well and just love Visual Studio as IDE. :) Yet now I want to start developing for android...
I found out about MonoDroid and wanted to ask if it has any downsides to it that would make Java more preferable, or should I uninstall Eclipse and dive straight into MonoDroid?
If I understand right, MonoDroid deploys/compiles native android applications and does not need any additional .net-like framework or anything?
Are there any significant limitations to what I can do with MonoDroid? For example, having the app run in the background or using some external .net libraries for image editing, etc. ?
I've been worrying about the same thing - productivity in C# instead of playing with an unfamiliar language, vs developing how the OS developers intended it to be.
Its easy to list pros vs cons -
pros (of monodroid, for C# developers)
familiar dev environment, can develop using Visual Studio
C# instead of Java
Reusable code assets - you can use a lot of code in your iphone project or Windows phone 7 project using monotouch and the WP7 SDK.
cons -
debugging could be difficult, due to lack of api documentation from Google. Will have to depend solely on monodroid documentation.
there could be a lag when it comes to latest cutting edge features - safe to assume that the monodroid team will require some time to wrap around the latest android features every time there is a new OS release
availability of libraries - I am not sure how you can use the open source libraries that would have evolved around the android platform, that could cut down on development time
Much of the documentation available is in Java: so if you run into difficulties with phone behavior when using MonoDroid you won't really find that much help or debugging information so you may want to stick with Eclipse.
There's a lot more than just a set of wrappers running under davlick, truth to be told, there is much more of a horizontal relationship between MonoDroid and Android;
When did using the same language as the OS developers become a big issue? There's lots of C++ programmers wondering how to use BSD or SVR5 and many C programmers who want to know what the heck to do on Windows++...
If you will write in c# anyway you will be have to wrap it into a Java code, so what's the point ? Also you may head with a very difficult issues while trying to understand the APIs who written for Java programming...
Here are some points that you can mull over:
Android applications are predominately written with Java. The Android SDK itself is natively written in Java.
Working in Mono may not provide all the functionality available in the Java SDK.
If you are a C# Developer you wont be able to find, in Java, some of the (cool) features available in C# (like Property Delegates etc).
Code written in .NET can be re-used for other environments - this may save a lot time that would have been spent learning a new language/environment (like Objective C), and coding in it.
.NET extends the Android development stack with it's existing libraries and API's.
I think both are good for certain reason. It will be very hard to say which one is preferable for Android development - in the end that is up to you too decide.
Also note that any release build using monodroid adds an additional 4mb to the apk filesize and increases app startup time with a few seconds.
For simple apps this can mean a 500-800% increase in filesize - whic is pretty bad in my book.
I have an app which I want to run on as many Android phones as possible. My current solution is to just compile it with the newest version and doing the critical code in sections that will only be used on devices with the correct Android version. This worked fine until I started using Android 2.2. Now running the app on older phones gives me an error.
So I am thinking about using reflections, this would mean however that I would be compiling for version 1.5. So my question is will I suffer from any disadvantages? Apparantly compiling for a different version makes a difference as I can see at my error. So would I for example loose the JIT support or something?
Some insight from you guys on this topic would be great! Thanks in advance.
I am sorry if I'm telling you obvious things, but are you sure that you really need reflections?
You will have run-time exceptions when you try to instantiate class that uses higher version of SDK then one installed on device/emulator.
To avoid it you need to check for SDK version in run-time.
Example:
//check for multitouch support (Android 2.0+)
inputSystem = android.os.Build.VERSION.SDK_INT < 5 ? new InputSystem() : new MultitouchInputSystem();
There are no inherent disadvantages of using Java reflection to support different SDK's. However, there is a more elegant way described here that uses lazy class loading that is more maintainable. This I feel is a more robust way of handling different SDK support.
Will Titanium work properly on all android sdk versions (1.5, 1.6, 2.0, 2.1, 2.2).....
Based on the research I've done, yes, I believe so. I'd recommend trying it out.
Yes it is.
But be warned that while Titanium has its strengths, it also has its weaknesses (ie; memory).
If you're working on a project for a client or are just starting your journey into mobile development, I would recommend learning how to code a native application. At least that gives you some options if you run into troubles. I've been burned a couple of times.
Titanium works with all android SDKs .You just have to make some changes to make it work with all SDKs. Titanium works with sdk 2.1 and below without any changes. But in order to make it work with 2.2 and above you have to add a symbolic link of adb file which is in
platform-tools(source) folder to tools(target).
Occasionally the platform-level support for a particular feature is different between the iOS and Android. For instance, the underlying audio support is significantly better on iOS; many features are simply missing on Android (we eventually patched them ourselves).
In addition, the way that the underlying platform's primitives are wrapped differs, so that code that is correct Javascript will result in incorrect Java on Android. An example we came across was related to the treatment of null and undefined when used with the Ti.App.Properties.setXXX functions. This issues are becoming fewer and farther between, as mentioned, but there are still issues not just related to UI.
I suggest you make a point of continuously developing and testing on both platforms; you'll find incompatibilities (mostly related to leaky abstractions) and their workarounds more easily that way.
Well it works great for the cross platform Execution.
The Only problem is that when user want to compare the iphone version & Android Version by developing same code.
iphone is excellent as per its gesture supports & fine UI works.While Android is still improving the terms.
So you should firstly check your terms and requirement then Go a head with Titanium. OtherWise
Appcelerator consistently working around all the native support as well as common features.
you need to find the possibilities in proposal for the Framework.it will be great approach & future perception as well.
This might sound like a stupid question, but google didn't help me.
Is there a JRE available for Android? If so which version is it? Are there any major features missing?
If not does that mean all java apps need to be recompiled for Dalvik to work on the Android?
Update; Will there ever be JRE available for the Android?
No, there is not. Google did create a completely different runtime for Android, where the base classes are completely different ( albeit compatible )
It uses Java as the language ( syntax ) but not the Java platform.
You can learn about the Android platform here.
From that page:
Android includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language.
Read in bold "most".
So, although they look similar, they are not the same.
The closest I've found is http://www.apogee.com/products/cjre-a
Unfortunately as stated on that page:
Note that Apogee temporarily suspended further development of CJREs+A
in June, 2012, because of insufficient demand for them. Please,
contact Apogee if you are interested in a CJRE+A targeted at a an
Android-running device of your choice for "volume" distribution to
your customers and/or other third parties.
...and a download/demo is nowhere to be found.
Taken from their products page http://www.apogee.com/products it does sound like it would have been a great thing to have:
CJRE+A - The “CJRE for Android” is suitable for devices running
Android v4.x or higher, which need to execute the Java SE 5 and SE 6
applications in addition to executing the Android applications.
We can still dream. I have not contacted them. I am aware of many companies that are looking for this functionality. I can't imagine it will dwindle all too fast (or let's say slower than flash)?
I have not reached out to Apogee, might be worth a try...If anyone ever finds a solution, please keep us updated! Thanks.