Android App

The Android app is the primary interface for seekers and hosts. It is a native Kotlin app using XML layouts (no Jetpack Compose), located in the android-app/ folder of the repository.

For build and install steps, see Building and Installing the App.

Libraries

Library	Used for
Retrofit 2 + Gson converter	Calls to the Payload REST API (ApiService.kt)
OkHttp logging interceptor	Request logging in debug builds only
Glide	Loading listing and profile images
Material Components	Buttons, cards, bottom sheets, bottom navigation
Flexbox	Wrapping rows of amenity and filter chips

Blurhash placeholders are decoded by a small in-house decoder (BlurHashDecoder.kt) rather than a library.

Code layout

All Kotlin sources are in a single package, com.example.myapplication, under app/src/main/java/. The main groups are:

Area	Files
Networking	RetrofitClient.kt, ApiService.kt, response models (ListingsResponse.kt, SeekingListingResponse.kt, AuthModels.kt, SavedResponse.kt, etc.)
Entry and auth	MainActivity (launcher), LoginActivity, RegisterActivity, OtpVerifyActivity, ForgotPasswordActivity, ResetPasswordActivity, EmailVerificationSentActivity
Main shell	HomeActivity with bottom navigation: FeedFragment, CollectionFragment, ProfileFragment
Listings	HomeDetailActivity, RoomDetailActivity, BedDetailActivity, FeedAdapter, FilterBottomSheet
Hosting	CreateListingActivity + CreateStep1/2/3Fragment (listing wizard), EditListingActivity
Account	ProfileAccountFragment, ProfileListingsFragment, NidVerificationActivity, NidFormActivity, SavedSearchesActivity, NotificationsActivity
Shared state	SaveManager (saved-listing cache), RoleManager (seeker / host), LanguageManager, BaseActivity

Talking to Payload

• The API root comes from BuildConfig.BASE_URL, set in app/build.gradle.kts (see Backend URL).
• After login, the Payload JWT is stored in SharedPreferences (raj_shelter_prefs → auth_token) and attached to every request as Authorization: Bearer <token> by an OkHttp interceptor in RetrofitClient.
• Payload returns relationship fields either as a bare ID or as a populated object depending on depth. Models therefore use Any? for these fields, and the shared Gson instance registers custom deserializers for rich text and amenities.
• Listings follow the Home → Room → Bed hierarchy, with a separate endpoint set for each collection (home-listings, room-listings, bed-listings) plus seeking-listings.

Sessions and guest mode

• Session data (token, user ID, name, email, email_verified, etc.) lives in raj_shelter_prefs. Logging out clears everything except the chosen language.
• MainActivity skips the launcher when a saved token exists.
• Guest mode lets users browse without an account. Host details are hidden, and actions that need an account (e.g. saving or posting a listing) ask the user to log in.

Email verification

Email addresses are verified through a link on the website, not inside the app. The backend only sends email (OTP codes, alerts, NID results) to verified addresses. In the app:

• After registration, EmailVerificationSentActivity (“Check your inbox”) is shown.
• Unverified users see a banner on the feed and an Email verification row in Profile → Account to resend the link.
• The status is refreshed from GET users/{id} when the feed and profile load, so it updates once the user verifies on the website.
• OTP login and password reset are rejected by the backend for unverified emails. The app then shows a dialog offering to resend the verification link.

See OTP Authentication for the backend side.

Localisation

• Strings are in res/values/strings.xml (English) and res/values-bn/strings.xml (Bangla). Every user-facing string should be added to both files at the same time.
• LanguageManager stores the selected language, and BaseActivity applies it to every screen. The language can be switched from the launcher, login screens and Profile → Account.
• Listing requests pass a locale (en or bn-BD) for localised fields. Some screens currently hardcode en, so listing text does not always follow the app language.

Dark mode

• Colours are defined in res/values/colors.xml, with dark variants in res/values-night/colors.xml.
• The theme (Theme.Material3.DayNight) switches between them automatically.
• Users can choose Light, Dark or System in Profile → Account. Guests and logged-out users follow the device setting.
• Colours hardcoded in layouts, drawables or Kotlin do not switch in dark mode, so new colours should always be added to both colors.xml files.