Roadmap for Runtime SDK - Quartz and C++/QML interoperability

[MarcoGregorini]

@Hi Luke, after some interesting tests with MapQuickItem, I’m wondering what exactly Quartz will allow about the forthcoming QQuickItem MapView (you said “which will allow you to create your UI in QML, and write all of your business logic in C++” and “Quartz will officially support this pattern”). Will we be able to create the app in QtQuick, adding the map and all other features (such as geometry, graphic layers, feature layer, etc.) with the Runtime SDK QML API, handling them as objects with JavaScript (and C++ of course), and, if required, extract a C++ reference to the map that actually is a C++ object as defined in the Runtime SDK C++ API, and programming it using such API (and the other way round too)? And, if this is the case, will we be able to handle this way just the map object or other breed of objects too, such as GraphicsLayer, Graphic, Symbol, Geometry, and so on? This would allow passing object references smoothly between the two API (QtQuick and C++), which the current SDK doesn’t support (the release note says “Interoperability between identical object instances from both the C++ and QML APIs is not supported. For example, passing a Point geometry object from QML to C++ and performing geometry operations on that Point in C++ is not supported”). Stated another way, will Quartz allows exactly that, interoperability between identical object instances from both the C++ and QML APIs?

Thanks for the valuable support you are giving us in planning our project.

Marco

P.S. - I'm sorry I had to open a new discussion, since the system didn't allow me to reply to your last comment.

Hi Marco,

Glad to clear things up. You are very observant and resourceful! Our QML API at 10.2.6 was built directly on top of the C++ API, and so we needed to expose the MapQuickItem. This was supposed to be an internal class for our QML API build to pick up (which is why you don't find the header in the public SDK), but we accidentally included it in our doc build, so you see it there. This was not intentional, so if you are able to get something to work, I would say that is impressive, but we may not be able to assist you if problems arise. Quartz will officially support this pattern, and I think you will find it to be very easy and straight forward.

Thanks,

Luke

[LucasDanzinger · Accepted solution]

Our 10.2.6 release supported 2 paradigms:

1) Pure QML API, where you write everything in QML and JavaScript. If using this paradigm, you could not easily write business logic in C++ against the ArcGIS Runtime API.

2) Pure C++ API, where you use Qt Widgets and our C++ API- no QML.

Our Quartz release will still support those two paradigms, but it will support a 3rd paradigm, which we unofficially refer to as the hybrid approach. This allows you to exclusively use our C++ API, but still have a MapView in QML. You won't be using our QML API, so you won't be creating graphics, adding layers, and running tasks from QML. Rather, you will do this all on the C++ side. This means you won't necessarily be passing references back and forth. In your example, you wouldn't create a Point from the QML side, and pass that over to C++ to do something. Rather, you would just create the Point in C++ only. You will be able to hook into all of the same signals that you would have from QML side, but in C++ instead. So instead of listening for a mouse click on a map in QML, then passing that point to C++, you would just set up your slot for that mouse click on the C++ side. Any Runtime object you need to pass back to QML can be done so through creating a Q_PROPERTY or Q_INVOKABLE function, and registering the type with QML.

What it boils down to is the QML API is really designed for people that only want to write in QML and JavaScript- no C++. If you use our C++ API, you can do Widgets or Qt Quick, and you have much more flexibility to register your types, and pass them back and forth. Hope that helps.

-Luke