sarawinter
## Description The Android Party member list does not appear to apply the user's persisted Party sorting settings (`party.order` and `party.orderAscending`). I noticed this after clearing the Habitica Android app cache. Before clearing it, my own character had consistently appeared first in the Party member list. After the cache was rebuilt, the visible member order changed. ## Expected behavior The Android Party member list should respect the Party sort preference stored on the user's account, or otherwise use a deterministic documented sort order. ## Actual behavior The Party member order can change after local app data is rebuilt. Looking at the current Android implementation: - `UserParty.kt` contains both `partyOrder` and `orderAscending`. - `RealmSocialLocalRepository.getPartyMembers(partyId)` retrieves Party members from Realm without applying any sort. - `PartyViewModel` exposes those results directly. - `PartyDetailFragment.updateMembersList()` renders the members in the order received. Because no explicit sort is applied, the displayed order can depend on the ordering of the local Realm records rather than the user's persisted Party sort preference. ## Steps to reproduce 1. Have an existing Party with a stable visible member order in the Android app. 2. Clear the Habitica Android app cache/data so the local member data is rebuilt. 3. Reopen Habitica and navigate to the Party. 4. Compare the Party member order with the order shown before clearing the cache. ### Observed result The member order changed after the cache was rebuilt. In my case, my own character had previously appeared first and moved to a different position afterward. ## Additional context The Habitica website still allows Party member sorting and persists that choice using `party.order` and `party.orderAscending` through "Apply Sort Options to Party Header". The Android app still models those fields, but I could not find anywhere in the current Party member display code where they are applied. The iOS app appears to have a similar implementation pattern, but this issue is specifically about the Android behavior I reproduced.