When getting the search result on Android, the result bar does not fully cover the search bar, resulting a funky UI:

This is going to be soon addressed in re-design of the search UX/UI, so we'll resolve and verify this issue with that update.

The Listview.ItemTemplate in the Autocomplete control for Xamarin doesn't work and so the app has to pass a string rather than a SuggestResult. Fix this so it works properly

Here's an example on the WPF version of the app running on a Win7 x64 virtual machine.
Searching for a location (i.e. Portland, OR) and then clicking the route button leads to this effort before the app crashes.

• WPF
• UWP
• iOS
• Android

Due to a Xamarin.Forms bug, performance while displaying the basemap and user map lists is very noticeably poor while debugging. This only happens when native debugging is disabled.

To work around the issue, disable native/mixed debugging in project properties -> Debug.

This issue can be closed when Xamarin fixes the bug in a future release.

When the app is run on desktops not supporting touch screen input, allow the reverse geocoding functionality to be prompted with a map click.

I recently ran into this on UWP and WPF when testing the app on Parallels for Mac. It would be nice for the app design to provide a consistent set of functionality regardless of whether touch input is supported.

This is a nice-to-have and not a must-have piece of functionality.

For most app designs which incorporate a current location or show location button within a map display, the behavior exhibited by tapping the icon usually zooms to the current location in addition to panning the map extent to center on the current location. We should add this zoom to functionality to the Maps App button as well.

• WPF
• UWP
• iOS
• Android

This behavior isn't totally consistent, but it does occur some of the time. It sounds like it's fixed in a more recent version of the API, so let's use this issue to remind ourselves to verify there.

This behavior occurs in two situations:

1. When entering the address or place name in the search bar, and
2. When tapping the current location icon

In either case above, the expected result is for the map to be entirely panned/zoomed to the new location and have it centered within the view extent. Instead, the target location is often still well beyond the map extent.

When using the current location feature, tapping it a few more times will often finally center on the true location.

This behavior becomes more egregious the farther the current map extent is from the next intended map extent.

This is not specific to any particular platform and occurs - as far as I have seen - across Android, iOS, UWP, and WPF.

I've only tested this in Android so far. It may be an issue on other platforms.

Steps to repro:

1. Pick an address and route to it.
2. Click the start or end location to modify it.

Observations:

• In Portrait mode - notice that the screen elements shrink in size so that the start and end text become partially obscured.
• In Landscape mode - notice that the screen elements shrink in size so that they become totally obscured.

Example in Landscape mode:

Will allow user to switch maps after they have logged in.

• WPF
• UWP
• iOS
• Android

• WPF
• UWP
• iOS
• Android

After the requested route between two locations is returned, the keyboard remains in view, which also causes the returned list to remain active, all clouding the display.

Move WPF OAuthAuthorize to the presentation layer like with Android and iOS

On UWP, typing into the search bar does not yield any auto-suggested results in some environments.
This prevents testing workflows such as routing and verifying the existence of a turn-by-turn locations screen.

Note: this appears to be specific to the UWP app and only occurs in certain environments:

• Failed for Mike on a Mac running Windows under Parallels
• Worked for Mara on a Windows on a PC natively
• Worked for Rich on a MacBook running Windows under Parallels and natively
• Failed for Rich running Windows on a PC (HP Spectre XT) natively

On UWP:

Same workflow on WPF:

Edit (Rich 4/4/18): Updated title and description to be more environment-agnostic - i.e. to specify that this issue is not limited to running under Parallels. Also listed all instances of the issue being tested and present or not present.

When double-clicking to run the MapsApp application on a loaned Windows 7 VM, the WPF version of the app immediately encounters this error:

Here are the problem details:

Problem signature:
  Problem Event Name:	CLR20r3
  Problem Signature 01:	MapsApp.exe
  Problem Signature 02:	1.0.0.0
  Problem Signature 03:	5a3d6ce8
  Problem Signature 04:	Esri.ArcGISRuntime
  Problem Signature 05:	100.2.0.1912
  Problem Signature 06:	5a31dfd6
  Problem Signature 07:	2fa
  Problem Signature 08:	0
  Problem Signature 09:	System.Windows.Markup.XamlParse
  OS Version:	6.1.7601.2.1.0.256.4
  Locale ID:	1033
  Additional Information 1:	0a9e
  Additional Information 2:	0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:	0a9e
  Additional Information 4:	0a9e372d3b4ad19135b953a78882e789

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
  C:\windows\system32\en-US\erofflps.txt

