Theory
Put it all together, in Kotlin
BCA503-02 taught you Kotlin and how to build Android apps with it: the language (Units 1-2), then multi-screen apps with JSON, intents, SQLite, location and camera (Unit 3). The capstone PROJECT asks you to combine them into ONE working Kotlin Android app.
The natural choice is the running example you have followed: FestConnect Mobile, rebuilt in Kotlin. This closing lesson gives practical guidance on scoping and building it well, so it demonstrates real mastery rather than sprawling into a half-finished mess. Small, complete, and polished beats large and broken, every time.
Follow along
Scoping the capstone Kotlin app
- Choose a small, complete app FestConnect Mobile is ideal: an event list, an event detail screen, and a registration form. Finishable and coherent.
- Multiple screens with intents Use explicit intents to navigate (list -> detail) and pass data with extras; maybe an implicit intent to share an event.
- Persist with SQLite Store registrations in an on-device SQLite database with CRUD, so they survive between sessions.
- Add one device feature Include at least one: location (nearby venues) or camera (a photo), with proper runtime permission handling.
- Apply Kotlin well, and document Use null safety, concise classes, and val over var; write a short doc: what it does, and how to run it.
Theory
One app, every skill
Your project weaves together the whole subject: Kotlin (safe, concise classes and logic), JSON (data from a server or a bundled file), intents (moving between screens and cooperating with other apps), SQLite (persistent local data), and a device feature (location or camera, with permissions).
Even a SMALL app that does these few things properly, a clean event list, a working registration saved to SQLite, a shared event, one device feature, demonstrates that you can build a real, data-driven, device-aware Android app in Kotlin. That end-to-end competence, not the app's size, is what the project shows. Build it incrementally: one screen and feature working fully, then the next, testing as you go.
Quiz
For the BCA503-02 capstone project, what is the best approach?
- Build the largest possible app with every feature, even if unfinished
- Build a small, complete Kotlin Android app (multiple screens, SQLite, a device feature), scoped to finish and built incrementally
- Skip Kotlin and use Java instead
- Only do the IKS mathematics, no app
Show the answer
Build a small, complete Kotlin Android app (multiple screens, SQLite, a device feature), scoped to finish and built incrementally
The right approach is a SMALL, COMPLETE Kotlin Android app applying Units 1-3: multiple screens (intents), SQLite storage, and a device feature, scoped so you can finish and polish it, and built incrementally. Option A is the over-scoping mistake: a huge, unfinished app demonstrates less than a clean, working small one (the same lesson as every project topic). Option C ignores that this is the KOTLIN subject: the project should showcase Kotlin. Option D confuses the IKS mathematics topic (a separate deliverable) with the app project. Depth over breadth: one solid, complete, documented Kotlin app shows the Unit 1-3 skills best. Small and finished beats big and broken.
Think first
Which device feature to include?
The project asks for at least one device feature (location or camera). How should you choose, and what must you not forget? Then tap.
Show the answer
Choose the feature that best FITS your app's story and that you can implement cleanly. For FestConnect Mobile, CAMERA fits naturally (a profile photo, or a photo at an event), and LOCATION fits if you show nearby venues, pick whichever your app has a genuine reason for, not one bolted on arbitrarily. What you must NOT forget: PERMISSIONS. Both location and camera involve sensitive access, so declare the permission, request it at RUNTIME, check it is granted, and handle DENIAL gracefully (the feature simply does not appear, no crash). This is the runtime-permission discipline from Unit 3, and doing it correctly is part of demonstrating real Android competence, and of respecting the user (BCA402-02's trust principle). A device feature done WITHOUT proper permission handling is incomplete and would crash on a real phone. Pick a feature with a purpose, and handle its permission properly.
Watch out
Project traps
Over-scoping: a huge, half-built app shows less than a small, complete one; scope to finish.
Skipping permission handling: device features need runtime permissions handled correctly, or the app crashes.
Not persisting data: use SQLite so data survives; an app that forgets everything is incomplete.
Ignoring Kotlin's strengths: use null safety, val, and concise classes; do not write Java-style Kotlin.
No documentation: a project without a clear write-up (what, how to run) is incomplete.
(Exact assessment criteria are set by your institute; confirm them.)
Theory
BCA503-02 complete
You have learned Kotlin, Google's preferred Android language, and built a real, data-driven, device-aware Android app with it, plus a factual study of classical Indian mathematics from the Lilavati. That is the full arc of Advance Mobile Technology. Follow your institute's own guidance for this unit; present the mathematics accurately and cite your sources. Across three languages now, Java, Dart, and Kotlin, you can build for mobile: adaptable, and ready.
Summary
Key takeaways
- The capstone combines Units 1-3: a Kotlin Android app with multiple screens, SQLite storage, and a device feature.
- Scope a small, complete app (FestConnect Mobile is ideal) that you can finish and polish.
- Use intents to navigate and pass data; SQLite to persist; JSON for data; and at least one device feature (location or camera).
- Handle runtime permissions correctly for any device feature, and degrade gracefully if denied.
- Apply Kotlin's strengths: null safety, concise classes, val over var; build incrementally and test as you go.
- Document the project; small and finished beats big and broken.
- Memory hook: one small complete Kotlin app, multiple screens, persisted data, one device feature, built end to end.