In AP Computer Science Principles, program inputs are data sent to a computer for processing by a program (EK CRD-2.C.1). Inputs can be tactile, audio, visual, or text, can be supplied by events like clicks or key presses, and usually determine the output a program produces.
Program inputs are any data sent to a computer for processing by a program. That's the official CED definition (EK CRD-2.C.1), and the key word is any. Input isn't just a user typing into a text box. A temperature sensor reading, a microphone picking up sound, a camera capturing an image, a mouse click, a file loaded from a server, all of these count. The CED groups input forms into four buckets: tactile (touch, button presses), audio, visual, and text.
Inputs often arrive through events. An event is associated with an action (a key press, a mouse click, the program starting) and supplies input data to the program (EK CRD-2.C.2 and CRD-2.C.3). In event-driven programming, code segments sit and wait until their event fires, and then they run. The other half of the picture is that inputs usually affect the output a program produces (EK CRD-2.C.4). Type a different city into a weather app and you get a different forecast. Same program, different input, different output. That input-to-output relationship is the core idea AP CSP wants you to trace.
Program inputs live in Unit 1: Creative Development, Topic 1.2 (Program Function and Purpose), directly supporting learning objective 1.2.C: Identify input(s) to a program. It also props up 1.2.B (explaining how a program functions) because EK CRD-2.B.3 says a program needs to work for a variety of inputs and situations, and 1.2.D (identifying outputs) because EK CRD-2.D.2 says output is usually based on input or prior state. In other words, you can't explain what a program does without naming what goes in. This idea also follows you all the way to the Create Performance Task, where your written response asks you to describe input and output for your own program. If you can spot inputs in a scenario in Unit 1, you can describe them in your own code later.
Keep studying AP Computer Science Principles Unit 1
User Inputs (Unit 1)
User inputs are one slice of program inputs, the slice that comes directly from a human, like typing a username or tapping a button. Program inputs are the bigger umbrella that also covers sensors, files, and data from other programs. Every user input is a program input, but not the other way around.
Variables (Unit 3)
When input arrives, a program has to put it somewhere, and that somewhere is a variable. A line like userName ← INPUT() is literally the handoff point between the outside world and your program's memory. Inputs are the data; variables are the containers that hold it for processing.
Code Segment (Unit 1)
In event-driven programming, a specific code segment is tied to a specific event, like a click handler. The event supplies the input data and triggers that segment to run (EK CRD-2.C.5). Inputs don't just feed a program data; they can control which parts of the code execute at all.
Data (Unit 2)
Inputs are data the moment they cross into a program. Unit 2 zooms in on what happens next, how that data gets represented in binary, stored, and transformed. The input/processing/output pipeline from Topic 1.2 is the frame Unit 2 fills in with detail.
Program inputs show up in multiple-choice questions that give you a scenario and ask you to identify what counts as input, or to pick the most effective inputs for a program's purpose. A classic setup describes a weather app receiving sensor data, a typed city name, and server forecast data, then asks what term covers all three. The answer is program inputs, because the definition covers any data sent for processing, not just what a user types. Other stems ask which inputs best serve an app's primary function (for a bird-identification app, think camera and microphone, not a text box) or ask you to spot the input in an event scenario like a button click submitting a username and password. The skill is the same every time: separate the input (data going in) from the output (data going out) and from the event that delivered it. No released FRQ uses 'program inputs' verbatim, but the Create Task written response requires you to describe your program's input and output, so this vocabulary is non-negotiable.
User inputs are data a human directly provides, like typing text or clicking a button. Program inputs include user inputs plus everything else, like sensor readings, files, network data from a server, and data from other programs. On the exam, if a question lists a temperature sensor alongside a user typing, the term that covers both is program inputs. Picking 'user input' for a sensor reading is a common wrong-answer trap.
Program inputs are any data sent to a computer for processing by a program, and they can be tactile, audio, visual, or text (EK CRD-2.C.1).
Inputs are broader than user inputs; sensors, servers, files, and other programs all supply program inputs too.
An event (like a key press, mouse click, or program start) is tied to an action and supplies input data to a program, and in event-driven programming it triggers code to run.
Inputs usually affect the output a program produces, so changing the input typically changes the result.
A program needs to work for a variety of inputs and situations, which is why testing with different inputs matters (EK CRD-2.B.3).
Program output is usually based on input or the program's prior state, so input and output are two ends of the same pipeline.
Program inputs are data sent to a computer for processing by a program. The CED (EK CRD-2.C.1) says input can come in a variety of forms, including tactile, audio, visual, or text.
Yes. A mouse click is an event, and events supply input data to a program (EK CRD-2.C.2). Key presses, clicks, and even a program starting all count as input-generating events on the AP exam.
User inputs come directly from a human, like typed text or a button tap. Program inputs include those plus non-human sources like temperature sensors, server data, and files. If a question mixes a sensor with a typed value, 'program inputs' is the term that covers both.
No. A weather app can receive input from a temperature sensor, a server sending forecast data, and a user typing a city name, and all three are program inputs. The definition only requires data sent to a program for processing, not a human source.
Inputs usually affect the outputs a program produces (EK CRD-2.C.4), and outputs are usually based on input or the program's prior state (EK CRD-2.D.2). Think of it as a pipeline: data in, processing, data out.