courses: smoother data tag view modelling (fixes #13082)

[dogi]

Moves course loading orchestration into CoursesViewModel out of CoursesFragment, ensuring the fragment is focused exclusively on rendering, selection, and navigation as requested. Removes direct repository fragment dependencies for handling data load configurations before touching sync behavior. Includes feedback improvements ensuring thread safety during database filtering operations.

---

PR created automatically by Jules for task 10508090116705126768 started by @dogi

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[qltysh]

❌ 2 blocking issues (2 total)

Tool	Category	Rule	Count
qlty	Structure	Function with many parameters (count = 7): processCourses	2	❌

[qltysh]

Function with many parameters (count = 7): processCourses [qlty:function-parameters]

[qltysh]

Function with many parameters (count = 6): filterCourses [qlty:function-parameters]

[Okuro3499]

1. getAllCourses() / getMyCourses() run on wrong dispatcher (CoursesViewModel.kt:~68–72)                                                                                           
  val allCourses = coursesRepository.getAllCourses()   // no dispatcher
  val validCourses = allCourses.filter { ... }                                                                                                                                       
  val myCourses = coursesRepository.getMyCourses(...)  // no dispatcher                                                                                                              
Ratings and progress correctly use async(dispatcherProvider.io), but the Realm list fetches run on viewModelScope's default dispatcher. If getAllCourses() returns managed Realm
objects, they have thread affinity and this can crash on config change. All three fetches should be under withContext(dispatcherProvider.io).                                      
                                                                                                                                                                                     
2. filterCourses() silently drops ratings/progress refresh (CoursesViewModel.kt:~101–109)                                                                                          
processCourses(..., _coursesState.value.map, _coursesState.value.progressMap, tagsMap)                                                                                             
The old filterCoursesAndUpdateUi() re-fetched ratings and progress from the repository on every filter. The new code reuses the cached state. If a user rates a course mid-session
and then applies a filter, the stale rating persists until the next full reload. This is a silent behavioral regression.                                                           
                                                                                                                                                                                     
3. Dead public processCourses overload (CoursesViewModel.kt:~38–41)                                                                                                                
  fun processCourses(                                                                                                                                                                
      isMyCourseLib: Boolean, userId: String?, validCourses: ..., myCourses: ..., map: ..., progressMap: ...
  ) {                                                                                                                                                                                
      processCourses(..., emptyMap())  // delegates to private                                                                                                                       
  }                                                                                                                                                                                  
Nothing in the Fragment calls this anymore. It's orphaned code that adds API surface for no reason. Remove it or make the 7-param private overload the only entry point.                                                                                                                                                                             
   
4. Double loadCourses() call on startup still present                                                                                                                              
getAdapter() calls viewModel.loadCourses() at its end, and loadDataAsync() (called separately in onViewCreated) also calls viewModel.loadCourses(). This existed before, but
consolidating into the ViewModel was the moment to fix it — cancel the redundant call by having getAdapter() not trigger a load, and let only loadDataAsync() own the first load.  
                  
5. onDataUpdated loses the initialized-adapter guard (CoursesFragment.kt:~688)                                                                                                     
The previous code guarded with if (::adapterCourses.isInitialized). Now it always calls loadDataAsync() unconditionally. If a sync event fires before getAdapter() completes and
adapterCourses is still uninitialized, the StateFlow emission at collectLatest will try to call adapterCourses.submitList() on an uninitialized lateinit — crashing with           
UninitializedPropertyAccessException. At minimum add an isInitialized guard back in the collector.
                                                                                                                                                                                     
6. RealmTag.toTag() moved but toTag() still exists as a local extension                                                                                                            
The extension moved from Fragment to ViewModel (correct), but the mapping logic is now fully duplicated in a private function inside a ViewModel with no unit-test coverage. A shared mapper object (or putting toTag() on the model directly) would be cleaner if this pattern grows.  

new code

[Okuro3499]

1. getAllCourses() / getMyCourses() run on wrong dispatcher (CoursesViewModel.kt:~68–72)                                                                                           
  val allCourses = coursesRepository.getAllCourses()   // no dispatcher
  val validCourses = allCourses.filter { ... }                                                                                                                                       
  val myCourses = coursesRepository.getMyCourses(...)  // no dispatcher                                                                                                              
Ratings and progress correctly use async(dispatcherProvider.io), but the Realm list fetches run on viewModelScope's default dispatcher. If getAllCourses() returns managed Realm
objects, they have thread affinity and this can crash on config change. All three fetches should be under withContext(dispatcherProvider.io).                                      
                                                                                                                                                                                     
2. filterCourses() silently drops ratings/progress refresh (CoursesViewModel.kt:~101–109)                                                                                          
processCourses(..., _coursesState.value.map, _coursesState.value.progressMap, tagsMap)                                                                                             
The old filterCoursesAndUpdateUi() re-fetched ratings and progress from the repository on every filter. The new code reuses the cached state. If a user rates a course mid-session
and then applies a filter, the stale rating persists until the next full reload. This is a silent behavioral regression.                                                           
                                                                                                                                                                                     
3. Dead public processCourses overload (CoursesViewModel.kt:~38–41)                                                                                                                
  fun processCourses(                                                                                                                                                                
      isMyCourseLib: Boolean, userId: String?, validCourses: ..., myCourses: ..., map: ..., progressMap: ...
  ) {                                                                                                                                                                                
      processCourses(..., emptyMap())  // delegates to private                                                                                                                       
  }                                                                                                                                                                                  
Nothing in the Fragment calls this anymore. It's orphaned code that adds API surface for no reason. Remove it or make the 7-param private overload the only entry point.                                                                                                                                                                             
   
4. Double loadCourses() call on startup still present                                                                                                                              
getAdapter() calls viewModel.loadCourses() at its end, and loadDataAsync() (called separately in onViewCreated) also calls viewModel.loadCourses(). This existed before, but
consolidating into the ViewModel was the moment to fix it — cancel the redundant call by having getAdapter() not trigger a load, and let only loadDataAsync() own the first load.  
                  
5. onDataUpdated loses the initialized-adapter guard (CoursesFragment.kt:~688)                                                                                                     
The previous code guarded with if (::adapterCourses.isInitialized). Now it always calls loadDataAsync() unconditionally. If a sync event fires before getAdapter() completes and
adapterCourses is still uninitialized, the StateFlow emission at collectLatest will try to call adapterCourses.submitList() on an uninitialized lateinit — crashing with           
UninitializedPropertyAccessException. At minimum add an isInitialized guard back in the collector.
                                                                                                                                                                                     
6. RealmTag.toTag() moved but toTag() still exists as a local extension                                                                                                            
The extension moved from Fragment to ViewModel (correct), but the mapping logic is now fully duplicated in a private function inside a ViewModel with no unit-test coverage. A shared mapper object (or putting toTag() on the model directly) would be cleaner if this pattern grows.  

issues not addressed

new code

[Okuro3499]

three must-fix issues remain unaddressed.                                                                                                                                 
   
  - Issue 1 (CoursesViewModel.kt:73–80): getAllCourses() and getMyCourses() still run without withContext(dispatcherProvider.io), while ratings/progress below them correctly use    
  async(dispatcherProvider.io).                                                                                                                                                    
  - Issue 2 (CoursesViewModel.kt:105): filterCourses() still reads _coursesState.value.map and _coursesState.value.progressMap from cached state instead of re-fetching from the     
  repository.                                                                                                                                                                        
  - Issue 3 (CoursesViewModel.kt:38–47): The public 6-param processCourses() overload is still present and still unreachable from any call site.

new code