Hoppa till huvudinnehållet

Studio Go not opening to previous map extent

Kommentarer

8 kommentarer

  • Phil MacIntyre

    Hi Bill,

    Thank you for your report. This is Phil MacIntyre with the Mobile team. Could you please provide some additional details about the issue you're encountering? I've tried to replicate it with our 5.22 store builds on Android, iOS, and Windows, using both custom and predefined map areas, with a variety of extents. Following a refresh, restarting the Go app entirely, or simply returning to the app selector and reloading the app my previous extents are being faithfully remembered.

    Are there any particular steps that I'm missing beyond:

    a. Load an app

    b. Make and activate a map area

    c. Move your extent to a particular area

    d. Refresh/reload/restart the app

    ?

    Is your app using a web map and MMPK or just an MMPK?

    Thank you,

    Phil MacIntyre

    0
  • Bill Warren

    Hi Phil,

    Yes, steps (a) to (d) are essentially what I followed. The extent in step (c) is remembered if using an online map but not if using an offline map.  The problem could very well be related to your last question.  The application uses both a web map and MMPK (contains a series of lookup tables).  This is not the first issue I have had with an MMPK.  I wonder if it is related to the behaviour outlined in an existing case - ref: 201906 'Geodatabase change tracking not enabled'.  

    0
  • Phil MacIntyre

    Hi Bill,

    Ah yes, that did it. It's the presence of the MMPK. We're resetting you back to the MMPK's default extent. I don't think it's your specific MMPK, but MMPKs more generally. I did the local testing of your other bug and confirmed that the map area send change failure is specific to your MMPK (it works fine with others). First thought being that since your MMPK just contains tables, rather than tables + features (which is what we've most commonly seen), that's causing the bug. We've got that up in priority in our backlog and will look to fix it in the near future.

    I'll file a bug for this issue here and we'll look to address it as well. I'll keep you updated on our progress.

    Thank you for the clarification,

    Phil MacIntyre

    0
  • Bill Warren

    Hi Phil,

    I appreciate you testing this along with the related MMPK issue.  While you are addressing this particular issue, I wonder if there is a preferred method for taking reference tables offline or if this is still part of future enhancements? 

    Also, what commands/parameters could I use in a workflow that runs when the map is initialized that might override this behaviour?  I've tried a few options with Run Command without success and would appreciate any thoughts you may have.  As it stands now, the web map has a bookmark that the user references in order to zoom to the web map extent but would prefer to automate.

    Thanks - Bill

    0
  • Phil MacIntyre

    Hi Bill,

    We most commonly see reference tables tied in to spatial features as related records, which seem to work reliably. If memory serves, Esri introduced the ability to add standalone (not related) tables in about Portal 10.9, and we encountered a number of issues on the Esri side about taking them offline (in both custom and predefined map areas). So if you can tie your tables into some spatial data, either in the web map or MMPK, you may have more success at this point.

    The bookmarks component is certainly an option, but I agree that automating it would be nice. It's obviously going to depend on what your user flow looks like, but one thing you could perhaps do would be to:

    1. Make use of the 'app.set-persistent-data' command. This allows you to store data at a per-app session (memory), per-app between sessions (app), or between apps (global) scope. These data can include geometries, so you could do something like run a 'Get Map Extent' activity, then feed its geometry into that set command. If it's just within one app, you would use the 'app' level scope argument, as this will persist between full Go restarts until it's cleared.

    2. You could then configure a startup Workflow (tied into the onMapInitialized event found in the Map component in mobile App Designer) which would then use the 'app.get-persistent-data' command to fetch that geometry, then feed it into a Set Map Extent activity. As soon as your map has rendered, it would then shift the extent to the location stored in step 1.

    These commands are described in the Commands and Events section of our DevCenter Docs:

    https://developers.vertigisstudio.com/docs/mobile/api-commands-operations-events/

    When exactly you'd fire step 1 (to get that extent) is going to influence what extent you use, but if you can predictably rely on a user performing a certain action, that you could tuck that Workflow piece into, then you could at least get a better approximation of their last location than a wholesale reset to the MMPK's extent.

    Hope that helps!

    Phil

    0
  • Phil MacIntyre

    Hi Bill,

    We have fixed this bug (the extent not being remembered) and this will be included in our 5.24 release, scheduled to go live in mid-June.

    Have a great day,

    Phil

    0
  • Bill Warren

    Thanks Phil.  Since we just started our annual employment survey which is making use of our first Mobile application, we likely won't be upgrading our on-prem Mobile installation in June.  However, if we upgrade Studio Go in June to v5.24 while Mobile remains at 5.23, will this introduce any issues?

    Thanks - Bill

    0
  • Phil MacIntyre

    Hi Bill,

    Studio Go is backwards compatible so a 5.24 Go should be able to load apps from a 5.23 on-prem installation no problem. The new version of Go will benefit from the bug fix even if you don't use a 5.24 on-prem to bump up your Designer-generated app version.

    Cheers,

    Phil

    0

Du måste logga in om du vill lämna en kommentar.