Building a YouTube “Study & Rating” Desktop App in C# (WPF) — From Search Cards to SharePoint Online Notes

Below is a public, end-to-end technical article describing the WPF app you built: a YouTube search experience that renders results as visual cards (thumbnail + title + description) and opens videos in the browser. We’ll also outline the next step: adding a personal rating system and saving your scored videos to SharePoint Online—without exposing any secrets or tenant-specific details.

Public-safe note: All identifiers (keys, client IDs, secrets, tenant URLs, list names) are shown as placeholders. Never publish real credentials in code, screenshots, or logs.

What the App Does

This app is a lightweight YouTube learning dashboard you can run locally:

• Type a query (e.g., “sharepoint spfx pnp”)
• Click Search
• The UI displays cards with:
  • thumbnail (preview image)
  • video title
  • short description
  • channel name
  • an Open button to watch in the browser

Screenshot reference (UI concept): a WPF window titled YouTubeAppsWpf, with a search bar and button at the top, and a scrollable grid of video cards (3 columns) beneath it.

Why This Is a Great “Study App” Project

A YouTube “study organizer” is a perfect lab project because it combines:

• API consumption (YouTube Data API)
• UI rendering (WPF data binding + card layout)
• MVVM patterns (ViewModel + ObservableCollection)
• Error handling & quotas
• Future data persistence (SharePoint Online for notes/ratings)

It’s not just a “search UI”—it’s a foundation for your own learning workflow.

High-Level Architecture

1) UI Layer (WPF)

• MainWindow.xaml contains:
  • TextBox (query)
  • Button (search)
  • ItemsControl with WrapPanel (card layout)
  • ScrollViewer (pagination-like scroll UX)

2) ViewModel (MVVM)

• MainViewModel.cs:
  • Query (string)
  • Videos (ObservableCollection)
  • Status (string)
  • IsBusy (bool)
  • SearchCommand (Async command)
  • OpenVideoCommand

3) Model

• VideoCard.cs:
  • VideoId, Title, Description, ChannelTitle, ThumbnailUrl
  • computed VideoUrl

YouTube Integration Options: API Key vs OAuth

There are two valid ways to call YouTube Data API:

Option A — API Key (recommended for public search)

Best when you only need:

• search results
• public metadata

Pros

• simplest
• no login prompt
• fewer moving parts

Cons

• quota can be consumed fast if you search frequently

Option B — OAuth (needed for user actions)

Required if you want to:

• create playlists
• manage subscriptions
• access private user data

Important public guidance

• Desktop apps should avoid treating secrets casually.
• Prefer OAuth flows designed for installed apps (and keep tokens protected).
• Never ship or publish real secrets.

Your current app can support either mode. For a study/rating tracker, API Key is usually enough unless you’ll write back to YouTube.

Quota & Performance: What You Must Know

The endpoint behind “search” is typically search.list, which is expensive in quota terms. The best practices:

• Search only on button click (not every keystroke)
• Limit MaxResults (e.g., 20)
• Add basic caching (query → results)
• Consider “Next Page” via nextPageToken rather than infinite re-search

Card Rendering in WPF (The Core UI Pattern)

The basic idea is:

• Bind ItemsControl.ItemsSource to Videos
• Render each VideoCard with a DataTemplate
• Use WrapPanel to get a card “grid”

A key detail:

• avoid building a BitmapImage with empty UriSource
• bind Image.Source directly to the URL string when possible

Example pattern:

<Image Stretch="UniformToFill" Source="{Binding ThumbnailUrl}" />

The Classic WPF Threading Pitfall (and How You Fixed It)

When you use async API calls, you must ensure that UI-bound operations happen on the UI thread, especially:

• raising CanExecuteChanged
• modifying ObservableCollection that the UI is bound to
• raising PropertyChanged

A frequent root cause is using ConfigureAwait(false) inside a ViewModel in WPF. That may resume continuation on a non-UI thread, causing:

“The calling thread cannot access this object because a different thread owns it.”

Fix strategies

• Don’t use ConfigureAwait(false) in UI code unless you marshal back to the dispatcher
• Raise command events through Application.Current.Dispatcher

This is one of the most valuable “real-world WPF lessons” from the project.

Making It a “Study & Rating” App

Now the app becomes truly personal:

What we’ll add

• A rating field per video (e.g., 0–10 stars/score)
• Status fields:
  • “To Watch”
  • “Watching”
  • “Watched”
  • “Favorite”
• Notes / summary
• Tags (e.g., “SPFx”, “PnP”, “Graph”, “Performance”)

UX upgrade idea (simple and powerful)

• Each card has:
  • “Open”
  • rating dropdown (0–10)
  • “Save” button (to SharePoint)

This turns YouTube into a structured learning pipeline.

Persisting Ratings in SharePoint Online (Public-Safe Design)

You asked to store your video list + notes + rating in SharePoint Online. The clean approach is:

SharePoint List Schema (example placeholders)

Create a list like:

List title: Learning Videos (placeholder)

Columns:

• Title (single line text) — use as video title (or a short title)
• VideoUrl (hyperlink)
• VideoId (single line text)
• Channel (single line text)
• SearchQuery (single line text)
• Rating (number 0–10)
• Status (choice: ToWatch / Watching / Watched / Favorite)
• Notes (multiple lines)
• Tags (multiple lines or managed metadata later)
• ThumbnailUrl (single line text)

Authentication Options (choose one)

Because this is a desktop app, you have a few realistic options:

1. Microsoft Graph (recommended long-term)
   • clean REST model
   • modern auth
   • works well with lists
2. SharePoint REST API
   • direct calls to SharePoint endpoints
   • good when you already know SharePoint internals
3. PnP / CSOM (more “classic” tooling)
   • powerful but heavier
   • still useful in enterprise tooling

For a public-facing article: keep this generic. In implementation, you’ll use one auth flow and store tokens securely.

Data Flow: From YouTube Search to SharePoint Save

A practical flow:

1. User searches YouTube → app gets results
2. User opens a video
3. User rates and writes notes
4. Click “Save”
5. App checks if VideoId already exists in SharePoint:
   • if exists → update rating/notes
   • else → create new item

This prevents duplicates and makes the app feel “database-backed.”

Implementation Roadmap (Incremental, Safe)

Phase 1 — Current baseline (done)

• Search + cards + open link

Phase 2 — Local rating (no SharePoint yet)

• Add UI controls to each card
• Store ratings in memory
• Serialize to local JSON (backup)

Phase 3 — SharePoint storage

• Create the SharePoint list
• Add “Save/Update” API integration
• Add search/filter in the app: “show my Favorites”, “show ToWatch”, etc.

Phase 4 — Quality upgrades

• Pagination with nextPageToken
• Local cache
• Offline-first behavior (queue sync)
• Bulk operations (“save all results”)

Security Notes for a Public Article

If you publish this project:

• never show API keys, client IDs, client secrets
• don’t paste raw App.config with real credentials
• don’t show tenant URLs or list names from a real environment
  Use placeholders like:
  • https://contoso.sharepoint.com/sites/ExampleSite
  • Learning Videos

Also:

• consider using secure storage (Windows Credential Manager / DPAPI) for tokens
• rotate any credentials if they were ever posted in plain text

Conclusion

You now have a working WPF YouTube search app that renders clean cards and behaves like a proper desktop tool. The next “big leap” is transforming it into a learning workflow system:

• rate videos
• write notes
• save everything to SharePoint Online
• build your own searchable knowledge base