In order for sign-in to work, Configuration.AppClientID must be specified with a valid developers.arcgis.com client ID, and the value specified for Configuration.RedirectURL must be specified in the list of redirect URIs for the application. In trying to get this working locally, this didn't seem clear. I would suggest:

1. Spelling this out in the doc in an easily discoverable way.
2. Adding a check during sign-in to point the developer to these values. This could, for instance, check for the default value of AppClientID and call that out specifically if unchanged, and otherwise suggest checking these values on sign-in failure.

• WPF
• UWP
• iOS
• Android

• WPF
• UWP
• iOS
• Android

• WPF
• UWP
• iOS
• Android

When picking a different basemap from the basemap gallery, your selection will refresh the map view and zoom out to a global extent. This is in place of preserving the current extent/scale.

i.e. on iOS:

Qualifier: this only seems to happen if and only if you've interacted with the map by panning or zooming before making your basemap selection. If you do this right from the default extent when the app launches, the new basemap will be added with the same extent and zoom scale preserved.

• Mobile app design doc
• Desktop app design doc

• WPF
• UWP
• iOS
• Android

With the phone setting for portrait mode unlocked, rotate the phone 90 degrees in either direction. This causes the Current Location and Basemap Selector buttons to disappear from view.

This behavior turned up while testing on an Android device. I was able to reproduce it several times. (This may or may not be specific to Android.)

Steps to repro:

1. Enter an address to which you'd like to route (i.e. West End Bikes)
2. Click the 'Route' button which appears near the bottom of the UI
3. Once brought to the authentication page, click the Android back button to decline entering credentials

The app continues to display a "Requesting Route" message with a progress spinner but there is no other apparent way to dismiss the action. The only way I've found around this is to totally close and re-open the app.

Architect app to account for responsive UWP UI and maximized shared logic between Xamarin Forms and WPF

In what appears to be an iOS-only issue, whenever the user taps the 'Address or Place' bar to search for a place name or enter an address, the app preemptively displays horizontal lines where the relevant search results will be listed. This occurs before the user has entered anything and before those results even appear.

They also remain even when not necessary:

With the phone setting for portrait mode unlocked, rotate the phone 90 degrees in either direction. This causes the app to become unresponsive. Tested on iPhone 5S.

In UWP, the menu item for opening user items should stay grayed out until the user is logged in. This works everywhere except in UWP.

This is a Xamarin bug: https://bugzilla.xamarin.com/show_bug.cgi?id=41268

• WPF
• UWP
• iOS
• Android

I've seen this on both Android and iOS, but am still narrowing down the more exact steps to reproduce.

When searching for an address or location, doing this enough times over can cause the UI to seem to become unresponsive to the selection of a particular result.

Android:

iOS:

In neither case above does clicking the blue highlighted result (Android), or grey highlighted result (iOS) result in any feedback from the application.

If a user is currently viewing a web map, then elects to log out of the account which gives access to the web map, we should remove that web map from the map.

We could do this by simply restoring the default map view when first starting up the app.

Low priority, but I noticed this while comparing the app the Nick's native iOS version. When he loads a user map, the map display is panned/zoomed to the web map's initial load extent.
In my opinion, this is slightly more intuitive behavior - it makes clear the web map is loaded. I don't think there is a need to ensure we preserve the active map extent on load as we're doing now.

• WPF
• UWP
• iOS
• Android

I've only been able to reproduce this on UWP so far.

Steps:

1. Sign in to the app
2. Load one of the user's web maps
3. Zoom to a location where data for that web map appears
4. Select a new basemap to display

Based on some testing, it appears step 3 is essential to getting the odd behavior. If I preserve the map extent to an area where the web map does not show data/layers, changing basemaps seems to work fine.

Screenshot on UWP: