D308 Mobile Application Development (Android) is banner number ITSW 3034 and three competency units in the School of Technology. The catalog describes it as mobile device programming using an Android software development kit to build and deploy a basic application, and the word deploy is the one to notice. The competency runs past writing code to producing something that installs and runs on a device that is not yours. What it builds toward is comfort with a platform that has its own lifecycle, its own permission model and its own build system, none of which behave like a desktop program.
The platform is the subject, not the language
Students expect a programming course and find a platform course. The code you write is ordinary, and what makes mobile development its own discipline is everything the platform does around your code. Your app does not own the process it runs in. The system can stop it, restart it, rotate it, interrupt it with a phone call, and reclaim its memory while it is in the background, and your code has to survive all of that without losing the user's data.
The lifecycle is therefore the first competency. Knowing which callbacks fire on creation, on becoming visible, on losing focus and on destruction is the entry level. Knowing where to put which work is what gets scored: expensive setup in the right place so it does not repeat on rotation, state saved where it survives a configuration change, listeners released where they will not leak.
Layout is the second, and it is unlike web layout. Screens vary in size and density, orientation flips, text size is a user setting, and a layout that assumes a fixed height in pixels will look wrong somewhere. Constraint based layout and density independent units exist for exactly this reason. An app that renders correctly only on the emulator you developed against has not met a portability aspect.
Data and permissions are the third. Where the app stores what it remembers, whether that store survives an uninstall, and which capabilities it has to ask the user for at runtime rather than at install. Requesting a permission the app never uses is a defect that a reviewer can see from the manifest alone.
Turning aspects into screens, features and a word budget
WGU scores aspects individually, requires a 2 in each, and returns the task when one falls short. For an app build the productive translation is aspect to screen or aspect to feature, and the check is whether you can open the app and point at the thing that satisfies each row.
The budget arithmetic on a typical shape. Say there are nine scored aspects and the documentation should run near 1,100 words. Nine into 1,100 is roughly 122 each. Sort them. Five aspects are feature demonstrations, satisfied by the app itself, so each needs about 70 words naming the screen and the class that implements it, which totals 350 and releases about 260. Two aspects ask for design justification, such as why this navigation pattern or why this storage mechanism, and those take 280 each. One aspect asks about testing, which is mostly a table with 120 words of framing. One asks for a deployment or build note, 100 words. Adding up gives 350 plus 560 plus 120 plus 100, which is 1,130, close to target with the justification sections carrying half the document.
Sequence the build from data outward. Decide what the app stores and what shape it takes, then build the screen that displays it, then the screen that edits it, then navigation, then polish. Building screens first and retrofitting storage is the standard way to lose a weekend.
Building the Android app now?
Send the aspects plus the app requirements. You get a screen map, a storage decision with its rationale, and a lifecycle checklist to build against.
The pre-submission sweep for a mobile deliverable
| Check | How to run it | What it catches |
|---|---|---|
| Clean build | Delete build outputs, rebuild from source, install fresh | Code that only compiles against stale artifacts |
| Rotation survival | Rotate the device on every screen that holds input | State lost on configuration change, the classic return |
| Background and return | Send the app to background, open others, come back | Crashes on restore, leaked listeners, stale views |
| Empty and first run | Uninstall, reinstall, use the app with no data at all | Screens that assume data exists |
| Bad input | Empty fields, wrong formats, impossible dates | Validation that was never written |
| Permission denial | Deny every runtime permission and keep using the app | Code paths that assume the user said yes |
| Second device or size | Run on a different screen size or density | Hardcoded dimensions and clipped layouts |
Rotation and first run are the two that catch the most. Both take under a minute and both are checks an evaluator will perform without being asked.
Evidence, screenshots and citing a platform
Mobile evidence is visual, so treat screenshots as figures rather than decoration. Capture the whole device frame, keep them in the order a user would encounter the screens, and caption each with what it demonstrates rather than what it is called. A screenshot titled main screen tells the reader nothing they could not see. One captioned entry saved and list refreshed after submit demonstrates a behavior.
Where a behavior is not visible in a still image, use a short numbered sequence: before, action, after. Log excerpts have a place too, especially for lifecycle work, where a log showing the callbacks firing in order on a rotation is direct evidence for an aspect about configuration changes.
For sources, the platform documentation is authoritative and it is versioned, so cite the page with a retrieval date when your program requires APA. This matters more on Android than on most platforms because guidance changes between releases, and an approach that was standard several versions ago is often deprecated now. Sample code adapted from documentation or a published tutorial gets attributed in a comment, and you should be able to explain every line, since aspects that ask for justification are unanswerable about borrowed decisions.
What passes first time on a mobile task
Work at WGU is Competent or Not Competent with no letter grades, and performance assessment work can be revised and resubmitted without penalty when an aspect is missed. In a six month flat rate term the return costs days rather than marks, which makes the sweep in the table above the highest value hour in the whole build.
Apps that clear immediately install from a clean build on a device the developer has not seen. They keep the user's input across a rotation. They behave sensibly with no data. Their documentation names the file and class behind each feature so an evaluator does not have to hunt for it. And they include whatever build information a person needs to run the project, since a project that will not open is a project that cannot be scored.
Returns concentrate in three places. State lost on rotation, which is the most common single defect in the subject. Hardcoded values that make the app work on one screen size. And an aspect about data persistence answered by describing the storage option chosen without explaining why it suits the data this app holds.
Six time sinks in D308
- Fighting the tooling on day one and calling it progress. Get the environment installed and one generated app running before you study anything. Toolchain problems in week six masquerade as knowledge gaps.
- Ignoring the lifecycle until something breaks. Almost every strange bug in a first mobile app is a lifecycle bug, and the callbacks were documented before the bug appeared.
- Building the UI before deciding on the data. Screens shaped around a data model you have not chosen get rebuilt when you choose one.
- Sizing in pixels. Density independent units exist because devices differ. Pixel values are how a layout ends up clipped on a reviewer's device.
- Requesting permissions you do not use. The manifest is read. Unused permissions are a visible defect and an easy one to remove.
- Testing only on the emulator you developed against. One second device or one different screen size catches most portability defects.
How we work on this course
Support for D308 starts at the screen map. Send the scored aspects and the requirements and you get a screen and navigation plan, a storage decision with the argument for it, a lifecycle checklist keyed to the behaviors your aspects name, and a model document that points at classes rather than describing the app in general terms. Reviews of your own project explain what is wrong and where, so the justification aspects stay answerable in your own words. Where a section is assessed by an objective assessment, we prepare only, and objective assessments are proctored: we never sit one, never assist during one, and never ask for or touch your WGU portal credentials.
Three units in a six month flat rate term is worth planning carefully, because mobile is the course where an unnoticed platform behavior can absorb a week that the rest of your term needed.
Three questions D308 students ask
Is D308 the same course as ITSW 3034?
Do I need a physical Android device?
How complete does the app have to be?
Where D308 sits in WGU's programs
The July 2026 catalog places this code in 2 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.