Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts

Google OAuth2 for UWP C# XAML Apps Example

I have previously posted on consuming Google YouTube APIs in UWP C# XAML apps, showing how to consume Google APIs using the API key technique for authentication.

That technique works well, but has its drawbacks.  Mainly, you can't access any of the non-public user specific information that the APIs expose.  In other words, to get to the juicy bits you need to make authenticated Google API calls.  To do that, you need to work out Google OAuth2 authorisation flows.

Now, that's easier said than done if you are a part time hack like myself, and not a serious developer.  Through lack of skill I need to rely on the dotnet API libraries that Google kindly provides.  There are a good number of blog posts out there that detail the API key method, but not many that have a working example for using Google OAuth2 as per Google's developers API reference samples..

This is where this post kicks in.  But it also comes with a disclaimer (see below).  The following code snippet is an actual working example for a Google API OAuth2 authentication flow.  It uses the Google provided libraries which can readily be downloaded from Nuget and implemented in your project in Visual Studio.  Just use the Nuget Package Manager and search available packages for Google.Apis.

The magic sauce here is that the good folk at Google have fixed the OAuth flow for UWP C# only in a beta release of their dotnet libraries.  Specifically version 1.31.0 beta 01.  In the package manager, make sure to tick the box to include pre-releases, or else you won't get the beta on the list of available packages.


And here is the disclaimer... the mainstream release - currently up to 1.32.0 - does NOT work.  The code will build but fail at run time.

Enough said.  Following is the example code that will manage your Google OAuth2 authentication flow for you.  It prompts the user to log in with a Google account, authorise our example App, access the user's AdSense account, grab a list of payments for the account and finally display the results as the items source on a XAML ListView. Sounds tough?  Not really, just a few lines of code 😃

Of course, instead of accessing the AdSense Management API we could access the YouTube Data API or any of the other Google APIs presumably. I have only tested AdSense and YouTube, though.

     private async void PopulateAdsenseList()
     {
         UserCredential credential;
         using (var stream = new FileStream("client_secret.json", FileMode.Open, FileAccess.Read))
         {
             credential = await GoogleWebAuthorizationBroker.AuthorizeAsync(
                 GoogleClientSecrets.Load(stream).Secrets,
                 new[] { AdSenseService.Scope.AdsenseReadonly },
                 "user",
                 CancellationToken.None
                 );
         }
         var adSenseService = new AdSenseService(new BaseClientService.Initializer()
         {
             HttpClientInitializer = credential,
             ApplicationName = "Your App Name",
         });
         var myPayments = adSenseService.Payments.List().Execute();
         MyList.ItemsSource = myPayments.Items;
     }

Of course you will have to have a XAML page with a ListView (in this case called "MyList") to display the retrieved list of payments.

Just remember, don't be tempted to upgrade your Google.Api Nuget packages.  Stick with the 1.31.0. beta 01 release, or your code will break!  We'll have to wait until the devs at Google fix the libraries properly for UWP support.

Hopefully the above makes sense and you enjoyed reading this post.  If you have any questions or comments, why not drop me a line via email or comment below.

Cheers

MB


Visual Studio Team Services - 5 Good Reasons that make it a Great DevOps Toolkit for Everyone

Microsoft Visual Studio Team Services - A great DevOps Toolkit for Agile Teams

Really, I hear you ask? Why is that? Are there not more established players with better tools in the market? Well, let's give it a bit of context...

Traditionally we would run projects at work the old fashioned way, employing a traditional waterfall delivery model. Like everyone else however, we were wondering what all the hype of Agile, Lean, Scrum and goodness-knows-what was all about. You know, all this new age rage that promises to be so much more effective in delivering projects.

Not wanting to miss out, we grabbed the opportunity as soon as a software development centric project rolled along. We decided to challenge ourselves and deliver this one using Agile. But where do you start with all that? Luckily, some of us had some formal yet basic Agile training and with a bit of research and chatting to like minded folk we felt we had a good basis to get going.

We quickly decided that an Agile wall with sticky notes, cards and blutack was not for us, even though I am of the firm opinion that you can effectively manage projects in that fashion. We wanted a tool to help us, as we set out to manage our work items like Epics, Features, Stories and Tasks, needed a Git based repository for our code, and a visual way of reporting our progress.

Looking around for tools, we quickly zeroed in on the Atlassian kit as they are certainly setting the trend in a fragmented DevOps space and appear to have mature offerings that get good reviews. However, we remembered that Microsoft are playing in this space these days with their Visual Studio Team Services (VSTS) product. In fact, Gartner recognises Microsoft as a Leader in their 2017 Magic Quadrant for Enterprise Agile Planning Tools.

So we decided to have a closer look, and here is where it got interesting. VSTS has a freemium pricing model, where small DevOps teams of up to five people can join a VSTS subscription/workspace, and use this for work item management, Git repositories, load tests and other things for free. Continuous Integration and Delivery pipelines can be set up and appear to work well particularly when used in context of Microsoft's Azure cloud services.

But I digress. The purpose of this post was to outline the key reasons why I think it is worthwhile looking at VSTS if you are a small team wanting to get in on the Agile act and you are looking for a tool to help.  So here we go, in no particular order...

Five Good Reasons that make VSTS a great DevOps toolkit

1. Ease of setup and onboarding - get going fast

Just head over the visualstudio.com/team-services and sign up for free to create your workspace. Then simply create a New Project, give it a Name and Description, select your Version Control format as Git, and your Work Item Process methodology as Agile.


Voila, this will give you a new project shell, with a dashboard for visualisation, a git repository to manage your code, and a work item management area with initial iterations configure.  There is a bit more setting up to do, but it is all very intuitive and within an hour or two you will have everything exactly as you need it to start managing your project

2. It's free for up to 5 people

Yes, free.  Free private Git repos, work tracking, load testing (to a degree), CI and CD pipelines.  And if you have a MSDN subscription by chance, you don't count against the limit of 5 free people but can access it in addition.  Free stakeholder access also included

3. Seamless Git integration with Visual Studio

If you develop in Visual Studio, VSTS will seamlessly integrate.  Push and pull / synch your code to the Git repo online.  Never leave your IDE.

4. Collaborative work item management

Easily manage your backlog, plan your sprints and work collaboratively using mentions to easily keep team members up to date on progress

5. Visually track progress

Sprint burn down, cumulative flow and team velocity charts come out of the box and together with your backlog and task board views allow you to keep track of what is happening at any point during your project


VSTS really served us well and was simple and intuitive to use.  We delivered the full scope of the project right on time and budget.  Reporting and tracking was a breeze thanks to the built in charts that came right out of the box.  And did I mention it did not cost us a cent to get the tool? \

I have to admit I am a bit of a fan - not often you get a useful solution like this for free.  Give it a shot if you are out there wondering about Agile DevOps tooling to use in your next project, and let me know how you went.

Cheers

MB


Some further reading:

Visual Studio Team Services
Atlassian






Most Popular Posts