CreatingGeometryOptions & ListViewActionPage

[KierenTinning1]

Does anyone know why invoking the Accept Geometry action item would cause a null reference exception in a subsequent ListViewActionItemPage?

Code example

gam.CreatingGeometryOptions += new ActionItemEventHandler<ListViewActionItem>(gam_CreatingGeometryOptions);

void gam_CreatingGeometryOptions(object sender, ActionItemEventArgs<ListViewActionItem> e)
        {
            IEnumerator<ListViewActionItem> ela = e.ActionItems.GetEnumerator();
            ela.Reset();
            ela.MoveNext();
            ListViewActionItem la = ela.Current;
           
            la.Action.Invoke();
           
        }

Then later I have a custom function which gets called and at the end of that function the system is supposed to transition to a new ListViewActionPage

ListViewActionItemPage.TransitionToListViewActionItemPage(new FinishCollectionPage(this));

Where this is the calling task.

If I leave the above alone and have ArcGIS Mobile show the standard GPS Averaging Finish Page (Accept Geometry, Offset, etc) then my Finish Collection page is show without issue.

However if I invoke the Accept Geometry option then the Finish Collection page throws a Null Reference Exception in the 'CreatingActionItems()' event which I have not overridden.

Any thoughts anyone?

[AkhilParujanwala]

Can you describe the workflow?

It seems like you are trying to avoid one screen, trying to make your data collection process faster.

Just an FYI, when I was using all of the forms in the out-of-the-box solution to create a feature (point), it would take roughly one minute to create a point. This was too long for my users and the computers we are using are too slow.

Instead I create my own data collection methods and I still used the AttributesForm and the SketchForm to allow users to point on the map for the location of the point.

Here's my workflow for GPS mode:
1. Click on "GPS Point".
2. The feature's geometry will be automatically saved and the AttributesForm will appear.
3. User will fill in AttributesForm and then click OK.
4. This is a customized "OK" button, and will call my own synchronize event.
5. Then the map will be shown and the new point will appear and it will be synchronized to the server.

I also have a button where the AttributesForm will not appear and default values for fields with domains will be used, and the point will simply appear on the map and be synchronized.

My workflow for Map mode:
1. Click on "Map Point".
2. The SketchForm will appear.
3. User will click on the map, then click Accept.
4. The AttributesForm will appear and the user can fill out the data and then click OK.
5. This is a customized "OK" button, and will call my own synchronize event.
6. Then the map will be shown and the new point will appear and it will be synchronized to the server.

I also have a button where the AttributesForm will not appear and default values for fields with domains will be used, and the point will simply appear on the map and be synchronized.

With these newer and faster data collection buttons I have created, I can collect a point in 1-30 seconds. The reason for the large range is because the computers are slow, otherwise the 30 seconds would be a bit shorter.

My suggestion for you would be to skip or go back to the map page instead of going to the CreatingActionItems(). I believe the error is occurring because the feature is now null? This is assuming you don't need the CreatingActionItems form that appears. Instead create your own save feature method and synchronize the feature. This is what I did.

As you can see in my workflow, I try to minimize the steps to collect features. For me this works, because most of the fields are being auto populated by my code and integration with the devices I am using.

I hope this helps.

[KierenTinning1]

Thanks for the reply. I too am trying to streamline the collection workflow and avoid any additional clicks.

Workflow

1. User selects 'Collect Features' - which is actually a custom task I've written
2. System shows the FeatureTypePage with editable features
3. User selects a feature type
4. Depending on which type the system will show a map where the user can select the design feature
5. or the system takes them directly to the edit attributes screen
6. User edits the attributes for the feature (part numbers, and so on)
7. User clicks next
8. System takes them to the GPS Averaging screen (i.e. right to the start button)
9. When averaging is finished, System prompts to Accept Geometry, Take Offset, and so on (standard functionality)
10. User clicks Accept Geometry
11. A bunch of post processing is done on the device - feature is saved
12. System shows a custom finish collection page (extends a ListViewActionPage)
13. Depending on what is picked here the user can re-enter the above flow at steps, 1, 2 or 8

This all works very well.

So, what I am trying to do is eliminate steps 9 and 10 now.

If I capture the GeometryActionOptions and automatically invoke the Accept Geometry option (ListViewAction.Action.Invoke())

I can eliminate steps 9 and 10 and the system runs step 12 and the feature is saved properly to the Mobile Cache for posting later.

The issue is at step 12 where it is complaining about a Null Reference Exception. This page does not reference the existing feature which is set to Null, so there is no change in the Finish Steps. But it seems there is some internal reference error between auto invoking a list view action item on one ListViewActionItemPage and the display of another ListViewActionItemPage.

Any thoughts would be greatly appreciated.

K

[AkhilParujanwala]

Excellent workflow and yes, streamlining is a tough job.
I started with a 1 minute process with a lot of clicking to a process with 1 click and can collect a feature in 1 second.

On step 6 and 7 this is where you can actually remove step 8, 9, 10.

I have personally worked with the ListViewActionItemPage and yes it doesn't require a feature object, but there is something inside that page that we don't see. My initial guess was the Feature object, but it could definitely be something else.

Right now I am using the GPSAveragingTool instead of the GPSAveragingPage (this will save 10 seconds and 2-3 clicks).

My old code used a GPS average of 2, I found this to be useless for my use cases. Also in ArcGIS Mobile 10.1 I believe they removed the GPSAveragingTool. Instead replaced it with GPSSingleShot, so I would recommend against using it and instead use the GPSStreamingTool.

Regardless here is how my older code works.
When the user goes to the Attributes page, the GPSAveragingTool is already averaging in the background. So I change the Next button to reflect the averaging being completed.
For example, user is now at the AttributesPage, there is a Cancel and a Next button. However the Next button's text shows the following; "GPS Averaging 0/10" then "GPS Averaging 1/10" and etc, all the way up to 10/10. Then the text of the Next button becomes "Next".
When the user clicks on the Next button with the text of Next it will save and sync the feature.
If the user clicks on the Next button while it is averaging, it will do nothing.

When you use the GPSAveragingTool or GPSStreamingTool you will not need to use Step 8,9,10, because you will no longer be using ESRI's forms, but instead coding your own Geometry collection methods.

PS: I will be switching from the GPSAveragingTool to the GPSStreamingTool and then try the GPSSingleShot when I am in 10.1.

In conclusion, modify the application to use the GPSAveragingTool or GPSStreamingTool. So after the user clicks on the FeatureType, go to the AttributesForm, start your GPSAveraging behind the scenes, when the user clicks Next, the feature is saved and go to a page you desire.

For my use cases my each deployment of my application is used in a moving state, meaning vehicles or walking, so Averaging made no sense. I simply use an instantaneous GPS position but I still use the GPSAveragingTool, I take an average of 1 point (itself) which is instantaneous.

Let me know what you think?

[KierenTinning1]

Hmmm, that could work. My only trouble there is I'll have to refactor the finish page as I can route back to the averaging screen again and again and again.

Plus my users like the counter aspect and are quite comfortable with the tool.

It seems like you and I are on the same path and don't really have anything "standard" left in our respective applications 🙂 Basically all custom now.

I've filed a bug with ESRI Canada who'll no doubt route to Redlands and we'll see what they come back with. But you're right there is something there in the forms which we don't see. I had a bad memory leak in the ListViewActionPage with a hidden Bitmap. No idea why it was there, but in the background it was and it never disposed, so it's probably something else along those lines.