A Context object contains a list of properties in the form of NamedValue objects. These properties represent information about the client, the environment, or the circumstances of a request and generally are properties that might be inconvenient to pass as parameters.
Context defines the set of actions you can take, i.e. methods to invoke, variables to use, etc. The following, among others, create a context: a class, a method (or a function, a procedure, etc.), a block of code. Generally, all scopes have little contexts of their own.
Definition. it's the context of current state of the application/object. It lets newly-created objects understand what has been going on. Typically, you call it to get information regarding another part of your program (activity and package/application).
Clojure is a dynamic, general-purpose programming language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming.
Let's say you go to the dentist to have a tooth pulled out.
When the receptionist asks you for your name, that's information they need in order to begin the appointment. In this example, your name is contextual information. So in the context of visiting the dentist, you need to provide your name to get your tooth pulled.
Now let's say you walk over to the bank.
At the bank, you ask to withdraw $100. The teller needs to establish your identity before giving you money, so you'll probably have to show them a driver's license or swipe your ATM card and enter your PIN number. Either way, what you're providing is context. The teller uses this information to move the transaction forward. They may then ask you which account you'd like to withdraw from. When you answer, "My savings account", that's even more context.
The more context you give, the more knowledge the other party has to help deal with your request. Sometimes context is optional (like typing more and more words into your Google search to get better results) and sometimes it's required (like providing your PIN number at the ATM). Either way, it's information that usually helps to get stuff done.
Now let's say you take your $100 and buy a plane ticket to fly somewhere warm while your mouth heals.
You arrive at a nice sunny destination, but your bag doesn't make it. It's lost somewhere in the airport system. So, you take your "baggage claim ticket" (that sticker with the barcode on it) to the "Lost Baggage office". The first thing the person behind the desk will ask for is that ticket with your baggage number on it. That's an example of some required context.
But then the baggage person asks you for more information about your bag like so they can find it more easily. They ask, "What color is it? What size is it? Does it have wheels? Is it hard or soft? While they don't necessarily need those pieces of information, it helps narrow things down if you provide them. It reduces the problem area. It makes the search much faster. That's optional context.
Here's the interesting part: for a lot of software and APIs, the required context usually ends up as actual parameters in a method signature, and optional context goes somewhere else, like a flexible key-value map that can contain anything (and may be empty) or into thread-local storage where it can be accessed if needed.
The examples above are from real life, but you can easily map them to areas within computer science. For example, HTTP headers contain contextual information. Each header relates to information about the request being made. Or when you're sending along a global transaction ID as part of a two-phase commit process, that transaction ID is context. It helps the transaction manager coordinate the work because it's information about the overall task at hand.
Hope that helps.
Context can be seen as a bucket to pass information around. It is typically used to pass things not necessarily tied directly to a method call, but could still be pertinent. A layperson way of describing it might be "stuff you may care about".
For e.g. if you were writing a service to update a value in a db, you'd probably pass in the record id, and the new value.
If you want generic interfaces, you may also define a context to pass, such that the service can perform arbitrary business logic. So you may include a user authentication, the user's session state, etc... in the context, as the service may perform additional logic dependent on these values.
This is 2015 - may years after this thread began.
Nonetheless, I am posting this message to help anyone out there like me that is Struggled to understand "Context"
By no means do I claim to have used Context in Java programs - so its entirely up to you to write Context out in hard coding So here goes :-
"Conceptually context" is the same "as tell me more" When a client makes a request to server - in order to carry out the request the server says "give me some more info so that i can help you". Thus, alongwith the request, the client provides a bundle of details. The server picks and chooses from the bundle all pieces of info required to serve the request. This bundle is what is called "Context"
E.g.
Patient goes to doc and says treat_me ( "I have a headache" ) Doc office gives the patient a form to fill. Patient fills form. The form is used by the doctor to carry out the "treat_me" request.
Here is how the request now looks :
treat_me ( "i have a headache", filled_form_num_23321 )
Here is how filled_form_num_23321
looks :
Q.What lead to the condition ? A. 10 pegs of neat Scotch last nite
Q.Patient name ? A. Joe Bigdrinker
Q.Age ? 98
In this transaction filled_form_num_23321
is the "context".
Hope this helps in clarifying the concept of "Context".
i always think of context as a particular state relevant to the object or construct i am working with.
For example, when you are using drawRect in a view (where all drawing must be done for a view) you must always get the currentGraphicsContext into which you will issue your core graphics statements. This context contains things like bounds of the view, the stroke colour, the stroke thickness for drawing a line, the fill color for filling a closed Path etc. this context (like most others) is just the current state at this point in time. so think of the graphics context in this case as just a set of state such as
stroke thickenss is 1.5 pixels fill color is black bounds of view is (155, 200) stroke color is Red
Its basically the state at the current point in time ...
To give a practical example. Lets say you have a certain webpage to fetch/render some information based on the user (thats logged on) and language of the browser. The logic of fetching the information is independent from the user and the language. Your page will receive a user and a language ... for the logic it doesnt matter if it is me or you or english or spanish.
Some pseudo code:
class FooPage
{
void handleRequest(RequestContext context)
{
User user = context.getUser();
Locale locale = context.getLocale();
… do some logic based on the context
}
}
Its not that difficult, but it takes some time to understand the concept
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With