ArcGISEngine vs ArcGIS Runtime Q&A

[EricHolsinger]

ArcGIS Runtime Development Team (Eric Bader and company):

I'm getting ready to convert portions of a complex ArcGIS Engine app over to ArcGIS Runtime.  I've spent the day looking over the ArcGIS Runtime documentation, I went to the ESRI UC in SD this summer and spent a lot of time w/the java team there, but there's still quite a few issues I find lacking in the docs, and I'm getting a sinking feeling about the whole thing.

I'd like this thread to be an ongoing discussion for ArcGIS Engine methodology vs. ArcGIS Runtime methodology.  I have a couple of questions now, and will be adding more in the very near future:

1.  Tell us definitively what methods in ArcGIS Runtime are supported against File Geodatabases, including what objects can be stored in them, any peculiarities, etc.

2.  Please list a comparison of File Geodatabases to MPK files.

3.  Tell us definitively and provide sample code as to exactly how to create, open, modify, save, etc. File Geodatabases.



More questions to come in the very near future.

Thanks.

[EricHolsinger]

As an update to my first post on this topic, I just discovered that Martin asked for a Functionality Matrix between ArcGIS Engine and ArcGIS Runtime almost a year ago via this forum post:  http://forums.arcgis.com/threads/44685-Functionality-Matrix

Has this functionality matrix been created?  Why was this extremely important post not addressed by the ESRI Java Product Group for almost a year?  If you want developers to take this new runtime kit seriously, then you need to consider that many of us have a lot of time and effort invested in ArcGIS Engine and the other, older tools from ESRI that function against the original COM-based APIs.

We need the functionality matrix ASAP.  We also need another functionality matrix:  what is supported by the ArcGIS Runtime locally vs. online?  In the samples that are delivered with the new runtime kit, there are too many examples of "online" and we need to see a one-for-one comparison between online and offline/local.  Most of my customer base cannot work from online sources because of security specifications...and this includes all applications that we build for two large federal clients.

When can we expect an ArcGIS Engine vs. ArcGIS Runtime functionality matrix and an Online vs. Local functionality matrix?

[EricBader]

Hi Eric.

Yes, it's been almost a year, and no public matrix yet. Wow. I agree, this is long overdue and I apologize.
We have a draft comparison document we are finalizing. We will provide it as soon as possible.

It would be great if we could, offline possibly, get some specifics about what you need to do exactly with the File Geodatabase in your application.

There are ways to get to the local File Geodatabase with the Runtime SDK. However, let me first point out a few of the motivations for providing the Runtime SDKs.

1. A developer toolkit for building or embedding focused, light-weight client applications to the ArcGIS System across small, mid-sized and large (desktop)  devices.


2. A developer tool kit for bringing remote and device-local GIS resources together into a single focused application to work with the ArcGIS System.


3. A developer toolkit for building ArcGIS System focused applications that work in both connected and disconnected environments seamlessly.

Notice the emphasis on "The ArcGIS System". The ArcGIS System goes way beyond fine-grained arcobjects-like access to resource details on a subsystem at the low-level. Do you know I mean? These are basic points to keep in mind for context. The focus now is on a more coarse-grained, simpler model of programming.

With respect to accessing File Geodatabases, this could be answered better in a blog, but I will try to follow up with one. In the mean time, there are a few ways to do this, all of which require the use of a LocalServer of course:

Map Packages (MPKs): these can contain feature layers that have data coming from a file geodatabase. The file geodatabase can either be packaged with the MPK or referenced from the MPK when opened. The Runtime SDK provides an editing framework that supports CRUD workflows on that layer's features. There are OOTB samples that demonstrate how this works.

Geoprocessing Tools/packages (GPKs). There is a list of SDK-supported geoprocessing tools from the OOTB GP toolbox  here that contain some data management tools for creating feature classes that live in file geodatabases. These can be executed from within your Runtime App to create what you want. By the way, some of these tools do require an additional extension license, but not the Data Management tools. These only require Standard license.

Fine-grained access to local resources directly from the Runtime APIs is not there in the product. However, using GPKs, a developer can create a custom ArcPy script to do some python-level local access to file geodatabases, whatever ArcPy supports in this area, package up that script into a GPK and use/execute it within their Runtime App.

There is a blog here that talks about how to use some custom ArcPy scripting to extend your Runtime App to perform some shapefile creation, but the concept is similar to doing something with a local File Geodatabase.

The creatiion and use of MPKs and GPKs are there in the documentation today. We need to flesh this documentation out a bit more to cover possibilities like the ones you mentioned.

Again, a blog on this would be very useful, and we will try to get information like this up there asap. In the mean time, is this helpful?

Thanks for your patience and understanding, and lets keep the dialog going.

Eric

[EricHolsinger]

Eric B,

