It would be a shame if it doesn't, because it will make for more attractive looking Android applications.
Not right now, and it would be a nontrivial task to make it work. Android doesn't have all the libraries that the typical desktop JRE does. Although since Android is open source and it will run anything that can be compiled to Dalvik byte code, it's not impossible.
Really, I don't really think JavaFX will make for more attractive looking Android applications - the most important thing is how integrated the application is into the hardware and the Android display framework has a lot of stuff to make that easier.
JavaFX 2.0 is now a library. The implementations are platform specific because, amongst others, of the use of hardware accelerated graphics. There's a version for Windows (that uses DirectX) and a developer preview for Linux and Mac (which uses OpenGL) : oracle
Because of the heavy use of hardware acceleration, I guess if there will be an android version (very likely), the target will be relatively new tables, rather then all android devices.
Perhaps it's not so important the attractiveness. I think portability matters a lot nowadays, and this kind of tech makes it very portable.
Please go through below link : openjdk , oracle
Related
We have a working OpenGL project made for PC (works on MacOS and Linux under Wine as well) which we want to try to cross-compile to tablets. Delphi XE2/XE4 offers iOS support, but there's no Android yet and judging from iOS implementation history it might take 1-2 years. Now we start looking into other possibilities which will allow us to keep the majority of Pascal codebase (80k lines). So here's the question for the Oxygene:
Are there any examples of OpenGL applications made with Oxygene that can be cross-compiled to work on PC/MacOS/iOS/Android ?
If not, what alternatives are there (except Lazarus)?
AFAIK there is none.
Even the low-level Sugar cross-platform RTL is not finished. It would be a first mandatory step to be done before accessing higher level libraries in a cross-platform way (i.e. with identical source code), like OpenGL.
So with Oxygene, you have a great cross-compiler, but you are tied to use the RTL available on each platform.
You can compare with two object-pascal compilers:
With FreePascal, which has built-in OpenGL units, and already several libraries over it - one of the most powerful/known is GLScene;
With SmartMobileStudio, which has built-in WebGL support and can do amazing things on modern browsers - WebGL is a translation of the OpenGL API/concepts in HTML5.
Oxygene doesn't attempt to be source compatible with Delphi. What's more the runtime libraries used by the various Oxygene flavours differ entirely from those used by Delphi. So you won't find any serious libraries that have single source that can compile on Oxygene and Delphi.
The way that RemObjects have developed Oxygene on different platforms is quite interesting and radically different from the approach taken by Embarcadero with Delphi.
With Delphi the goal is that you can single source development for all the platforms. That is made possible by the FireMonkey framework which presents a common interface to all platforms. Obviously you need to vary some elements of an app to account for device differences.
With Oxygene, each platform is targetted separately. So for Windows, the runtime is .net. For Java it is the JVM and for Apple platforms you target Cocoa.
All this means that you cannot expect to write a GUI app in Oxygene and have it work on multiple platforms.
So not only can you single source your app between Delphi and Oxygene, you cannot readily single source multiple Oxygene targets.
Now, you can probably port to Oxygene or FPC without too much trouble. But maintaining single source is liable to mean a lot more effort. Whether that's worth the effort is debateable. In the long run you'll want a codebase in one of Delphi, FPC, Oxygene, or even something radically different. But you won't want your code spread out over multiple languages.
You can write or own OpenGL layer in Oxygene with the usage of mapped types like it is used in the sugar open source project.
It sounds pretty cool. In your code you have just to use one class which is during compiling direktly mapped to the underlying platform class method, without an overhead of that layer.
IMHO, when Oxygene is growing, we will then find a lot of such "suger" layers and write once compile anywhere will come closer :)
Edit:
Using OpenGL with .Net
OpenGL Java Tuturial
I've been working on a game engine runtime environment in C++ for my future games, and have started to consider android as a platform. I noticed that it was tightly bound to Java and uses Java VMs heavily.
But is it possible to sustain a full C++ runtime environment in Android NDK? I have nothing against Java and am prepared to use it if I have to, but performance is one of my prime concerns (I intend for my games to be resource-intensive), especially on phones.
And if a full C++ environment is possible, how exactly would I implement it in Eclipse Indigo CDT? Would I be able to create a compiled game executable for Android ahead of time for maximum performance? And would there be any additional plugins I'd need to install in Eclipse? Could I use MinGW for compiling my games, or would I need to use a different compiler? If I had to use Java in one way or another, would compilation of the C++ code even be required? These are all questions I'd like to answer to get a sturdy development environment going in the Eclipse IDE.
Please know that I'm still fairly new to Android development, and multiplatform programming in general. My goal is to create a game engine that'll take the most advantage of the new hardware out there, especially on phones!
Thanks for any advice you guys can give!
NativeActivity, added in Android 2.3 (API 9) might be what you're looking for in terms of writing Android games using only C++. http://developer.android.com/reference/android/app/NativeActivity.html
However since you say you're new to this you may want to start with one of the currently available Android game engines instead of writing your own right away. Mobile devices have a very different set of constraints than other platforms. A phone isn't very useful if the battery dies mid-afternoon, so starting a project with the stated goal of being "resource-intensive" is already getting off to a bad start. Few people will want to play your games for 20 minutes here and there if it means they won't be able to make a phone call in the evening.
If what you meant is that you are shooting for high-end graphics, keep in mind that devices have a wide range of capability in this area and targeting only the high end limits your audience. Different GPUs have very different strategies and performance characteristics and all have cases where they shine or lag behind. The most successful mobile games aren't the ones with the highest polycounts or the most complex lighting shaders, they're the games that achieve a consistently smooth framerate and have a distinctive style.
Have a look at some of the existing game engines for Android and try them out. Write a couple small games to take them for a test drive and see where they do and don't mesh with what you're trying to do. If you find yourself feeling limited with what's available, take what you've learned and try to write your own engine that fits with the types of games you want to make.
Here are some links to get you started. These engines power some very popular games on Android Market and many developers have found them useful:
http://www.andengine.org/ andengine is written in Java and is open source.
http://unity3d.com/ Unity is based on C# and Mono.
http://www.madewithmarmalade.com/ Marmalade, formerly Airplay SDK is based on C++.
The answer you want to pay close attention to is #adamp's. Ignore his answer at your own peril.
To address a couple of other points in your question, though:
Would I be able to create a compiled game executable for Android ahead of time for maximum performance?
No, insofar as Android does not use "compiled game executables". Your C/C++ code will be compiled into a Linux shared object (.so) file and packaged with other stuff (like your manifest) in an APK file. Compiling the .so will be ahead of time, though.
Could I use MinGW for compiling my games would I need to use a different compiler?
I get the distinct impression that you will claw your eyes out trying to do NDK development in Cygwin on Windows. I heartily encourage you to do your NDK development on OS X or Linux. At least set up a VirtualBox with Ubuntu or something in it to do your NDK compiles.
Regardless, the NDK comes with its own GCC compiler. AFAIK, MinGW is not a cross-compiler, and most Android devices are not running on x86 CPUs.
If I had to use Java in one way or another, would compilation of the C++ code even be required?
Yes. Now, for Honeycomb, you have the option of using Renderscript for OpenGL work -- that amounts to a C99 environment whose code you will not need to compile with the NDK.
I've tried a bunch of them, and one of the best I found that cross compiles instantly to a bunch of other devices and let's you program your goodies in HTML5/C++ combo (sweeeeet) is MoSync (http://www.mosync.com/) and another little known one that is a little more setup friendly is MotoDev by Motorola (http://developer.motorola.com/tools/motodevstudio/?utm_campaign=mhp01092012&utm_source=mhp&utm_medium=mws)
I've noticed there is some virtual machine images and tutorials you can use to prevent the setting up hassle.
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'd like to start creating Android apps but I don't like Java. I read that scala can be used to do it. Are there another option?(Clojure?)
I'm a Python/Django developer so it would be great to learn a pretty different language.
At this point Scala is the one that is most mature..I wanted to try groovy myself but its not even out of alpha..
Plus Scala on android has docs..:)
It's not hard to do with Mirah (formerly Duby), a very young language based on Ruby that compiles to bytecode that's basically indistinguishable from Java's, but adds some great new features like closures, type inference, and obviously a Ruby-like syntax. It's particularly well-suited for Android because it has no runtime or standard library (it uses compiler plugins instead) outside the JDK, whereas basically all other JVM languages bring along a lot of baggage, especially languages that weren't designed to target the JVM (like Ruby and Python).
http://github.com/technomancy/Garrett
Much nicer than writing Java!
for clojure development a useful tutorial: http://riddell.us/ClojureAndAndroidWithEmacsOnUbuntu.html
Clojure gets a LOT of benefit from android-2.2's JIT compiler and has not really been widely adopted on previous versions.
Appcelerator Titanium is an awesome environment for using web-ish skills (like HTML, CSS, and JavaScript) to build native apps for Android (and iPhone, and desktops, etc.). For example, the gang at Intridea have made several popular Android & iPhone apps with Titanium Mobile, including the OilReporter app that has been used for gathering data on the extent of the Gulf oil spill.
If you use Python, maybe SL4A (Scripting Layer for Android) is a good choice.
You could write python script that runs on Android and use Android API, but it also has a drawback that you need install Python/SL4A runtime library on your Android device.
In addition to the other solutions listed here previously, you have:
PhoneGap
Rhodes
AIR (pre-release)
AppInventor
Clojure
Another immature implementation is JRuby/Ruboto: http://blog.danieljackoway.com/first-ruboto-release.html
I want to learn a new programming language and develop for the Android platform.
I'm a fulltime C# / F# - developer and I also use C# in the most functional way possible (because I like this paradigm far better than the old skool style "lets iterate and describe to the barkeeper how to make the cocktail", to quote Microsoft).
However, I have a strong dislike for Java, because in my opinion it is outdated and, hm, a dinosaur - it lacks exactly the features I like best about C# and F#.
On the other hand, developing for the Android platform requires JDK use.
So, would you recommend Scala? Or is the JDK stuff not for me at all?
Scala rocks exactly as you'd expect that a functional language built on the JVM might. The only downside compared to C# for me (I haven't used F#) is that the IDEs haven't quite got the refactoring down yet. It isn't bad. I'm using IntelliJ's plugin for Scala; that seems to work well enough.
Of course, the main benefit you get from Scala is being able to leverage all the many Java libraries out there, since they work (mostly) interchangeably. That might not be important for the Android platform where your apps will be small and stand-alone, but for commercial development it means that Scala is already a serious Enterprise language. Learning Scala will therefore give you more job opportunities in the future. I would definitely recommend Scala.
One of my large financial clients is using it as their server-side language and it works beautifully. There are a few interesting clashes between eg: Scala and Java lists, Scala and Java booleans, all well-documented, but otherwise it's smooth.
Good luck!
An alternative to using Scala might be the upcoming MonoDroid, a port of the Mono runtime to android. Unfortunately it isn't completed yet, and will cost something like 400$.
I'd recommend looking into scala if you develop a new application for android and only use monodroid if you want to create a port of an existing .net application.