►
From YouTube: Microsoft Graph Community Call – April 2021
Description
This month's community call features presentations on 1) Microsoft Graph Java SDK v3 (New features and developer experience improvements), 2) Project Kiota, (Kiota streamlines SDK release process. A demo showing using Kiota to generate a TypeScript SDK for the messages subset of Microsoft Graph.), and 3) Microsoft Graph Toolkit (New - Released MGT v2.1, Get started with Microsoft Graph Toolkit Learn module and Electron Provider. Demo - building a Microsoft To Do application using Electron provider. Coming soon - File and login components plus MSAL 2.0 Provider). Q&A in chat throughout call. Call hosted by Nik Charlebois (Microsoft). Recorded on April 7, 2021.
Stay connected:
• See the full blog post for this call at - http://aka.ms/m365pnp-blog
• Twitter - https://twitter.com/microsoft365dev
• YouTube - https://aka.ms/M365DevYouTube
• Blogs - https://aka.ms/M365DevBlog
• Recurrent Invite to this community call - https://aka.ms/microsoftgraphcall
• All Microsoft 365 developer community calls – https://aka.ms/M365DevCalls
A
A
Today
we
have
a
full
agenda,
so
we're
going
to
be
talking
today
about
first
thing
is:
we
might
juggle
the
the
agenda
a
bit,
but
we're
going
to
be
talking
about
the
microsoft
365
developer
survey.
Then
we're
going
to
have
amazon
talk
about
the
microsoft
graph
version.
Three
that
was
recently
released,
then
the
famous
events
gonna
be
doing
a
an
overview
and
a
demo
of
podex
toyota,
then
we're
gonna
have
elise
and
amrita
talk
about
microsoft.
A
Graph
toolkit
tell
us
what's
new
and
what's
coming
so
first
off,
I
need
to
do
a
quick
shout
out
to
our
friend
and
colleague
sebastian
who's
out.
Today
it
is
his
birthday.
So
if
you
name
him
on
social
media,
just
make
sure
you
wish
and
happy
birthday
if
you
are
interested
in
presenting.
If
you
have
a
solution,
that's
using
the
microsoft
graph
or
if
there's
a
specific
topic,
you'd
be
interested
in
presenting
something
you've
built,
something
that
your
organization
is
working
on.
A
B
Thank
you
hi
everyone.
My
name
is
maiza
hisi
and
I
am
a
pm
on
microsoft.
Graph,
developer
experience
team.
Today,
as
nick
said,
I'm
going
to
highlight
some
of
the
new
features
and
improvements
in
our
microsoft
java
sdk.
So
we
recently
announced
the
general
availability
of
microsoft
graph
java
sdk
v3.
B
B
B
B
Filter
order
by
top
skin
skin
token
and
expand
are
maintained
through
the
use
of
query
options
to
provide
a
modern,
more
reliable
and
faster
data
and
time
api.
You
can
use
offset
data
time
instead
of
calendar
covering
a
broader
set
of
scenarios
and
providing
more
consistent
apis.
It
also
also
added
optional
parameters
for
all
data.
B
You
have
access
to
the
tailored
information
about
the
java
sdk
v3
and
find
important
link
such
as
the
upgrade
guide,
where
you
can
see
all
the
updates
for
this
new
version
and
which
improvements
are
considered
as
a
breaking
changes
and
which
are
not.
The
java
sdk
is
available
on
github,
where
you
can
read
our
week.
Open
issues
and
submit
requests,
pull
requests
so
now
I'll
hand
it
to
vincent
to
talk
about
kyoto.
Thank
you.
A
C
C
First
and
foremost,
we
have
a
different
services
like
sharepoint
onedrive
exchange
and
many
more
that
put
together.
Something
called
a
csdl.
Csdl
is
a
document
that
allows
those
different
services.
Saying
hey.
I
have
an
entity,
that's
a
drive
item,
it's
going
to
be
a
visa
and
that
place
in
the
api
and
it's
going
to
be
a
visa
and
that
way
contain
those
different
fields.
It's
a
way
for
us
as
microsoft,
but
also
for
you
to
understand,
what's
the
shape
of
the
apis
and
what
do
they
contain.
C
Once
we
have
that
csdl
document,
we,
the
sdk
team,
take
it
and
put
it
in
a
tool
called
typewriter,
which
parses
that
csdl
document
understands
the
different
data
conventions,
use
different
t4
templates
to
actually
generate
the
sdks,
because
most
of
the
sdk
that
you're
using
are
actually
generated.
They're,
not
handwritten,
because
vpi
is
way
too
large,
and
it
would
take
us
too
much
time
to
handwrite
all
of
that
for
each
and
every
language.
C
So
that's
what
happens
on
the
one
hand,
on
one
hand
we
use
typewriter
with
the
csdl,
and
that
gives
us
sdks,
but
of
course
we
want
to
make
sure
those
sdks
are
up
to
standards
very
good
quality.
So
we
have
a
second
tool
called
the
devx
api
that
generates
the
snippets
in
the
documentation.
It
also
generates
the
code
snippets
when
you
use
graph
explorer,
and
this
is
how
you
get
from
an
http
request
on
microsoft,
graph
to
a
code,
sample
code,
snippet,
in.net,
java
or
any
other
language.
C
So
we
use
that
second
tool
and
the
csdl
again
to
generate
the
different
snippets
in
the
documentation
and
once
we
have
both
the
snippets
and
the
sdks,
we
use
both
via
sdk,
in
combination
with
the
snippets,
and
we
try
to
compile
the
snippets
against
the
sdks
to
make
sure
that
the
generations
are
aligned.
Things
are
working
as
expected
and
so
on
and
so
forth,
and
if
raptor
gives
us
a
green
light,
raptor
being
the
process
that
compiles
the
snippets
against
vsdks.
C
This
is
when
we
say
all
right.
This
newer
version
of
the
sdk
that
has
the
latest
and
greatest
version
of
the
api
and
provides
the
latest
and
greatest
entities
and
fluent
api,
and
so
on
so
forth
actually
works.
We
can
release
it
in
the
open,
and
this
is
how
you
get
it.
So,
as
you
can
see,
it's
a
fairly
complex
process
today,
and
it
requires
some
knowledge
about
oh
data
and
csdl,
which
is
not
super
popular
and
easy
to
understand.
C
Some
other
challenges
that
we
are
facing,
via
viodata
complexity,
leaks
in
the
different
templates,
and
by
that
I
mean
specific
conventions
instead
of
being
understood
and
planned
for
and
parsed
for
are
at
one
place
they
are
being
done
in
different
different
templates
for
different
different
languages.
So
we
duplicate
the
effort
here.
The
t4
templates
themselves
are
great,
but
the
lack
of
tooling
they
induce
some
kind
of
duplication.
C
So
this
is
not
so
much
a
problem
for
backend
apis
on
servers
that
have
tons
of
space
and
so
on,
but
it
might
become
a
challenge
for
mobile
apis
or
front-end
mobile
applications,
sorry
or
front-end
applications
where
you
want
to
trim
down
the
size
of
the
application.
So
it's
easier
to
distribute
to
the
end
user.
So
that's
another
challenge.
Today
we
are
only
able,
via
that
tool
to
ship
sdks
for
the
full
api,
not
a
subset.
C
Also,
the
feedback
from
the
tests
become
ver
comes
very
late.
Instead
of
having
unit
testing
very
early
on
to
test
on
the
conventions
and
other
things
like
that,
we
actually
rely
on
raptor.
That
is,
at
the
end
of
a
process,
to
get
the
tests
and
to
get
the
feedback
from
the
generation
process.
Did
it
work,
did
it
produce
something
that
was
expected
and
that
slows
down
our
ability
to
innovate
and
make
major
changes?
C
So
now,
let's
talk
about
project
qrs,
so
we
still
have
the
services
that
are
onedrive,
sharepoint
exchange
and
and
many
more
that
are
building
that
csdl
description
of
the
service
and
the
apis.
And
now
we
have
a
tool.
That's
provided
by
the
open
api
community
that
allows
us
to
convert
that
csdl
document
into
an
open
api
description.
C
So
for
those
of
you
that
don't
know
about
open
api
open
api,
is
this
standard
that's
been
around
for
a
couple
of
years
now
it
used
to
be
called
swagger
a
long
time
ago,
and
it's
a
way
of
a
standardized
way.
That's
broadly
adopted
to
describe
your
api
and
to
say
all
right.
My
api
has
all
those
endpoints.
They
accept
those
different
parameters.
C
C
If
we
talk
about
the
high
architecture
before
we
dive
dive
into
the
code
again,
we
have
this
open
api
document
that
comes
in
qra
has
a
builder,
so
that
builder
uses
the
open
api,
libraries
and
parses.
The
document
thanks
to
that
and
generates
a
code
dumb
so
a
little
bit
like
you
have
web
browsers
that
have
that
generator
code
down
from
the
html.
They
receive
to
understand
all
the
different
elements
that
are
on
the
page
and
what
we
need
to
display
on
the
screen
for
the
user
and
those
different
different
things.
C
Well,
we
kind
of
have
the
same
mechanism,
but
for
code,
this
code,
dom
is
a
very
high
level,
abstract
notion
of
hey.
We
need
a
class
or
hey.
We
need
a
method
or
hey.
We
need
a
property
in
within
that
class
and
so
on
and
so
forth,
and
we
describe
at
a
very
high
level
abstracted
all
the
things
we
need
to
generate
in
the
sdk.
C
Once
we
have
that
code
down,
we
use
it
and
we
feed
it
into
the
language
refiner,
which
is
a
way
for
us
to
flavor
that
code
down
in
a
dot-net
kind
of
way
or
flavor
that
code
down
in
a
typescript
kind
of
way
or
flavor
again
in
in
different
different
languages.
Why
are
we
doing
that?
Well,
some
languages
support
more
or
less
features.
C
A
few
advantages.
So,
as
we've
seen,
your
data
conventions
are
abstracted
away
by
the
open
api
conversion
step.
So
that's
something
what
we
are
not
responsible
for
anymore:
that's
the
open
api
and
the
data
communities
that
are
doing
that.
For
us,
it's
more
robust.
It's
at
one
place.
There
is
no
more
duplication
anymore.
C
We
have
a
very
testable
generation
process
that
was
kind
of
one
of
the
key
requirements
or
kind
of
a
key
design
we
had
in
mind
and
the
idea
that
was
that
we
wanted
to
design
and
build
a
generator,
that's
easy
to
test
and
to
unit
test.
So
we
can
get
feedback
very
early
on
and
iterate
on
that
feedback
very
early
on,
rather
than
later
in
the
process,
we
don't
have
any
duplication
within
the
languages.
C
If
I
want
to
define
how
do
I
write
a
method
in
java,
I
only
do
it
once
at
one
place
in
the
writer
and
then
it's
been
reused
whenever
it's
needed,
but
we
don't
have
duplication
of
what
is
a
method,
how
to
define
the
accessibility
of
that
method
and
so
on
and
so
forth
anymore
within
the
languages.
It
is
done
once
per
language.
C
It's
it's
gonna,
be
easier
to
contribute
to,
and
the
reason
is
because
we're
relying
on
plain.net
there
is
no
t4
anymore.
The
tooling
support
is
great
and
it's
easier
to
understand.
For
community
members,
we
are
also
going
to
be
able
to
ship
modular
sdks,
so
part
of
the
vision
is
to
give
you
a
way
to
say:
hey.
I
want
to
have
only
the
mail
things
for
microsoft
graph,
because
I
don't
my
application
will
only
do
that.
I
don't
care
about
the
files
I
don't
care
about.
C
I
don't
know
the
security
policies
or
anything
like
that,
because
my
application
is
not
going
to
touch
that.
So
I'm
going
to
select
both
different
aspects
and
those
different
endpoints
in
some
kind
of
tool
that
will
provide
you
and
then
you
will
be
able
to
generate
your
own
sdk
for
your
application,
using
qra
for
just
that,
smaller
part
of
microsoft
graph,
which
will
be
super
appreciated
by
mobile
applications
or
front-end
applications
or
other
kind
of
applications
like
that,
and
thank
you
for
all
the
hearts
and
the
claps.
C
It
also
will
work
with
any
app
any
api
that
has
an
open
api
description,
so
we're
building
the
tool
in
a
way
that
it
works
first
for
microsoft,
graph
and
the
sdks
that
we're
we're
building.
But
if
you
have
in-house
apis
and
evo's
apis
have
an
open
api
description.
You'll
be
able
to
use
kyoda
feed
in
that
open
api
description
instead
and
get
a
fluent
sdk
in
the
language.
D
C
Choice
for
that
specific
api
and
lastly,
it's
also
plug
and
play.
We
received
feedback
that
some
people
prefer
this
or
that
json
serializer,
for
example,
or
some
people
prefer
this
or
that
http
client.
So
it
is
also
designed
in
a
way
that
we
have
a
high
level
of
abstraction,
will
provide,
of
course
default
implementations.
C
C
So
here
I
have
and
before
we
dive
into
kyoto
itself.
I
have
this
open
api
description
here.
It's
rather
lengthy
and
we
don't
need
to
go
over
the
details,
but
that's
a
description
that
we
use,
for
example,
to
generate
the
partial
sdks
today,
and
the
idea
is
that
description
only
contains
males
things.
So
things
about
sending
emails,
getting
the
emails
from
microsoft,
graph,
getting
the
attachments
all
those
different
things.
C
It
doesn't
contain
anything
else
than
things
that
are
related
to
my
to
microsoft,
graph
messages,
capabilities
and
it's
effectively
a
subset
of
microsoft
graph,
and
so
that's
the
first
thing
in
terms
of
how
yoda
is
built.
Well,
we
do
have
a
few
things
here.
First,
we
have
a
generator,
that's
contained
in
the
source
folder,
and
you
will
see
that,
as
I
mentioned,
we
have
a
different
constructs
for
the
code
dom.
So
what
is
the
namespace?
What
is
the
method?
C
What
is
your
class
and
those
different
things,
but
we
also
have
different
writers
for
the
different
languages
for
typescript,
java
and
and
c-sharp
here
as
well,
and
the
different
writers
for
the
different
languages
here
that
are
available.
And
finally,
we
also
have
a
builder
that
I
was
mentioning
earlier
that
takes
in
the
open
api
description.
C
So
that's
that's
a
high
level
overview
of
how
kyoda
works,
I'm
going
to
fire
off
a
generation
and
show
you
what
you
get
out
of
it
and
before
I
do
that
here
I
have
this
other
project,
which
is
typescript
starter
for
a
node.js
application.
I
chose
typescript
for
today
and
I
chose
a
node.js
application
for
today
as
well,
but
this
would
work
in
a
browser.
This
would
work
in
dot
net
or
in
java
as
well.
Those
are
the
free
languages
we're
supporting
today,
so
I'm
going
to
go
ahead
and
clear.
C
So
I've
set
up
cuda
to
I've,
set
up
my
environment
to
be
able
to
generate
things.
So
here
you
can
see
that
I'm
calling
kyota
not
for
java
for
typescript
here
we
you
can
see
that
I'm
calling
kyota,
I'm
passing
it
the
open
api
description,
I'm
saying
hey,
I
want
a
typescript
thing
and
please
put
all
the
files
here
and
here's
the
namespace,
even
though
it's
not
namespace
in
typescript
that
I
want
you
to
generate
things
in
as
well.
So
I'm
going
to
kick
off
the
generation
process.
You'll
see
that
very
quickly.
C
C
So
again,
all
of
that
is
going
through
the
open
api
description,
generating
a
code,
dom
parsing
refining
the
code,
dom
you
know
typescript
flavor
and
then
calling
the
writer
to
write
all
the
different
files
to
the
local
storage
and
there
we
go
generation
is
finished
so
again
within
a
few
seconds
and
keep
in
mind
that
me
being
sharing
my
screens
only
impacts
the
performance
of
my
computer.
We
were
able
to
generate
an
sdk
for
the
messages
subset
of
microsoft
graph.
C
So
here
you
can
see
that
all
the
things
that
I
had
previously
deleted
are
back
and
one
great
thing
about
kyoda.
Is
we
try
to
make
it
so
what
we
generate
is
easy
to
map
with
the
api,
so
you'll
see
that
the
folders
or
the
namespace
segmentation
is
very
close
to
what
you
find
in
the
api.
We
know
that
messages,
for
example,
are
attached
to
users
or
are
under
users
or
groups,
of
course,
on
the
microsoft
graph
api.
So
you
can
see
that
under
users
I
have
a
message
entity
here.
C
C
So
now,
if
we
jump
into
the
application,
my
actual
application,
you
can
see
that
the
first
thing
I'm
doing
here
is
I'm
using
azure
identity
to
get
the
token
and
to
authenticate
against
microsoft
graph,
I'm
passing
that
authentication
provider
to
the
core
provider.
So
again,
that's
one
of
the
things
we've
implemented
by
default.
We've
implemented
a
way
using
fetch
to
talk
to
microsoft
graph
behind
the
scenes.
C
All
of
that
is
plug
and
play
as
well
as,
as
I
mentioned,
and
you're
ready
to
go
you're
ready
to
use
the
the
api.
So
here
what
do
I
have?
Let
me
just
because
I
made
it
bigger
here.
You
can
see
that
if
I
do
client
dot,
control
space
you'll
see
that
I
get
my
phone
api.
So
I
get
users
I
can
get
all
the
users.
If
I
want
to.
If
I
get.
If
I
want
to
get
a
single
user,
I
can
get
a
single
user.
C
C
C
There
we
go
so
here.
It's
telling
me
hey,
because
I'm
using
the
device
code
flow,
but
again
it's
because
of
azure
identity.
It
would
work
with
any
kind
of
flow
for
the
back
end
for
the
front
end
for
anything
you
want
to
do,
and
here
I'm
going
to
chrome
with
my
debugging
profile
entering
the
code
saying
signing
in
and
that's
it
I'm
ready
to
use
my
app
that
I'm
showing
to
you
here.
C
So
if
we
get
back
here,
I
have
a
breakpoint
that
stopped
here,
so
you
can
see
that
what
happened
here
using
the
fluent
api
I've
used
my
client.
I
got
my
own
user
here.
I
got
a
specific
message
with
a
specific
id
and
I
executed
a
request
with
a
dot
get
here.
If
I
can
hover,
you
can
see
that
I
have
my
decilize
message
with
all
the
different
properties
with
sub
properties.
Eventually
it
all
visualizes
recursively
that
are
available,
and
here
then
I'm
using
this
message,
I'm
getting
the
subject.
C
C
Oops,
sorry
about
that,
I'm
creating
a
new
message,
I'm
setting
the
different
properties
I
want
to
set
all
of
that
again
supports
auto
completion
because
we're
using
typescript-
and
here
I'm
using
the
default
serializer-
that's
provided
to
actually
serialize
the
message
that
would,
I
could
eventually
send
or
do
anything
with
on
the
wire.
We
also
support
enumerations.
We
support
collections,
of
course,
and
many
many
other
things,
and
here
you
can
see
in
the
console
that
I
have
my
serialized
payload
here
with
the
different
properties.
A
C
Sure
that's
my
next
slide.
So
if
you
want
to
get
started
with
kyota
one
place
to
go,
github.com
microsoft,
slash
kyota,
that's
k,
I
o
t
a
and
there
you
can
do
a
couple
of
different
things.
We
still
have
a
couple
of
poll
requests
to
merge
and
clean
up,
but
you
can
go
and
try
qra,
either
on
your
own
api
or
on
microsoft
graph
and
give
us
feedback
around
that.
C
You
can
also
tell
us
your
expectations
about
typescript
fluent
api,
because
one
of
the
first
things
we're
trying
to
call
via
kyota
is
to
make
sure
you
get
a
fluent
api
for
typescript,
because
we
know
that's
been
a
consistent
request
for
the
past
few
years.
Let's
say
so.
If
you
have
expectations
in
terms
of
typescript
format,
api,
what
it
should
look
like
how
it
should
behave,
all
those
different
things,
it
is
feedback.
C
We
want
to
hear
about
you
these
things
we
want
to
discuss
with
you
about,
so
we
make
sure
we
build
the
greatest
typescript
fluent
api
and
with
that,
if
there
are
no
questions
I'll
hand
it
to
the
microsoft
graph
toolkit
team
to
tell
us
more
about
their
new
features
and
new
capabilities.
Thank
you
very
much.
E
E
First
off
for
what's
new,
we
released
version
2.1
of
the
toolkit
a
couple
weeks
ago,
so
this
includes
a
lot
of
new
features
and
improvements
to
what
we
released
with
2.0.
So
if
you
haven't
seen
that
yet
or
haven't
tried
it
out,
I
would
highly
recommend
that
you
do
so.
You
can
just
go
download
it
from
our
repository
at
ak.m.s
mgt.
E
Another
thing:
that's
new,
is
that
we
have
a
new
microsoft
graph
toolkit,
learn
module,
which
was
created
by
the
advocates
aicha,
rabia
and
waldex.
So
thanks
to
them,
I
would
recommend
trying
this
out
if
you
haven't
used
the
toolkit
at
all.
Yet
it
gives
a
great
overview
of
what
the
toolkit
is
and
also
walks
you
step
by
step
through
how
you
can
build
your
first
single
page
application
using
the
toolkit
and
finally
another.
D
Now,
before
I
get
into
what
that
is
in
case
you're,
not
aware
of
the
toolkit,
I
thought
I'd
give
you
a
brief
intro.
So
the
microsoft
graph
toolkit
is
a
collection
of
ui
components
and
authentication
providers
that
make
using
the
graph
really
really
easy
and
help
you
create
these
data
rich
and
user-centric
experiences
with
very
few
lines
of
code
in
your
application.
D
So
there
are
two
parts
to
that:
ui
components
and
authentication
providers.
So
when
you
talk
about
the
ui
components,
these
are
fully
functional
right
out
of
the
box
and
they
use
data
from
the
graph
and
they
help
you
render
it
really
beautifully
with
just
basically
two
to
three
lines
of
code
and
the
best
place
to
kind
of
explore.
All
the
components
we
have
is
here
at
mgt.dev.
D
As
you
can
see,
this
actually
is
pulling
data
from
the
graph
to
render
this
for
you.
Similarly,
you
have
a
component
like
mgt
agenda,
so
all
you
have
to
do
is
include
this
html
tag
and,
of
course,
import
our
library
and
authenticate
to
get
all
of
this
beautifully
rendered
agenda
data
and
they're
super
customizable
with
your
own.
You
can
add
your
own
css
make
them
match
the
look
and
feel
of
your
application.
D
So
that's
that's
where
ui
components
are
concerned
and
they're.
Oh
sorry,
there
are
a
lot
more
components
here
on
the
left
that
you
can
go
and
look
at
and
play
with.
So,
as
you
can
imagine,
all
of
these
components
use
the
use
the
graph
in
a
different
way.
They
call
different
graph
apis,
so
we
have
to
first
be
authenticated
with
microsoft,
identity
to
be
able
to
get
these
access
tokens
for
the
graph
and
that's
where
our
authentication
providers
come
in.
D
So
we
have
different
authentication
providers
for
the
different
platforms
that
you
may
want
to
build
on
that
help
abstract
away
all
of
that
code
that
you
would
need
to
get
access
tokens
not
only
for
these
ui
components
to
work,
but
also
it
gives
you
a
graph
endpoint
to
call
any
graph
api
of
your
choice
and
so,
like
I
said
we
have
different
providers
for
different
platforms.
So
if
you
were
building
a
web
application,
you
would
be
using
our
msl
provider
if
you
were
building
a
sharepoint
web
part
you'd
be
using
a
sharepoint
provider.
D
Similarly,
if
you're
using
it,
if
you're,
building
a
teams,
tab
you'll
be
using
a
teams
provider
and,
last
but
not
least,
if
you're
building
an
electron
app,
you
can
use
our
electron
provider
and
there's
a
very
simple
example
of
how
you
would
use
an
m
cell
provider
here
for
our
web
app
for
a
web
application.
So
all
you
need
to
do
is
import
the
provider
from
our
package
and
then
say:
providers.google
provider
initialize,
the
msr
provider,
with
a
client
id
of
your
app
app
registration,
and
that's
basically
it
that's
all.
D
D
That
you're
looking
at
right
now
are
electron
applications
and
electron
has
two
kinds
of
processes
main
and
renderer
right,
and
you
can
think
of
main
as
back
end
and
render
as
the
front
end.
So
the
main
process
is
responsible
for
the
application
life
cycle
for
all
native
interactions
and
also
for
creating
render
processes.
The
renderer
is
the
ui,
so
every
page
that
you
would
have
in
your
electron
application
would
be
associated
with
a
renderer
process
and
the
main
process
kind
of
controls,
the
generation
and
deletion
of
these
render
processes.
D
D
This
is
the
electron
provider
itself
it's
in
its
own
package
and
then
mgt
element
is
the
base
package
that
allows
these
components
and
providers
to
interact
with
each
other
and
what
we're
going
to
be
building
today
is
a
very
simple
to
do
application,
so
we
can
go
over
here.
So
now
we're
going
to
try
to
get
authenticated
first
using
the
provider
so
in
the
main
process
we're
going
to
be
initializing.
D
What
I've
done
here
is
I've
created
a
config
object
of
all
the
the
details
that
you
would
need
to
pass
to
initialize
electron
authenticator
like
your
app
registration,
the
window
on
which
you
want
to
get
authenticated,
which
is
this
browser
window
instance
and
all
the
scopes
that
you
would
need
to
call
all
the
apis
or
to
render
all
the
ui
components
and,
last
but
not
least,
initialize
the
authenticator
and
we're
done
with
this
part.
So
there's
only
one
step
left,
which
is
in
the
renderer
process.
D
D
So
I
added
mgt
login,
which
is
our
login
component
mgt
person,
which
shows
personal
details
of
the
person
logged
in
and
mgt
to
do
basically
displays
all
your
to-do
information
from
microsoft.
To
do
so,
wait
till
it
runs
again.
I
think
it's
taking
more
time
than
usual,
because
I'm
sharing
my
screen
so
just
to
recap:
we
initialize
the
electron
authenticator
and
the
main
process
and
we
initialized
electron
provider,
and
then
we
added
some
mgt
components.
A
In
the
meantime,
for
folks
that
are
following
the
staff,
jeremy
just
put
out
a
quick
survey
out
there
and
we're
just
interested
in
knowing
how
many
devs
are
actually
doing,
relaxing
doing
dev
and
like
an
alt
right
now.
But
if
you
can
just
do
a
thumbs
up
on
jeremy's,
both
we're
just
surveying.
Just
quick
surveys.
Try
to
understand
like
where
you
guys
are
actually
or
not
with
that.
A
D
Password
and
then
once
you're
logged
in
the
login
component
will
display
your
name
and
your
picture
and
yeah.
So
all
of
this
data
just
rendered
right
away
and
that's
pretty
much
how
easy
it
is
to
get
started
with
the
electron
provider.
And
so,
as
you
can
see,
this
is
the
login
component,
and
then
you
have
the
person
component.
That
has
a
picture
and
also
your
status,
your
name
and
you
can
always
customize
the
amount
of
data
you
want
to
display
here
and
then
all
of
your
to-do
tasks
straight
from
microsoft.
To
do
now.
D
D
D
My
app
actually
turns
to
dark
theme-
and
I
did
this
solely
for
the
purpose
of
showing
off
that
mgd
supports
dark
theme
and
all
you
have
to
do
to
enable
that
is
to
add
a
class
to
all
your
mgt
components
or
in
your
document,
in
your
body,
dot
element,
but
also
my
wallpaper
changed
to
this
giraffe.
That's
telling
me
that
it's
watching
me
and
I
need
to
get
back
to
work.
D
Similarly,
when,
when
I'm
done
with
work,
I
like
to
appear
away-
and
I
also
have
this
bad
habit
of
lingering
on
on
my
laptop
when
I'm
done
with
work,
but
really
I
should
be
working
out.
So
I
have
my
wallpaper
reminding
me
that
I
need
to
go
work
out
with
this
cute
little
kitten,
so
how
I'm
doing
that
is
in
this
application.
D
It's
basically
the
same
the
same
code,
so
as
you
can
see,
this
is
the
renderer
process
and
we
initialize
the
electron
provider.
Here.
What
I
did
was
I
I
npm
installed
a
package
called
wallpaper
that
allows
me
to
do
all
the
wallpaper
changing
magic
and
what
I'm
basically
doing
is
pulling
presents
data
from
the
graph
every
five
seconds,
and
this
is
how
I'm
doing
it.
So
you
can
subscribe
to
the
on
state
changed
event
on
the
provider
that
will
fire
every
time.
There's
a
log
in
or
log
out.
D
So
I'm
checking
here
if
a
person
is
signed
in
and
then
I'm
calling
this
function
called
check
presence
that's
going
to
pull
data
every
five
seconds
from
the
graph
for
the
presence
data.
So
this
is
how
I'm
calling
the
graph.
So
I
don't
know
if
you
remember
that
I
said
that
all
our
providers
give
you
expose
a
graph
endpoint
that
allows
you
to
call
any
graph
api,
so
here
I'm
using
that
graph
endpoint
to
call
the
presence
api
and
I'm
also
checking
based
on
what
the
response
I
receive.
D
I'm
checking
what
the
the
status
is
and
based
on
that
I'm
changing
the
wallpaper
using
the
wallpaper
npm
package
and
one
more
thing
I'm
doing
is
I'm
also
able
to
manually
set
the
presence
over
here,
because
in
our
person
component
we
use
a
different
polling
frequency
to
poll
for
presence.
But
since
I
am
pulling
presents
every
five
seconds,
I
want
to
manually
update
that
every
time
I
find
every
time
I
get
the
presence
data,
so
I
just
pull
the
mgt
person
dom
element
and
then
I
manually
add
the
presence
object.
D
A
D
E
So
russo
showed
us
what
the
electric
provider,
which
is
available
now
and
then
now
we're
gonna,
show
a
couple
of
things
that
we're
currently
working
on,
give
you
a
preview
of
them.
So
first
we
have
three
new
components
that
we're
working
on
file
file
list
and
file
picker
components.
So
all
three
of
these
are
using
the
onedrive
and
sharepoint
apis
on
microsoft
graph
in
order
to
get
drive
item
data
and
render
them
in
a
component.
E
D
So
basically,
if
you
want
to
switch
from
msl
to
msr2
provider,
you
also
have
to
have
a
different
app
registration
and
you
have
to
register
as
your
redirect
uris
as
a
single
page
application,
but
we
will
definitely
be
giving
you
docs
for
that
to
make
sure
that
your
experience
with
that
is
as
seamless
as
possible.
So
yeah
you
can
play
the
video
now
yeah.
So
all
you
have
to
do.
Is
you
see
in
the
in
the
videos
screenshot?
E
One
of
the
added
benefits
of
switching
to
msl
2.0
is
that
now
there's
support
for
logging
in
with
multiple
accounts,
so
we're
also
updating
our
login
component
to
support
that
as
well.
So
this
is
a
preview
of
the
current
design
that
we
have
right
now
subject
to
change,
but
I
just
wanted
to
show
how
it's
looking
taking
any
feedback
or
questions
on
this
as
well.
E
I
wanted
to
show
actually
the
three
file
components
that
we're
working
on.
We
do
have
previews
available
for
them,
so
this
is
the
first
component.
It's
just
mgt
file,
so
it's
used
to
represent
a
single
drive
item,
that's
retrieved
from
microsoft
graph
and
you
can
display
the
file
with
its
file
type
icon
as
well
as
properties.
E
However,
many
you
want
it's
configurable
by
you
as
a
developer,
and
there
are
multiple
ways
for
you
to
actually
specify
which
file
that
you
want
to
show.
So
in
this
example,
we're
giving
the
full
file
query
to
an
item.
You
could
also
provide
the
drive
id
and
item
id
for
an
item
in
a
specific
drive
same
with
the
site
id
or
you
can
also
specify
by
insight
type.
So
the
insights
api
on
microsoft
graph
has
provides
three
different
insight
types
which
is
shared
recently
used
and
trending.
E
E
So
you
can
change
how
many
lines
of
text
that
is
shown
as
well
as
change
what
properties
are
being
shown
as
well
and
then
the
second
component
that
we're
working
on
is
the
file
list.
So
this
is
a
representation
of
a
list
of
files.
That's
retrieved
from
graph
by
default,
it'll
show
the
signed
in
user's
root
drive.
So
that's
what's
happening
here
shows
the
folders.
You
can
expand
the
list
to
show
additional
items.
E
And
then,
similarly
to
the
file
component,
there
are
multiple
ways
where
you
can
specify
what
list
of
files
that
you
want
to
show.
So
this
is
an
example
showing
using
a
file
query
so
providing
the
full
path
to
where
the
files
are.
You
can
do
the
same
thing
with
the
drive
id
and
show
files
within
a
specific
drive
or
folder
same
with
site
id.
E
And
then
insights
as
well,
so
here
we're
showing
the
files
for
this
user
that
are
returned
by
the
trending
insight
type
and
then
the
third
one
that's
coming
will
be
file
picker.
We
don't
have
a
preview
of
that
yet,
but
it
will
be
coming
soon,
and
so,
if
you
want
to
try
either
the
file
components
or
the
msl
2.0
provider,
you
can
do
that
now
by
using
the
next.file
or
next.msl2
provider
preview
packages.
D
A
Perfect
yeah
and
those
links
are
going
to
be
available
on
the
actual
blog
post
that
we
put
out
for
the
community
talk.
So
again.
I
appreciate
your
time.
Great
work
from
the
mgc,
soon
always
exciting,
with
spokesperson
presents,
so
I
appreciate
your
time
at
least
and
I'm
rooting
yeah
so
with
for
the
last
30
minutes,
just
some
out
cleaning
stuff.
So
we
have
the
microsoft
graph
tap
program.
The
tap
program,
basically,
is
a
monthly
call
that
we
have.
A
We
have
our
next
call
tomorrow
and
it
gives
you
access
to
some
new
up
and
upcoming
features
right.
We
notify
you,
we
introduce
what's
coming
down.
The
five
gives
you
an
overview
of
the
roadmap.
We
present
some
case
studies
and
it's
another
opportunity
for
you,
folks,
their
feedback
for
the
product
group.
So,
if
they're
interested
we're
still
looking
for
additional
partners
and
customers
to
join
the
the
tap
program,
there's
a
link
at
the
bottom
here
again
that
link
is
going
to
be
available
on
the
blog
post,
so
instagram.
A
A
We
have
our
weekly
podcast
with
jeremy
and
paul,
so
always
great
content.
Great
guests
on
the
show
feel
free
to
register
to
that
great
stuff
to
listen
to,
and
last
but
not
least,
we
also
have
the
microsoft
graph
mailbag
blog
series
that
we're
putting
out
we're
putting
them
out
twice
a
month.
So
we
have
one
on
the
second
and
the
fourth
tuesday
of
the
month.
A
The
next
one
is
going
out
next
tuesday,
great
content
there
as
well
again,
thank
you
for
joining
the
recording
will
be
available
on
the
youtube
channel
at
ak.msl,
m365
dev
youtube.
You
can
follow
us
on
twitter
at
microsoft365,
dev
and
the
next
community
call
is
going
to
be
on
may
4th
at
8pm,
so
you
can
actually
grab
the
calendar,
invite
at
ak
dot,
math
microsoft
craft
call.
So
again,
I
was
next
to
the
blog.
Thank
you
for
your
time.