Thanks for the speedy reply.  The Runtime looks to me like an amazing piece of work by your team - it's very refreshing to be able to finally get away from the chains of COM in the product line.  I can definitely appreciate the coarseness of the API as I've spent many hours in the fine-grained never-never land of COM stubs for java...  I'm sure that the stumbling block we have at this moment is our lack of experience in the runtime, possibly coupled with a lack of documentation on a fairly new API.

In the spirit of keeping the dialog going, I'll try to keep this as short as possible as to where we're interested in going with the runtime.  I'll list these in order of our priority:

1.  First and foremost, we need to insure that all of our tools will run on all platforms with a single pure java codebase (Windows, Linux and, where possible, Android).  We're not expecting to write GUI code for Linux that we can run on droid, but we want to insure that all processing code (i.e. creation of file databases and/or MPKs, creation of layers, shape files, and geoprocessing routines) can be accomplished in middleware and run on any platform.  This is the holy grail, right? 

2.  Since we had to maintain offline (aka local) storage for our products, we used the File GeoDB extensively as the main container for moving map workspaces around and all that goes with that, so my first interest is in being able to leverage at least the logic, if not the code.  From my time spent at the UC, I did come away understanding that a lot of the code would have to be rewritten, so that's expected.  The issues we're having is either a lack of documentation on things such as how to get to and manipulate the workspace and all that goes with that - or I just don't know where the documentation is.  I can see it in the API, but other than basic javadoc, we're not finding examples and working code.  We need to create point, polyline, and polygon shape files, push them in to a package of some sort (don't care what as long as it's local), then add them as layers to maps.

3.  We're using a lot of geoprocessing tools, and we need to be able to run these tools on-the-fly.  If we have to create some type of "package" in Arc Desktop and then deploy them, that's not a problem - but if we can't run dynamic data against the gpk's that we publish in our products, that would be a show-stopper as the value in our products are a combination of map content and map object processing.

4.  We want to be able to leverage the same paradigm that your team seems to have built-in to the runtime:  local vs remote and, going one step further, we want to write once and run in both thick-client RCP and Swing apps - and Android...so we're very keen on insuring we pick the right container (File GeoDB vs MPK vs whatever) for our various map objects and geoprocessing methodology.

5.  We're not going to be able to use any type of scripting language.  Also, I'm seeing quite a bit of silverlight dependencies in the runtime samples and we obviously can't use that either.  I'm hoping that they've been updated to be cross-platform compatible?


I think I can speak for most developers in saying that we don't mind unpolished example code - you could write it on a napkin with a crayon, scan it, and put it up on the Resources site - as long as we have working examples of the new API, we're good-to-go.  In this day and age we have to be nimble.   😉

Thanks for the time,

Eric H.

[EricBader]

This is awesome, Eric H.

This discussion is extremely appreciated and important to us. Really.

1. The Holy Grail is right. Amen to that. You folks are obviously seasoned Java technologists, at the very least. This goal has been our vision as well: Java is not just a language, but a tried and true platform. We want our products to reflect this fact. Having said that, it has been a process for us, so we aren't there quite yet. For example, the workflows of getting and using data from MPKs and GPKs do not translate to the Android platform. Android does not have what we call a "Local Runtime", also called a "Local Server". So, accessing data from an Android device, today, is by on-line services. Once you have the service data, the business logic and operations on those services are almost identical between the Android and desktop(Java Runtime) programming models. Does that make sense?

2. Our documentation for v1 was very basic, yet informative. However, I can't disagree with you that in some cases it was too basic, and there is much more work to do here for a better developer product, more code examples, deeper dives. We are continuing to enhance the docs as you can expect, and are fully emersed in this task right this moment. Your discussion here is extremely valuable in inspiring us to go deeper. By the way, have you spent time running the OOTB Sample Viewer application? It exposes lots of development concepts and code that has been of tremendous help to a lot of us. We'd value your feedback on it.

3. GP. Yep. Understood. A GPK is static in it's logic, but the in out parameters are certainly dynamic within you app. For example, you package a GP tool that takes Features in, and spits them out to a GDB. On the fly, your app defines the FeatureSet as the inputs, and the app can also dynamically determine where the GDB is to be written out. Now, back up. When the package was created from a running result in ArcMap, there certainly was static data used to operate against, but when the package is created after that, the operational data it worked on is basically "throw-away", not needed anymore. Do you know what I mean? Your package now holds the tool, but the previous data is now insignificant.

4. Nice! Both RCP and Swing. Music to my ears. :-). Anyway, the only issue is going to be, as I said before, with the Android platform. You will need to use the Andriod SDK to build that part of your solution. While the SDK for Android and the SDK for Java do share some fundamental parts of their core API, they still need to be 2 separate apps, built with 2 different SDKs. We need to continue to look at this and figure out if this still makes sense as we go along. Thanks for this discussion.

Silverlight: Yikes. We will have a closer look and see what we can do to fix this. Thanks for pointing that out.

I hear you. Code, code and more code. This is what a developer toolkit should lead with, I totally agree.

Thanks!