Replaced Volley calls with Graph SDK

[jasonjoh]

Purpose

• Replaces raw HTTP calls via Volley with Graph SDK calls

Does this introduce a breaking change?

[ ] Yes
[ x] No

Pull Request Type

What kind of change does this Pull Request introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ x] Other... Please describe: Enhancement

What to Check

Verify that the following are valid

• Works like before

Other Information

This is pertinent to discussions with @baywet and @mairissi

[baywet]

@jasonjoh thanks for putting all of that together, a few minor comments from my end

[iambmelt]

Suggested change

	@Nonnull
	@Nullable

Since this method can return null

[jasonjoh]

Hmm - maybe it would be better to return CompletableFuture.completedFuture(""). @baywet what would the SDK handle more gracefully?

[baywet]

yep, return a CompletableFuture.completedFuture(null) https://github.com/microsoftgraph/msgraph-sdk-java-core/blob/dev/src/main/java/com/microsoft/graph/httpcore/AuthenticationHandler.java#L54

[jasonjoh]

Done

[rpdome]

The purpose of doing this is to show how exactly the token can be used to access any resources
(We picked Graph because Graph's User.Read is accessible to every accounts).

This change would encapsulate that.

I'd suggest we have an extra page (fragment) for Graph SDK, and you're free to bring in all the best practices with the Graph SDK in that one.

[rpdome]

If all they need to access MSGraph, and Graph SDK already wraps around the authentication part, I'd say we probably won't even need MSAL in that page

or you could have a demo of both - with, and without MSAL like what you did here

cc @hamiltonha

[jasonjoh]

Graph SDK does not "do" authentication - it relies on an auth provider. It can use the provider from the Azure Identity SDK, but that SDK isn't supported in Android. So, I wrote a custom provider that wraps the token you guys already get from MSAL.

My goal here was not to undo any of the token acquisition work you've already done, just to remove the HTTP calls to Graph (which we do not want to encourage). cc @baywet

[baywet]

@rpdome I think there are multiple conflicting goals here:

• Showcase how to call a custom API with native http client
• Showcase how to call Microsoft Graph with code that is closer to real life for customers

We, as Microsoft, don't want to encourage people to call Microsoft Graph with a native client. Of course they technically can do it, but they shouldn't as they as loosing a lot of value from the different handlers to the types and the fluent APIs. Not using the SDK to call Microsoft Graph makes their applications less resilient and is not what is recommended.

Now, I understand you also want to showcase calling an API using the native HTTP client, this is fine, just pick a different API that doesn't have an SDK, or send the request to localhost with a mock.

I hope that makes sense and we can merge this PR in? We're on the identity call tomorrow and it'd be great if things were aligned.

[rpdome]

In that case, what about having both options in the code, but comment out the manual part?

We can explicitly call out something along the line of "If you're going to use MSGraph in your app, Please use the SDK. The manual way is kept here - in case you're trying to call other APIs"

We don't want to mock the request - because we still want the customer to 'play with the real thing' - we want to let them know that if they want to do it manually (if you don't have other options), here is how.

This sample app is supposed to be a playground after all, and MSGraph is the only SDK that are available to everyone by default.