Utterly confused and sort of misguided between ArcGIS engine SDK and WPF Runtime

[xariaD]

Hi,

I have a question on which product to use.

After going through the esri website I understand that we can use the WPF API for the following:

Add graphics and markup to a map interactively
Search for features or attributes in your geographic information system (GIS) data and display the results
Edit feature geometry and attributes

Can we use the ArcGIS engine SDK for the same?
We do not want the user to change the attribute of a graphic. it should be changed from the code upon certain event.

The local distributor mentions that it is possible, but I still have my doubts.

Also one more important question is,
Similar to what the WPF API does by loading the base map and feature layer; can the ArcGIS Engine Desktop SDk for .net load 2 maps at a time.

It will be of very much help if some one could answer my queries at the earliest.

[xariaD]

Any inputs?

[RichardWatson]

I think that the ArcGIS Runtime is the future and ArcGIS Engine is the past.

If I had to choose then I would go with the future rather than the past.

My impression is that Engine is more powerful, proven, and customizable then is the ArcGIS Runtime.  It is also more like to be deprecated (though I have no knowledge of this).

ArcGIS Runtime is where the focus is.

[AlexanderGray]

This is a very interesting thread, I am not sure what esri's position is on the whole thing.  I guess it depends what kind of development you are doing.  If you are doing windows forms in .NET then I think engine is the tool.  If you want to do a WPF project then the Runtime is probably better suited (someone can chime in now).  That opens up the debate to windows forms vs WPF.  There has been a lot said about it by more knowledgeable people than me, so you can google that.

[EricBader]

Yes! This is a very interesting thread, and I hope I can help. Thanks for asking about Runtime vs. Engine: when to go with what.

Runtime is certainly the future direction for native, standalone or embedded application development of Apps that work with the ArcGIS System. It addresses many of the "problems" that ArcObjects developers had with Engine, though Engine is a fantastic product, capable of just about anything.

Engine is, of course, founded upon ArcObjects. Very, very powerful, but also very heavy and not too modular. 32-bit only.
Runtime is not based on ArcObjects. It provides the majority of capabilities that Engine users need, but of course not all. It is very light-weight, registry-free, a bit more modular, easier to deploy, and native 64-bit. Also, could be more cost-effective for deployments.

So, think about this. ArcGIS Engine development is your best bet if your application needs to support the following functionality:

1. 3D visualization


2. Heavy "local" data management (lots of shapefiles and ad-hoc data sources)


3. Content Authoring


4. Complex geodatabase feature types


5. Custom ArcObjects Extensions, such as custom datasources and custom renderers, etc.

Now, the story is slightly different with Java Engine. Esri would like for Engine Java developers to make their migration plans to Runtime Java as soon as they can. This is the recommended path. If there are hurdles to this effort today, Esri would love to hear about these hurdles and engage with those folks to see where guidance can be provided. The reason for this is, the Esri Java Engine folks are focusing their best work and development efforts into the ArcGIS Runtime SDK for Java.

I hope this is helpful!