Solved! Go to Solution.
It really depends on the application. QML is pretty powerful, but there are definitely some limitations if you are comparing to C++.
The first area of limitation to consider would probably be performance. For example, if you perform a query and get an iterator or list of feature objects in QML, and need to iterate through the list in QML/JS, that will be faster in C++. Additionally, you can spin up additional threads for performing background tasks like this in C++, but JavaScript code is all executed in the main UI thread. QML/JS does have the WorkerScript type, which executes a block of code in another thread, but this only handles built in data types, so any types from Runtime or that you create on your own cannot be passed over to the WorkerScript, so it is a bit limiting. With that said, much of the rendering performance should be about the same between both APIs. The performance hits are typically going to come from the client application code, especially when there is lots of imperative code. Your goal when writing QML code should always to be as declarative as possible and to write as little imperative code as possible. That is where you will get optimal performance.
The second area of limitation is probably in extensibility. Qt itself is written in C++, so once you want to do something that is not available in QML, you will likely need to do this in C++. In fact, that is how we expose QML objects from ArcGIS Runtime - we write them all in C++ and you consume in QML. With that said, lots of things are available to you in QML, so depending on what you are doing, you might not need to write any C++ code.
Basically, there is no easy answer. If your application is relatively simple, QML is just fine. If it is extremely complex, it might be better suited in C++ (but not necessarily). One final thought is that it isn't all or nothing. Probably the most preferred way to write your Qt app is to use QML exclusively for your UI and C++ for your backend code. The different options are discussed a bit more here - https://developers.arcgis.com/qt/latest/cpp/guide/qt-sdk-best-practices.htm
It really depends on the application. QML is pretty powerful, but there are definitely some limitations if you are comparing to C++.
The first area of limitation to consider would probably be performance. For example, if you perform a query and get an iterator or list of feature objects in QML, and need to iterate through the list in QML/JS, that will be faster in C++. Additionally, you can spin up additional threads for performing background tasks like this in C++, but JavaScript code is all executed in the main UI thread. QML/JS does have the WorkerScript type, which executes a block of code in another thread, but this only handles built in data types, so any types from Runtime or that you create on your own cannot be passed over to the WorkerScript, so it is a bit limiting. With that said, much of the rendering performance should be about the same between both APIs. The performance hits are typically going to come from the client application code, especially when there is lots of imperative code. Your goal when writing QML code should always to be as declarative as possible and to write as little imperative code as possible. That is where you will get optimal performance.
The second area of limitation is probably in extensibility. Qt itself is written in C++, so once you want to do something that is not available in QML, you will likely need to do this in C++. In fact, that is how we expose QML objects from ArcGIS Runtime - we write them all in C++ and you consume in QML. With that said, lots of things are available to you in QML, so depending on what you are doing, you might not need to write any C++ code.
Basically, there is no easy answer. If your application is relatively simple, QML is just fine. If it is extremely complex, it might be better suited in C++ (but not necessarily). One final thought is that it isn't all or nothing. Probably the most preferred way to write your Qt app is to use QML exclusively for your UI and C++ for your backend code. The different options are discussed a bit more here - https://developers.arcgis.com/qt/latest/cpp/guide/qt-sdk-best-practices.htm
//
My goal is to create an iOS app that will be used by our tree trimmers...
This sounds like a relatively simple application that could be written in QML or C++ with (most likely) little to no difference in the output product.
Are any drawing tools available for creating the polygons and assigned attributes?
We don't yet have a sample or API for this, but we eventually plan on having a SketchEditor type component that will help simplify drawing geometries. For the time being, you will have to create your own editing experience using the various GeometryBuilder classes. For example, if creating/editing a polygon, you should use the PolyonBuilder class for this.
what do you think about using 2 different feature services?
Either sounds find. It doesn't sound overly complicated with 2 in my opinion.
I should be able to use the same code on an Apple machine, and build the app there, right?
Yes, your code is all cross platform, so it should build just fine on Mac for iOS.