Certainly, Java and HTML5 are safe bets.
For NaCl, the only browser missing currently is IE. I might be over-optimistic, but i believe we will see another AppStore-like gold rush with Chromium.
Hi all,
I have been away from Juce for a while. I checkout the latest code from the repository and saw quite a few Android related files. Are there any plans of supporting Juce on Android?
Yep.
Cool :D. How are you planning to get around Java.
JNI/NDK. It’s really not too difficult to make calls in and out of java classes.
[size=200]DROID DOES![/size]
+1
fantastic news ! - thx Jules
Might worth a new look, the NDK revision 5 includes full native support for application:
http://developer.android.com/sdk/ndk/index.html
[quote]Might worth a new look, the NDK revision 5 includes full native support for application:
http://developer.android.com/sdk/ndk/index.html[/quote]
Supporting the app wrapper actually isn’t a big deal at all, it’s actually really neat to just have a java class to kick it all off. The tricky bit which NDK5 still doesn’t provide is support for RTTI and exceptions, but the Crystax mods sort that out (until hopefully google get their act together and provide those things).
The only real showstopper I’ve hit so far is that there’s absolutely no way to run a modal loop - they’ve deliberately made it impossible, so I’m having to make some big changes to work around that.
Well, in fact it does!
From the release log document of version 5:
Provides a default C++ STL implementation (based on STLport) as a helper module. It can be used either as a static or shared library (details and usage examples are in sources/android/stlport/README). Prebuilt binaries for STLport (static or shared) and GNU libstdc++ (static only) are also provided if you choose to compile against those libraries instead of the default C++ STL implementation. C++ Exceptions and RTTI are not supported in the default STL implementation. For more information, see docs/CPLUSPLUS-SUPPORT.HTML.
I’ve seen this, and all those “Async” hack in the code.
I was wondering how does Google do their menu ? Seems to me that it “behave” like being modal, or am I missing something ?
I couldn’t get the R5 stuff to work, so I carried on using Crystax… I might have another look though.
You can still have modal components, you just can’t run a modal event loop. Luckily I’d already written a bunch of stuff for VSTs that provided async callbacks when a modal component finished, so I’m just making that more pervasive. TBH it’s probably a good idea anyway, modal loops are good for writing quick dialog boxes, but they’re not a very safe way to structure things.
ah yes, I remember now - if you read the “important caveat” in that c++ document, they explain that although you can turn on exceptions, you can’t use their STL with exceptions turned on. So all pretty useless, really.
Oh. I thought that this STL version “STLport” was the same one as the official STL on linux/gcc package. Once again, STL is not so standard at all.
wow Jules, you’ve been busy… This all looks very exciting. All we need now is a Viewport that supports “kinetic scrolling” or whatever the the technical term is for flick type list scrolling.
Yes, well once I’ve got the basics all running on iOS and Android, I’ll start thinking a bit more about making more mobile-friendly components that can do stuff like that.
(…and on a side-note, I’ve got it running without crystax now, so all happily compiling under the standard ndk-r5)
this will be an awesome feature.
Just saw this comment in the post… What would this actually involve? Would it be the sort of thing google is doing with GWT (Java->JavaScript)?
It’d involve some serious hackery! You’d have to compile the whole library using LLVM → bytecode → (html + javascript), and it’d need a new set of native classes to interact with javascript via embedded “asm” javascript commands. All very messy, difficult and inefficient, but an interesting idea!