C971 Mobile Application Development Using C# is banner number ITSW 3315 and three competency units in the School of Technology. The catalog describes it as applying prior C# knowledge to mobile device programming, including mobile user interface design and development. The phrase prior C# knowledge is the important one: this course assumes you already write the language and asks you to move it onto a device, where the interface is declarative, the screen is small, the data has to survive being closed, and the code you write is not the code that runs the loop.
A declarative interface changes how you think
Mobile development in this stack separates the description of a screen from the code that gives it meaning. The layout is declared, the logic sits behind it, and the two are joined by binding rather than by direct manipulation. Students who learned to build interfaces by assigning values to controls in code find this backwards at first, and getting past that discomfort is most of the early difficulty in the course.
Binding is the concept to master properly. A control displays a property, and when that property changes the control updates itself, provided the object holding it announces the change. Objects that do not raise change notifications produce the most common and most confusing symptom in the subject: correct data in memory and stale data on screen. If your list does not refresh, the answer is nearly always notification rather than layout.
Navigation and page lifecycle come next. Pages are pushed and popped rather than opened and closed, state has to survive a page going away and coming back, and work started when a page appears has to stop when it disappears. A timer or subscription started on appearance and never released is a leak that grows every time the user visits the page.
Persistence closes the loop. A mobile app is expected to remember, so choosing where data lives, a local database for structured records or simple key storage for preferences, is a design decision the aspects usually ask you to justify. Storing structured records in preference storage works and is the wrong answer to the question.
Turning aspects into pages, bindings and a word budget
WGU scores each aspect on its own and needs a 2 in every one to pass a task. In an app build the productive translation is aspect to page or aspect to behavior, with a note of the class behind it, so that every row has an address before you write documentation.
Run the numbers. Suppose ten scored aspects and a document of about 1,200 words. Ten into 1,200 gives 120 words per aspect. Sort them. Six are feature demonstrations proved by the running app, so 70 words each of pointer text naming the page and the class, which is 420 and releases about 300. One asks you to justify the data storage choice, at 280. One asks about the interface design decisions for a small screen, at 280. One asks about validation and error handling, 180. One is a build or deployment note at 100. Adding up: 420 plus 280 plus 280 plus 180 plus 100 is 1,260, near target, with two justification sections carrying almost half the prose.
Build in this order: data model, then storage, then the page that lists records, then the page that edits one, then navigation, then validation. Starting from the prettiest page is how a weekend disappears.
On the C971 app now?
Send the aspects and the requirements. You get a page map, a storage decision with its argument, and a model write-up.
A symptom table for the bugs this course produces
Mobile bugs in this stack look mysterious and have a short list of causes. Matching symptom to cause saves more time in this course than any other single habit.
| Symptom | Usual cause | Where to look |
|---|---|---|
| Data is correct but the screen does not update | The object never announces property changes | The model class, not the layout |
| The list is empty although records exist | The collection was replaced rather than updated, or bound before loading | Where the collection is assigned |
| An edit saves but reappears unchanged | The edited copy was never written back to storage | The save path in the page logic |
| The app slows the more you use it | Subscriptions or timers started on appearing and never released | The appearing and disappearing handlers |
| It works on one device size and not another | Fixed dimensions instead of flexible layout | The layout declaration |
| Data disappears after closing the app | Records held in memory only | The storage layer, which may not exist yet |
Five of the six have nothing to do with the visible layout, which is why staring at the screen declaration is usually the slowest way to debug this course.
Evidence from a device, and citing the platform
Capture the app as a sequence rather than as a gallery. Before the action, the action, the result, each captioned with the behavior it demonstrates. For persistence specifically, the convincing sequence is create a record, close the app fully, reopen it, and show the record still there. That is three images and it answers a storage aspect completely.
Include the failure cases: what the app does with an empty required field, with a value out of range, and with no records at all. Empty state is the screen students never design and evaluators always visit.
For sources, the framework documentation is authoritative and versioned, so cite the version and a retrieval date in APA where your program requires it. This matters in cross-platform mobile more than most places, because the tooling has changed names and structure across releases and older tutorials describe patterns that no longer apply. Sample code adapted from documentation gets a comment naming its source, and anything you cannot explain is a risk in a write-up where aspects ask you to justify your choices.
What clears evaluation on a mobile task
Work at WGU is Competent or Not Competent with no letter grades and no ordinary grade point average, and performance assessment work returns for free revision when an aspect falls short. The cost is calendar days inside a six month flat rate term, so the pre-submission pass matters more than one more feature.
Apps that clear build from a clean solution, install and run on a device the developer has not used, keep their data across a full restart, and behave sensibly on first run with nothing stored. Their documentation names the page and the class behind each aspect. Their layout holds at more than one screen size.
Returns follow a short list. Data that vanishes on restart, which is a storage aspect failed outright. Screens that assume records exist. Validation missing on the edit page while present on the create page, which is the inconsistency that comes from building the two separately. And a justification aspect answered by naming the storage mechanism without saying why it suits this data.
Six mistakes that cost C971 students time
- Debugging binding problems in the layout. The cause is almost always change notification in the model. Check there first.
- Manipulating controls from code. It works and it defeats the pattern the course is teaching, which the structural aspects are written around.
- Leaving storage until last. Persistence changes the shape of the data classes. Deciding it late means editing every page.
- Ignoring the empty state. The first screen a new user sees has no data in it, and it is the first screen an evaluator sees too.
- Starting work on appearing without stopping it on disappearing. Every visit adds another subscription and the app degrades as it is used.
- Following an outdated tutorial. This tooling has changed across releases. Match the documentation to the version in your project or you will chase errors that are not yours.
How we work on this course
Support for C971 is the plan and the debugging map. Send the scored aspects and the requirements and you get a page map, a storage decision with the argument behind it, a binding checklist that prevents the common symptoms, an evidence sequence for the persistence aspect, and a model document in the register WGU evaluators expect. Reviews explain the cause of a defect rather than replacing your project. Where a section uses an objective assessment, support is preparation only, and objective assessments are proctored: we never sit or assist during one, and we never ask for or use portal credentials.
Three units in a six month flat rate term is worth protecting, and mobile is a course where one misunderstood mechanism can absorb a week that the rest of your plan needed.
Three questions C971 students ask
Is C971 the same course as ITSW 3315?
How much C# do I need before C971?
Do I need a Mac or a physical device?
Where C971 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. 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.