cycle3_feedback.txt

author:	sourcery-ai
association:	none
edited:	true
status:	none
--
<!-- Generated by sourcery-ai[bot]: start review_guide -->

## Reviewer's Guide

Migrates core item and list screens from a custom ViewPager/FragmentStatePagerAdapter stack to ViewPager2/FragmentStateAdapter, replaces deprecated fragment lifecycle and menu APIs with onViewCreated and MenuProvider, and introduces a ViewModel-backed lazy loading mechanism for fragment state retention.

#### Sequence diagram for ViewPager2 page selection and lazy loading

```mermaid
sequenceDiagram
    actor User
    participant ItemActivity
    participant ViewPager2
    participant TabLayout
    participant TabLayoutMediator
    participant ItemPagerAdapter
    participant Fragment as LazyLoadFragment
    participant VM as LazyLoadViewModel

    User->>ItemActivity: open item screen
    ItemActivity->>ItemPagerAdapter: new ItemPagerAdapter(fragmentActivity, builder)
    ItemActivity->>ViewPager2: setAdapter(mAdapter)
    ItemActivity->>TabLayoutMediator: new TabLayoutMediator(TabLayout, ViewPager2, configureTab)
    TabLayoutMediator-->>TabLayout: attach()

    rect rgb(230,230,255)
        User->>ViewPager2: swipe to page N
        ViewPager2-->>ItemPagerAdapter: request fragment for position N
        ItemPagerAdapter-->>Fragment: createFragment(N)
        Fragment->>Fragment: onCreate()
        Fragment->>Fragment: onViewCreated()
        Fragment->>VM: obtain LazyLoadViewModel via ViewModelProvider
        Fragment->>Fragment: eagerLoad() if isNewInstance()
        Fragment->>VM: setLoaded(true)
    end

    rect rgb(230,255,230)
        User->>TabLayout: tap tab N
        TabLayout->>TabLayoutMediator: tab selected
        TabLayoutMediator->>ViewPager2: setCurrentItem(N)
        ViewPager2-->>ItemActivity: OnPageChangeCallback.onPageSelected(N)
        ItemActivity->>ItemActivity: toggleFabs(isComments)
        ItemActivity->>ItemActivity: getFragment(N)
        ItemActivity->>Fragment: loadNow()
        Fragment->>VM: setEagerLoad(true)
        Fragment->>Fragment: eagerLoad()
        Fragment->>VM: setLoaded(true)
    end
```

#### Sequence diagram for fragment menu handling with MenuProvider

```mermaid
sequenceDiagram
    participant Activity
    participant BaseFragment
    participant ViewLifecycleOwner
    participant MenuProvider
    participant Menu
    participant MenuTintDelegate

    BaseFragment->>Activity: onAttach(context)
    BaseFragment->>BaseFragment: onCreateView(...)
    BaseFragment->>BaseFragment: onViewCreated(view, savedInstanceState)
    BaseFragment->>Activity: addMenuProvider(MenuProvider, ViewLifecycleOwner, RESUMED)
    Activity-->>MenuProvider: registered for menu events

    loop when menu is first shown
        Activity->>MenuProvider: onCreateMenu(Menu, MenuInflater)
        MenuProvider->>BaseFragment: createOptionsMenu(Menu, MenuInflater)
        BaseFragment->>MenuTintDelegate: onOptionsMenuCreated(Menu)
    end

    loop before menu is displayed
        Activity->>MenuProvider: onPrepareMenu(Menu)
        MenuProvider->>BaseFragment: prepareOptionsMenu(Menu)
    end

    User->>Activity: selects menu item
    Activity->>MenuProvider: onMenuItemSelected(MenuItem)
    MenuProvider->>BaseFragment: onOptionsItemSelected(MenuItem)
    BaseFragment-->>Activity: return handled or not
```

#### Class diagram for ViewPager2 paging and lazy loading stack

```mermaid
classDiagram
    direction LR

    class ItemActivity {
        - ViewPager2 mViewPager
        - TabLayout mTabLayout
        - FloatingActionButton mReplyButton
        - NavFloatingActionButton mNavButton
        - ItemPagerAdapter mAdapter
        - boolean mFullscreen
        + void bindData(WebItem story)
        + void setFullscreen()
        + <T> T getCurrent(Class clazz)
        + Fragment getFragment(int position)
        + void toggleFabs(boolean isComments, FloatingActionButton navigationFab, FloatingActionButton genericFab)
    }

    class BaseListActivity {
        - ViewPager2 mViewPager
        - TabLayout mTabLayout
        - ItemPagerAdapter mAdapter
        - TabLayoutMediator mTabLayoutMediator
        - ViewPager2.OnPageChangeCallback mPageChangeCallback
        - TabLayout.OnTabSelectedListener mTabSelectedListener
        + void bindViewPager()
        + void unbindViewPager()
        + void setFullscreen()
        + KeyDelegate.BackInterceptor getBackInterceptor()
        + Fragment getFragment(int position)
    }

    class ItemPagerAdapter {
        - Context mContext
        - WebItem mItem
        - boolean mShowArticle
        - int mCacheMode
        - int mDefaultItem
        - boolean mRetainInstance
        + ItemPagerAdapter(FragmentActivity fragmentActivity, Builder builder)
        + long getItemId(int position)
        + Fragment createFragment(int position)
        + int getItemCount()
        + CharSequence getPageTitle(int position)
    }

    class ItemPagerAdapter.Builder {
        WebItem item
        boolean showArticle
        int cacheMode
        boolean retainInstance
        Preferences.StoryViewMode defaultViewMode
        + Builder setItem(WebItem item)
        + Builder setShowArticle(boolean showArticle)
        + Builder setCacheMode(int cacheMode)
        + Builder setRetainInstance(boolean retainInstance)
        + Builder setDefaultViewMode(Preferences.StoryViewMode defaultViewMode)
    }

    class BaseFragment {
        - MenuTintDelegate mMenuTintDelegate
        + void onAttach(Context context)
        + void onViewCreated(View view, Bundle savedInstanceState)
        + void createOptionsMenu(Menu menu, MenuInflater menuInflater)
        + void prepareOptionsMenu(Menu menu)
        + boolean onOptionsItemSelected(MenuItem menuItem)
    }

    class LazyLoadFragment {
        <<abstract>>
        + static String EXTRA_EAGER_LOAD
        + static String EXTRA_RETAIN_INSTANCE
        - boolean mActivityCreated
        - LazyLoadViewModel mViewModel
        + void onCreate(Bundle savedInstanceState)
        + void onViewCreated(View view, Bundle savedInstanceState)
        + void onSaveInstanceState(Bundle outState)
        + void onDetach()
        + void setUserVisibleHint(boolean isVisibleToUser)
        + void loadNow()
        + boolean isNewInstance()
        + void eagerLoad()
        + void load()
    }

    class LazyLoadViewModel {
        - boolean mEagerLoad
        - boolean mLoaded
        - boolean mInitialized
        + boolean isEagerLoad()
        + void setEagerLoad(boolean eagerLoad)
        + boolean isLoaded()
        + void setLoaded(boolean loaded)
        + boolean isInitialized()
        + void setInitialized(boolean initialized)
    }

    class ListFragment {
        + void onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
        + void onViewCreated(View view, Bundle savedInstanceState)
    }

    class WebFragment {
        + void onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)
        + void onViewCreated(View view, Bundle savedInstanceState)
    }

    ItemPagerAdapter --|> androidx.viewpager2.adapter.FragmentStateAdapter
    LazyLoadFragment --|> BaseFragment
    WebFragment --|> LazyLoadFragment
    ListFragment --|> BaseListFragment
    LazyLoadFragment --> LazyLoadViewModel
    ItemActivity --> ItemPagerAdapter
    ItemActivity --> ViewPager2
    ItemActivity --> TabLayoutMediator
    BaseListActivity --> ItemPagerAdapter
    BaseListActivity --> ViewPager2
    BaseListActivity --> TabLayoutMediator
    ItemPagerAdapter o-- ItemPagerAdapter.Builder
```

### File-Level Changes

| Change | Details | Files |
| ------ | ------- | ----- |
| Migrate activities and layouts from custom ViewPager + FragmentStatePagerAdapter to ViewPager2 + FragmentStateAdapter with TabLayoutMediator and explicit callbacks. | <ul><li>Change BaseListActivity and ItemActivity to use ViewPager2 fields, userInputEnabled, and ViewPager2.OnPageChangeCallback instead of the custom ViewPager and its swipeEnabled API.</li><li>Replace the custom ViewPager widget in activity_list.xml and activity_item.xml with androidx.viewpager2.widget.ViewPager2.</li><li>Refactor ItemPagerAdapter to extend FragmentStateAdapter, implement createFragment/getItemCount, and remove custom bind/unbind methods and fragment caching array.</li><li>Introduce TabLayoutMediator wiring and explicit TabLayout.OnTabSelectedListener implementations in activities to manage tab titles, reselection scroll-to-top, and initial/current page selection.</li><li>Adjust navigation, back handling, and FAB visibility logic to work via Fragment lookups by tag ("f" + position) instead of adapter.getItem().</li></ul> | `app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseListActivity.java`<br/>`app/src/main/java/io/github/sheepdestroyer/materialisheep/ItemActivity.java`<br/>`app/src/main/java/io/github/sheepdestroyer/materialisheep/widget/ItemPagerAdapter.java`<br/>`app/src/main/res/layout-w820dp-land/activity_list.xml`<br/>`app/src/main/res/layout/activity_item.xml`<br/>`app/src/main/java/io/github/sheepdestroyer/materialisheep/widget/ViewPager.java` |
| Replace deprecated fragment lifecycle/menu APIs with onViewCreated and MenuProvider-based handling and clean up obsolete overrides. | <ul><li>Update BaseFragment to perform menu setup in onViewCreated and register a MenuProvider tied to the view lifecycle owner for menu creation, preparation, and item selection.</li><li>Remove onActivityCreated overrides where they were no-ops or only used for adapter state restoration, moving that work into onViewCreated where needed (e.g., ListFragment).</li><li>Drop setHasOptionsMenu usage in BaseListFragment and WebFragment now that menu handling is centralized via MenuProvider.</li><li>Remove the now redundant onActivityCreated override from FavoriteFragment.</li></ul> | `app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseFragment.java`<br/>`app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseListFragment.java`<br/>`app/src/main/java/io/github/sheepdestroyer/materialisheep/FavoriteFragment.java`<br/>`app/src/main/java/io/github/sheepdestroyer/materialisheep/ListFragment.java`<br/>`app/src/main/java/io/github/sheepdestroyer/materialisheep/WebFragment.java` |
| Introduce LazyLoadViewModel and rework LazyLoadFragment to use ViewModel-backed state instead of setRetainInstance and manual flags. | <ul><li>Create LazyLoadViewModel to hold eagerLoad/loaded/initialized flags across configuration changes.</li><li>Refactor LazyLoadFragment to obtain a LazyLoadViewModel in onCreate, initialize eager-load state from arguments or savedInstanceState, and store/retrieve state via the ViewModel instead of local booleans and setRetainInstance/getRetainInstance.</li><li>Move lazy-load triggering from onActivityCreated to onViewCreated and base isNewInstance on ViewModel semantics rather than retain instance flags.</li><li>Update eagerLoad/loadNow logic to use the ViewModel flags, and ensure state is saved in onSaveInstanceState while allowing re-loading after restoration.</li></ul> | `app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java`<br/>`app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadViewModel.java` |

### Possibly linked issues

- **#**: PR replaces deprecated menus, lifecycle, retainInstance, and ViewPager APIs exactly as outlined in the modernization issue.

---

<details>
<summary>Tips and commands</summary>

#### Interacting with Sourcery

- **Trigger a new review:** Comment `@sourcery-ai review` on the pull request.
- **Continue discussions:** Reply directly to Sourcery's review comments.
- **Generate a GitHub issue from a review comment:** Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with `@sourcery-ai issue` to create an issue from it.
- **Generate a pull request title:** Write `@sourcery-ai` anywhere in the pull
  request title to generate a title at any time. You can also comment
  `@sourcery-ai title` on the pull request to (re-)generate the title at any time.
- **Generate a pull request summary:** Write `@sourcery-ai summary` anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment `@sourcery-ai summary` on the pull request to
  (re-)generate the summary at any time.
- **Generate reviewer's guide:** Comment `@sourcery-ai guide` on the pull
  request to (re-)generate the reviewer's guide at any time.
- **Resolve all Sourcery comments:** Comment `@sourcery-ai resolve` on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
- **Dismiss all Sourcery reviews:** Comment `@sourcery-ai dismiss` on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  `@sourcery-ai review` to trigger a new review!

#### Customizing Your Experience

