In theory, Dalvik executes any virtual machine byte code, created for example with the compilers of
AspectJ
ColdFusion
Clojure
Groovy
JavaFX Script
JRuby
Jython
Rhino
Scala
Are there already working versions of bytecode compilers for Dalvik available for other languages than Java?
At launch, Java was the only officially supported programming language for building distributable third-party Android software.
Android Native Development Kit (Android NDK) which will allow developers to build Android software components with C and C++.
In addition to delivering support for native code, Google is also extending Android to support popular dynamic scripting languages. Earlier this month, Google launched the Android Scripting Environment (ASE) which allows third-party developers to build simple Android applications with perl, JRuby, Python, LUA and BeanShell. For having idea and usage of ASE, refer this Example link.
Scala is also supported. For having examples of Scala, refer these Example link-1 , Example link-2 , Example link-3 .
Just now i have referred one Article Here in which i found some useful information as follows:
programming language is Java but bridges from other languages exist (C# .net - Mono, etc).
can run script languages like LUA, Perl, Python, BeanShell, etc.
I have read 2nd article at Google Releases 'Simple' Android Programming Language . For example of this, refer this .
Just now (2 Aug 2010) i have read an article which describes regarding "Frink Programming language and Calculating Tool for Android", refer this links Link-1 , Link-2
On 4-Aug-2010, i have found Regarding RenderScript. Basically, It is said to be a C-like language for high performance graphics programming, which helps you easily write efficient Visual effects and animations in your Android Applications. Its not released yet as it isn't finished.
Scala works very well.
I'm programming my Android application projects in Scala (Website written in Chinese with some screenshot, source code # GitHub), and it is pretty easy to setup the evnviroment (without IDE, using SBT as build tool).
It could access every API in Android SDK, so anything you could do in Java, you could do it in Scala too.
You may check this blog entry to see how to build Android application with Scala and SBT.
Kawa is a lovely but little known variant of Scheme that has existed quietly for many years and runs on both the JVM and Dalvik, natively. Therefore, its output includes no extra VM and only includes explicitly imported libraries. To the end-programmer, this means Kawa's performance and executable size are nearly identical to standard Java (ProGuard not required).
Kawa also includes lots of macros (including some specific to Android APIs) that make for a nice clean syntax (assuming one is not averse to parentheses), and adds some tasty goodies on top of Scheme, like "promises" (lazy eval and futures in one). The language is quite robust and well-documented, and has been actively maintained and evolving since the early days of Java.
The Java Advent Calendar summarizes Kawa's merits with some informative examples and links.
I haven't played with it but I know that Scala works.
http://www.scala-lang.org/node/160
Another JVM language that works on Android is Kotlin with Anko, both from Jetbrains.
Mercury also works on Android, using its Java backend. I've written a simple app that should help someone get started (there are still few other examples), and mercury-android-helper also for this purpose (although at this exact moment, it's short a few commits. And neither are using ProGuard yet, so the .apk size is shocking.)
Although the other posts here are cheerful about Scala-on-Android, posters in Scala forums are more concerned by Scala's ability to blow through some of Dalvik's limitations, and people who do use it say they reserve it for non-production code. (Some discussion about Scala's problems here.)
I can't say yet if Mercury has its own problems with Dalvik, but I've switched to it from Scala for the time being.
The dynamically typed languages wont be possible until Dalvik supports JIT (Just In Time) compiling. I believe there is JIT support in one of the experimental Eclair branches, but it is not yet officially available/supported in Android.
1) Angular + nativeScript
2) Reactnative
Related
I read a lot about Dalvik and Google's Android OS when it first came out. One of the things that I don't quite understand though is why Java is used. The way I understand it is this:
Java code -> Java bytecode -> Dalvik bytecode
What I don't understand is why I have yet to see anything compile to straight Dalvik code or any other front end than Java for the Dalvik VM. Is there any work being done on a straight compiler or way to work with Android without Java?
To clarify I'm looking for languages that do not compile to Java bytecode. And also I'm not concerned with dynamic languages, I've read a few questions about them already. And also I'm aware of the NDK, I'm looking for information about Dalvik-compiled languages, not actual native-compiled languages.
There is also a possiblity to write native Android applications running directly on the operating system (which is a variation of *nix). The recommended way for that is to use the Android NDK:
http://developer.android.com/sdk/ndk/index.html
There is also more "hacky" way to do that: use ARM C/C++ compiler and just write your applications like any ordinary *nix program. This fits mostly for background services without GUI, though.
What I don't understand is why I have yet to see anything compile to straight Dalvik code or any other front end than Java for the Dalvik VM.
The reason for this is basically that there is no need for a "direct-to-Dalvik" compiler, since, as you correctly point out, the existing compile chain goes via bytecode anyway.
The only reason to go directly to dalvik, would be if the language in some sense could take advantage of dex-features that's not in the bytecode. However, dex and java bytecode are extremely similar. Main difference is probably that Dalvik is register based while the JVM is stack based. Other than that, the instruction set is strikingly similar.
As you probably realized already, you can use any language that is based on the JVM, that is, that compiles to java bytecode.
Some examples:
Scala on Android tutorial
Clojure and Android with Emacs on Ubuntu
MonoDroid is a beta project that converts C#.NET code to Dalvik.
It's not quite finished, but it will open some possibilities for people that know C#, but no Java.
Everyone uses Java because that's what Android development officially supports and it's what the Android SDK is based around developing in. However, they also offer the NDK (Native Development Kit) which allows you to develop in C/C++.
See their original announcement for it here: http://android-developers.blogspot.com/2009/06/introducing-android-15-ndk-release-1.html
After doing the whole "enterprise" programming for a while, I'm seriously disillusioned by the language itself and always feel quite hampered if I have to go back to it. The project size of your average Android app isn't too intimidating and the libraries are actually quite nice regarding their coding style, but if I could avoid Java, I'd certainly do.
So that's the question: Can I avoid it? While there are lots of JVM language that would be an option on desktops and servers, the Dalvik VM and the devices themselves pose some limits. This seems to be a bit better in 2.2 with the JIT, but limiting myself to the cutting edge would be a rather harsh decision.
The only alternative I know that's used somewhat seems to be Scala. Is there some possibility I'm missing? Clojure seems to run in exactly the problems I've illustrated above with Dalvik, but as the AppInventor is built on Kawa there might be hope for a Lisp on the mobile platform?
What other languages are already usable or make strides towards that?
Personally, I'd say Scala is your best bet right now. It works really well, with the one drawback being that you are required to include Scala as a dependency (which will increase the size of your application).
Scala Programming for Android
Can I program for Android using any JVM language?
Getting Started Programming in Dynamic Languages in Android
Have you looked at Mirah? It gives you a Ruby-like syntax and compiles to Java. It’s been labeled the CoffeeScript of Java.
This link has some details on how to get scala apps working on android. I'm sure you can do something similar for clojure or other jvm languages.
Ruboto is aiming to bring JRuby in.
Xamarin Studio let's you build in C#/Mono and build apps for both Android and iOS. Now the presentation layers have to be implemented differently on both platforms, but for the ability to use C#, it's a big Win.
DroidScript is probably one of the easiest of the above mentioned development tools to use for Android development. Like Cordova you use JavaScript, but unlike Cordova you have the choice of using native Android GUI's or HTML5 to build your App interfaces.
Also you still have access to all the devices sensors/hardware without needing to import loads of complicated plugins. Plus you get the bonus of being able to develop actually on your mobile device if you need to (you can even build APK's and publish them from your device).
I would say its very good for beginners or prototyping but perhaps not flexible enough for seasoned developers.
I have never used it, but Kotlin is a new language that runs on the JVM developed by JetBrains (the maker of Android Studio) that deserves a mention. The Kotlin website claims the language is 100% interoperable with Java and has a tutorial for Getting started with Android and Kotlin and Android Studio now actually comes with Kotlin support.
You can build an android app with the knowledge of just Html/css/Js. So there is no need of Java to create an android applications. Visit here for some basic knowledge. [1]http://www.chromeearth.com/requirements-cordova-platform/
Edit: My bad, I meant objective-c, not c#. Some reason I got it into my head it was c# the iphone used. So the answers for c# were great, thanks, but theyre a bit irrelevant, sorry about that.
I've had a look but can't find anything that answers this, though a few have shortened the question by answering parts of it. Between a small group, we were planning on doing some work on iPhone and Android, the 2 seperate for the most part but helping each other out, and with some guys doing graphics work split between them.
But we were thinking about the possibilities of moving things between the two, not necessarily apps, maybe just useful classes or something. Looking at objective-c and Java, they seem to have about the same features that the biggest obstacle would be system interface stuff, so we were wondering whether, if we created an abstraction over these on each system so they could be given the same input (which unless I'm wrong wouldn't put too much strain on the system?), would there be any problems in writing something to convert between objective-c and Java, worse than the locations of methods in the sdks? Or are there key features or something in one language that the other doesn't have which we've missed that would mean the only way to do it would be rewriting from scratch.
I wouldn't waste time trying to find commonality between iOS and Android.
Cross-platform is almost always a waste of time and resources unless the cross-platform capability is central to the apps functioning. That is especially true for platforms such as iPhone and Android which have custom OS and work very tightly with the hardware.
Cross-platform development environments add rather than reduce complexity long term. Yeah, it sounds neat but usually you get 90% what you want easily and then you hit a roadblock that destroys all the savings you made and then starts putting you in the hole. There are simply to many compromises and square pegs jammed into round holes.
Unless your app could in theory work from a generic web page, cross-platform is not for you.
In the specific case of Objective-C and Java, although Java is descended from Objective-C they have no modern interoperability. You can't use code from one on the other.
You should spend the time to learn each platform's specific API. There are no shortcuts.
Tools like XMLVM, Codename One and iSpectrum tell us that you can actually cross-compile Java code (from an Android app or creating one from scratch) to Objective-C code that is running on an iPhone without having to install any virtual machine on the Apple side of things.
I suggest watching Developing iPhone Applications using Java
Unfortunately Apple's license
agreement for the iPhone SDK prohibits
the porting of the Java virtual
machine to the iPhone. In this
presentation we introduce an Open
Source Java-to-Objective-C
cross-compiler as well as a Java-based
implementation of the Cocoa library.
With the help of these tools, iPhone
applications can be written in pure
Java. Using the Java version of Cocoa,
it is possible to run a Java-based
iPhone application as a Java
desktop/applet application that can be
cross-compiled to run natively on the
iPhone. The talk will discuss the
challenges of the Java-to-Objective-C
cross-compiler as well as the
Java-based version of Cocoa. Details
are available at http://www.xmlvm.org/
and for more insight a more recent talk about Cross-Compiling Android applications to the iPhone from Frebruary 2010 is available here, which is documented at http://www.xmlvm.org/android/ :
Android is an Open Source platform for mobile devices. Initiated by Google, Android has received much attention. Android applications are developed using Java, although a special compiler converts class files to a proprietary, register-based virtual machine that is used on Android devices to execute applications. Android defines its own API for writing mobile applications. With the help of XMLVM it is possible to cross-compile Java-based Android applications to native iPhone applications.
The Android application is written in
Java and makes use of an Android
specific API. XMLVM offers a
compatibility library, written in
Java, that offers the same API as
Android, but only makes use of the
Java-based API for Cocoa Touch. During
the cross-compilation process, both
the application and the Android
compatibility library are
cross-compiled from Java to
Objective-C and linked with the Cocoa
Touch compatibility library to yield a
native iPhone application.
From the 2008 talk about building Java applications for the iPhone http://www.xmlvm.org/iphone/ :
Apple's iPhone has generated huge
interest amongst users and developers
alike. Like MacOS X, the iPhone
development environment is based on
Objective-C as the development
language and Cocoa for the GUI
library. The iPhone SDK license
agreement does not permit the
development of a virtual machine.
Using XMLVM, we circumvent this
problem by cross-compiling Java to the
iPhone. Just like a Java application
can be cross-compiled to AJAX, XMLVM
can be used to cross-compile a Java
application to Objective-C. The
cross-compilation is also accomplished
by mimicking a stack-based machine in
Objective-C.
If you focus on abstracting away things like system interactions, and stick to the common subset of the languages, you can probably build classes that would require little or no modification to move from one language to the other.
C# does have a better implementation of generics than Java, in that C#'s generics retain strong typing at run-time.
C# also has LINQ, which as far as I know has no equivalent (yet) in Java. LINQ provides a SQL-like query capability, built into the language and fully supported by the .NET frameowrk, that lets you query object collections, and does so in a very functional-language style. LINQ can be extended by query providers to work with other data formats, such as XML and SQL, once the query provider provides an object model that translates to the other format. LINQ also makes parallelization very easy for multi-core work. It's a huge extension to language capability.
This topic is often filled with the dogma of technology jihadis, so I shall try and steer clear of that in my answer.
In my experience, I would largely agree with people saying that trying to share code between the two platforms would be difficult. However, there are some important exceptions:
I would consider cross-platform development where your business logic:
is non-trivial;
should be standardized across platforms; and
has well defined interactions with the outside world (e.g. network stack or UI).
(bonus) is written already.
Apple is the rate determining step here, given the now infamous 3.3.1 restrictions on source code languages. You can write code in Javascript according to the bundled Webkit, C, C++ and Objective C.
If you don't want to install extra languages on a 'droid, you can use the Java that compiles down to dalvik code, the Javascript as per the slightly different build of webkit or something from the NDK. Then you'll be looking at C/C++. You could cross-compile Objective-C, but I haven't had any experience of that.
The clean separation of business logic from UI and networking is important, as you'll be looking to write adapters for the networking layer, something else for the UI.
I would not attempt to write cross platform UI code in C/C++, and would either write something that used HTML/CSS/JS, or more likely write something completely custom to take advantage of the different UI metaphors on each platforms - e.g. there is no analogue to the notification bar on the iPhone. Animation on the iPhone is orders of magnitude simpler to implement than on Android.
If you don't need the UI to be massively integrated with the OS, then a webview and some HTML5 may be sufficient. Titanium is a good option here, and my colleagues in the know tell me it is better (i.e. compiles, not interpreted) than PhoneGap. Again I don't know.
Going the other way in complexity, Open GLES is available on both platforms.
It should also be noted that SVG is not available on the current crop of Android OSes.
If you actually want to do cross phone development, as long as it is not something really computationally expensive, I would probably go with PhoneGap.
PhoneGap is an open source development framework for building cross-platform mobile apps. Build apps in HTML and JavaScript and still take advantage of core features in iPhone/iTouch, iPad, Google Android, Palm, Symbian and Blackberry SDKs.
As far as I can tell, it's pretty much the only cross platform toolkit that is allowed in the iPhone app store.
If you're dead set on native development, I think you'll find that unless you're making a game and targeting c, it will be a lot of work to port. The frameworks are very different and the way of building UI is very different. That said, to answer you're direct question of objective-c vs. java, it's not that bad. It is different enough, though, that an abstraction tool would not be that easy - not like Java vs C#. Objective-c does not have garbage collection (on the iPhone anyway), for example, and the syntax is very different. Objective-c is more loosely typed in the way that it does method calls (messages in objective-c). That said, they aren't wildly different in terms of programming paradigms. They are both object oriented imperative languages. They both have classes and methods, public and private. If you wanted to port the code by hand, it wouldn't be the end of the world, I just think you might wind up spending a lot more time trying to build an abstraction layer.
If you're thinking about doing Android development my best advice is to go for java. There is no benefit at all of writing a complete abstraction (assuming you can) layer to convert from C# to Java. As for the IPhone development dont doubt about using Objective-C for the same purpose.
You can't develop for the iPhone in the same language as for Android. For the iPhone, you can only program in Objective C, it's developed by Apple. You can't use it for android, and the only way to do iPhone development is with that language (it's in the user agreement).
As for C# vs. Java, the whole principle is different. Java is one language for every platform, .Net is one platform for every language. They are not compatible. You can use Java on Android, but I'm not sure if you can use C# (.Net) as well.
Anyway, you'll have to build two different apps for these two mobile operating systems.
Is there any way to manage/debug/compile Java projects in Visual Studio 2010?
Before you answer, please read this topic.
I'm a little late to the party, but it looks like someone has started adding support. From the description, right now it only does syntax highlighting and basic navigation within a single file. However, in the Q&A section the author mentions plans to add compilation and debugging support later in the year.
The short answer - No.
The long answer - No, because the supposed intellisense support for Java that the blog entry referred to, in the question, relies on J# support. I believe it has been quite sometime since Microsoft has discontinued J# - VS2008 does not have it.
In the long run, you're better off learning how to use Eclipse/Netbeans/IntelliJ IDEA or any other IDE for the purpose of managing Java projects.
Sure. Visual Studio works with any language so long as someone takes the time to write the plug-ins for it. Heck, Mainsoft has already added JVM debugging support to Visual Studio. They just don't support the language.
The only problem is YOU are going to have to be the one who writes it.
I won't lie to you. It won't be easy and fan-boys on both sides will hate you for it. But if you pull it off I can at least offer you some money to write about how you did it.
No, although, I long for the day when VS might possibly support building Java applications. I don't think I have yet found an IDE as fully featured. Personally, if VS supported Java development, then I would trash my installation of Eclipse and Netbeans. ... so tired of wonky Java IDEs....
Cyberduck is written in Java and developed in Visual Studio 2010, though it requires IKVM, an implementation of Java for Mono and the Microsoft .NET Framework. Here are the build instructions.
C++ syntax highlighting looks pretty good for Java. Turn this on in Options->Text Editor->File Extension.
Extension: java
Editor: Microsoft Visual C++
Now reopen a .java file and see pretty colors.
I will advise to go for Eclipse, if you have to do at least 25% Java coding. Otherwise VS is good as well. But I like Eclipse for C++ as well as Java.
A new plugin is currently being developed named IntegraStudio,
aiming at full Java development under VS. It currently supports:
IntelliSense for Java (comparable to standard C++ IntelliSense in VS)
build with Ant or Maven
direct Ant / Maven project view in Solution Explorer
Java debugger with container visualization
support for VS browsing features (Class View, Code definition, etc.)
Class View works also for classes in JARs (including standard library)
browsing Maven repositories
JDK: 1.6 - 1.8
It uses standard JDK tools and targets the real Java platform (it
is not a .NET platform solution, as VJ# was).
At the moment of writing this, the IntegraStudio plugin is beta.
It does not yet contain advanced Eclipse features, however many
of them are in current roadmap (e.g. code refactorings and quick fixes).
You can find it on Visual Studio gallery:
http://visualstudiogallery.msdn.microsoft.com/588fb167-d18c-4e61-8aeb-30baeddb00da
The product official website is:
http://www.softerg.com/integra
Current docs (with large number of screenshots):
http://www.softerg.com/integra/docs/pages/is_intro.htm
I was looking for a Desktop Application Programming Language with one of the biggest constraint: - “I need to output as native executable”.
I explored multiple options:
Java is not a very good option for desktop programming, but still you can use it. But Java to Exe is a problem. Only GCJ and Excelsior-Jet provides this.
.Net platform does not support native compilation. Only very few expensive tools are available which can do the job.
Python is not an option for native compilation. Right?
VB6 is the option I am left with.
From the above list, if I am correct, VB6 is the only and probably the best option I have.
But VB6 itself has issues like:
It is no more under development since
There are questions on support of VB6 IDE with Vista
Thus my questions are:
From the list of programming language options, do you want to add any more?
If VB6 is good/best option, looking at its development status, would you suggest using VB6 in this era?
Delphi (and its underlying Pascal language) is still alive and well, with the 2010 edition recently released; if you have funding (a minimum of $899 for the cheapest edition, I believe). it may be worth your time to download a try a free-for-30-days (or something like that) version.
Out of curiosity, what are the driving factors behind the "native-binary-only" constraint?
As others have said, it's essentially impossible to prevent reverse engineering. (I realize the answer I linked to is in the context of .Net, but it applies to all programs.)
You added a comment saying it is because .NET and java can be decompiled that you don't want to use them. You could use an obfuscator which makes the output code harder to read.
Visual C++ is an option, though unfortunately the free version is a bit crippled from the point of view of building MFC-based applications.
You can also choose to use a different GUI framework than MFC, such as wxWidgets or Qt. With these frameworks a GCC compiler (such as MinGW) can be used. There are several free IDEs that are supposed to work with one or both of those frames works including Qt Creator or Code::Blocks.
I've heard good things about Delphi, but don't know anything else about it.
I was involved in a hunt for a similar language/platform for a client to replace their VB6 application. Although they eventually decided to webify everything and rewrite it all in Flex, they were briefly looking at RealBasic. VB6-esque syntax and it compiles to native binaries.
I can't speak for what it's like for day to day use; the trial looked ok. A bit of the RAD oh-that-didn't-take-long workflow that VB6 had and very little else has got anywhere near. Not unreasonably expensive for the Personal Edition.
Check out 'Power Basic' - It compiles 'true' small native EXEs and provides a fast VB like basic environment, and doesn't require a run-time environment. This makes it much harder to disassemble. It isn't VB, but its affordable and powerful.
VB is an interpreted language not native although I guess there are native compilers. Also it's runtime support is not guaranteed past windows 7. The IDE and runtime have a few issues in windows vista and 7 mainly related to UAC and network drives.
I would suggest delphi or some c variant if it must be native.