Availability of Playn support libraries and engines - playn

This slide in a recent playn presentation shows clearly the differentiation between playn Core API, and third party libs and engines. I wish to re-implement as little as possible, is there an obvious method to source these libs and engines that will combine with playn?
The playn-jbox2d.jar used in the showcase, I assume this a specific build of the java box 2d lib for playn? Will similar manual porting be required for other libraries or can e.g. Android libs be easily reused?

PlayN is a completely different API than Android, so you cannot use an Android game development library with PlayN. Higher level libraries are already being written for PlayN (for example, http://github.com/threerings/flashbang-playn), but since the platform is relatively new, not as many such libraries exist as for Android directly.

You have to realize that while you write in java that is used by all platforms, the method of how that java is compiled to the different platform is widely different (Android SDK for Android, GWT for html etc). If you have a library that uses only a subset of java that is supported on each compilation path for evey platform you should be able to use it out of the box but this is not very likely.

Related

Uno-Platform: OpenGL in cross platform app

Does anyone know if there is a way to embed an OpenGL view in an Uno-Platform app? I need it to work across iOS, macOS, Android and UWP. I have a lot of C# / Xamarin code I'd like to reuse.
There is no universal implementation of OpenGL for all platforms. Some does not support it at all...
Android: You may use the Android.Opengl namespace
iOS: You may use GLKit
macOS: You may use NSOpenGLView BUT IT IS DEPRECATED (Apple is suggestion to use MetalKit instead)
Wasm: You need to use WebGL, a subset of OpenGL.
Windows: A popular way is to use GTK3
Linux: A popular way is to use GTK3
Right now, the only universal API available for graphic rendering with Uno Platform is SKIA. I don't know if it suits your case, but here's a Uno sample running SKIA on multiple platforms: https://github.com/unoplatform/Uno.Samples/tree/master/UI/SkiaSharpTest

xmpp client library in qt5 for mobile cross platform programming

Can any one suggest me a QT5 cross mobile platform library and APIs of XMPP protocol to develop a mobile cross platform chat client. This is my college project.
I'm stoped for three month and searching for suitable library and now, Not started yet!!!.
I have a few time to present and speack.
I am disappoint now.
Just a QT5 based XMPP Liberary for mobile programming (Android , IOS and maybe etc)
Swiften ( http://swift.im/swiften/ ) is not Qt, but is plain old C++ with Boost, and is used in the Swift client, which is Qt. It's cross platform desktop, iOS, Android. Not quite what you asked for, but usable in that environment.
(Bias: I'm responsible for those projects)
QXmpp is quite nice for Qt development.
When using Qt, the advantages in comparison to gloox or Swiften are obviously:
No need to convert any types (like QString to std::string)
No different signals from different libraries (in case of Swiften: boost signals and Qt signals)
No additional dependencies, only Qt, so creating builds for all platforms is easier
Another point that can be positive (but in some cases might also be negative) is that QXmpp's classes are mostly monolithic.
This makes the whole architecture very simple and easy to use, but not always that nicely extensible. Extending from outside of the library is however possible.
QXmpp uses DOM trees to parse the XML elements. The serialization is done using an XML stream writer.
(like Kev I'm biased here: I'm responsible for QXmpp)

Qt Mobility or Qt Location available for desktop use?

I have been trying to implement a mapviewer application in Qt as a desktop applicaation to work with multi-touch. I'd been having some trouble when I came across mention of Qt Mobility. Qt Mobility seems to be an old module that was used on mobile devices but doesn't appear to be supported by Nokia anymore. Although there is a active repository.
From what I can gather from various more recent forum posts such as this is if we want to use Qt Mobility's Location features we need to wait for it to be released in newer versions of Qt.
If the Qt Mobility api is still available through the repository is it possible to use this for desktop applications or is it strictly for mobile devices? I am interested in making use of the Qt Location classes to help create a map viewer client.
The QtMobility API while deprecated is still being updated and is still available and according to a thread on the Qt Developers it should work with Qt 4.8 (it was only officially supported up until Qt 4.7). According to the documentation it can be used for desktop applications, but they are mostly tier 2 platforms.
While Qt Location won't be ready until Qt 5.2 (expected at the end of November), I wouldn't expect it to drop support for platforms that are already supported in QtMobility.

PlayN - Managing Common Code / Native Code

I am thinking about using PlayN to manage "common code" in Java and use PlayN to generate iOS, Android, and HTML native versions of the common code.
I figure I could then use the playn-generated native code and link with actual platform specific code (such as UI).
In other words,
Common Code libs in Java-> PlayN -> Native Commond Code Libs -> Link with Native App
Is the use of Play for the above workflow/pipeline appropriate? Any challenges?
Thank-you...
Firstly, you have to specify what you mean by "native" code for the different platforms.
On Android, your java files are specifically compiled/prepared for dalvik. So they are already "native" of a fashion, no work needed to be done here. If you want to get C/C++ native code for Android using the NDK, you're out of luck. PlayN doesn't do this and this is a hard problem (going from Java to C++)
If you take a look at the Maven modular layout of how PlayN is intended to be used, it isn't difficult to define a Factory interface in the common code and pass in a platform specific implementation for each module. It's no big deal to support Android specific functionality this way.
For the HTML version, you can use HTML libraries no problem using JNI, although really garnering specific functionality of the browser I'd imagined of limited value compared to what PlayN has already exposed. The one thing that is useful is text/keyboard input, although I'd recommend triplePlay https://github.com/threerings/tripleplay UI library as they've solved this, and it's an active project.
As for iOS, this might be more complicated as the iOS module is a bit of a hack where the compiled Java classes are run through an JVM runtime for .net (IKVM) and then uses the Monotouch tools to compile the whole thing to native code for iOS. See https://github.com/samskivert/ikvm-monotouch
So for iOS, you won't be able to bind the code to any form of native version, and what you have access to via the toolchain method depends very much on what Monotouch has catered for iOS (quite a lot I imagine), and also what IKVM-Monotouch has supported (I imagine the bare minimum to get PlayN working).
I'm not familiar enough with the Flash pipeline to give you an appraisal, although I think that it's quite flexible.
The above answer is written assuming your app is actually a game. If it is not and you intend to use the standard widget libraries for various platforms on mass, it should be possible. Choosing a good MVP framework would be good here, and depending on the assumptions it makes on different host environments will determine how easy the whole thing will be.
I'd recommend reading and comparing https://developers.google.com/web-toolkit/articles/mvp-architecture and perhaps look at questions like What is your favorite GWT MVP Framework?
...although a lot of these frameworks might be GWT specific and not really have catered to being reused on other platforms.

Qt for Symbian VS. Qt for MeeGo

What is the difference between Qt for Symbian and Qt for MeeGo? I know Qt is a cross-compiling platform. Does this mean that if I use a library from Qt the exact same library works on all devices which support Qt (e.g. Symbian, MeeGo)?
For example:
QtDesktopServices can launch a web browser. Despite the name 'Desktop' is confusing for mobile devices can I launch a web browser on every device which supports Qt? If I look at MeeGo, MeeGo is used for different kind of devices e.g. In-Vehicle, TV, media phone
Is it guaranteed that every device has a web browser on it? I don't think so and that's why I'm asking. If a browser is guaranteed, which browser is it? Which features does it have? I know there is WRT, but a user here stated that WRT has discontinued. So what now?
Do I have to choose between Qt 4.7 and Qt Mobility 1.0?
What leinir said - Qt Mobility is a module that implements common features for mobile devices. Qt's API is the same on all platforms, though there are some platform-specific functions (mainly dealing with low-level stuff).
While the API (the interface) is the same, the implementation of course may be different. I suggest looking at the Qt online documentation - the pages linked under "Platform-specific Development"
According to "Platform notes - Symbian", the Symbian port is not complete and lacks some features (e.g. OpenGL support is "planned for a future release", while printing probably never will be supported). I'm pretty sure that the MeeGo/Maemo version supports OpenGL ES, as I've seen a Qt-based application using it (Stellarium on a Nokia N900).
QtMobility is an extra module for Qt, which provides a bunch of extra functionality which is more esoteric than the other 13 or so Qt modules, but functionality which is really useful when you are building applications the way you suggest.
So no, you don't choose between Qt 4.7 and QtMobility 1.0, because you have to use Qt to be able to use the extra module QtMobility :)
The browser will always be whatever is set up as the default browser on the system. So, no, there is no guarantees - for Windows, for example, you might have people using Firefox, Chrome, Internet Explorer 6 and many others. This is the nature of platform integration, i'm afraid :)

Resources