Access your [dashboard](https://app.sourcery.ai) to:
- Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
- Change the review language.
- Add, remove or edit custom review instructions.
- Adjust other review settings.

#### Getting Help

- [Contact our support team](mailto:support@sourcery.ai) for questions or feedback.
- Visit our [documentation](https://docs.sourcery.ai) for detailed guides and information.
- Keep in touch with the Sourcery team by following us on [X/Twitter](https://x.com/SourceryAI), [LinkedIn](https://www.linkedin.com/company/sourcery-ai/) or [GitHub](https://github.com/sourcery-ai).

</details>

<!-- Generated by sourcery-ai[bot]: end review_guide -->
--
author:	coderabbitai
association:	none
edited:	true
status:	none
--
<!-- This is an auto-generated comment: summarize by coderabbit.ai -->
<!-- other_code_reviewer_warning_start -->

> [!NOTE]
> ## Other AI code review bot(s) detected
> 
> CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

<!-- other_code_reviewer_warning_end -->

<!-- walkthrough_start -->

<details>
<summary>📝 Walkthrough</summary>

## Walkthrough

The PR modernizes fragment lifecycle and menu handling (replacing deprecated methods with onViewCreated and MenuProvider), migrates ViewPager-based navigation to ViewPager2 with FragmentStateAdapter/TabLayoutMediator, introduces LazyLoadViewModel for fragment load state, and removes a custom ViewPager subclass and related layout usages.

## Changes

| Cohort / File(s) | Change Summary |
|---|---|
| **BaseFragment & menu handling** <br> `app/src/main/java/.../BaseFragment.java` | Removed onActivityCreated/onCreateOptionsMenu/onPrepareOptionsMenu; added onViewCreated registering a MenuProvider tied to getViewLifecycleOwner() delegating menu creation/selection/preparation. |
| **List & related fragments lifecycle** <br> `app/src/main/java/.../BaseListFragment.java`, `app/src/main/java/.../ListFragment.java`, `app/src/main/java/.../FavoriteFragment.java`, `app/src/main/java/.../WebFragment.java` | Replaced onActivityCreated with onViewCreated (or removed deprecated overrides); removed explicit setHasOptionsMenu(true) usages; preserved equivalent initialization in onViewCreated. |
| **ViewPager → ViewPager2 (activities & layouts)** <br> `app/src/main/java/.../BaseListActivity.java`, `app/src/main/java/.../ItemActivity.java`, `app/src/main/res/layout-w820dp-land/activity_list.xml`, `app/src/main/res/layout/activity_item.xml` | Replaced androidx.viewpager.widget.ViewPager with androidx.viewpager2.widget.ViewPager2; integrated TabLayoutMediator, updated adapter binding, page change callbacks, setUserInputEnabled for swipe control, and layout tag updates. |
| **Pager adapter migration** <br> `app/src/main/java/.../widget/ItemPagerAdapter.java` | Migrated from FragmentStatePagerAdapter to FragmentStateAdapter: constructor now accepts FragmentActivity; implemented createFragment/getItemCount/getItemId; removed old instantiateItem/getItem/getCount and internal fragment cache. |
| **Lazy load ViewModel & fragment** <br> `app/src/main/java/.../LazyLoadViewModel.java`, `app/src/main/java/.../LazyLoadFragment.java` | Added LazyLoadViewModel (eager/load/initialized flags with getters/setters); LazyLoadFragment now uses ViewModelProvider, moves init from onActivityCreated to onViewCreated, adds setUserVisibleHint, and defers load decisions to ViewModel. |
| **Removed custom ViewPager widget** <br> `app/src/main/java/.../widget/ViewPager.java` | Deleted custom ViewPager subclass (swipe toggle logic and setSwipeEnabled API); codebase now relies on ViewPager2. |

## Sequence Diagram(s)

```mermaid
sequenceDiagram
    participant Fragment as BaseFragment
    participant View as ViewLifecycle
    participant MenuProv as MenuProvider
    participant Activity as Activity
    participant Menu as Menu

    Fragment->>View: onViewCreated(view, bundle)
    View->>MenuProv: register MenuProvider (getViewLifecycleOwner(), RESUMED)
    MenuProv->>Fragment: onCreateMenu(menu, inflater)
    Fragment->>Menu: inflate/delegate to mMenuTintDelegate
    Menu->>MenuProv: onMenuItemSelected(item)
    MenuProv->>Fragment: onOptionsItemSelected(item)
```

```mermaid
sequenceDiagram
    participant Activity as ItemActivity
    participant VP2 as ViewPager2
    participant TLM as TabLayoutMediator
    participant Adapter as ItemPagerAdapter
    participant Fragment as PageFragment

    Activity->>Adapter: new ItemPagerAdapter(activity, builder)
    Activity->>VP2: setAdapter(adapter)
    Activity->>TLM: new TabLayoutMediator(tabLayout, VP2).attach()
    VP2->>Adapter: createFragment(position)
    Adapter->>Fragment: instantiate page fragment
    VP2->>Activity: onPageSelected(position)
    Activity->>Activity: toggle FABs / trigger lazy load via fragment tag
```

## Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

## Possibly related issues

- **sheepdestroyer/materialisheep#52**: Implements the fragment API modernization, ViewModel lazy-load approach, and ViewPager → ViewPager2 migration described in the issue.

## Possibly related PRs

- **sheepdestroyer/materialisheep#51**: Touches the same deprecated fragment lifecycle/menu methods in BaseFragment; changes may conflict or overlap with this PR's removals.

## Suggested labels

`Review effort 3/5`

## Poem

> 🐰 Hopping from old hooks to newer light,  
> > Menus find providers, tabs align just right,  
> > ViewModels remember what the rabbit forgot,  
> > ViewPager2 hops in—no custom swipe to plot,  
> > A joyful thump for code made bright!

</details>

<!-- walkthrough_end -->


<!-- pre_merge_checks_walkthrough_start -->

<details>
<summary>🚥 Pre-merge checks | ✅ 2 | ❌ 1</summary>

<details>
<summary>❌ Failed checks (1 warning)</summary>

|     Check name     | Status     | Explanation                                                                           | Resolution                                                                         |
| :----------------: | :--------- | :------------------------------------------------------------------------------------ | :--------------------------------------------------------------------------------- |
| Docstring Coverage | ⚠️ Warning | Docstring coverage is 21.28% which is insufficient. The required threshold is 80.00%. | Write docstrings for the functions missing them to satisfy the coverage threshold. |

</details>
<details>
<summary>✅ Passed checks (2 passed)</summary>

|     Check name    | Status   | Explanation                                                                                                                                        |
| :---------------: | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------- |
|    Title check    | ✅ Passed | The title accurately summarizes the two main changes: ViewPager2 migration and Fragment API modernization to replace deprecated lifecycle methods. |
| Description Check | ✅ Passed | Check skipped - CodeRabbit’s high-level summary is enabled.                                                                                        |

</details>

<sub>✏️ Tip: You can configure your own custom pre-merge checks in the settings.</sub>

</details>

<!-- pre_merge_checks_walkthrough_end -->

<!-- finishing_touch_checkbox_start -->

<details>
<summary>✨ Finishing touches</summary>

- [ ] <!-- {"checkboxId": "7962f53c-55bc-4827-bfbf-6a18da830691"} --> 📝 Generate docstrings

</details>

<!-- finishing_touch_checkbox_end -->

<!-- tips_start -->

---

Thanks for using [CodeRabbit](https://coderabbit.ai?utm_source=oss&utm_medium=github&utm_campaign=sheepdestroyer/materialisheep&utm_content=56)! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

<details>
<summary>❤️ Share</summary>

- [X](https://twitter.com/intent/tweet?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A&url=https%3A//coderabbit.ai)
- [Mastodon](https://mastodon.social/share?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A%20https%3A%2F%2Fcoderabbit.ai)
- [Reddit](https://www.reddit.com/submit?title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&text=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code.%20Check%20it%20out%3A%20https%3A//coderabbit.ai)
- [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcoderabbit.ai&mini=true&title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&summary=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code)

</details>

<sub>Comment `@coderabbitai help` to get the list of available commands and usage tips.</sub>

<!-- tips_end -->

<!-- internal state start -->


<!-- DwQgtGAEAqAWCWBnSTIEMB26CuAXA9mAOYCmGJATmriQCaQDG+Ats2bgFyQAOFk+AIwBWJBrngA3EsgEBPRvlqU0AgfFwA6NPEgQAfACgjoCEYDEZyAAUASpETZWaCrKPR1AGxJcbJAGZoYvgUXABq8CQA7lZopBQATJAAsvBEVOL4WJj0AGJURGwYuJAAglYAksmKlBjwAF7U8JmQkAYAco4ClFwArABskIAoBJCwuLjciBwA9FNE6rDYAhpMzFOIsCQk3EqIuBT4spRTzNSU8GgeSBtbU9zYHh5T/S0GAKqI3fbX29J7B5RDSAAZXw2AoDG8kAo/kCBAoUwkEUi3FilHiYGYqXSTSwgCTCGDOUicSAnXYA1oAYWhp1oXHiAAZ4n0wPSAIxgVkATmg9PpHDZHAAzIKAFqAoG4ajYSb8bhkNwIZC2ElY07IXAbdDcbiQPz7ZiQDUkSBeIiBeThKIxOKQKaQPKxQq4CWna2UEq0NDcGh8D64bA6giQS3RVEJSCReb2/JOl00D1en3oDD0ZjVCi1OrSaOO9ilCrIbIksjYEbZS4YIgaSAU2CYUjIeAYBgebBKDgGKApNKnSDlGjMEpiSTqeRFgBCaA+ABkkLgh+JEbh5EHpcaQ27w0XoCpp2hZKDcEk6Oc4ZAABTcVvIFGkRh1yvGhgXDwCQIAa0QAEoNJ3IL4r0CJ9pQIA0NzDSBpVRFAsA8fdD2Qc9YRHZcAH1Ll2DQAA9mA8AAadBhyXWRUPUEhmGw3CvwjKNwLiRIiyULwaENTUGBAlhgyRTdGDgxBEF/KBXm2Xt+3IzcE29AEgxILCaBTHMCnYOMSEkn1BKqKRdRjPMPHwOYGG0zilF4UQaX4DAFxQ2QqRIcyg0yENbPMotoTTLS/V8SUm3KDBdkwCEAG4YL+WhsAhSA9zqWRp3wNBaBDJJqg8XVgnsSUWOheSMiwc8opiuLaAdJSigI/LYvixLkp/P8kqUDN6mNQpSwfWgKyISA5HsSNcAYBBK0NfBkhLKx9kReqYMgScPmKp1grc/AtJM6Fnxoeg9VzIpiwwUsynKQsFL9AAJKcAHlvRxRBjx2xgXwEv8gXgZgr3gPwx09KS+DUFMmw61zyMW41lrMtaTVe0RZBbY0oIbQj9n4+wSCkKgUo2krcEQ6aSFm9gCKx2ddhx0rIrnIncAInI0AkYIyLJgiAHUSAEMmapyeAvGQPr6zoGCWzbY1WVZSAACkqbQXV2ezItEjgg88Aljn0GQJRvK8egm1Y41lT8SWIwud8NX2bAiFgX8DAsGsWCdZAHCcFwjCgEo8FgNLz3WTYfl2fZDgoaim2p98eehREogUJwU2QZh7nEK9jXENgZQAIlmcimx0YOkUTgjE4AASYeqVDUbyoSRzPs5zxBQXBShZDAbQS5DyIs8gZOM6iZuiynQP6AAUQeeAJlQIM28iDT8+UVR1G0ABtAR8FwABdC8KWqGxC/UajoUQbhMiUehcEjCKetgHBQPM6EXuzJtaHgVbfvQBukT19UKFSOIeaLDB5/vjVqE1+xZBkgNLQfA2Yv7FGhGAEe6APDUloPIEePMViYgxtWNoQ0FgnCwIgvgfhNi0DfAwd8/A+A30QOxfiOJWJwMLNCHgW88wayNPQxa8A95h2tmbC2K9WDqGLPxVENtHAnHtn+HWWFzwjy/FweKtAt7IDwXQQhxC9ScQAOKp1qMmeg49kwXEAUgAwLQoDlUKmTLgRBsDOHoHZOIFV95DVMlILa0IwopkwMUPS8VfpGN0H2AcVliJcAWktAMlxVpNTaFTcceACBZEoUQDATpfFQHxnOQJo4uDiJNHZYhXUVaBH6h1HcAg9xyyPCeagaUizPgeMoxsWBsAYG+rQB2YBDAGBMFAMg9B8B+FPoQUg5B0hIKtuwLgvB+DCFEIubMXVx5UEnpoeu+hOngCgHAVAqBMADOIGQZQoNkHjKhGgSI9hhHOHkPM9M69lk6FWcYdZRgvTcDWOCY42gMBTCEGLKYTRZjzEWGsb4Ow/g+w+T6c4GFvhTCxmTDQPyJBoA7InVF5tLAlHKHs4Z5lbYiPkH0+83NEAO3/ADKQ9BLh4IYJDLw2jtq7QqJBRAqIuCZAycuZya1zwxJTF4aiRZmHAwib0jAXKSDnRyldEs55rrYAInK3yfg4I+gFQpTIo0tjOAlRdTI0qdqypLNRNgGpFC0KBiQZidANIATghCegx8LJOWpNykMeMmltRINRQGFBX5KEGjBdQULGoMrLHy++iJxbizlaNVhE1oRzDJK4miGp/7IWIgRSMr8BrNUYC6nEBEyIGg+F4YcmQCJFlMiibEzRDaghNv/XgcbKAaQ9OwtO4gLj1EaM0ZV+AznHw1o5JE4raS3QeOqIazA5XuCKAAEUtSQM0NANDsqIqOUd54iQctkOeL8ar6AJrnDWrAhLo0jTGmw6SdZihMSXWqANDAXU6qlXKgimRJWXTEswIEi6xB0ArQpKt2rP16rlRGDYWBmFoydCgQsYxCnWtqiWMNbV75fzOfgBg7EKA3gBI3MG1LaXQ0QPfIkIZZxEahqdSIwy930vFpRiGUMNAqULX5Gg8V+D9OYU4po0ptKbVwGASM/qqXMbpSal2tB7pQE1R8CgFLICyTnPfJAJQEN9ToPRrTRCDr0DvcuqhQZp0llnbgBdppex+DSrmp9dkcr0uAyegiAh5ZZp5nW42J9mHkDOTGy9E1amvg/PdIw6LSgeB9D2vyAahWiDgie5AhLZI7woKDNKdwBDhOU0UIN0hSXHlNYe8ldAuAAAMss5epmwiyO7N28s9fYKmdBfL+WbCQFSX5yuTXK3CnSRQevnh1l4GR2o3kMA+U2b5vz/lzA1EC92WxQXeyOCcSFXaluvP60JhFYsvzIeKyXdyZXICVcWDlnWGALiQBq6K8VoG/JysNTdZqCqSxKpVQCJsyrTi+x6xrPrU5sYDdwENkbkIXkTam18xFaA/n4ABQtgQwKPYrf+PCdbZxNswp2+jPbSKDtdhIEdkJp3zvZdvhLa7KU7sWU1dWl9l1nvgeat13reOnTg8lmN15iB3knGm3DhHSOFgo62+j8FWPX4449rC4H8K4dE+Gkd2R5OqtU7p8OqIm6c7ZH2GwrCWgMDgJixodBGAOgPG0Qb2gGhG4aBDLdpEBE9cplt0bzApucrm/uHBbLxpGt0pZRStrkoOtdYB1gIHM1Qfc9G1qPnAvPkzaRSL+bYvUfLd+KtzHf3g1bfl7H3bSvzCWCSJgcGux7S6xKDT2QWYKBGFnOQTmD5SBjoANTxAABxTDAIKAALEYHuuwnrmV0dA/wNn0tcCOqkWABhUWJzaWAZ543+eTcF7D2biOM+LZBTnjHELsfQrl2k3YO6CfIqX2ii2mLsUHJ5niy53GiWPhJX+W1QFkB0QBDDY0R1P/cMeZdvH+TUHWS1feWQOUelaELwJFLaDtYNBoKVVtWgGTAkUpeCPAY8G+KpPgJsGgHsRzIMJgE3GZLAspQ8FNE+YAhiBSeqSQY0W8OOTwbMVRA0ZheKRMFtL/LYO1bMfADwegHgz6Tqa+e+F5fYQpWgriK0MMdEFYFEcQAPRGf0bgdjPmG+AaP0cQAabgj6H0AiNgfAuEQDegVg9/O8YLepViP+eKIQECe0EoccZ3UjNQS4ZcKYZCPVelPYN+AEOCaKE0QqNTLAGDdgWTPsIofYMKCEBRUHEuAIpGG7LqSUDqGfeQ0MeiHgQRZ3KNSAPzSAIkMmS8fAUjHKaiDYDwOUCgCwyCESGgGQD8MAa7REIzZoVqdqANNcViVAGouo9Apw3YZAPSAyVKPgFsCo36KYJpFpcA9cbiCCfJEnQpRY4sMw4IAiJpI9JNe+Ww0LBoxAHqPqH+IacWDIsAN8D4daJIkJG7L2U4IgeQDWeY6+YAjSYST0ZokkaOeAMAFEcgIoqmVIGLcdELIhR9F8CyKJDo3sWtCA+4knV+JGHmSNEoknMo+kTeagDYPgX+KDTUPjUEZAb9CSIwvgx2DAhpINLtVAqhQlHIVw9KB9NAPwJMBYgaeguAy1cyV4SoA+XJRCREDw9mUcBjMtPyGqKAb/BI7qAeJ8TIP4FKPaLgP0IESMOUHua7APegdpdQ94SgXyO4XAHUlQNWSY7IzceILhDFKLA5S6OLTUJQFsZwGLZLfpVLYIDLPgDXQydgfLT/KANmKA6w8nC/ecddZcDQZgYAnrLmR8aA2Azgs7eMgNcreg8rUlNoUOKTRQCrXgSQXsMmTE3AMoogngGYqonrNXBxM7SMndbMiLCvWoPBavNmOlOvfRRvcLTsZvJsbMRMjvLgTvHvQUfveIVkW/FfTsUwAwKHTfGHVPeHObQFcXQ/L2Y/aXAvXHYHAmcs0Ha/FFO/DFLFIZJ/egF/FwN/Ycgrfgk7feTUTIcVc8HOK3f3OlIPY0EPVrDjAKTrDKL1QjCTY0H1P1EgLQ1sHQjqdQZAHOIEAMUyfiemZwWoSsRAc8ROYVGLRONVb3KhQVNiGEoMY6M6XVJ7GVPYbAL1G1UrJ8sCyyaMmyZ9WgHlD1YPFrWgMPACrrECmlKGfgZGCCqCtsNTDGc5OoiEjSOAaQY0B4jwZAS1J6JsXsZhVLcJdQAiHC0GZqMAbo++cTAS4PGgCYfwzUKcSuBgU8HmZA+k8E7LLDT8ehUuUkjweQWSUQPAHmMKbNDqU1D4VkhsM2MvSLaLKVZ0i1N0pLN/b09LHmTLC7KnQM8Qe84nUneiirF859N8j8i0wPDin8riniiPIC9nDWN0hGGPEgA8smIbFEIhaCcrJoDQffJYCXI/H2WM/PWXLYcrZXIraTY7QGMdcrNdRcDdVi9ivlIq0Pf80q04cqrASq5Aaq2quPC8Bq98JqlqtqjQDqrcrqnc3q7gfqgc1vcMrvekfvLkEfMfLHHRaoR+UOafH0rgPA+ARwGc1fdfJPLfFPYXNc5HLPT2MFNbHqs/G4SmamV+GgRXMWE8lfe/c8/ZEZK8i5G8wlO8z/XwR8/+ca6yBrQq6iIy4jCE5RIyA0aGmmOGo8mATUfMywjONyglYSthJQIk40SIraUmwSsgmEhwIYgm4iTdX87i+aiELrYKOCyAO9RzZSzEa7X4zADyrCF6ay4oAygwm9fgbDMEZNXyqQ5ivNBzAtHJUEgaXmulLoOsRENKByI0PgFTMfHNEnaTASSAdBfgR2/ismxKynQyPacM81Fyj4JAzm2W16PwEKw7IasnUa/027fAWrYWyahzbTb85rOa9rSWsqqPXiSys7am2GkHITfO8rRc5PIXXfUXA/NHTq8GjbSG15Yu2mI8uHZslvIc9vU7Tva6jkeIO6+OCfJ6qfPwGfYkD6r65fH6hcjfKunfNPIGzPA6sGvPJuq4OXb9K/OHRGiLB/C8tG85O2AlfpbGwrVUUGVM4AgNegmRDA2y56H0hRNKHk7cXcHAipLYigaWooGoG7Vg3BCIEQw0GAp8Huu4ziG+oMeg4KLkjqcYqnPG1M8WFpAEaQuKPqANG+FaYoHkv0AMOQkpag3AypOEdA3gqYvVaiqU+wVIJWsEaGJo07cksMNSb7eaztRzDDZlKWBQDjCgcKM8X+YoFgGWsmVsiCf6L7egeBitS4RJe+IA5Y3IgAjSHk+B+lG20EtKAMH46QYJAQoCJm1ygTMQ9SFpc8DQaxg9Kgz+qYG+zRx1HByg/BknAMDsYxEkT4v0dhigc8QcSk32FJbxlRltP0U6ce8haEMgN0WcFBc8eIA7Lx4hz+j6ggmiLeOx8pW+sJrcRgs4KQdUFQQ0dgxIziQwyhkJttD+a0xQvImwnu8mj8OLfSIgOlZk8cfTQ0V+IgG0YI+QLxGCt/bmjGEJ06KDEphhUtHKAiaJ4QxSxgfWvMUZ1pnUV6FAYoQWtLCS+Z/uSsP8OEsExzIsPwP3aJzYLIWgEY3Aa2Lgdo45qhQ4qEvR+yIaPo0o0Hc8HEmCMkLjQlQJyh1qknb9b5r8YKE4geA45U/YB4HmLqP0I0igE0vAc0vUyaP0HIc5+zeUKAXMs5QYgERmwsB+2kEJospFFiUsz5oTc8SsneSonEaiIMPBXqE+UZmQFcTUQAHAI/AABvBloNTIAAX0AFwCQ0WIEJhC2QIoDYcQQyOnAgPprwSmAQTCueYQuyLAJAHha2CmLxfQogKyTIGJMYZoB5zojAVV/VuKQ141jAU1uJTE4ZW+VV5lqdTAaCTp9w+ATwiUosbRu2pvLsJsNKAUqYQNpoPgRwkCO52WmEaOVk9LcS8iMOU0j+BSF5S4TzIaWBlwrpwaZVj+bDYIGC9y0K0lEoB0mKoMeLaKj02KtWn0hKv0pKgMvLVK4My2ARoRtKUjRJKUOhV5taLgXyfxciHesWAiVhuIPx358PLhp5iBymzxvxU6EQ+50OGd90IJ88DUJAAiIkRC7UH0iRz1uIPdAiYo7digPxjQGJdmeqejaxjQZJvxfFzds5G9vxvdxUK9rdgcCkoFh9kQygZ9mxnM+eSEU6H2us44RQV6CIegQl3DdAOhClhE30GVo0eV+lEBIo+eGBJMROoOhwCgAICEM2LutvbmLvHoAAdn705CHvH0OVHtLhevHresgHnxNm+rnLXznr+uXMBr33XJBsl0btP03puFMXinhqRT3uRsfyPuvNPuDtJTlKEKYoms5Smu/OokdW10iE3TdSmmJsmjk6KiPL/F8lCnCmzCqiYmuOByvKApJHPfIjzAxKs6c8tQIgvjtXvhcbEBJB7jDHsWOHsToGOHxZKoijUb/DbUbCfvSytL848FjXGnQYUjssuCzEjgy8mmyvTuZXvgy6y6vQoA0m7BGRtnc63jhHBJMyK/PCBGgBKGgB7lQh7hKDUR7hsFQmnFOhKDnVsby8aiUogiGfAKNgbSK8QYYHQMwO2Z9KtMRYU3CA8K8Hny2lrd6ZtFsSCLCIGkiEg3/lWa6BWGzFFN9a8B2NI21qWKiDqktV1DgiIGiK0+VngFwc6nwE1Z2UgJEOQEdTjKRFe48A0CQHC7sUKkvdCZe+Sn2pJ1h8oHsQR6LHB6R6YhR9wGi7YoFSfQqLGMKh6cCNwzmfc5D1+gaJm4Gj7VHj/FrGJVCPinQUiHo1IpJ2U2m5O46gxOYSK66BnyfBfHviO4oAx5lMgG+IfSQDi4lpIC54uI8EiH3GQCyjBCg0EcguGsRAGhJIEyyk+TACbBzuNEW7ooo7hCm7h/ihV5LncoskR8iEh/e9iEnXjesv9TO7IGhOtyGb3Rjvv2rYbdrZdIS3dIipSybfit6VbYDty3EE7cKzdsUDoYHf9CHeYYTrbaTpTp08Jv08Kqzr/It8j0mhWrOys7qsmghzO0rv+urqXrE+BtXtzxPxl2bqmFr/brFh63xAp2q2TtFWdXTrYv11H/tyREdyfkbndRmrL/For7ztjoz7rMLPz7pw28oC27u5IF29wHPA1a8B2SQH34D2gHwCRaWoLqqr77Lvr91grvnub8XtXLb5Xs3LXq793Ll0f744O6f4UMiA035nYMOLEXzhD2Siu9IegUfOtX3KyACucm1V+JSyajkQugP9AjsUDiprRlc5QVLsUHAHNViBNuUfkbitokA5+OPS1JV3qgIDesKA9gNfiGzslqUElEjkykyDO8MSABN/BV0CyUADsLZSvO2WKCdljQ3Zdyr2QMDUdLqo5IfP3kFCD0Z6AnX6tDm3wrl084nDvtuQhoydXk0AugVD13rfVlOh9XFBjXU7n0DAyXB+MUUTqiwkU9/ZACYLd6wDZI8kYZkV0dSGxNg/3QHhEWAaYEAmaPKXoVBMIE8TCvkOkvlzoC2MmAvqaQDvB+iG98+RIH0N0z0KUAZQMPCLoVDWCo9Ch8UQtIgAJ7FD8ehUADHBjiGdoEhtAKofUJQLWp6aT4PiEpSbYfBaSDQ7tI5n8gsQMSSAFofSQzZXkQWtQPoVmFoDyNMgn3K9LzziBgAhm9KIZjzF+yfc0EFxDAkKxpyhEJiaUSgPsD4Ba0iAELPYNoBNi4AZ86vCgG517DkFvIwyGOni1DiJ0VqFWDwZD3zoN9X+wnbQaJ1robl66h1KTt3yMG980A0UexBlzYGHN3h+fRmpnwYZbxV2UAcrKfy1ZwYIh0vRAZ0Jr7QiColUGAUxGzJeNysO/EofbzYpYidkkvexHfyQHfDko5IvxJiIB5n9tWFQmoYT3xGF1kBRI2EaSMtRsiMRVI6ofFG0x0jYIvIpkQSMFEwjCoGXMUWdhlF1CphrQvkVXwVEsiyRITSkaP3UKjDGhJ/TkdiIm4zD5RAovUaKPOrd1aOSgwfP3npAscHqCgf1GPQnrvUTw09NFBoKE5aCAaNdNqhJwbrr1pOhedaiXgRoWCzyKnawSfVvI90u233f+NQOaZQlwKiw1MqnT04T9cqfufKuZxmrusnUI6KamZ3fJFi1CBnasLJSKJ5l0+V5ehoO2NBNhtC2YIXk/GrRoATUOXdWAdG9w8xHUOcU6GzSUD1iGazY/7vAmOyfIFETSKUi+A8oABHbAMWS8BFAuAfCS0UITVaUBkYiAOZn+gkrcFtQ+wIsqJAHCSM4gDRcgjrEsRZNKm4hIsAKU6gkBbaUbasG2j2EriK0IsMWCAkMiOUoSOwJ9L63vjGdR0iMLBPK2QB1gZAlzdAKSw/Gi9/4xRRmiH3tLhUnSEfKKolgbax8dmLbHgPnxSoRAu2g1DPv21RFMN9GefJPlriL4i0pq1Yh4MWMzpi14ugFRavyIf6kwNqw2HnIniDEt9P+wIsMWCIjEQioxgkmMYTkgBD9E6zE8fjSHPBO4F+kAdiZ+QKpL9uJSvSvhVV1HyT0YQ2FlGwAVhepQqrZKvJINrz145BCgu8l3kY5gBB6BgUfMPTY6eiOOZyV6rPmGg3w/Rs5CAIJyb4icQxegn/p32Oo99GYzMfvopzjGlAUaOKUGGp2THEojAuNEav/GCwBoyKiAR7PqmwB7tde1EVMglPhTQTWKAXclBsQ0q3xdxP0O+IiT/jQYkiTabLgdFlARVmo2w72viQOFU5saUyBTBSmCjMJGub+WqRPw/Ffi0obkBcZBGbAQNsJYVR0n4Xwne9CJMfL0nH19JkSk+FEtKp7SGj4CYuidFKvIFoltjg68bGgP+jtz2iaOSZUcv3WnKeT7qI9XyQRgCmT1fRzAfjmFM0FLlARUU9vjFIMEb1C8omIkFMG/ZBNjyKUg+qjUTH4ospH+C+iQWzBIzKGlNeNqZBFSKRYwQFIDuISDBT9DcM/KIIA1tLmMW0ZMFSHe34KAR5SZ7a7HECmBPDvBLnW4vwy9i9s+AjqMmDun5mjIe2QQHAcO2zCC0wOL7aiAVMCDJCy2sgOiidgaQ+h9hqzZ8FpgvDMAyY34XkjI3nYeIbK36FOLgBXhNJRGE46QBpDs5xEHOnMZ9GUUFZVF6URIb9OUDYoeymWAaLtIkjkI8lyCziKVMFG9kDg6WRQTePRTorszswRIG2UUHoyOoo55EFOcf1sayzI4C6AINHG/SBpphzXd5oFQznMAs5wffgs8NJ4TEsiTaeIj/EiCOJ8ibmYoDwwxL2ZTgpZG4glSwD+zmg3zXQHoHHaGzQcBEIWAaWqmg4ZeuUophIXSF/QFIkoAQFAj5Kgx3xWae+Cf2vgEQlW7TbGCoGPGrSWktjeAuZGYDEM5wqNVDO1A0hWB8+QdbGlwHIJCzpZKItsYexBYDhfZBEbubTSEzfzcA36LOQ0QUpv4K5VsrOX8k4YWyBwGkcccoGtxPDYW73ftHQ2ehUpKJDTJ8PmkRJzcT4zMoCn4wADkrs9OqWSLBFoFAtsgomWVAWggigMdfemHwio7TXSe0p0sRObYJ9jpOWU6V2wpAEi7p2fcBo6JeAtB8Z4hDWFtWgi7V1y+1aGUdUMFbYNA8Mnnjw28E9J9MHuWmciEUJaBkZxC04HO3N6cZek/SExTQApnqRSUK8KWWeFEWMNFBki/hVTmkU+hzwDimgHJH4a+LyYpM9gLeIBB+BmAruC3B+XM6PsAQbmGJb7DcX4hWgLQROp4rA7UzaARuUZloG1AaAxZxtUZjugiWZAolIHCaHEtA7BMQBoQ44FgLyH68LgPhXYTlC4DJKyUeNf0rcHQEllQc08JeOPKEyIQZ8bACgM7zXDrQ0oesopOC3148xUm5SDQBMxKS/oZmdAA8rfKvm7gb5wyE2fZBUAYhPOsGYHjJlqXFYwscmJETONkR7DEAPMlMa0t8Sd53FhkPSANArm+yY5xQQeRgGohtKnlidUsgAtLroxPlVZRlpkF+WPLnlIUBhQOCrmQqvG88nmACqSIVzQV3yhFX4iRWWF8+p0aZKF3MXmzTgoLEMGoiNg6gnhnySgOxi+XVkA5bS2UvRWhWVlk5TC7OS8D/CPyk+yIrKIGUyBTBoQ12RWkQAeUtB/l+fFnhQF/TriyAEUIkG6HcC4AvA6KulRCovDLTzeodPMO3NwFxxNQClAVWQD7FQT+k88YaYA2LBnLJo+7H7uPUhW2c/6GYG7ItxLh4JBV9qTqPIG4HlBRVJIfOWgELkDhi5KBcEjwzXDIAK58K+dnZEsVll4VIVC2LZIkE14uyjkygK9NcWd5WQ8QfvH0Ho5ujfp8lPycpi46BSp6wM9QaDMDHgzgxrfSSfoKlyqKYUGi3AA4zyYoyZ6lg9GRlJsFYyGwRgSzCTlqYkd3cRom+g4AEDV8RGLCbLqIQVKwED5XgasNio7AXKk+1fG+rIo/DyL8ArVRRQ2pbRxSjB6ithESGUxyQekUhUdTTMbiAMT1tAIkLQJyLpq11OWN+TQ1t5hA8m3i5Ut4P8XeDbGwBH9X/T8W8y5IBEDTAEXbmdYee1APYN+D/BILfU7Nf3ozTZQYA7OlACEN6Gv7hRYAPccObKm/iZACNeYJGHHOz7oUOoP6LUiQDRaWkAA/JJRbSZBMN1cHDaCD6ikbU55GyAFkguAfBOVly4rOqRJyalFS9G6UeaPpG6k1YyuUaMWRYjHKuA6omjRJtk10AjAY7afDMnkYpQXVRqynJWCmBkILS98SFrAQbBiLumF80GN6ojCUAi1eNC4PMLkLMIVqG0qtrhO2lDQ62XCvwjwvj4kJoVgi+xQSPjpb911BI9MoDgUXI4lFoItet1VhnfB71RIHrNoqXmN9r1mS/RXepbVPrNw2ZKAA4vflngItEA/PkBp8V/qwNuAO/s1V3V7UD11XI9WooK3xlme1DQRh/Iq3D8qc1W39aBqG2BLINr8aDb+hIFjBcMDWuLWLgS3Z5pJyWyMalo615NitKuOOplTOxjj7Z0K9UaxsdXYbcAuGrjYRqSg5RuNeAiQLNqa37rlFh6ptR7DS0k5CtYYDbdRJKyPlItI/WrBqVo2SbaR0mrAIZrk3l05tiwBbaDVzzLbZJq209a9s60hlQhsyhOt0pYiqbxN2pDTbQHB13b4tLW2Hf/y2AvbNAnWsQW2V+AprpBaapvPIMHJvSRykAPuv3kHweSvJrHUZH9KfgAyfRwUitf6KrURTtBW8KYLLEPAiYe8DIWgNwBWHZAfCzFdCHOEogeAlO8YqwT2qTFY0UxmnIxh6u7EKEbQLawmZcQQD3DASzgbwhQlAgoAsFXnIoOCX8Gag68ciUfgAA06m9EKcXHFiAPTUyEO9qg9ta1PaSda2w3dJAuI5ajct6wxWHufUJBM0CAOlMwjYQERxd8sb5ccXqBSFptvrbypr3IifJ/4FkmgX2VD7ebYsHCqPjFUC1HTrpHbSiWFsLouSKsAeqHZJ2D0pbntceorc/zpT/CxJXyUXenuEyRApd9IGXXLpTAK7dOJEDCJoBwgeBB+2W13TeqRD0zSdb2+iPnWYQl6rJNk8QVTqkGlBadGalvcztZA3UC1Pkotf9NLWAz+dIM+csLpTzD77G6aUcKRAQWL61dqUhMZrsxna7spbMwQgxSWa7AoGeTGiA+p56OoXdtuD3TySYSagR91YIEHKGso6xgssgfeZqEXSwY29hOtrfDpgNk6oD6vRnTmwoFr66ZsehHWQfD0J70A49GZBsUbioQLV+BxhFkEV1FoVdg0s1UEU/rpQetYi4LZG0mUpi0OxoUuBzWKDIGgYUdTzWwrwm+bI+9bfaeepIl8L69KfRvX+HfHKFMgeYThdHyoSyyx0I+5TF4AINZA3+y5N/eUhn3WQv95EFXSE3HD+BggkIYAIQaD1E6Tqm+m+i+1tCGAvGJQDkp8GAAZLo96+ug6Qa31ohIAIRqYB0mckQNRyl+jkNfq5236ed9+vnZ9QF2hT2kjyCALlljUBqCA/+0ZKwGORUAzkmU65AXCWRaB7kpRrpBwnUCkQZMqERBLQFQj+Q0uDyTo4Pj8D0dBQDAeIPEAEB+Ae8JAQfLQFZBoBJjJAJkJyHiAEI+gJATkIKD6A9Ae8g+ejv4FZA94egDHXQB0fWToAegg+NYz0GFAkAJjzxkgH0E5AqB6OrIBjoPk5AMAfjz4AQPRz6B+AfjPeAQJyGNAjHrjyCbo2wkQB9G/JdAVCD0kuOGBOjpkVCCMtICoRdMn4QY5KGGOlGDAfLXxInCQBIa/UHNROPxsUqQVSTSAWwOOD0hEI6AurdgFYAqJrRqTuoATXSZaCJx1goIEQkyacq2BuTAQWk3hFJM3xaANgJpHOiwwSg/KiAWsKIHfDcnqKfJluDKblMYBFVXgVU0Qg1O68pT/JnU/KekAQSKKhp9UzSY+CmmW4FYbuPtAcDSAlT3J1FA6cTh8RrZGwIhL4AcBRZEA3J6eL4haAkmWgkZluLiaiRsAPT+p8BmqazhhnIzApjKNKGNM0UHTUZxOBpU9Y5R4zmoFPnShVlghTgzva8pN3/gHwPWFVe5Z7qSOYgSChFBSKWSDpph6omYUuSXETlEyVo5kDMcSw0DJmoz/JjsyQA9N3CqNI50c4nBWiZBHxjDcU7yezOpmaYcwGnDadjMTmuAicYsxOZTPCtVzEZ2czGb7E7mW4CphgF7HvgrxkYqIGczmcGEZm7TWpnM3maVo4gPTV5m8wNCYD3m7wqAKchoF7wABSCDLfBPhbI/I2Aces1NYHtCS46437p5lgBbwXYIDVAD3npAaBeQoF4c6uf5NbxhCeAL87ufpgl1ZaWGX859ytLQYlx/UpAI938obAuCQ0FlOIEQBvR8pPqaCAEMFMiECLKZsc9UEnNoVfoj5tc701UoeAtz55j08BJovBnDzx54S9Gb9Pvhtz35y06/Aoo1gNLkl/k8+eDNcBNThFluB+dwq7mbT9gd8APDlD6lLYSgNeEskACYBAhIXwrC0SKUTKagFB3WpDLLccc2JYaiVhAricdczJbktxndz4E3SwWcPO+IF4Xpn07YATMemBAtATkLQE2PxAQTQJvwO8bQBoA+gAgQUOMb6DxB6OqgNnRCAhB+A9ZPxwUPSB7xLHaA2GVq4Pj6AMA+gvIBgJyEKusgyrtx+kDOe9NThcAtgBdNEwHgFndzJAHoPajyvPguQaAHvAwFoANXjjLV4q4sbGOfGWrbIHK5yEBOAn4ggoTa5MYGubGBAgsBaxMc2PFW/APQUa16cUsBFKwd55QKQDY004VI3Jk8/yZf3iTdBUMxLbFJD3bYFcSUtAADbUt7n54FwLFs2ClTcnB85lxOGcxRuXR6Y8wH8x9c+7cnpyUZo8ymcTjA2P+oN7/uDZhkraABQosxDDbhujmW4BASUB4GRtSkTLkAHvBjaxtc3cbGofG8qe5N9AVLZNimzoOXp11Ftv/Yg/TaVEkjTB1+Zm7ObZtI2GLl0UW3zc1t6pBbsAYW79G5uuiSbq58m/YYhl1rQxLWv/idSLw1V0kzFFW1wEBupn1bHN3W35CJvxAdb2NvW3jeosE3ubxNyM6TZzOS2gR1toPbbZ77b0nbcOVWzmfduc3UbXAQWL7YFsB3rzQdom+LfDsW3a1EkqOzTcbVd6bgLaxGYBzYbIyE7Lt+G8nc9vc2egGdqVPrcNsYVuTJt0O2bYjuQzqbstiG2XeMGmSnQztyAK7f5MN2/bXttOy3ZxtZ2lLudkm74mFYGBV7aycoxiaxMkAcTGl+Eyif0BAA== -->

<!-- internal state end -->
--
author:	gemini-code-assist
association:	none
edited:	false
status:	none
--
## Summary of Changes

Hello @sheepdestroyer, I'm Gemini Code Assist[^1]! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly modernizes the application's UI and Fragment management by adopting contemporary AndroidX components and lifecycle practices. The core changes involve upgrading the paging mechanism from the legacy ViewPager to ViewPager2, streamlining Fragment lifecycle callbacks, and introducing ViewModel for robust state retention. These updates enhance maintainability, improve performance, and ensure compatibility with the latest Android development standards.

### Highlights

* **ViewPager2 Migration**: The application has been migrated from the deprecated `ViewPager` and `FragmentStatePagerAdapter` to the modern `ViewPager2` and `FragmentStateAdapter` for improved performance and integration with AndroidX.
* **Fragment Lifecycle Modernization**: Deprecated Fragment lifecycle methods like `onActivityCreated` have been replaced with `onViewCreated` across several fragments (`BaseFragment`, `BaseListFragment`, `FavoriteFragment`, `LazyLoadFragment`, `ListFragment`) to align with current Android development best practices.
* **State Retention with ViewModel**: The `setRetainInstance` method, which is now deprecated, has been replaced by a new `LazyLoadViewModel` to manage the state of `LazyLoadFragment` instances, ensuring proper data retention across configuration changes.
* **Modern Menu Handling**: Menu creation and preparation in `BaseFragment` have been updated to use the `androidx.core.view.MenuProvider` API, replacing the older, deprecated Fragment menu callbacks.
* **Custom ViewPager Removal**: The custom `io.github.sheepdestroyer.materialisheep.widget.ViewPager` class has been removed, as its functionality (swipe enabling) is now handled directly by `ViewPager2`'s `setUserInputEnabled` method.









<details>
<summary><b>Using Gemini Code Assist</b></summary>
<br>

The full guide for Gemini Code Assist can be found on our [documentation page](https://developers.google.com/gemini-code-assist/docs/review-github-code), here are some quick tips.

<b>Invoking Gemini</b>

You can request assistance from Gemini at any point by creating a comment using either `/gemini <command>` or `@gemini-code-assist <command>`. Below is a summary of the supported commands on the current page.

Feature | Command | Description
--- | --- | ---
Code Review | `/gemini review` | Performs a code review for the current pull request in its current state.
Pull Request Summary | `/gemini summary` | Provides a summary of the current pull request in its current state.
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help | `/gemini help` | Displays a list of available commands.

<b>Customization</b>

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a `.gemini/` folder in the base of the repository. Detailed instructions can be found [here](https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github).

<b>Limitations & Feedback</b>

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with :thumbsup: and :thumbsdown: on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up [here](https://google.qualtrics.com/jfe/form/SV_2cyuGuTWsEw84yG).

<b>You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the [Gemini Code Assist IDE Extension](https://cloud.google.com/products/gemini/code-assist).</b>
</details>




[^1]: Review the [Privacy Notices](https://policies.google.com/privacy), [Generative AI Prohibited Use Policy](https://policies.google.com/terms/generative-ai/use-policy), [Terms of Service](https://policies.google.com/terms), and learn how to configure Gemini Code Assist in GitHub [here](https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github). Gemini can make mistakes, so double check it and [use code with caution](https://support.google.com/legal/answer/13505487).

--
author:	qodo-code-review
association:	none
edited:	true
status:	none
--
## PR Compliance Guide 🔍


<!-- https://github.com/sheepdestroyer/materialisheep/commit/4f73c22bf8e4d1a3ce2692db6e9365847ef18557 -->
Below is a summary of compliance checks for this PR:<br>
<table><tbody><tr><td colspan='2'><strong>Security Compliance</strong></td></tr>
<tr><td>🟢</td><td><details><summary><strong>No security concerns identified</strong></summary>
No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
</details></td></tr>
<tr><td colspan='2'><strong>Ticket Compliance</strong></td></tr>
<tr><td>⚪</td><td><details><summary>🎫 <strong>No ticket provided </strong></summary>


- [ ] Create ticket/issue <!-- /create_ticket --create_ticket=true -->

</details></td></tr>
<tr><td colspan='2'><strong>Codebase Duplication Compliance</strong></td></tr>
<tr><td>⚪</td><td><details><summary><strong>Codebase context is not defined </strong></summary>


Follow the <a href='https://qodo-merge-docs.qodo.ai/core-abilities/rag_context_enrichment/'>guide</a> to enable codebase context checks.

</details></td></tr>
<tr><td colspan='2'><strong>Custom Compliance</strong></td></tr>
<tr><td rowspan=2>🟢</td><td>
<details><summary><strong>Generic: Secure Error Handling</strong></summary><br>

**Objective:** To prevent the leakage of sensitive system information through error messages while <br>providing sufficient detail for internal debugging.<br>

**Status:** Passed<br>


> Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a>
</details></td></tr>
<tr><td>
<details><summary><strong>Generic: Secure Logging Practices</strong></summary><br>

**Objective:** To ensure logs are useful for debugging and auditing without exposing sensitive <br>information like PII, PHI, or cardholder data.<br>

**Status:** Passed<br>


> Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a>
</details></td></tr>
<tr><td rowspan=2>🔴</td>
<td><details>
<summary><strong>Generic: Meaningful Naming and Self-Documenting Code</strong></summary><br>

**Objective:** Ensure all identifiers clearly express their purpose and intent, making code <br>self-documenting<br>

**Status:** <br><a href='https://github.com/sheepdestroyer/materialisheep/pull/56/files#diff-a3f58229f06c2b8191eba660862f766fa28dd77ddd1acc12a3feebe4b7f1dfa0R125-R132'><strong>Misleading method name</strong></a>: The method <code>isNewInstance()</code> is now implemented as an unconditional <code>true</code>, making the name <br>misleading relative to its stated intent and documentation.<br>
<details open><summary>Referred Code</summary>

```java
/**
 * Checks if the fragment is a new instance.
 *
 * @return True if the fragment is a new instance, false otherwise.
 */
protected boolean isNewInstance() {
    return true;
}
```

</details>

> Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a>
</details></td></tr>
<tr><td><details>
<summary><strong>Generic: Robust Error Handling and Edge Case Management</strong></summary><br>

**Objective:** Ensure comprehensive error handling that provides meaningful context and graceful <br>degradation<br>

**Status:** <br><a href='https://github.com/sheepdestroyer/materialisheep/pull/56/files#diff-541bfd1c727ef903fd6bb20ddb37eb4d1dbd94a80a601db8b7804f8b61d358c2R146-R153'><strong>Unsafe fragment cast</strong></a>: The code casts the result of <code>getFragment(0)</code> to <code>Navigable</code> without null/type checks, which <br>can crash if the fragment is not yet created or is not <code>Navigable</code>.<br>
<details open><summary>Referred Code</summary>

```java
mViewPager = (ViewPager2) findViewById(R.id.content);
mViewPager.setVisibility(View.GONE);
mReplyButton = (FloatingActionButton) findViewById(R.id.reply_button);
mNavButton = (NavFloatingActionButton) findViewById(R.id.navigation_button);
mNavButton.setNavigable(direction ->
// if callback is fired navigable should not be null
((Navigable) getFragment(0)).onNavigate(direction));
AppUtils.toggleFab(mNavButton, false);
```

</details>

> Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a>
</details></td></tr>
<tr><td rowspan=2>⚪</td>
<td><details>
<summary><strong>Generic: Comprehensive Audit Trails</strong></summary><br>

**Objective:** To create a detailed and reliable record of critical system actions for security analysis <br>and compliance.<br>

**Status:** <br><a href='https://github.com/sheepdestroyer/materialisheep/pull/56/files#diff-541bfd1c727ef903fd6bb20ddb37eb4d1dbd94a80a601db8b7804f8b61d358c2R516-R548'><strong>No audit logging</strong></a>: The diff introduces new user-triggered state changes and navigation flows without any <br>audit logging, but it is unclear from the diff whether these actions are considered <br>&quot;critical&quot; or are logged elsewhere.<br>
<details open><summary>Referred Code</summary>

```java
        mViewPager.setVisibility(View.VISIBLE);
        bindViewPager();
        mSessionManager.view(mSelectedItem.getId());
    }
}

private void bindViewPager() {
    if (mAdapter != null) {
        // No custom unbind needed for Adapter anymore
    }
    mAdapter = new ItemPagerAdapter(this, new ItemPagerAdapter.Builder()
            .setItem(mSelectedItem)
            .setCacheMode(getItemCacheMode())
            .setShowArticle(true)
            .setDefaultViewMode(mStoryViewMode));
    mViewPager.setAdapter(mAdapter);
    new TabLayoutMediator(mTabLayout, mViewPager,
            (tab, position) -> tab.setText(mAdapter.getPageTitle(position))).attach();
    mViewPager.registerOnPageChangeCallback(new ViewPager2.OnPageChangeCallback() {
        @Override
        public void onPageSelected(int position) {


 ... (clipped 12 lines)
```

</details>

> Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a>
</details></td></tr>
<tr><td><details>
<summary><strong>Generic: Security-First Input Validation and Data Handling</strong></summary><br>

**Objective:** Ensure all data inputs are validated, sanitized, and handled securely to prevent <br>vulnerabilities<br>

**Status:** <br><a href='https://github.com/sheepdestroyer/materialisheep/pull/56/files#diff-cd1bd6c16056eabdbb05b9b46cd4f05e46572722c428ea2fa7bb3250beeb6545R186-R192'><strong>Unvalidated runtime type</strong></a>: The code casts <code>getFragment(0)</code> to <code>Navigable</code> without validating existence/type, which can be <br>influenced by lifecycle/state and lead to crashes rather than a controlled failure path.<br>
<details open><summary>Referred Code</summary>

```java
mReplyButton = findViewById(R.id.reply_button);
mNavButton = findViewById(R.id.navigation_button);
mNavButton = findViewById(R.id.navigation_button);
mNavButton.setNavigable(direction ->
// if callback is fired navigable should not be null
AppUtils.navigate(direction, mAppBar, (Navigable) getFragment(0)));
mVoteButton = findViewById(R.id.vote_button);
```

</details>

> Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a>
</details></td></tr>

<tr><td align="center" colspan="2">

- [ ] Update <!-- /compliance --update_compliance=true -->

</td></tr></tbody></table>
<details><summary>Compliance status legend</summary>
🟢 - Fully Compliant<br>
🟡 - Partial Compliant<br>
🔴 - Not Compliant<br>
⚪ - Requires Further Human Verification<br>
🏷️ - Compliance label<br>
</details>
--
author:	sourcery-ai
association:	none
edited:	false
status:	commented
--
Hey - I've found 2 issues, and left some high level feedback:

- In LazyLoadFragment, the new eagerLoad() implementation only checks isEagerLoad() and no longer guards on an unloaded state, so load() can now be invoked multiple times; consider tracking and checking an isLoaded flag (from LazyLoadViewModel) before calling load(), and revisiting isNewInstance() now that it always returns true.
- The new getFragment/unbindViewPager logic in BaseListActivity and ItemActivity relies on hardcoded ViewPager2 fragment tags ("f0", "f1"); this is brittle if itemIds or page count change—consider deriving tags from adapter itemIds or resolving current fragments via FragmentManager and container id rather than fixed tag strings.
- In ItemActivity.onCreate, mNavButton is assigned twice consecutively from findViewById(R.id.navigation_button); the second assignment is redundant and can be removed.

<details>
<summary>Prompt for AI Agents</summary>

~~~markdown
Please address the comments from this code review:

## Overall Comments
- In LazyLoadFragment, the new eagerLoad() implementation only checks isEagerLoad() and no longer guards on an unloaded state, so load() can now be invoked multiple times; consider tracking and checking an isLoaded flag (from LazyLoadViewModel) before calling load(), and revisiting isNewInstance() now that it always returns true.
- The new getFragment/unbindViewPager logic in BaseListActivity and ItemActivity relies on hardcoded ViewPager2 fragment tags ("f0", "f1"); this is brittle if itemIds or page count change—consider deriving tags from adapter itemIds or resolving current fragments via FragmentManager and container id rather than fixed tag strings.
- In ItemActivity.onCreate, mNavButton is assigned twice consecutively from findViewById(R.id.navigation_button); the second assignment is redundant and can be removed.

## Individual Comments

### Comment 1
<location> `app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java:135-136` </location>
<code_context>
     final void eagerLoad() {
-        if (mEagerLoad && !mLoaded) {
-            mLoaded = true;
+        if (mViewModel.isEagerLoad()) {
+            mViewModel.setLoaded(true);
             load();
         }
</code_context>

<issue_to_address>
**issue (bug_risk):** Guard `load()` with the `loaded` flag to avoid repeated loading.

Before the refactor, `eagerLoad()` guarded `load()` with `!mLoaded`, so it ran at most once per instance even if `loadNow()` or lifecycle events fired multiple times. Now `eagerLoad()` only checks `isEagerLoad()` and always calls `load()`, so multiple invocations (e.g., repeated `loadNow()` or visibility changes) can trigger repeated loads. Please reintroduce the `!isLoaded()` check:

```java
final void eagerLoad() {
    if (mViewModel.isEagerLoad() && !mViewModel.isLoaded()) {
        mViewModel.setLoaded(true);
        load();
    }
}
```

and ensure `STATE_LOADED` is restored from the ViewModel if that flag must be persisted.
</issue_to_address>

### Comment 2
<location> `app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java:39-48` </location>
<code_context>
      */
-    @SuppressWarnings("deprecation") // Using deprecated onActivityCreated; migration to onViewCreated requires
-                                     // refactoring
-    @Override
-    public void onActivityCreated(Bundle savedInstanceState) {
-        super.onActivityCreated(savedInstanceState);
</code_context>

<issue_to_address>
**suggestion:** Using `setUserVisibleHint` is deprecated and won’t be triggered by ViewPager2.

With ViewPager2 + FragmentStateAdapter, `setUserVisibleHint` is never invoked because visibility is controlled via `setMaxLifecycle`, so this method is effectively dead code and can mislead future maintenance around lazy loading.

Given that `loadNow()` is already triggered from the ViewPager2 `OnPageChangeCallback`, you can remove this override. If you still need lifecycle-driven loading, tie it to fragment lifecycle callbacks (e.g., `onResume` with the adapter’s current item) instead of `setUserVisibleHint`.
</issue_to_address>
~~~

</details>

***

<details>
<summary>Sourcery is free for open source - if you like our reviews please consider sharing them ✨</summary>

- [X](https://twitter.com/intent/tweet?text=I%20just%20got%20an%20instant%20code%20review%20from%20%40SourceryAI%2C%20and%20it%20was%20brilliant%21%20It%27s%20free%20for%20open%20source%20and%20has%20a%20free%20trial%20for%20private%20code.%20Check%20it%20out%20https%3A//sourcery.ai)
- [Mastodon](https://mastodon.social/share?text=I%20just%20got%20an%20instant%20code%20review%20from%20%40SourceryAI%2C%20and%20it%20was%20brilliant%21%20It%27s%20free%20for%20open%20source%20and%20has%20a%20free%20trial%20for%20private%20code.%20Check%20it%20out%20https%3A//sourcery.ai)
- [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https://sourcery.ai)
- [Facebook](https://www.facebook.com/sharer/sharer.php?u=https://sourcery.ai)

</details>

<sub>
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
</sub>
--
author:	qodo-code-review
association:	none
edited:	true
status:	none
--
## PR Code Suggestions ✨

<!-- 4f73c22 -->

Explore these optional code suggestions:

<table><thead><tr><td><strong>Category</strong></td><td align=left><strong>Suggestion&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </strong></td><td align=center><strong>Impact</strong></td></tr><tbody><tr><td rowspan=1>Possible issue</td>
<td>



<details><summary>✅ <s>Use onResume for fragment visibility detection</s></summary>

___

<details><summary><b>Suggestion Impact:</b></summary>The commit removed the setUserVisibleHint override (the method called out as deprecated/non-functional with ViewPager2), and adjusted loading logic to avoid re-loading (added !isLoaded check) while triggering eagerLoad from onViewCreated instead. However, it did not implement the suggested onResume-based visibility detection.


code diff:

```diff
     public void onViewCreated(android.view.View view, Bundle savedInstanceState) {
         super.onViewCreated(view, savedInstanceState);
         mActivityCreated = true;
-        if (isNewInstance()) {
+        if (true) {
             eagerLoad();
         }
     }
@@ -98,15 +91,6 @@
         mActivityCreated = false;
     }
 
-    @Override
-    public void setUserVisibleHint(boolean isVisibleToUser) {
-        super.setUserVisibleHint(isVisibleToUser);
-        if (isVisibleToUser && !mViewModel.isLoaded()) {
-            mViewModel.setEagerLoad(true);
-            eagerLoad();
-        }
-    }
-
     /**
      * Loads the data immediately.
      */
@@ -122,17 +106,8 @@
      */
     protected abstract void load();
 
-    /**
-     * Checks if the fragment is a new instance.
-     *
-     * @return True if the fragment is a new instance, false otherwise.
-     */
-    protected boolean isNewInstance() {
-        return true;
-    }
-
     final void eagerLoad() {
-        if (mViewModel.isEagerLoad()) {
+        if (mViewModel.isEagerLoad() && !mViewModel.isLoaded()) {
             mViewModel.setLoaded(true);
             load();
         }
```

</details>


___

**Replace the deprecated <code>setUserVisibleHint</code> method with <code>onResume</code> for detecting <br>fragment visibility. This is necessary because <code>ViewPager2</code> does not call <br><code>setUserVisibleHint</code>, which would prevent lazy-loaded fragments from ever loading <br>their data.**

[app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java [101-108]](https://github.com/sheepdestroyer/materialisheep/pull/56/files#diff-a3f58229f06c2b8191eba660862f766fa28dd77ddd1acc12a3feebe4b7f1dfa0R101-R108)

```diff
 @Override
-public void setUserVisibleHint(boolean isVisibleToUser) {
-    super.setUserVisibleHint(isVisibleToUser);
-    if (isVisibleToUser && !mViewModel.isLoaded()) {
+public void onResume() {
+    super.onResume();
+    // onResume is called when the fragment becomes the primary navigation fragment in ViewPager2
+    if (getUserVisibleHint() && !mViewModel.isLoaded()) { // Maintain compatibility with old ViewPager if needed
         mViewModel.setEagerLoad(true);
         eagerLoad();
     }
 }
```


`[Suggestion processed]`


<details><summary>Suggestion importance[1-10]: 9</summary>

__

Why: This suggestion correctly identifies a critical bug where lazy-loaded fragments would not load due to the deprecation of `setUserVisibleHint` in `ViewPager2`, and it provides the correct fix using `onResume`.


</details></details></td><td align=center>High

</td></tr><tr><td rowspan=1>General</td>
<td>



<details><summary>✅ <s>Unregister callbacks to prevent leaks</s></summary>

___

<details><summary><b>Suggestion Impact:</b></summary>The commit introduces member fields for TabLayoutMediator and the ViewPager2.OnPageChangeCallback, uses them when binding the ViewPager, and properly detaches/unregisters them in unbindViewPager(). It also additionally stores/removes a TabLayout.OnTabSelectedListener for cleanup.


code diff:

```diff
+    private TabLayoutMediator mTabLayoutMediator;
+    private ViewPager2.OnPageChangeCallback mPageChangeCallback;
+    private TabLayout.OnTabSelectedListener mTabSelectedListener;
 
     /**
      * Called when the activity is first created.
@@ -529,9 +532,11 @@
                 .setShowArticle(true)
                 .setDefaultViewMode(mStoryViewMode));
         mViewPager.setAdapter(mAdapter);
-        new TabLayoutMediator(mTabLayout, mViewPager,
-                (tab, position) -> tab.setText(mAdapter.getPageTitle(position))).attach();
-        mViewPager.registerOnPageChangeCallback(new ViewPager2.OnPageChangeCallback() {
+        mTabLayoutMediator = new TabLayoutMediator(mTabLayout, mViewPager,
+                (tab, position) -> tab.setText(mAdapter.getPageTitle(position)));
+        mTabLayoutMediator.attach();
+
+        mPageChangeCallback = new ViewPager2.OnPageChangeCallback() {
             @Override
             public void onPageSelected(int position) {
                 super.onPageSelected(position);
@@ -544,8 +549,10 @@
                     ((LazyLoadFragment) fragment).loadNow();
                 }
             }
-        });
-        mTabLayout.addOnTabSelectedListener(new TabLayout.OnTabSelectedListener() {
+        };
+        mViewPager.registerOnPageChangeCallback(mPageChangeCallback);
+
+        mTabSelectedListener = new TabLayout.OnTabSelectedListener() {
             @Override
             public void onTabSelected(TabLayout.Tab tab) {
             }
@@ -561,7 +568,8 @@
                     ((Scrollable) fragment).scrollToTop();
                 }
             }
-        });
+        };
+        mTabLayout.addOnTabSelectedListener(mTabSelectedListener);
 
         // Initial FAB state
         int current = mViewPager.getCurrentItem();
@@ -575,6 +583,20 @@
 
     @SuppressLint("RestrictedApi")
     private void unbindViewPager() {
+        if (mTabLayoutMediator != null) {
+            mTabLayoutMediator.detach();
+            mTabLayoutMediator = null;
+        }
+
+        if (mPageChangeCallback != null) {
+            mViewPager.unregisterOnPageChangeCallback(mPageChangeCallback);
+            mPageChangeCallback = null;
+        }
+        if (mTabSelectedListener != null) {
+            mTabLayout.removeOnTabSelectedListener(mTabSelectedListener);
+            mTabSelectedListener = null;
+        }
```

</details>


___

**To prevent memory leaks, store the <code>OnPageChangeCallback</code> and <code>TabLayoutMediator</code> <br>instances as member fields. Unregister the callback and detach the mediator in <br>the <code>unbindViewPager()</code> method to ensure they are properly cleaned up.**

[app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseListActivity.java [534-547]](https://github.com/sheepdestroyer/materialisheep/pull/56/files#diff-541bfd1c727ef903fd6bb20ddb37eb4d1dbd94a80a601db8b7804f8b61d358c2R534-R547)

```diff
-mViewPager.registerOnPageChangeCallback(new ViewPager2.OnPageChangeCallback() {
+// declare fields
+private ViewPager2.OnPageChangeCallback mPageCallback;
+private TabLayoutMediator mTabMediator;
+
+// in bindViewPager():
+mPageCallback = new ViewPager2.OnPageChangeCallback() {
     @Override
-    public void onPageSelected(int position) {
-        super.onPageSelected(position);
-        AppUtils.toggleFab(mNavButton, position == 0 && Preferences.navigationEnabled(BaseListActivity.this));
-        AppUtils.toggleFab(mReplyButton, true);
-        AppUtils.toggleFabAction(mReplyButton, mSelectedItem, position == 0);
+    public void onPageSelected(int position) { /* ... */ }
+};
+mViewPager.registerOnPageChangeCallback(mPageCallback);
+mTabMediator = new TabLayoutMediator(mTabLayout, mViewPager,
+    (tab, pos) -> tab.setText(mAdapter.getPageTitle(pos)));
+mTabMediator.attach();
 
-        Fragment fragment = getFragment(position);
-        if (fragment instanceof LazyLoadFragment) {
-            ((LazyLoadFragment) fragment).loadNow();
-        }
-    }
-});
+// in unbindViewPager():
+if (mPageCallback != null) {
+    mViewPager.unregisterOnPageChangeCallback(mPageCallback);
+    mPageCallback = null;
+}
+if (mTabMediator != null) {
+    mTabMediator.detach();
+    mTabMediator = null;
+}
+FragmentTransaction transaction = getSupportFragmentManager().beginTransaction();
+// ...
+transaction.commitAllowingStateLoss();
```



`[To ensure code accuracy, apply this suggestion manually]`


<details><summary>Suggestion importance[1-10]: 8</summary>

__

Why: This suggestion correctly identifies a memory leak caused by not unregistering callbacks and provides a clear, correct solution to fix it, which is crucial for application stability.


</details></details></td><td align=center>Medium

</td></tr>
<tr><td align="center" colspan="2">

- [ ] Update <!-- /improve_multi --more_suggestions=true -->

</td><td></td></tr></tbody></table>
--
author:	ellipsis-dev
association:	none
edited:	false
status:	commented
--
> [!CAUTION]
> **Changes requested  :x:**
> <details>
> <summary>Reviewed everything up to 4f73c22bf8e4d1a3ce2692db6e9365847ef18557 in <ellipsistime>2 minutes and 3 seconds</ellipsistime>. Click for details.</summary> 
> 
> - Reviewed `826` lines of code in `13` files
> - Skipped `0` files when reviewing.
> - Skipped posting `8` draft comments. View those below.
> - Modify your [settings](https://app.ellipsis.dev/sheepdestroyer/settings/code-review) and [rules](https://app.ellipsis.dev/sheepdestroyer/code-review/rules) to customize what types of comments Ellipsis leaves. And don't forget to react with :+1: or :-1: to teach Ellipsis.
> 
> <details>
> <summary>1. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java:101</code></summary>
> 
> - **Draft comment:** 
> Usage of setUserVisibleHint is deprecated; consider using a modern visibility observer or the FragmentTransaction#setMaxLifecycle API.
> - **Reason this comment was not posted:**
> Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% The comment is about code that was added in this PR (the setUserVisibleHint method is new). The comment is technically correct - setUserVisibleHint is deprecated. However, I need to consider the rules: the PR is migrating from setRetainInstance to ViewModel, which is already a significant refactoring. The author may have intentionally kept setUserVisibleHint for now as part of a gradual migration. The comment suggests alternatives but doesn't provide specific actionable code. It's more of a "you should consider" type comment rather than pointing out a clear bug. Given the context that this is already a migration PR, the author likely knows about this deprecation and may be addressing it incrementally. The author is already doing a significant refactoring to migrate to ViewModel. They may be aware of the deprecation and intentionally keeping this for now. The comment doesn't show that this causes a concrete problem, just that it's deprecated. Without knowing if there's a specific issue this causes, this might be premature optimization feedback. While the author may be aware of the deprecation, adding deprecated APIs in new code is generally a code smell. However, the comment is somewhat speculative ("consider using") rather than pointing to a definite issue. The rules state not to make speculative comments and to only comment if there's clearly a code change required. This comment points out a deprecated API but is more of a suggestion than identifying a clear bug or required change. Given the rules against speculative comments and the fact that this is already a refactoring PR, this comment should be deleted as it's not pointing to a definite issue that must be fixed.
> 
> 
> </details>
> 
> <details>
> <summary>2. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseListActivity.java:578</code></summary>
> 
> - **Draft comment:** 
> Unbind logic removes fragments using hardcoded tags 'f0' and 'f1'; ensure these tags remain valid if the page count ever changes.
> - **Reason this comment was not posted:**
> Comment did not seem useful. Confidence is useful = `0%` <= threshold `50%` The comment is asking the author to ensure that the tags remain valid if the page count changes. This is a form of asking the author to double-check their work, which violates the rules. The comment does not provide a specific suggestion or point out a specific issue with the code.
> 
> 
> </details>
> 
> <details>
> <summary>3. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/widget/ItemPagerAdapter.java:43</code></summary>
> 
> - **Draft comment:** 
> Migration to FragmentStateAdapter is successful; note that caching of fragments is no longer manual. If state retention is needed, consider managing state via ViewModels.
> - **Reason this comment was not posted:**
> Comment did not seem useful. Confidence is useful = `20%` <= threshold `50%` This comment is purely informative, explaining a change in behavior related to `FragmentStateAdapter`. It doesn't provide a specific suggestion or ask for confirmation about an intentional change. It seems to be informing the author about a feature rather than addressing a potential issue or improvement in the code.
> 
> 
> </details>
> 
> <details>
> <summary>4. <code>app/src/main/res/layout-w820dp-land/activity_list.xml:83</code></summary>
> 
> - **Draft comment:** 
> Replacement of the custom ViewPager with ViewPager2 and proper TabLayoutMediator usage looks good.
> - **Reason this comment was not posted:**
> Confidence changes required: `0%` <= threshold `50%` None
> 
> 
> </details>
> 
> <details>
> <summary>5. <code>app/src/main/res/layout/activity_item.xml:57</code></summary>
> 
> - **Draft comment:** 
> The layout now uses ViewPager2 in place of the deprecated custom ViewPager; ensure all IDs (e.g. 'view_pager') are consistently referenced in code.
> - **Reason this comment was not posted:**
> Confidence changes required: `0%` <= threshold `50%` None
> 
> 
> </details>
> 
> <details>
> <summary>6. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseFragment.java:56</code></summary>
> 
> - **Draft comment:** 
> Typo: Consider changing "restored in to the view" to "restored into the view".
> - **Reason this comment was not posted:**
> Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment is about a grammatical typo in documentation. While technically correct, I need to consider if this is "obvious or unimportant" according to the rules. The typo is minor - "in to" vs "into" - and doesn't affect code functionality. However, looking more closely at the diff, this JavaDoc comment appears to be copied from Android's standard documentation for onViewCreated. The text "restored in to the view" is actually the original Android documentation text. If this is copied from the Android SDK documentation, then the author likely copied it verbatim and changing it might not be appropriate. But I can't be 100% sure without checking the Android source. The comment is very minor and could be considered "obvious or unimportant" - it's just a small grammatical issue in a comment that doesn't affect functionality. This could be standard Android documentation that was copied verbatim, in which case changing it might not be appropriate. Also, even if it's a legitimate typo, it's extremely minor and could fall under "obvious or unimportant" comments that should not be made. While it might be standard documentation, I cannot verify that without additional context. However, the rule about "obvious or unimportant" comments is clear - this is a very minor grammatical issue in documentation that has no impact on code functionality. Such minor typo corrections typically fall into the category of unimportant comments. This comment should be deleted. It's pointing out a very minor grammatical typo in documentation that has no functional impact. This falls under the rule against "obvious or unimportant" comments. Additionally, the JavaDoc may be copied from Android's standard documentation, making the change potentially inappropriate.
> 
> 
> </details>
> 
> <details>
> <summary>7. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java:67</code></summary>
> 
> - **Draft comment:** 
> Typographical suggestion: On line 67, consider replacing "in to" with "into" for better readability.
> - **Reason this comment was not posted:**
> Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a comment about a typo in documentation/comments. Looking at the rules, I need to check: 1) Is this about a code change? Yes, the javadoc comment was added in this diff. 2) Does it require a code change? It's suggesting a typo fix, which is very minor. 3) Is it obvious or unimportant? This is a very minor typo fix in a comment. The rules say "Do NOT make comments that are obvious or unimportant." A typo in documentation is quite minor and could be considered unimportant. 4) The rules emphasize not making comments unless there is "clearly a code change required" - a typo in a comment is not really a code change that affects functionality. This seems like the kind of nitpicky comment that should be filtered out. While fixing typos improves code quality, this is an extremely minor issue in a comment that doesn't affect functionality. The rules specifically say not to make obvious or unimportant comments, and a two-word typo in documentation could fall into that category. You're right that this is very minor. The rules emphasize not making comments unless there's clearly a code change required, and fixing "in to" vs "into" in a javadoc comment is not a critical code change. This is the type of nitpicky, unimportant comment that should be filtered out. This comment should be deleted. While it correctly identifies a typo, it's an unimportant and obvious issue in documentation that doesn't warrant a review comment according to the rules.
> 
> 
> </details>
> 
> <details>
> <summary>8. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/ListFragment.java:185</code></summary>
> 
> - **Draft comment:** 
> Typo in the documentation comment: consider using "into" instead of "in to" in the phrase "restored in to the view."
> - **Reason this comment was not posted:**
> Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a documentation typo fix suggestion. The rules state "Do NOT make comments that are obvious or unimportant." A typo in documentation could be considered minor/unimportant. However, the rules also say "Comments that suggest code quality refactors are good! But only if they are actionable and clear." This is actionable and clear - it's a simple typo fix. The question is whether fixing a documentation typo counts as important enough. The phrase "in to" vs "into" is indeed incorrect grammar - "into" is the correct preposition here. However, this is a very minor issue in a comment that was just added. The rules emphasize not commenting unless there's "clearly a code change required" and to avoid "obvious or unimportant" comments. A documentation typo, while technically incorrect, is quite minor and doesn't affect functionality. This seems to fall into the "unimportant" category. While the typo is real and the fix is correct, documentation typos are generally considered minor issues. The comment doesn't affect code functionality, and the meaning is still clear despite the grammatical error. This might be too pedantic for a code review. Even though it's minor, documentation quality matters for maintainability. However, the rules explicitly state not to make "obvious or unimportant" comments, and a small grammatical error in documentation that doesn't affect understanding likely falls into this category. The bar for keeping comments should be high. This comment points out a legitimate typo, but it's a very minor documentation issue that doesn't affect code functionality or clarity. Given the rules emphasize avoiding unimportant comments, this should be deleted.
> 
> 
> </details>
> 
> 
> Workflow ID: <workflowid>`wflow_aWmqFbXzZ6ycdrMk`</workflowid>
> </details>
> 
> <sup>You can customize </sup>[<img alt="Ellipsis" src="https://img.shields.io/badge/Ellipsis-blue?color=175173">](https://www.ellipsis.dev?ref=sheepdestroyer%2Fmaterialisheep&utm_source=github&utm_medium=referral)<sup> by changing your [verbosity settings](https://app.ellipsis.dev/sheepdestroyer/settings/code-review), reacting with :+1: or :-1:, [replying to comments](https://docs.ellipsis.dev/features/code-review#teaching-ellipsis), or adding [code review rules](https://app.ellipsis.dev/sheepdestroyer/code-review/rules).</sup>
--
author:	gemini-code-assist
association:	none
edited:	false
status:	commented
--
## Code Review

This pull request is a significant and well-executed refactoring to modernize the app's architecture. The migration from the deprecated `ViewPager` and `FragmentStatePagerAdapter` to `ViewPager2` and `FragmentStateAdapter` is a great improvement. I also appreciate the modernization of Fragment APIs, such as replacing `onActivityCreated` with `onViewCreated`, using `MenuProvider` for menus, and adopting `ViewModel` for state retention instead of `setRetainInstance`. The code is cleaner and follows current Android best practices. I've left a few minor suggestions to further improve code quality and maintainability, but overall this is excellent work.
--
author:	sheepdestroyer
association:	owner
edited:	false
status:	none
--
/gemini review
--
author:	sheepdestroyer
association:	owner
edited:	false
status:	none
--
@coderabbitai review
--
author:	sheepdestroyer
association:	owner
edited:	false
status:	none
--
@sourcery-ai review
--
author:	sheepdestroyer
association:	owner
edited:	false
status:	none
--
/review
--
author:	sheepdestroyer
association:	owner
edited:	false
status:	none
--
@ellipsis review this
--
author:	coderabbitai
association:	none
edited:	false
status:	none
--
<!-- This is an auto-generated reply by CodeRabbit -->
<details>
<summary>✅ Actions performed</summary>

Review triggered.

> Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

</details>
--
author:	qodo-code-review
association:	none
edited:	true
status:	none
--
## PR Reviewer Guide 🔍

#### (Review updated until commit https://github.com/sheepdestroyer/materialisheep/commit/a54e2533e73737e69ab715749c49cab76f498b9e)


Here are some key observations to aid the review process:

<table>
<tr><td>⏱️&nbsp;<strong>Estimated effort to review</strong>: 4 🔵🔵🔵🔵⚪</td></tr>
<tr><td>🧪&nbsp;<strong>No relevant tests</strong></td></tr>
<tr><td>🔒&nbsp;<strong>No security concerns identified</strong></td></tr>
<tr><td>⚡&nbsp;<strong>Recommended focus areas for review</strong><br><br>

<details><summary><a href='https://github.com/sheepdestroyer/materialisheep/pull/56/files#diff-cd1bd6c16056eabdbb05b9b46cd4f05e46572722c428ea2fa7bb3250beeb6545R498-R546'><strong>Lifecycle Leak</strong></a>

ViewPager2/TabLayout listeners are registered via anonymous instances (TabLayoutMediator, OnPageChangeCallback, OnTabSelectedListener) without being stored and explicitly detached/unregistered. This can lead to duplicated callbacks after rebinding data, or leaking the Activity/Views across configuration changes. Consider holding references and cleaning them up in a symmetric teardown (e.g., onDestroy/onDestroyView or when rebinding).
</summary>

```java
        break;
}
boolean hasText = story instanceof Item && !TextUtils.isEmpty(((Item) story).getText());
mAdapter = new ItemPagerAdapter(this,
        new ItemPagerAdapter.Builder()
                .setItem(story)
                .setShowArticle(hasText || !mExternalBrowser)
                .setCacheMode(getIntent().getIntExtra(EXTRA_CACHE_MODE, ItemManager.MODE_DEFAULT))
                .setRetainInstance(true)
                .setDefaultViewMode(mStoryViewMode));
mViewPager.setAdapter(mAdapter);
mViewPager.setOffscreenPageLimit(2);
new TabLayoutMediator(mTabLayout, mViewPager,
        (tab, position) -> tab.setText(mAdapter.getPageTitle(position))).attach();
mViewPager.registerOnPageChangeCallback(new ViewPager2.OnPageChangeCallback() {
    @Override
    public void onPageSelected(int position) {
        super.onPageSelected(position);
        toggleFabs(position == 0, mNavButton, mReplyButton);
        Fragment fragment = getFragment(position);
        if (fragment instanceof LazyLoadFragment) {
            ((LazyLoadFragment) fragment).loadNow();
        }
    }
});
mTabLayout.addOnTabSelectedListener(new TabLayout.OnTabSelectedListener() {
    @Override
    public void onTabSelected(TabLayout.Tab tab) {
        // handled by Mediator/ViewPager2 callback
    }

    @Override
    public void onTabUnselected(TabLayout.Tab tab) {
    }

    @Override
    public void onTabReselected(TabLayout.Tab tab) {
        Fragment fragment = getFragment(mViewPager.getCurrentItem());
        if (fragment instanceof Scrollable) {
            ((Scrollable) fragment).scrollToTop();
        }
        mAppBar.setExpanded(true, true);
    }
});
int defaultItem = Math.min(mAdapter.getItemCount() - 1,
        mStoryViewMode == Preferences.StoryViewMode.Comment ? 0 : 1);
mViewPager.setCurrentItem(defaultItem, false);
toggleFabs(defaultItem == 0, mNavButton, mReplyButton);
if (story.isStoryType() && mExternalBrowser && !hasText) {
```

</details>

<details><summary><a href='https://github.com/sheepdestroyer/materialisheep/pull/56/files#diff-a3f58229f06c2b8191eba660862f766fa28dd77ddd1acc12a3feebe4b7f1dfa0R101-R108'><strong>Deprecated API</strong></a>

setUserVisibleHint is deprecated and not reliably invoked with ViewPager2/FragmentStateAdapter. Depending on it for triggering eager load may cause fragments to never load. Prefer triggering load based on lifecycle (e.g., onResume + current item) or ViewPager2 page selection callbacks routed to the fragment.
</summary>

```java
@Override
public void setUserVisibleHint(boolean isVisibleToUser) {
    super.setUserVisibleHint(isVisibleToUser);
    if (isVisibleToUser && !mViewModel.isLoaded()) {
        mViewModel.setEagerLoad(true);
        eagerLoad();
    }
}
```

</details>

<details><summary><a href='https://github.com/sheepdestroyer/materialisheep/pull/56/files#diff-541bfd1c727ef903fd6bb20ddb37eb4d1dbd94a80a601db8b7804f8b61d358c2R600-R613'><strong>Fragment Lookup</strong></a>

Fragment retrieval/removal relies on hardcoded FragmentStateAdapter tags ("f0", "f1") and assumes itemId == position. This is brittle if the adapter uses stable IDs, if the dataset changes, or if the underlying tag format differs. Validate that fragments are consistently found/removed across rotation/process death, and consider using adapter item IDs or FragmentManager fragment list filtering by container id instead of fixed tags.
</summary>

```java
    // Remove fragments by Tag ("f" + id). IDs are 0 and 1.
    FragmentTransaction transaction = getSupportFragmentManager().beginTransaction();
    Fragment f0 = getSupportFragmentManager().findFragmentByTag("f0");
    if (f0 != null)
        transaction.remove(f0);
    Fragment f1 = getSupportFragmentManager().findFragmentByTag("f1");
    if (f1 != null)
        transaction.remove(f1);
    transaction.commitAllowingStateLoss();
}

private Fragment getFragment(int position) {
    return getSupportFragmentManager().findFragmentByTag("f" + position);
}
```

</details>

</td></tr>
</table>

--
author:	sourcery-ai
association:	none
edited:	false
status:	commented
--
Hey - I've found 4 issues, and left some high level feedback:

- The new `getFragment(int position)` helpers in `BaseListActivity` and `ItemActivity` rely on the internal `FragmentStateAdapter` tag format (`"f" + position`) and `unbindViewPager()` manually removes `f0`/`f1`; this is brittle—consider holding references in the adapter or using a `FragmentTransactionCallback`/`FragmentStateAdapter` API rather than hard-coding tags and positions.
- In `LazyLoadFragment`, `setUserVisibleHint` is reintroduced even though it is deprecated and not invoked by `ViewPager2`; if you need visibility-based loading with `ViewPager2`, consider using `ViewPager2.OnPageChangeCallback` (as you already do) or `FragmentTransactionCallback` instead of `setUserVisibleHint`.
- The `LazyLoadFragment` migration changes `isNewInstance()` to always return `true` and no longer uses the `STATE_LOADED` flag from saved state, which effectively forces reloads on every view recreation; if this is unintentional, you may want to restore `loaded` state into `LazyLoadViewModel` or adjust `isNewInstance()` semantics to avoid redundant loads.

<details>
<summary>Prompt for AI Agents</summary>

~~~markdown
Please address the comments from this code review:

## Overall Comments
- The new `getFragment(int position)` helpers in `BaseListActivity` and `ItemActivity` rely on the internal `FragmentStateAdapter` tag format (`"f" + position`) and `unbindViewPager()` manually removes `f0`/`f1`; this is brittle—consider holding references in the adapter or using a `FragmentTransactionCallback`/`FragmentStateAdapter` API rather than hard-coding tags and positions.
- In `LazyLoadFragment`, `setUserVisibleHint` is reintroduced even though it is deprecated and not invoked by `ViewPager2`; if you need visibility-based loading with `ViewPager2`, consider using `ViewPager2.OnPageChangeCallback` (as you already do) or `FragmentTransactionCallback` instead of `setUserVisibleHint`.
- The `LazyLoadFragment` migration changes `isNewInstance()` to always return `true` and no longer uses the `STATE_LOADED` flag from saved state, which effectively forces reloads on every view recreation; if this is unintentional, you may want to restore `loaded` state into `LazyLoadViewModel` or adjust `isNewInstance()` semantics to avoid redundant loads.

## Individual Comments

### Comment 1
<location> `app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java:134-135` </location>
<code_context>
+        return true;
     }

     final void eagerLoad() {
-        if (mEagerLoad && !mLoaded) {
-            mLoaded = true;
+        if (mViewModel.isEagerLoad()) {
+            mViewModel.setLoaded(true);
             load();
</code_context>

<issue_to_address>
**issue (bug_risk):** Guard eagerLoad() with a loaded flag to avoid calling load() multiple times.

The previous `if (mEagerLoad && !mLoaded)` ensured `load()` ran only once per fragment. Now we only check `mViewModel.isEagerLoad()`, always set `setLoaded(true)`, and never read the loaded state, so repeated `eagerLoad()` calls (e.g. via `loadNow()` or visibility changes) will re-invoke `load()`. Unless `load()` is guaranteed idempotent, this is a behavioral regression. Please reintroduce a loaded guard using the ViewModel state, e.g. `if (mViewModel.isEagerLoad() && !mViewModel.isLoaded()) { mViewModel.setLoaded(true); load(); }`.
</issue_to_address>

### Comment 2
<location> `app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java:39-48` </location>
<code_context>
      */
-    @SuppressWarnings("deprecation") // Using deprecated onActivityCreated; migration to onViewCreated requires
-                                     // refactoring
-    @Override
-    public void onActivityCreated(Bundle savedInstanceState) {
-        super.onActivityCreated(savedInstanceState);
</code_context>

<issue_to_address>
**issue (bug_risk):** Using setUserVisibleHint() with ViewPager2 is deprecated and likely ineffective.

This means the lazy-load check (`if (isVisibleToUser && !mViewModel.isLoaded())`) may never run as intended. Instead, trigger lazy loading from lifecycle callbacks (`onStart`/`onResume`) or from ViewPager2’s page change callbacks (similar to how `loadNow()` is used in Activities), and drive any per-page visibility handling from those callbacks rather than `setUserVisibleHint()`.
</issue_to_address>

### Comment 3
<location> `app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseListActivity.java:531-540` </location>
<code_context>
+        mViewPager.setAdapter(mAdapter);
</code_context>

<issue_to_address>
**issue (bug_risk):** TabLayoutMediator and callbacks are never detached, which can leak and cause duplicate callbacks on rebind.

`bindViewPager()` now creates a `TabLayoutMediator`, a `ViewPager2.OnPageChangeCallback`, and a `TabLayout.OnTabSelectedListener`, but `unbindViewPager()` only removes fragments. If `bindViewPager()` is invoked multiple times, you’ll accumulate mediators and callbacks, leading to leaks and duplicate events. Store these as fields and clean them up in `unbindViewPager()` (e.g. `mediator.detach()`, `mViewPager.unregisterOnPageChangeCallback(...)`, `mTabLayout.removeOnTabSelectedListener(...)`).
</issue_to_address>

### Comment 4
<location> `app/src/main/java/io/github/sheepdestroyer/materialisheep/ItemActivity.java:186-187` </location>
<code_context>
         mSystemUiHelper = new AppUtils.SystemUiHelper(getWindow());
         mReplyButton = findViewById(R.id.reply_button);
         mNavButton = findViewById(R.id.navigation_button);
+        mNavButton = findViewById(R.id.navigation_button);
         mNavButton.setNavigable(direction ->
</code_context>

<issue_to_address>
**nitpick:** mNavButton is assigned twice in a row; the first assignment appears redundant.

In `onCreate`, `mNavButton` is assigned twice with `findViewById(R.id.navigation_button)` in consecutive lines; the second is redundant and should be removed, or the ID corrected if a different view was intended.
</issue_to_address>
~~~

</details>

***

<details>
<summary>Sourcery is free for open source - if you like our reviews please consider sharing them ✨</summary>

- [X](https://twitter.com/intent/tweet?text=I%20just%20got%20an%20instant%20code%20review%20from%20%40SourceryAI%2C%20and%20it%20was%20brilliant%21%20It%27s%20free%20for%20open%20source%20and%20has%20a%20free%20trial%20for%20private%20code.%20Check%20it%20out%20https%3A//sourcery.ai)
- [Mastodon](https://mastodon.social/share?text=I%20just%20got%20an%20instant%20code%20review%20from%20%40SourceryAI%2C%20and%20it%20was%20brilliant%21%20It%27s%20free%20for%20open%20source%20and%20has%20a%20free%20trial%20for%20private%20code.%20Check%20it%20out%20https%3A//sourcery.ai)
- [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https://sourcery.ai)
- [Facebook](https://www.facebook.com/sharer/sharer.php?u=https://sourcery.ai)

</details>

<sub>
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
</sub>
--
author:	gemini-code-assist
association:	none
edited:	false
status:	commented
--
## Code Review

This pull request is a great step forward in modernizing the app's architecture by migrating from the deprecated `ViewPager` and `FragmentStatePagerAdapter` to `ViewPager2` and `FragmentStateAdapter`. The changes also correctly replace other deprecated APIs like `onActivityCreated`, `setRetainInstance`, and fragment menu methods with their modern counterparts (`onViewCreated`, `ViewModel`, and `MenuProvider`).

The implementation is solid overall, but I've identified a few issues:
- A duplicated line of code in `ItemActivity`.
- A potential bug in `LazyLoadFragment` that could cause data to be loaded multiple times.
- Some redundant code in `LazyLoadFragment` due to API changes in `ViewPager2`.

I've left specific comments with suggestions to address these points. Once these are fixed, this will be a very strong contribution to the codebase's health.
--
author:	ellipsis-dev
association:	none
edited:	false
status:	commented
--
> [!IMPORTANT]
> **Looks good to me!  :+1:**
> <details>
> <summary>Reviewed everything up to 4f73c22bf8e4d1a3ce2692db6e9365847ef18557 in <ellipsistime>2 minutes and 13 seconds</ellipsistime>. Click for details.</summary> 
> 
> - Reviewed `826` lines of code in `13` files
> - Skipped `0` files when reviewing.
> - Skipped posting `12` draft comments. View those below.
> - Modify your [settings](https://app.ellipsis.dev/sheepdestroyer/settings/code-review) and [rules](https://app.ellipsis.dev/sheepdestroyer/code-review/rules) to customize what types of comments Ellipsis leaves. And don't forget to react with :+1: or :-1: to teach Ellipsis.
> 
> <details>
> <summary>1. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseFragment.java:58</code></summary>
> 
> - **Draft comment:** 
> Good migration to onViewCreated with MenuProvider integration. Verify that mMenuTintDelegate callbacks (~lines 61–64) faithfully reproduce the previous deprecated lifecycle behavior.
> - **Reason this comment was not posted:**
> Comment did not seem useful. Confidence is useful = `0%` <= threshold `50%` The comment is asking the PR author to verify the behavior of `mMenuTintDelegate` callbacks, which violates the rule against asking the author to confirm or verify behavior. It does not provide a specific suggestion or point out a specific issue.
> 
> 
> </details>
> 
> <details>
> <summary>2. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseListActivity.java:468</code></summary>
> 
> - **Draft comment:** 
> Switching to ViewPager2 and using setUserInputEnabled is appropriate. Note the getFragment method uses hard-coded tags (e.g., "f0", "f1"); ensure this remains correct given the expected page count.
> - **Reason this comment was not posted:**
> Comment did not seem useful. Confidence is useful = `0%` <= threshold `50%` The comment is asking the author to ensure that the hard-coded tags remain correct given the expected page count. This is a request for confirmation of intention, which violates the rules. The comment does not provide a specific suggestion or point out a clear issue.
> 
> 
> </details>
> 
> <details>
> <summary>3. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java:101</code></summary>
> 
> - **Draft comment:** 
> setUserVisibleHint is still used for lazy loading, but it is deprecated. Consider migrating to the FragmentTransaction#setMaxLifecycle approach in future revisions.
> - **Reason this comment was not posted:**
> Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment is about code that was added in this PR (the setUserVisibleHint method). However, the comment is phrased as "Consider migrating... in future revisions" which makes it sound like a suggestion for future work rather than something that needs to be fixed now. According to the rules, comments should be about clear code changes required, not speculative or informational. The phrase "in future revisions" suggests this is not urgent or required for this PR. Additionally, if setUserVisibleHint is deprecated, that would likely be caught by the build system with a deprecation warning, which falls under "anything that would be obviously caught by the build." The author might be intentionally using setUserVisibleHint because they're maintaining compatibility with older Android versions or because a full migration to the newer approach would require more extensive refactoring. The comment could be useful as a reminder for future work, even if it's not actionable now. While the comment might be useful as a future reminder, the rules explicitly state not to make comments unless there is clearly a code change required. The phrase "in future revisions" indicates this is not a required change for this PR. Additionally, deprecation warnings would be caught by the build system, so this falls under things that would be "obviously caught by the build." This comment should be deleted because it's phrased as a suggestion for future work ("in future revisions") rather than a required change for this PR. It violates the rule about only commenting when there's clearly a code change required, and deprecation warnings would be caught by the build system anyway.
> 
> 
> </details>
> 
> <details>
> <summary>4. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/ItemActivity.java:189</code></summary>
> 
> - **Draft comment:** 
> The migration to ViewPager2 is well done. Ensure that using getFragment(0) (which relies on fragment tags) correctly retrieves the intended fragment in the new adapter setup.
> - **Reason this comment was not posted:**
> Comment did not seem useful. Confidence is useful = `0%` <= threshold `50%` The comment is asking the author to ensure that a specific method call behaves as intended. This falls under the rule of not asking the author to ensure behavior is intended. The comment does not provide a specific suggestion or ask for a test to be written, which would make it more actionable.
> 
> 
> </details>
> 
> <details>
> <summary>5. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/WebFragment.java:535</code></summary>
> 
> - **Draft comment:** 
> Fullscreen toggle logic (removing/reattaching scroll view content) is complex; ensure this approach remains robust during orientation or configuration changes.
> - **Reason this comment was not posted:**
> Comment was not on a location in the diff, so it can't be submitted as a review comment.
> 
> 
> </details>
> 
> <details>
> <summary>6. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/widget/ItemPagerAdapter.java:68</code></summary>
> 
> - **Draft comment:** 
> Migration to FragmentStateAdapter via createFragment looks correct. Confirm that passing EXTRA_EAGER_LOAD in the bundle properly initializes lazy loading in both ItemFragment and WebFragment.
> - **Reason this comment was not posted:**
> Comment did not seem useful. Confidence is useful = `0%` <= threshold `50%` This comment is asking the PR author to confirm the behavior of passing `EXTRA_EAGER_LOAD` in the bundle. It is not making a specific code suggestion or pointing out a specific issue. It violates the rule against asking the author to confirm their intention or ensure behavior.
> 
> 
> </details>
> 
> <details>
> <summary>7. <code>app/src/main/res/layout-w820dp-land/activity_list.xml:83</code></summary>
> 
> - **Draft comment:** 
> Layout now uses ViewPager2; ensure that the id '@id/content' consistently matches its usage in code.
> - **Reason this comment was not posted:**
> Comment was on unchanged code.
> 
> 
> </details>
> 
> <details>
> <summary>8. <code>app/src/main/res/layout/activity_item.xml:56</code></summary>
> 
> - **Draft comment:** 
> Updated activity layout to ViewPager2 is appropriate; verify that toolbar and header elements function correctly with the new ViewPager2 integration.
> - **Reason this comment was not posted:**
> Comment did not seem useful. Confidence is useful = `0%` <= threshold `50%` This comment is asking the PR author to verify the functionality of toolbar and header elements with the new `ViewPager2` integration. It falls under the category of asking the author to ensure behavior is intended or tested, which is against the rules.
> 
> 
> </details>
> 
> <details>
> <summary>9. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/WebFragment.java:146</code></summary>
> 
> - **Draft comment:** 
> LocalBroadcastManager is used for fullscreen toggling; note that it is deprecated. Consider alternatives (e.g., LiveData or Flow) for future architecture improvements.
> - **Reason this comment was not posted:**
> Comment was not on a location in the diff, so it can't be submitted as a review comment.
> 
> 
> </details>
> 
> <details>
> <summary>10. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseFragment.java:56</code></summary>
> 
> - **Draft comment:** 
> Typo: In the javadoc comment, consider changing "in to the view" to "into the view" for clarity.
> - **Reason this comment was not posted:**
> Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment identifies a real typo in the javadoc. However, I need to check the rules carefully. The rules state "Do NOT comment unless there is clearly a code change required" and "Do NOT make comments that are obvious or unimportant." A typo in a javadoc comment is relatively minor and could be considered unimportant. However, looking at the diff more carefully, I notice that this javadoc text appears to be copied from Android's standard documentation (it's describing onViewCreated). The text "in to" might actually be from the original Android documentation that was copied. But wait - this is still just a documentation typo, not a functional code issue. The rules emphasize not making obvious or unimportant comments, and a minor typo in documentation could fall into that category. This is a legitimate typo that should be fixed for code quality. Documentation quality matters, and fixing typos improves readability. The comment is actionable and clear, which the rules say is good for code quality refactors. While documentation quality does matter, the rules explicitly state not to make comments that are "obvious or unimportant." A single-word typo in a javadoc comment is quite minor and could be considered unimportant compared to functional code issues. The rules seem to prioritize avoiding noise over catching every small issue. This comment identifies a real but very minor typo in documentation. Given the rules emphasize avoiding unimportant comments and the low impact of this issue, I should delete this comment. It's the kind of minor documentation issue that doesn't warrant blocking or cluttering a PR review.
> 
> 
> </details>
> 
> <details>
> <summary>11. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java:67</code></summary>
> 
> - **Draft comment:** 
> Typographical error: consider replacing "in to" with "into" in the comment ("...restored in to the view").
> - **Reason this comment was not posted:**
> Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a comment about a typo in documentation. While it's technically correct that "into" is more proper than "in to" in this context, I need to consider the review rules. The rules state: "Do NOT comment unless there is clearly a code change required" and "Do NOT make comments that are obvious or unimportant." A typo in a comment/documentation is not a code change - it doesn't affect functionality. This is a very minor documentation issue that doesn't impact the code's behavior. The rules emphasize only keeping comments that require clear code changes, and this is just a stylistic/grammatical suggestion for documentation. However, code quality includes documentation quality, and fixing typos in documentation could be considered a valid improvement. The comment is actionable and clear, which the rules say is good for code quality refactors. While documentation quality matters, the rules explicitly state not to comment on obvious or unimportant things. A minor typo in a javadoc comment is both obvious (once pointed out) and relatively unimportant compared to functional code issues. This doesn't meet the bar of "clearly a code change required." This comment should be deleted. It's pointing out a minor typo in documentation that doesn't affect code functionality, which falls under "obvious or unimportant" comments that should not be made according to the review rules.
> 
> 
> </details>
> 
> <details>
> <summary>12. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/ListFragment.java:185</code></summary>
> 
> - **Draft comment:** 
> Typographical error: In the comment, consider changing "in to" to "into" to read "has been restored into the view."
> - **Reason this comment was not posted:**
> Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment is about a typo in a JavaDoc comment that was added in this diff. Looking at the rules: 1) The rule says "Do NOT comment unless there is clearly a code change required" - this is a documentation typo, not a code change. 2) The rule says "Do NOT make comments that are obvious or unimportant" - fixing a typo in documentation could be considered minor/unimportant. 3) However, the rules also say "Comments that suggest code quality refactors are good! But only if they are actionable and clear" - this is actionable and clear. But is fixing a typo really a "code quality refactor"? It's more of a documentation quality issue. The most important consideration is: does this require a code change? It's just a typo in a comment. While it would be nice to fix, it's not critical and falls under "obvious or unimportant" changes. The automated tool is being overly pedantic about a minor typo in documentation. While the typo is real and the suggestion is correct, documentation typos are generally considered minor issues. The rules explicitly state not to make "obvious or unimportant" comments, and a single-word typo in a JavaDoc comment could fall into this category. Additionally, this doesn't affect code functionality at all. Although the typo is minor, it's in newly added documentation and fixing it would improve code quality. However, the rules prioritize avoiding unimportant comments, and a documentation typo that doesn't affect functionality is likely not important enough to warrant keeping the comment. The bar for keeping comments is high - "STRONG EVIDENCE that the comment is correct" - and while correct, this is too minor. This comment should be deleted. While the typo is real, it's a minor documentation issue that falls under "obvious or unimportant" comments according to the rules. The automated tool is being overly pedantic about a trivial typo that doesn't affect code functionality.
> 
> 
> </details>
> 
> 
> Workflow ID: <workflowid>`wflow_9ayYUp98gHG48qpi`</workflowid>
> </details>
> 
> <sup>You can customize </sup>[<img alt="Ellipsis" src="https://img.shields.io/badge/Ellipsis-blue?color=175173">](https://www.ellipsis.dev?ref=sheepdestroyer%2Fmaterialisheep&utm_source=github&utm_medium=referral)<sup> by changing your [verbosity settings](https://app.ellipsis.dev/sheepdestroyer/settings/code-review), reacting with :+1: or :-1:, [replying to comments](https://docs.ellipsis.dev/features/code-review#teaching-ellipsis), or adding [code review rules](https://app.ellipsis.dev/sheepdestroyer/code-review/rules).</sup>
--
author:	sheepdestroyer
association:	owner
edited:	false
status:	none
--
/gemini review
--
author:	sheepdestroyer
association:	owner
edited:	false
status:	none
--
@coderabbitai review
--
author:	sheepdestroyer
association:	owner
edited:	false
status:	none
--
@sourcery-ai review
--
author:	sheepdestroyer
association:	owner
edited:	false
status:	none
--
/review
--
author:	sheepdestroyer
association:	owner
edited:	false
status:	none
--
@ellipsis review this
--
author:	coderabbitai
association:	none
edited:	false
status:	none
--
<!-- This is an auto-generated reply by CodeRabbit -->
<details>
<summary>✅ Actions performed</summary>

Review triggered.

> Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

</details>
--
author:	qodo-code-review
association:	none
edited:	false
status:	none
--
**[Persistent review](https://github.com/sheepdestroyer/materialisheep/pull/56#issuecomment-3765907034)** updated to latest commit https://github.com/sheepdestroyer/materialisheep/commit/a54e2533e73737e69ab715749c49cab76f498b9e
--
author:	ellipsis-dev
association:	none
edited:	false
status:	commented
--
> [!IMPORTANT]
> **Looks good to me!  :+1:**
> <details>
> <summary>Reviewed a54e2533e73737e69ab715749c49cab76f498b9e in <ellipsistime>1 minute and 14 seconds</ellipsistime>. Click for details.</summary> 
> 
> - Reviewed `98` lines of code in `3` files
> - Skipped `0` files when reviewing.
> - Skipped posting `3` draft comments. View those below.
> - Modify your [settings](https://app.ellipsis.dev/sheepdestroyer/settings/code-review) and [rules](https://app.ellipsis.dev/sheepdestroyer/code-review/rules) to customize what types of comments Ellipsis leaves. And don't forget to react with :+1: or :-1: to teach Ellipsis.
> 
> <details>
> <summary>1. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseListActivity.java:529</code></summary>
> 
> - **Draft comment:** 
> Good refactor: storing the TabLayoutMediator, OnPageChangeCallback, and TabSelectedListener in member variables improves lifecycle management. Ensure unbindViewPager is always called to detach these, as shown in lines 585–598.
> - **Reason this comment was not posted:**
> Confidence changes required: `0%` <= threshold `50%` None
> 
> 
> </details>
> 
> <details>
> <summary>2. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/ItemActivity.java:185</code></summary>
> 
> - **Draft comment:** 
> Removed duplicate view lookup for mNavButton improves code clarity.
> - **Reason this comment was not posted:**
> Confidence changes required: `0%` <= threshold `50%` None
> 
> 
> </details>
> 
> <details>
> <summary>3. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java:134</code></summary>
> 
> - **Draft comment:** 
> Enhanced eagerLoad() by adding a check for !isLoaded() prevents multiple load() invocations. This is a solid improvement.
> - **Reason this comment was not posted:**
> Confidence changes required: `0%` <= threshold `50%` None
> 
> 
> </details>
> 
> 
> Workflow ID: <workflowid>`wflow_WkyHdFC1hCJ85VjG`</workflowid>
> </details>
> 
> <sup>You can customize </sup>[<img alt="Ellipsis" src="https://img.shields.io/badge/Ellipsis-blue?color=175173">](https://www.ellipsis.dev?ref=sheepdestroyer%2Fmaterialisheep&utm_source=github&utm_medium=referral)<sup> by changing your [verbosity settings](https://app.ellipsis.dev/sheepdestroyer/settings/code-review), reacting with :+1: or :-1:, [replying to comments](https://docs.ellipsis.dev/features/code-review#teaching-ellipsis), or adding [code review rules](https://app.ellipsis.dev/sheepdestroyer/code-review/rules).</sup>
--
author:	sourcery-ai
association:	none
edited:	false
status:	commented
--
Hey - I've found 2 issues, and left some high level feedback:

- In both `BaseListActivity` and `ItemActivity`, `getFragment(int)` and `unbindViewPager()` rely on hard-coded tags like `"f0"`/`"f1"` and fixed page counts; consider deriving tags from the adapter (e.g. using `getItemId()`/`getItemCount()`) to avoid brittleness if the number of pages or IDs change.
- `LazyLoadFragment` reintroduces the deprecated `setUserVisibleHint`, which is not used by `ViewPager2`/`FragmentStateAdapter`; if you rely on visibility for eager loading, consider wiring that through the `ViewPager2` page change callbacks instead of `setUserVisibleHint`.
- The new lazy-load state handling splits logic between `LazyLoadFragment` and `LazyLoadViewModel` (e.g. `STATE_LOADED` is written to the bundle but no longer read, `isNewInstance()` always returns true); it may be worth simplifying and centralizing this logic so that initialization and reload behavior is clearly defined in one place.

<details>
<summary>Prompt for AI Agents</summary>

~~~markdown
Please address the comments from this code review:

## Overall Comments
- In both `BaseListActivity` and `ItemActivity`, `getFragment(int)` and `unbindViewPager()` rely on hard-coded tags like `"f0"`/`"f1"` and fixed page counts; consider deriving tags from the adapter (e.g. using `getItemId()`/`getItemCount()`) to avoid brittleness if the number of pages or IDs change.
- `LazyLoadFragment` reintroduces the deprecated `setUserVisibleHint`, which is not used by `ViewPager2`/`FragmentStateAdapter`; if you rely on visibility for eager loading, consider wiring that through the `ViewPager2` page change callbacks instead of `setUserVisibleHint`.
- The new lazy-load state handling splits logic between `LazyLoadFragment` and `LazyLoadViewModel` (e.g. `STATE_LOADED` is written to the bundle but no longer read, `isNewInstance()` always returns true); it may be worth simplifying and centralizing this logic so that initialization and reload behavior is clearly defined in one place.

## Individual Comments

### Comment 1
<location> `app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java:39-48` </location>
<code_context>
      */
-    @SuppressWarnings("deprecation") // Using deprecated onActivityCreated; migration to onViewCreated requires
-                                     // refactoring
-    @Override
-    public void onActivityCreated(Bundle savedInstanceState) {
-        super.onActivityCreated(savedInstanceState);
</code_context>

<issue_to_address>
**issue:** Using setUserVisibleHint for lazy loading is deprecated and ineffective with ViewPager2.

ViewPager2 uses `setMaxLifecycle` rather than `setUserVisibleHint`, so any eager-load logic there is effectively dead code and reintroduces a deprecated API. Because `loadNow()` is already invoked from page change callbacks with ViewModel state, you can likely remove this override and rely on that flow instead.
</issue_to_address>

### Comment 2
<location> `app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseListActivity.java:600-608` </location>
<code_context>
         }
-        transaction.commit();
+
+        // Remove fragments by Tag ("f" + id). IDs are 0 and 1.
+        FragmentTransaction transaction = getSupportFragmentManager().beginTransaction();
+        Fragment f0 = getSupportFragmentManager().findFragmentByTag("f0");
+        if (f0 != null)
+            transaction.remove(f0);
+        Fragment f1 = getSupportFragmentManager().findFragmentByTag("f1");
+        if (f1 != null)
+            transaction.remove(f1);
+        transaction.commitAllowingStateLoss();
+    }
+
</code_context>

<issue_to_address>
**suggestion (bug_risk):** Hard-coding fragment tags/indices and using commitAllowingStateLoss makes the unbind logic brittle.

This assumes the adapter always has exactly two positions with default `itemId`s mapping to tags `"f0"` and `"f1"`, making the unbind logic tightly coupled to the current `ItemPagerAdapter` and likely to break if page count or IDs change. It also relies on `commitAllowingStateLoss`, which risks silently dropping these removals. Instead, derive removals from `mViewPager.getAdapter().getItemCount()` (or let the adapter manage its fragments) and prefer `commit()` where feasible.

Suggested implementation:

```java
        if (mTabSelectedListener != null) {
            mTabLayout.removeOnTabSelectedListener(mTabSelectedListener);
            mTabSelectedListener = null;
        }

        RecyclerView.Adapter<?> adapter = mViewPager.getAdapter();
        if (adapter instanceof FragmentStateAdapter) {
            FragmentManager fragmentManager = getSupportFragmentManager();
            FragmentTransaction transaction = fragmentManager.beginTransaction();

            int itemCount = adapter.getItemCount();
            for (int position = 0; position < itemCount; position++) {
                long itemId = ((FragmentStateAdapter) adapter).getItemId(position);
                String tag = "f" + itemId;
                Fragment fragment = fragmentManager.findFragmentByTag(tag);
                if (fragment != null) {
                    transaction.remove(fragment);
                }
            }

            transaction.commit();
        }

/**

```

To compile successfully, ensure the following imports exist at the top of `BaseListActivity.java` (or equivalent are already present):

```java
import androidx.recyclerview.widget.RecyclerView;
import androidx.viewpager2.adapter.FragmentStateAdapter;
import androidx.fragment.app.Fragment;
import androidx.fragment.app.FragmentManager;
import androidx.fragment.app.FragmentTransaction;
```

If your `ItemPagerAdapter` uses a custom tag format or overrides how fragments are tagged, adjust the `tag` construction (`"f" + itemId`) to match that scheme.
</issue_to_address>
~~~

</details>

***

<details>
<summary>Sourcery is free for open source - if you like our reviews please consider sharing them ✨</summary>

- [X](https://twitter.com/intent/tweet?text=I%20just%20got%20an%20instant%20code%20review%20from%20%40SourceryAI%2C%20and%20it%20was%20brilliant%21%20It%27s%20free%20for%20open%20source%20and%20has%20a%20free%20trial%20for%20private%20code.%20Check%20it%20out%20https%3A//sourcery.ai)
- [Mastodon](https://mastodon.social/share?text=I%20just%20got%20an%20instant%20code%20review%20from%20%40SourceryAI%2C%20and%20it%20was%20brilliant%21%20It%27s%20free%20for%20open%20source%20and%20has%20a%20free%20trial%20for%20private%20code.%20Check%20it%20out%20https%3A//sourcery.ai)
- [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https://sourcery.ai)
- [Facebook](https://www.facebook.com/sharer/sharer.php?u=https://sourcery.ai)

</details>

<sub>
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
</sub>
--
author:	gemini-code-assist
association:	none
edited:	false
status:	commented
--
## Code Review

This pull request is a significant and well-executed refactoring to modernize the app's architecture by migrating from the deprecated `ViewPager` to `ViewPager2` and updating Fragment lifecycle methods. The introduction of `ViewModel` for state management instead of `setRetainInstance` is a great improvement. The code is cleaner and follows modern Android development practices. I've identified a potential memory leak in `ItemActivity` where `TabLayoutMediator` is not being detached, some dead code in `LazyLoadFragment`, and a minor style issue in `BaseListActivity`. Addressing these points will further improve the code's robustness and maintainability.
--
author:	ellipsis-dev
association:	none
edited:	false
status:	commented
--
> [!IMPORTANT]
> **Looks good to me!  :+1:**
> <details>
> <summary>Reviewed everything up to a54e2533e73737e69ab715749c49cab76f498b9e in <ellipsistime>2 minutes and 44 seconds</ellipsistime>. Click for details.</summary> 
> 
> - Reviewed `2790` lines of code in `14` files
> - Skipped `0` files when reviewing.
> - Skipped posting `12` draft comments. View those below.
> - Modify your [settings](https://app.ellipsis.dev/sheepdestroyer/settings/code-review) and [rules](https://app.ellipsis.dev/sheepdestroyer/code-review/rules) to customize what types of comments Ellipsis leaves. And don't forget to react with :+1: or :-1: to teach Ellipsis.
> 
> <details>
> <summary>1. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseFragment.java:63</code></summary>
> 
> - **Draft comment:** 
> Ensure the MenuProvider added in onViewCreated is removed in onDestroyView to avoid potential memory leaks.
> - **Reason this comment was not posted:**
> Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment is asking for manual cleanup of the MenuProvider. However, the code uses `addMenuProvider(menuProvider, lifecycleOwner, state)` with `getViewLifecycleOwner()` as the lifecycle owner. This is the recommended pattern in Android - when you provide a LifecycleOwner to addMenuProvider, the framework automatically removes the MenuProvider when that lifecycle is destroyed. The view lifecycle owner is destroyed in onDestroyView, so the MenuProvider should be automatically cleaned up. This comment appears to be incorrect because it's asking for manual cleanup that isn't necessary and would be redundant. The comment also violates the rule about not asking the author to "ensure" something. I might be wrong about the automatic cleanup behavior. Perhaps there's a specific bug or edge case in the MenuProvider API where manual removal is still needed even with a LifecycleOwner. I should consider that the automated tool might have knowledge of such issues that I'm not aware of. While there could be edge cases, the standard Android documentation and best practices indicate that using addMenuProvider with a LifecycleOwner parameter handles cleanup automatically. The comment doesn't provide any specific evidence of a problem, and asking to "ensure" something is done falls under the category of comments we should remove. Without strong evidence that manual cleanup is needed here, this appears to be an incorrect suggestion. This comment should be deleted. The MenuProvider is properly scoped to the view lifecycle owner, which means Android will automatically remove it when the view is destroyed. Manual removal in onDestroyView would be redundant. Additionally, the comment starts with "Ensure that..." which is explicitly mentioned as a pattern to avoid in the rules.
> 
> 
> </details>
> 
> <details>
> <summary>2. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseListActivity.java:611</code></summary>
> 
> - **Draft comment:** 
> Relying on fragment tags ('f'+position) for getFragment may be brittle; verify that this tagging scheme remains consistent with ViewPager2.
> - **Reason this comment was not posted:**
> Comment looked like it was already resolved.
> 
> 
> </details>
> 
> <details>
> <summary>3. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/ItemActivity.java:405</code></summary>
> 
> - **Draft comment:** 
> The migration to ViewPager2 looks good; ensure getFragment() reliably fetches the correct fragment and that FAB toggling synchronizes with page changes.
> - **Reason this comment was not posted:**
> Comment was not on a location in the diff, so it can't be submitted as a review comment.
> 
> 
> </details>
> 
> <details>
> <summary>4. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java:101</code></summary>
> 
> - **Draft comment:** 
> setUserVisibleHint is deprecated; consider using FragmentTransaction#setMaxLifecycle or Lifecycle observers for visibility handling.
> - **Reason this comment was not posted:**
> Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% The `setUserVisibleHint` override is indeed being added in this PR (it's in the diff as new code). The comment is technically correct that this method is deprecated. However, I need to consider: 1) This is a migration PR that's moving from `setRetainInstance` to ViewModel, so the author is already doing modernization work. 2) The comment suggests an alternative approach but doesn't provide concrete implementation details. 3) The author may have intentionally kept this deprecated method for compatibility reasons or because they're doing incremental migration. 4) The comment is somewhat speculative - it's suggesting a refactor but not pointing out a definite bug. 5) According to the rules, comments suggesting code quality refactors are good if they are actionable and clear, but this one is somewhat vague about how to implement the alternative. The author is clearly doing modernization work (migrating to ViewModel), so they may be aware of the deprecation but chose to keep this method for now. The comment doesn't explain why this is a problem or provide concrete steps to fix it. It's possible the deprecated method is still needed for backward compatibility or the author is doing incremental migration. While the author is doing modernization, the comment does point out a legitimate issue with newly added code using a deprecated API. However, the comment lacks specificity and actionable guidance - it just mentions alternatives without explaining how to implement them in this specific context. This makes it more of an informational comment than an actionable one, which violates the rules. The comment should be deleted. While it's technically correct that `setUserVisibleHint` is deprecated, the comment is not sufficiently actionable - it merely suggests alternatives without providing concrete implementation guidance. This falls into the category of informational comments that don't clearly indicate a required code change, which violates the rules.
> 
> 
> </details>
> 
> <details>
> <summary>5. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/ListFragment.java:80</code></summary>
> 
> - **Draft comment:** 
> The switch to onViewCreated and using getViewLifecycleOwner for LiveData observers is well implemented; confirm that adapter state restoration operates as expected.
> - **Reason this comment was not posted:**
> Comment was not on a location in the diff, so it can't be submitted as a review comment.
> 
> 
> </details>
> 
> <details>
> <summary>6. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/WebFragment.java:525</code></summary>
> 
> - **Draft comment:** 
> Review the setFullscreen implementation for potential UI reflow issues when moving scroll view content between containers.
> - **Reason this comment was not posted:**
> Comment was not on a location in the diff, so it can't be submitted as a review comment.
> 
> 
> </details>
> 
> <details>
> <summary>7. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/widget/ItemPagerAdapter.java:62</code></summary>
> 
> - **Draft comment:** 
> The conversion to FragmentStateAdapter is clean; double-check if the 'retain instance' flag is still necessary given modern fragment APIs.
> - **Reason this comment was not posted:**
> Comment did not seem useful. Confidence is useful = `0%` <= threshold `50%` The comment is asking the PR author to double-check something, which violates the rule against asking the author to confirm or double-check things. It doesn't provide a specific suggestion or point out a clear issue.
> 
> 
> </details>
> 
> <details>
> <summary>8. <code>app/src/main/res/layout-w820dp-land/activity_list.xml:83</code></summary>
> 
> - **Draft comment:** 
> The layout update to use ViewPager2 appears straightforward; ensure that IDs and references are updated consistently in the code.
> - **Reason this comment was not posted:**
> Comment did not seem useful. Confidence is useful = `0%` <= threshold `50%` This comment is asking the PR author to ensure consistency in updating IDs and references, which falls under the category of asking the author to double-check things. It doesn't provide a specific suggestion or point out a specific issue.
> 
> 
> </details>
> 
> <details>
> <summary>9. <code>app/src/main/res/layout/activity_item.xml:57</code></summary>
> 
> - **Draft comment:** 
> Verify that the activity layout’s switch to ViewPager2 preserves proper toolbar and AppBar behavior across orientations.
> - **Reason this comment was not posted:**
> Comment did not seem useful. Confidence is useful = `0%` <= threshold `50%` This comment is asking the PR author to verify behavior across orientations, which falls under the rule of not asking the author to ensure behavior is intended or tested. It doesn't provide a specific suggestion or point out a specific issue.
> 
> 
> </details>
> 
> <details>
> <summary>10. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseFragment.java:56</code></summary>
> 
> - **Draft comment:** 
> Typographical suggestion: Consider changing "restored in to the view" to "restored into the view" for improved clarity.
> - **Reason this comment was not posted:**
> Comment was on unchanged code.
> 
> 
> </details>
> 
> <details>
> <summary>11. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java:67</code></summary>
> 
> - **Draft comment:** 
> Typographical error: Consider changing "in to" to "into" in the comment for clarity.
> - **Reason this comment was not posted:**
> Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a comment about a typo in documentation. Looking at the rules: "Do NOT comment unless there is clearly a code change required" - this is just a documentation typo, not a code change. The rules also say "Do NOT make comments that are obvious or unimportant" - fixing a typo is relatively minor. However, the comment is technically correct - "in to" should be "into" in this context. But the rules emphasize not making comments unless there's a clear code change required, and typos in comments are generally low priority. The most important rule states I should only keep comments with STRONG EVIDENCE that they are correct and important. While the typo is real, it's a minor documentation issue, not a functional code problem. The typo is real and the suggestion is technically correct. Documentation quality matters, and fixing typos improves code quality. This could be considered an actionable code quality improvement, even if it's just in a comment. While the typo is real, the rules explicitly state not to make comments that are "obvious or unimportant" and to only comment when there's "clearly a code change required." A minor typo in a javadoc comment doesn't meet the threshold of importance for keeping the comment, especially given the instruction to err on the side of deleting comments unless there's STRONG EVIDENCE they should be kept. This comment should be deleted. While it correctly identifies a typo, it's a minor documentation issue that doesn't meet the threshold for "clearly a code change required" and falls under "obvious or unimportant" comments that should be avoided.
> 
> 
> </details>
> 
> <details>
> <summary>12. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/ListFragment.java:185</code></summary>
> 
> - **Draft comment:** 
> Typo: Consider changing "in to" to "into" in the Javadoc comment.
> - **Reason this comment was not posted:**
> Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a minor typo fix in documentation. While technically correct (both "in to" and "into" are grammatically acceptable in some contexts, but "into" is more standard here), this falls under "obvious or unimportant" comments. The comment is about a very minor documentation issue that doesn't affect code functionality. According to the rules, I should "Do NOT make comments that are obvious or unimportant." A typo like "in to" vs "into" in a Javadoc comment is quite minor and unimportant. However, I need to consider that this Javadoc appears to be copied from Android framework documentation, so the typo might actually be in the original source. This could be a legitimate documentation improvement, even if minor. Documentation quality matters, and fixing typos improves readability. The comment is actionable and clear. Also, looking at the Javadoc, it appears to be copied from Android's standard documentation for onViewCreated, so the typo might have been introduced during copying or might exist in the original. While documentation quality does matter, this is an extremely minor typo that doesn't affect understanding or functionality. The rules explicitly state "Do NOT make comments that are obvious or unimportant." A single-word spacing issue in a Javadoc comment falls squarely into the "unimportant" category. The comment doesn't meet the threshold of being clearly necessary. This comment should be deleted. It's about a very minor typo in documentation that doesn't affect code functionality or understanding. It falls under the category of "obvious or unimportant" comments that should not be made according to the rules.
> 
> 
> </details>
> 
> 
> Workflow ID: <workflowid>`wflow_4Box9Gdhbs6o0fKc`</workflowid>
> </details>
> 
> <sup>You can customize </sup>[<img alt="Ellipsis" src="https://img.shields.io/badge/Ellipsis-blue?color=175173">](https://www.ellipsis.dev?ref=sheepdestroyer%2Fmaterialisheep&utm_source=github&utm_medium=referral)<sup> by changing your [verbosity settings](https://app.ellipsis.dev/sheepdestroyer/settings/code-review), reacting with :+1: or :-1:, [replying to comments](https://docs.ellipsis.dev/features/code-review#teaching-ellipsis), or adding [code review rules](https://app.ellipsis.dev/sheepdestroyer/code-review/rules).</sup>
--
author:	coderabbitai
association:	none
edited:	false
status:	commented
--
**Actionable comments posted: 1**

> [!CAUTION]
> Some comments are outside the diff and can’t be posted inline due to platform limitations.
> 
> 
> 
> <details>
> <summary>⚠️ Outside diff range comments (1)</summary><blockquote>
> 
> <details>
> <summary>app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseFragment.java (1)</summary><blockquote>
> 
> `46-57`: **Remove orphaned Javadoc comment.**
> 
> Lines 46-52 contain the old Javadoc for the now-removed `onActivityCreated` method. This documentation block is orphaned and should be deleted to avoid confusion.
> 
> 
> 
> <details>
> <summary>Proposed fix</summary>
> 
> ```diff
>      }
> 
> -    /**
> -     * Called when the fragment's activity has been created and this
> -     * fragment's view hierarchy instantiated.
> -     *
> -     * `@param` savedInstanceState If the fragment is being re-created from
> -     *                           a previous saved state, this is the state.
> -     */
>      /**
>       * Called immediately after
>       * {`@link` `#onCreateView`(LayoutInflater, ViewGroup, Bundle)}
>       * has returned, but before any saved state has been restored in to the view.
>       */
> ```
> </details>
> 
> </blockquote></details>
> 
> </blockquote></details>

<details>
<summary>🤖 Fix all issues with AI agents</summary>

```
In
`@app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java`:
- Around line 101-108: The override of setUserVisibleHint(...) in
LazyLoadFragment is deprecated for ViewPager2 and can cause an NPE if mViewModel
is null; remove this method and instead trigger eager loading from a
lifecycle-aware place: override onResume() in LazyLoadFragment and inside
onResume() check that getUserVisibleHint() is not used but that the fragment
isResumed/visible, then if mViewModel != null and !mViewModel.isLoaded() call
mViewModel.setEagerLoad(true) and eagerLoad(); alternatively observe the
fragment lifecycle (LifecycleObserver) to perform the same checks so loading
only happens when the fragment reaches RESUMED, ensuring you null-check
mViewModel before calling isLoaded()/setEagerLoad().
```

</details>

<details>
<summary>🧹 Nitpick comments (7)</summary><blockquote>

<details>
<summary>app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseFragment.java (1)</summary><blockquote>

`59-84`: **Good migration to MenuProvider API with lifecycle-aware registration.**

The implementation correctly uses `getViewLifecycleOwner()` with `Lifecycle.State.RESUMED` to scope the menu provider to the fragment's view lifecycle. The `isAttached()` guards are appropriately retained.

Two minor style suggestions:

1. **Inconsistent null-safety**: Line 62 uses `getActivity()` while line 63 uses `requireActivity()`. Consider using `requireActivity()` consistently.

2. **Fully qualified annotations**: The inline fully qualified names (`@androidx.annotation.NonNull`, `androidx.core.view.MenuProvider`, etc.) work but reduce readability. Consider adding imports.




<details>
<summary>Optional cleanup</summary>

Add imports at the top of the file:
```java
import android.view.MenuItem;
import android.view.View;
import androidx.annotation.NonNull;
import androidx.annotation.Nullable;
import androidx.core.view.MenuProvider;
import androidx.lifecycle.Lifecycle;
```

Then simplify the method signature and body:
```diff
     `@Override`
-    public void onViewCreated(`@androidx.annotation.NonNull` android.view.View view,
-            `@androidx.annotation.Nullable` Bundle savedInstanceState) {
+    public void onViewCreated(`@NonNull` View view, `@Nullable` Bundle savedInstanceState) {
         super.onViewCreated(view, savedInstanceState);
-        mMenuTintDelegate.onActivityCreated(getActivity());
-        requireActivity().addMenuProvider(new androidx.core.view.MenuProvider() {
+        mMenuTintDelegate.onActivityCreated(requireActivity());
+        requireActivity().addMenuProvider(new MenuProvider() {
             `@Override`
-            public void onCreateMenu(`@androidx.annotation.NonNull` Menu menu,
-                    `@androidx.annotation.NonNull` MenuInflater menuInflater) {
+            public void onCreateMenu(`@NonNull` Menu menu, `@NonNull` MenuInflater menuInflater) {
                 // ...
             }

             `@Override`
-            public boolean onMenuItemSelected(`@androidx.annotation.NonNull` android.view.MenuItem menuItem) {
+            public boolean onMenuItemSelected(`@NonNull` MenuItem menuItem) {
                 return BaseFragment.this.onOptionsItemSelected(menuItem);
             }

             `@Override`
-            public void onPrepareMenu(`@androidx.annotation.NonNull` Menu menu) {
+            public void onPrepareMenu(`@NonNull` Menu menu) {
                 // ...
             }
-        }, getViewLifecycleOwner(), androidx.lifecycle.Lifecycle.State.RESUMED);
+        }, getViewLifecycleOwner(), Lifecycle.State.RESUMED);
     }
```
</details>

</blockquote></details>
<details>
<summary>app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadViewModel.java (1)</summary><blockquote>

`5-34`: **Move `mInitialized` field declaration with the other fields.**

The `mInitialized` field is declared at line 33, after its getter/setter methods. For consistency and readability, group all field declarations together at the top of the class.



<details>
<summary>Suggested reordering</summary>

```diff
 public class LazyLoadViewModel extends ViewModel {
     private boolean mEagerLoad;
     private boolean mLoaded;
+    private boolean mInitialized;

     public boolean isEagerLoad() {
         return mEagerLoad;
     }
@@ ... @@
     public void setInitialized(boolean initialized) {
         mInitialized = initialized;
     }
-
-    private boolean mInitialized;
 }
```
</details>

</blockquote></details>
<details>
<summary>app/src/main/java/io/github/sheepdestroyer/materialisheep/LazyLoadFragment.java (2)</summary><blockquote>

`57-68`: **Remove stale Javadoc comment.**

There are two Javadoc blocks here: the first (lines 57-62) describes the old `onActivityCreated` method, and the second (lines 64-68) describes `onViewCreated`. Remove the outdated comment block.



<details>
<summary>Remove stale comment</summary>

```diff
-    /**
-     * Called when the fragment's activity has been created and this
-     * fragment's view hierarchy instantiated.
-     *
-     * `@param` savedInstanceState If the fragment is being re-created from
-     *                           a previous saved state, this is the state.
-     */
     /**
      * Called immediately after
      * {`@link` `#onCreateView`(LayoutInflater, ViewGroup, Bundle)}
      * has returned, but before any saved state has been restored in to the view.
      */
```
</details>

---

`130-132`: **Consider removing this method since it always returns `true`.**

`isNewInstance()` no longer provides meaningful logic. Consider inlining the check or removing the method entirely to reduce dead code.

</blockquote></details>
<details>
<summary>app/src/main/java/io/github/sheepdestroyer/materialisheep/BaseListActivity.java (1)</summary><blockquote>

`146-153`: **Guard navigation against a null fragment.**  
ViewPager2 creates fragments lazily, so `getFragment(0)` can be null; a simple instance check avoids potential NPEs.  
  

<details>
<summary>🛠️ Proposed guard</summary>

```diff
-            mNavButton.setNavigable(direction ->
-            // if callback is fired navigable should not be null
-            ((Navigable) getFragment(0)).onNavigate(direction));
+            mNavButton.setNavigable(direction -> {
+                Fragment fragment = getFragment(0);
+                if (fragment instanceof Navigable) {
+                    ((Navigable) fragment).onNavigate(direction);
+                }
+            });
```
</details>


Also applies to: 589-590

</blockquote></details>
<details>
<summary>app/src/main/java/io/github/sheepdestroyer/materialisheep/widget/ItemPagerAdapter.java (1)</summary><blockquote>

`41-43`: **Remove stale deprecation suppression/TODO.**  
The adapter is already on `FragmentStateAdapter`, so the class-level suppression/comment looks outdated.  
  

<details>
<summary>🧹 Suggested cleanup</summary>

```diff
-@SuppressWarnings("deprecation") // TODO: Uses deprecated FragmentStatePagerAdapter; migrate to
-                                 // ViewPager2/FragmentStateAdapter
 public class ItemPagerAdapter extends androidx.viewpager2.adapter.FragmentStateAdapter {
```
</details>

</blockquote></details>
<details>
<summary>app/src/main/java/io/github/sheepdestroyer/materialisheep/ItemActivity.java (1)</summary><blockquote>

`186-189`: **Drop the duplicate `mNavButton` assignment.**  
There are two identical assignments back-to-back; keeping one is sufficient.  

<details>
<summary>🧹 Suggested cleanup</summary>

```diff
-        mNavButton = findViewById(R.id.navigation_button);
```
</details>

</blockquote></details>

</blockquote></details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->
--
author:	sheepdestroyer
association:	owner
edited:	false
status:	none
--
/gemini review
--
author:	sheepdestroyer
association:	owner
edited:	false
status:	none
--
@coderabbitai review
--
author:	coderabbitai
association:	none
edited:	false
status:	none
--
<!-- This is an auto-generated reply by CodeRabbit -->
<details>
<summary>✅ Actions performed</summary>

Review triggered.

> Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

</details>
--
author:	gemini-code-assist
association:	none
edited:	false
status:	commented
--
## Code Review

This is an excellent and substantial refactoring that modernizes key components of the app by migrating to `ViewPager2`, `ViewModel`, and `MenuProvider`. The code is much cleaner and follows modern Android development practices.

I've found one critical issue in `BaseListActivity` that will cause a crash on screen rotation from multi-pane to single-pane mode. I've also left a minor suggestion in `LazyLoadFragment` to improve code clarity.

Please address the critical bug before merging. Overall, great work on this complex migration!
--
author:	ellipsis-dev
association:	none
edited:	false
status:	commented
--
> [!IMPORTANT]
> **Looks good to me!  :+1:**
> <details>
> <summary>Reviewed 7b488c4bcf4f19236286cd56bfd5d3074ffc503f in <ellipsistime>2 minutes and 9 seconds</ellipsistime>. Click for details.</summary> 
> 
> - Reviewed `465` lines of code in `7` files
> - Skipped `0` files when reviewing.
> - Skipped posting `4` draft comments. View those below.
> - Modify your [settings](https://app.ellipsis.dev/sheepdestroyer/settings/code-review) and [rules](https://app.ellipsis.dev/sheepdestroyer/code-review/rules) to customize what types of comments Ellipsis leaves. And don't forget to react with :+1: or :-1: to teach Ellipsis.
> 
> <details>
> <summary>1. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/ItemFragment.java:150</code></summary>
> 
> - **Draft comment:** 
> Remove or replace the call to isNewInstance() since this method has been removed in the refactor. Its remaining use is causing a compilation error.
> - **Reason this comment was not posted:**
> Comment was on unchanged code.
> 
> 
> </details>
> 
> <details>
> <summary>2. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/ItemFragment.java:185</code></summary>
> 
> - **Draft comment:** 
> Remove the isNewInstance() check here as it no longer exists. This legacy check should be removed following the migration to onViewCreated.
> - **Reason this comment was not posted:**
> Comment looked like it was already resolved.
> 
> 
> </details>
> 
> <details>
> <summary>3. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/WebFragment.java:169</code></summary>
> 
> - **Draft comment:** 
> Remove the call to isNewInstance() here. As part of the migration, this method has been removed, so any remaining calls need to be updated.
> - **Reason this comment was not posted:**
> Comment looked like it was already resolved.
> 
> 
> </details>
> 
> <details>
> <summary>4. <code>app/src/main/java/io/github/sheepdestroyer/materialisheep/WebFragment.java:192</code></summary>
> 
> - **Draft comment:** 
> Remove the isNewInstance() check here. Ensure initialization logic is performed in onViewCreated or another appropriate lifecycle method.
> - **Reason this comment was not posted:**
> Comment looked like it was already resolved.
> 
> 
> </details>
> 
> 
> Workflow ID: <workflowid>`wflow_MeJ207VxImMmbQTH`</workflowid>
> </details>
> 
> <sup>You can customize </sup>[<img alt="Ellipsis" src="https://img.shields.io/badge/Ellipsis-blue?color=175173">](https://www.ellipsis.dev?ref=sheepdestroyer%2Fmaterialisheep&utm_source=github&utm_medium=referral)<sup> by changing your [verbosity settings](https://app.ellipsis.dev/sheepdestroyer/settings/code-review), reacting with :+1: or :-1:, [replying to comments](https://docs.ellipsis.dev/features/code-review#teaching-ellipsis), or adding [code review rules](https://app.ellipsis.dev/sheepdestroyer/code-review/rules).</sup>
--