Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Graph authentication improvements #2035

Merged

Conversation

GraniteStateHacker
Copy link
Contributor

@GraniteStateHacker GraniteStateHacker commented Apr 29, 2018

  • Updates logo for graph authentication service
  • Makes v2 MSAL default authentication provider
  • Updates Microsoft.Graph to package 1.8.1
  • Updates Microsoft.Identity.Client to 1.1.2-preview0008
  • Adds thumbnail & file size where available to OneDrive file items.

Issue: #
Related to requests by Adam Braden & team at Microsoft (by individual request)

PR Type

What kind of change does this PR introduce?
Enhancement

* Makes v2 MSAL default authentication provider
* Updates Microsoft.Graph to package 1.8.1
* Updates Microsoft.Identity.Client to 1.1.2-preview0008
@dnfclas
Copy link

dnfclas commented Apr 29, 2018

CLA assistant check
All CLA requirements met.

@nmetulev nmetulev added this to the 3.0 milestone Apr 29, 2018
GraniteStateHacker and others added 3 commits April 29, 2018 22:59
We no longer ask the user for an MSA/O365 account provider.
adds section for testing in Sample app.
/// <summary>
/// Gets the smallest available thumbnail for the object
/// </summary>
public string Thumbnail
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a Uri vs. a string?

Copy link
Contributor Author

@GraniteStateHacker GraniteStateHacker May 4, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that the XAML binding to Image.Source works as a string, I suggest letting it fly as is, and if folks need it as a URI, let them convert it as needed. Not gonna fall on my sword over it though.

{
get
{
return _path;
var size = _fileSize.HasValue ? _fileSize.Value : 0;
if (size < 1024)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR #2055 was doing something similar, could we make this an extension for long?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They started pulling it out here: https://github.com/Microsoft/WindowsCommunityToolkit/pull/2055/files#diff-e62611f48a9fc0cbaed40c2e841f0b25R30, but we should coordinate on needs/formatting.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this implementation is fine the way it is here, let's pull it out in a different PR if needed

@michael-hawker michael-hawker mentioned this pull request May 10, 2018
7 tasks
{
_thumbnail = string.Empty;
}
}).Wait();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really don't like doing this, but I can't think of anything that will have the same behavior (lazy loaded async property). @nmetulev ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. wouldn't this block the UI? Should we just have an asynchronous method to retrieve Thumbnails?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that is the best approach. But what if the developer wants to bind an image's Source property to it? I hate every since solution that I can think for this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd expect the developer to add it to their view model that extends INotifyProperty - seems like the cleanest approach

Copy link
Contributor Author

@GraniteStateHacker GraniteStateHacker May 18, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is lazy load, which is nice, since we don't want every thumbnail to load all the time, but when you'll get it when you ask for it without overhead on the client side. It will prevent the get from completing while the request is in process but other UI thread actions will continue while the request is in process... so you can bind to it without issue. If you run it, the result is a generally pleasant experience.

Copy link
Contributor

@azchohfi azchohfi May 18, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@GraniteStateHacker If you bind directly to it, it will block the UI Thread for as long as that GetThumbnailSetAsync method takes to do the request. Just remove that and add a Task.Delay(10000), to test it.
It is lazy loading it, but it is still blocking the UI Thread until it does it (that's what the .Wait() is doing).
This class is a Model, not a ViewModel, so it should not be bind directly to. Properties should return immediately (<50ms). This property should be replaced by a method that returns a Task, this way, the developer can wait for it's completion and create their own VM that handles that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha, sorry, I was forgetting that Task.Run doesn't keep you on the UI thread, so it doesn't matter that the await is used within it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Once you remove this property @GraniteStateHacker , I think we should be good to go.

@GraniteStateHacker
Copy link
Contributor Author

GraniteStateHacker commented May 22, 2018 via email

@GraniteStateHacker
Copy link
Contributor Author

GraniteStateHacker commented May 22, 2018 via email

@@ -23,98 +26,89 @@ namespace Microsoft.Toolkit.Services.OneDrive
/// <summary>
/// GraphOneDriveStorageItem class.
/// </summary>
public class OneDriveStorageItem
public class OneDriveStorageItem : INotifyPropertyChanged
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels weird extending INotifyPropertyChanged for just one property. This is a model level class so I don't think we should be extending the interface at all. How do you feel about removing the Thumbnail property and adding a return value to the GetThumbnailAsync method so the developer can create their own ViewModel?

Copy link
Contributor Author

@GraniteStateHacker GraniteStateHacker May 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrestled with this, myself, but decided that we're already binding to the class in the UI, now... I felt my choices were to either make the class support the interface, or build out a new viewmodel. The latter felt like overkill, too, but I really wanted to allow the user to continue to bind to the property, as we're already exemplifying, and achieve the expected result. Again, not gonna fall on my sword over it, but that was my rationale... if you still feel it needs to go, lemme know and I'll get it out.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like this, but I still think is the best solution. Only thing I would change is that now you don't need the Method... Lazy loading (fire and forget, so no .Wait()) would be perfect as it would update the UI when needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me check in that tweak just to see what it looks like, and to make sure I understand you. (will pull it back out if I misunderstood).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You just need to handle multiple requests (don't do them), and make sure you are on the UI thread when you set the variable back.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok... had to tweak a condition logic bug, but that makes it behave relatively nicely.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The project is not building. Remember that the Services project is using multi-targeting. This means that you can't use the namespace 'Windows' on it. Don't dispatch the call to the UI Thread if you are not on Windows 10. Wrap everything that uses that namespace on a #if WINRT. Also, never use async void. Change that method to "async Task" (still don't await or .Wait() on it, so it still is a fire and forget method) and return the newValue variable. This makes it possible to await that operation if you are not binding to pre property, but you want it's value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotta admit, the thought that any part of this might be targeting anything other than Windows 10 never crossed my mind. Feeling a bit outta touch... sorry.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is a good reason to go the route of the separate viewmodel. I'll refactor.

@@ -83,5 +93,30 @@ public OneDriveStorageFile(IBaseClient graphProvider, IBaseRequestBuilder reques
var renameItem = await base.RenameAsync(desiredName, cancellationToken);
return InitializeOneDriveStorageFile(renameItem.OneDriveItem);
}

/// <summary>
/// gets the smallest available thumbnail url as string for the OneDrive file item, asyncrounously, and applies it to the Thumbnail property.
Copy link
Contributor

@azchohfi azchohfi May 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upper case. I would rename this method. It's a "Get" method that does not return anything(aside from the Task). Either make it return a Task < string > (and then do both, update the property and return the value) or change it to be a Task UpdateThumbnailPropertyAsync();

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's the last comment. I promise.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOL Gotta say, thumbnails seem wildly disproportionately difficult for the value it feels like they provide.

@azchohfi azchohfi merged commit 4381c30 into CommunityToolkit:master May 23, 2018
@GraniteStateHacker GraniteStateHacker deleted the GraniteStateHacker branch May 23, 2018 19:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants