The best practice is to use AuthenticationManager.Current.ChallengeHandler to generate credentials and update AuthenticationManager credential store. The previous approach of calling ArcGISPortal.CreateAsync and passing a credential has been marked as obsolete.
This allows one to create a ArcGISPortal object which is not initialized. I am unclear what value this object would serve and why the ArcGISPortal.CreateAsync does not fire the ChallengeHandler .
Currently in order to get a initialized ArcGISPortal there would be a couple approaches
//Launches OAuth dialog, but does not fire ChallengeHandler
var credential = await AuthenticationManager.Current.GenerateCredentialAsync(new Uri(ServerUrl));
AuthenticationManager.Current.AddCredential(credential);
//ArcGIS Portal object that is hydrated
_portal = await ArcGISPortal.CreateAsync(new Uri(ServerUrl));
The other approach would be
//Create ArcGISPortal without a User object
_portal = await ArcGISPortal.CreateAsync(new Uri(ServerUrl));
// this will trigger the ChallengeHandler which launches OAuth dialog
_= await PortalItem.CreateAsync(_portal, "eb8be7257df742baaf320158b16f676b");
//run CreateAsync another time to get the hydrated ArcGISPortal object
_portal = await ArcGISPortal.CreateAsync(new Uri(ServerUrl));
The first approach seems better and it is not hard to hide the details in an your own OpenPortal method.
It seems to me to defeat the point of the AuthenticationManager. and ChallengeHandler pattern. To encapsulate the GenerateCredential code in the single ChallengeHandler delegate, the latter approach would be required, and one calls CreateAsync twice. Or one could use the former approach, but then are not even using the ChallengeHandler.
Seems that
_portal = await ArcGISPortal.CreateAsync(new Uri(ServerUrl));
triggering the ChallengeHandler would be better. As the ArcGISPortal object is somewhat useless until authentication has occurred
