ADO.NET interface - Introduction to the ArcGIS Mobile SDK

Spatial and attribute queries on map cache feature layers

Queries are executed against local data

Data loaded to

And, of course, we support updating the map cache, and the way we update the map cache is through ADO. We would manage and take control of the actual feature layer and the records inside the feature layer that we want to work with.

Editing

Edits can be performed in a disconnected mode

Let's look at some of the editing capabilities in more detail. Edits can be performed in a disconnected mode. Earlier on I talked about the fact that we can work in this disconnected mode.

Editing

Edits can be performed in a disconnected mode

Only SDE layers are editable

We were caching the data locally on the device, so anytime in your application as long as the cache exists, you can edit against it provided the feature layers are coming from an SDE data source.

Editing

Edits can be performed in a disconnected mode

Only SDE layers are editable

Connection required to synchronize updates with the server

We do require the connection to synchronize directly with the server. All the data transactions take place through the Web service. If you don't have access to the connection, then you can't post the updates back to the server itself.

Editing

Edits can be performed in a disconnected mode

Only SDE layers are editable

Connection required to synchronize updates with the server

Editing is supported for non-versioned and versioned transaction models

We support editing for both nonversioned and versioned transaction models.

Editing

Edits can be performed in a disconnected mode

Only SDE layers are editable

Connection required to synchronize updates with the server

Editing is supported for non-versioned and versioned transaction models

Coarse grained sketching components for geometry construction

I mentioned some of the map actions, and one of the map actions we put in place is a sketching map action. You can leverage this map action. It's a very coarse-grained component. The majority of customers and users or partners want to develop applications that, of course, have editing in it, whether it's creating points, lines, or polygons or maybe modifying existing geometries. The sketching component exists we feel that the majority of users want to leverage it, so we provide it to you out-of-the-box.

Editing

Edits can be performed in a disconnected mode

Only SDE layers are editable

Connection required to synchronize updates with the server

Editing is supported for non-versioned and versioned transaction models

Coarse grained sketching components for geometry construction

Attribute editing via ADO.NET components

And, we touched on the last slide, all of our attribute edits occurs via ADO .NET components.

Software demonstration

That was just a quick overview of the SDK and some of the components inside the SDK. I'm going to pass over to Allen, and he's going to run us through a development scenario.

Thanks, Myles. Let's take a look at some of the critical pieces here that Myles mentioned. The first thing we're going to do is, we're an ambitious developer and we just want to start developing straight-away with the Mobile SDK. We're going to pick a Visual Studio C# smart device, and a mobile Windows 5 Pocket PC device application. We'll let Visual Studio go ahead and build that for us. Of course, it can do so because we've previously installed the .NET 2.0 compact

framework. That's what gives us those options in the project new menu.

If we just want to start developing, a few other pieces of the puzzle that Myles mentioned before we get started actually, is looking at this device emulator. We have this emulator that comes as part of the compact framework install, and here we can see we're connected to the PC emulator right now. That's a bit of a preconfiguration thing.

After you connect and cradle, you'll see that you need to go to Active Synch and, as long as Active Synch is connected out to the emulator, because it is running right now, then that means I'll be able to run this application in real time. It's actually going to run and deploy to this emulator device that is running. That's a little bit of the background configuration that has happened here.

Let's get back to development. What I'm going to do is go to the toolbox and look at some of the mobile controls that are available. We have the map control, the map cache, GPS display, and then you'll see a number of actions down here. We've got the scale bar, sketch, zoom in, and zoom out. These are the basic tools that come as part of the SDK install. What I'm going to do here is just simply drag the map onto our form that's available on the default form for this project.

You'll notice that a map cache is automatically added, so one thing that's interesting is that as a developer, you know we can work with the map cache outside of the map, but you can't work

with the map without a map cache. The map cache is really the thing that connects you to the server on the back end. Let's take a look at that.

In order to make this project run and work, we need to hook the map cache up to a URL. Let's take a look at our service that we created earlier. We go to the properties. Again, we'll just copy the mobile URL endpoint. We'll paste that in the URL property for the map cache. We're also going to specify the storage path location. This is the location on the device and right now we're looking at the emulator of the device. If we're to run this application, then we wouldn't see a map cache, and many of you may have run into this, because there's a little more coding that's

involved here.

What I want to do is point everyone to the ESRI EDN Web site which basically has our EDN.

Basically, it has all of our walkthroughs and so forth that are set up. Here you can see we have a Mobile ADF developer scenario. Click down here. We're creating a Mobile ADF Pocket PC. It takes you through all the steps that I just basically stepped you through, and you'll see in the form load the application needs to be told to load the cache or load the map if it has one available.

What we're going to do is just paste in that code. Here we're looking at making sure the cache is valid. If it is, we're going to open it. We'll add using reference to the project. You notice that there's only one assembly that is required to develop with the SDK. Unlike working with

ArcObjects, you had many, many assemblies. Here, we just have the one. We should be ready to run this application.

Let's do a few things more before we get going because we're running out of time here. What we're going to do add some actions so people can actually interact with the application. I'm going to add a pan and a zoom in/out action here. These are the actions that Myles was making

reference to earlier. We could do sketch action and there's all kinds of custom actions that can be developed from a developer. It's essentially the same as implementing I command if you're an ArcObjects developer. Here, what I'm going to do is just title the menus. I'm going to go ahead and step out the handlers for the menu. What we need to do now is hook up the current map action to, in the first case, will be our zoom in/out map action. See how that works in a second.

In the second case, set up a current map action to simply just panning. Now we have some functionality to make our application work.

We have our emulator up and running. If you're using an actual device, the device would be just sitting beside me and it would be cradled and the emulator simulating that configuration. I'm going to start debugging, and you'll see what happens is when the project was to build itself, what it does it goes through and recognizes that in order for the application to deploy this to either a device or the emulator that it requires the ESRI Mobile 92CE .dll. This is the.dll that will support the .exe and that was the 540 kb .dll that Myles mentioned earlier. This went through and did the compile and now it's deploying and we'll go back to our emulator device and you can see that the application is essentially being uploaded or deployed to this device on-the-fly. Again, this is all working through Active Synch and through the emulator.

Here is the Web service that we published earlier. We can see that we have some functionality to implement it. Our map action to zoom in—a little different operation than you might be used to.

Here, I'm actually tapping and dragging on the display, simulating using the pen device itself. If I want to pan over to the side, then I can change the action and just pan over to the map. Right now, it's just feeing off of that map cache and drawing to the display. This is a very simple application that illustrates how to use the SDK, some of the components involved including the

device emulator manager, the Active Synch, and basically how to bring the whole thing together with the SDK.

Thanks for that, Allen. That was a pretty wonderful demonstration there, very easy to get a viewing application up and running.

Let's move on and finish up today, because we're running out of time here slowly. We're going to jump into a quick review and then a question and answer set, so this is your last chance. If you've got any questions, please forward them through now, and we'll do out best to answer them in a second. We've looked at designing mobile applications. We looked at some of the considerations in terms of the .NET compact framework. We also covered the core components to the SDK itself and the editing capabilities, and then we saw a demonstration tying all these pieces together.

I'm just going to take a few questions.

I have a question from Spencer, and it reads, "Is ESRI planning on releasing a Java SDK for mobile applications?" The current answer to that is we don't have plans to do that. Our approach to this is to look at the demand for that requirement. I think if we start to see lots of questions and customers who are demanding that we do a Java SDK, that would definitely be something that we would look at. If you need to, feel free to e-mail me directly at [email protected], and if you have any requirements like that, I'd definitely like to hear from you.

I have a question here from Chris in Greenwood Village. "Are complex features, geometric networks, and tracking supported?" The answer to that today is that we don't support the complex features or the networks or the tracing inside the Mobile SDK and its cache itself. But, from a development standpoint, what you can do is develop a Mobile SDK application that would interact with some of the geometric networks and perform tracing on the server side. So, if you do have the connection, we can deploy that level of functionality. That's currently something that we do not have in the client side of the SDK.

I have a question here from Daniel in New York which reads, "Which version of ArcGIS Server do we need to deploy Mobile?" The answer to that is today you need to purchase ArcGIS Server

Advanced Enterprise edition. As I mentioned previously, with that edition, you'll get 50 deployments of the SDK and, if you wish to, you can purchase additional packs of 25 deployments of the SDK deployment itself.

I have a question here from Laurel, and the question reads, "What if you have a large SDE raster, say 100 gigabytes in your MXD?" That's a very good question. Today, in the way that the SDK is developed, a lot of the limitations come about because of the device and the operating system that we're running. Today, we definitely cannot support synchronizing out a 100 gigabyte raster through the Web service. One thing that you could look at doing if you wanted to deploy from a service that had such a big raster in it is to chunk out the data as much as possible. But, really, even if you're looking at one gigabyte raster data is really going to be maxing out what you could store on a mobile device and operate against as part of the SDK.

I have a question here from Christopher in Chicago. "How easy is it to deploy both a PDA-based and Tablet PC-based application, keeping the functionality identical?" A simple answer to that is it's actually very easy, and the way to go about it is to actually develop around the Pocket PC platform first. Because the .NET compact framework is a subset of the .NET framework, if you develop the capabilities that are available inside the .NET compact framework, you could very easily deploy the same application with the same capabilities on the Tablet PC. Of course, I wouldn't necessarily recommend that you develop the same user interface for both platforms, so that's definitely something you might want to modify because on the PDAs we have different ways of interacting with the devices whereas on the Tablets you can really leverage big buttons and leverage the stylus and the inking capabilities. You might want to change the user interface experience.

I have lots and lots of other questions here. I'm going to take one more, and then we're going to finish up today.

The question here, another from Chris in Greenwood Village, and it reads, "While disconnected, does the cache expire?" The answer to that is that no, it doesn't. The purpose behind the cache itself is really to store the data, but mainly so that we can operate in this disconnected manner. If you lose connection to the server, the cache definitely doesn't expire, and when you regain the connection to the service again, you can just continue to post data back to that service provided it's the same service that your application was previously pointing to, and by that I mean the schema exists in the same form that it was previously. Of course, if you change the schema on the back end, then your cache will effectively have expired or would no longer work with that service.

In document Introduction to the ArcGIS Mobile SDK (Page 53-65)