Event Driven Programming

11 Key excerpts on "Event Driven Programming"

• 

  eBook - ePub

  Expert Python Programming

  Master Python by learning the best coding practices and advanced programming concepts, 4th Edition

  • Tarek Ziadé, Michał Jaworski(Authors)
  • 2021(Publication Date)
  • Packt Publishing

    (Publisher)

  messages ) and their flow between different software components. In fact, it can be found in many types of software. Historically, event-based programming is the most common paradigm for software that deals with direct human interaction. It means that it is a natural paradigm for GUIs. Anywhere the program needs to wait for some human input, that input can be modeled as events or messages. In such a framing, an event-driven program is often just a collection of event/message handlers that respond to human interaction.

  Events of course don't have to be a direct result of user interaction. The architecture of any web application is also event-driven. Web browsers send requests to web servers on behalf of the user, and these requests are often processed as separate interaction events. Some of the requests will indeed be the result of direct user input (for example, submitting a form or clicking on a link), but don't always have to be. Many modern applications can asynchronously synchronize information with a web server without any interaction from the user, and that communication happens silently without the user noticing.

  In summary, event-driven programming is a general way of coupling software components of various sizes and happens on various levels of software architecture. Depending on the scale and type of software architecture we're dealing with, it can take various forms:

  • It can be a concurrency model directly supported by a semantic feature of a given programming language (for example, async /await in Python)
  • It can be a way of structuring application code with event dispatchers/handlers, signals, and so on
  • It can be a general inter-process or inter-service communication architecture that allows for the coupling of independent software components in a larger system

  Let's discuss how event-driven programming is different from asynchronous programming in the next section.

  Event-driven != asynchronous

  Although event-driven programming is a paradigm that is extremely common for asynchronous systems, it doesn't mean that every event-driven application must be asynchronous. It also doesn't mean that event-driven programming is suited only for concurrent and asynchronous applications. Actually, the event-driven approach is extremely useful, even for decoupling problems that are strictly synchronous and definitely not concurrent.

  Sign up to read

  Learn more about book
• 

  No longer available |Learn more

  Expert Python Programming

  Become a master in Python by learning coding best practices and advanced programming concepts in Python 3.7, 3rd Edition

  • Michał Jaworski, Tarek Ziadé(Authors)
  • 2019(Publication Date)
  • Packt Publishing

    (Publisher)

  Events also don't have to be a direct result of user interaction. The architecture of any web application is also event-driven. Web browsers send requests to web servers on behalf of the user, and these requests are often processed as separate interaction events. Such requests are, of course, often the result of direct user input (for example, submitting a form or clicking on a link), but don't always have to be. Many modern applications can asynchronously synchronize information with a web server without any interaction from the user, and that communication happens silently without the user's notice.

  In summary, event-driven programming is a general way of coupling software components of various sizes, and happens on various levels of software architecture. Depending on the scale and type of software architecture we're dealing with, it can take various forms:

  • It can be a concurrency model directly supported by a semantic feature of given programming language (for example, async/await in Python)
  • It can be a way of structuring application code with event dispatchers/handlers, signals, and so on
  • It can be a general inter-process or inter-service communication architecture that allows for the coupling of independent software components in a larger system

  Let's discuss how event-driven programming is different for asynchronous systems in the next section. Passage contains an image

  Event-driven != asynchronous

  Although event-driven programming is a paradigm that is extremely common for asynchronous systems, it doesn't mean that every event-driven application must be asynchronous. It also doesn't mean that event-driven programming is suited only for concurrent and asynchronous applications. Actually, the event-driven approach is extremely useful, even for decoupling problems that are strictly synchronous and definitely not concurrent.

  Consider, for instance, database triggers that are available in almost every relational database system. A database trigger is a stored procedure that is executed in response to a certain event that happens in the database. This is a common building block of database systems that, among others, allows the database to maintain data consistency in scenarios that cannot be easily modeled with the mechanism of database constraints. For instance, the PostgreSQL database distinguishes three types of row-level events that can occur in either a table or a view:

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Mastering Node.js - Second Edition

  • Sandro Pasquali, Kevin Faaborg, Glenn Geenen(Authors)
  • 2017(Publication Date)
  • Packt Publishing

    (Publisher)

  The key design choice made by Node's designers was the implementation of an event loop as a concurrency manager. For example, notifying your Node-based HTTP server of network connections to your local hardware is handled by the OS passing along, via libuv, network interface events.

  The following description of event-driven programming (taken from: http://www.princeton.edu/~achaney/tmve/wiki100k/docs/Event-driven_programming.html ) clearly not only describes the event-driven paradigm, but also introduces us to how events are handled in Node, and how JavaScript is an ideal language for such a paradigm.

  In computer programming, event-driven programming or event-based programming is a programming paradigm in which the flow of the program is determined by events—that is, sensor outputs or user actions (mouse clicks, key presses) or messages from other programs or threads. Event-driven programming can also be defined as an application architecture technique in which the application has a main loop that is clearly divided down to two sections: the first is event selection (or event detection), and the second is event handling […]. Event-driven programs can be written in any language, although the task is easier in languages that provide high-level abstractions, such as closures. Visit https://www.youtube.com/watch?v=QQnz4QHNZKc for more information.

  Node makes a single thread more efficient by delegating many blocking operations to OS subsystems to process, bothering the main V8 thread only when there is data available for use. The main thread (your executing Node program) expresses interest in some data (such as via fs.readFile) by passing a callback, and is notified when that data is available. Until that data arrives, no further burden is placed on V8's main JavaScript thread. How? Node delegates I/O work to libuv, as quoted at: http://nikhilm.github.io/uvbook/basics.html#event-loops .

  In event-driven programming, an application expresses interest in certain events, and responds to them when they occur. The responsibility of gathering events from the operating system or monitoring other sources of events is handled by libuv, and the user can register callbacks to be invoked when an event occurs.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Essentials of Interactive Computer Graphics

  Concepts and Implementation

  • Kelvin Sung, Peter Shirley, Steven Baer(Authors)
  • 2008(Publication Date)
  • A K Peters/CRC Press

    (Publisher)

  1 Event-Driven Programming This chapter introduces the Event Driven Programming model. This chapter • explains the deficiencies of designing user-interface applications based on the traditional control-driven programming model; • introduces the event-driven programming model and examines how this new model addresses the above deficiencies; • demonstrates the development of user-interface solutions based on the event-driven programming model. After this chapter, you should • understand the parameters and principles of event-driven programming; • understand the process for designing an event-driven solution; • understand, at a conceptual level, the interactions between GUI APIs and our solution; • be able to design an event-driven programming solution based on given specifications. However, because this chapter does not cover the details of any API, we will not be able to implement the solutions we have designed. For that, we will wait for the next chapter. 13 14 1. Event-Driven Programming For many of us, when we were first introduced to computer programming, we learned that the program should always start and end with the main() function— when the main() function returns, all the work must have been completed and the program terminates. Since the overall control remains internal to the main() function during the entire lifetime of the program, this approach to solving prob-lems is referred to as the control-driven programming or the internal control model approach. As we will see, an alternative paradigm, event-driven program-ming or an external control model approach, is the more appropriate way to design solutions to interactive programs. In this chapter, we will first formulate a solution to the (2D) ball-shooting pro-gram based on the perhaps more familiar control-driven programming model. We will then analyze the solution, identify shortcomings, and describe the motivation for the external control model or event-driven programming approach.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Programming Logic & Design, Comprehensive

  • Joyce Farrell(Author)
  • 2017(Publication Date)
  • Cengage Learning EMEA

    (Publisher)

  GUI programs frequently are called event-driven or event-based because actions occur in response to user-initiated events such as tapping a screen or clicking a mouse button. When you program with event-driven languages, the emphasis is on objects that users can manipulate, such as text boxes, buttons, and menus, and on events that users can initiate with those objects, such as typing, pointing, clicking, or double-clicking. The programmer writes instructions within modules that execute in response to each type of event. Throughout this book, the program logic you have developed has been procedural, and not event-driven; each step occurs in the order the programmer determines. In a procedural application, if you write statements that display a prompt and accept a user’s response, the processing stops after the prompt is displayed, and the program goes no further until input is received. When you write a procedural program, you have complete control over the order in which all the statements will execute. If you call moduleA() before calling moduleB() , moduleB() does not execute until moduleA() is finished. In contrast, with most event-driven programs, the user might initiate any number of events in any order. For example, when you use an event-driven word-processing program, you have dozens of choices at your disposal at any moment. You can type words, select text with the mouse, click a button to change the text style to bold or italics, choose a menu item such as Save or Print , and so on. With each word-processing document you create, the program must be ready to respond to any event you initiate. The programmers who created 509 Understanding Event-Driven Programming Copyright 2018 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. WCN 02-300

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Introduction to Programming Languages

  • Arvind Kumar Bansal(Author)
  • 2013(Publication Date)
  • Chapman and Hall/CRC

    (Publisher)

  In a procedural input-driven model, the interaction of a program is directed by a programmer in input-driven mode; unless a procedure requests to interact and accept the input data, there is no interaction with the outside world. In reality, a program that interacts with the real world ubiquitously has to continuously keep registering the events that occur in the real world, match with the desired events, and activate corresponding methods (or functions) in response to the desired event. The events in the real world are asynchronous and nondeterministic and can occur in unpredictable order. A program should be able to capture the events and react to process the events. It is a program’s choice whether to take an action or ignore the event based on the state of the system. However, the initiator of the computation is the signal from an event-source and not the control thread. Compared to procedural programming that provides tight coupling between objects, event-based systems provide loose coupling to various objects; the control is decentral-ized and event based. An object can be activated only if an event occurs; no specific thread controls the events. An event may start a cascade of events, and these events can be nonde-terministic depending upon the state of the system. An event is characterized by a set of identifying features and may involve time-intervals and a region where action occurs. For example, raining or snowing on a specific day and time is an event; an accident is an event; a meeting of two or more people is an event; and a tsunami is an event. Multiple buttons on a graphical dashboard are a source of events, and pressing any button is an event.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Event Processing for Business

  Organizing the Real-Time Enterprise

  • David C. Luckham(Author)
  • 2011(Publication Date)
  • Wiley

    (Publisher)

  thought of as happening —like using your imagination to visualize the events that will happen if you don’t stop at a red light. Suppose, for example, there’s a car crossing on green, and you imagine a crash! But since you stopped at the red light, those events didn’t happen—you imagined them as virtual events. And you used them in decision making.

  Event Driven Simulation

  Event driven simulation refers to the use of events to drive the steps in computing with models to predict the behavior of systems—anything from a design for a controller for traffic lights, or a model for a manufacturing line, to a plan for battlefield operations. This is one of the earliest uses of events and event driven computing. Rooted in World War II, this area of computer programming took off in the 1950s. People started to use computers—a recent invention at the time—to predict how designs of devices such as controllers would behave before they were actually manufactured. The idea was to save costs involved in letting mistakes in designs go forward to the manufacture of the design and also to shorten the time taken in the design-to-manufacture cycle.

  Computer simulation started out very simply as a haphazard activity in which people wrote programs, usually in machine code, to predict the behavior of a design or model. The activity quickly expanded to other things, such as predicting how the operations of a company could be improved to grow sales, and later on to much more ambitious undertakings like forecasting the weather.3

  During the 1950s, the techniques for building computer simulations quickly became understood and formalized. The core idea is to use a computer program that models—or mimics—an actual system. The system could be anything from a factory production line to a company’s sales plans to voter behavior in an election. Simulation refers to executing the model on input data. It turned out that many simulations used events as a way to organize their computations. The event driven

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  ActionScript 3.0 Bible

  • Roger Braunstein(Author)
  • 2011(Publication Date)
  • Wiley

    (Publisher)

  Part IV Event-Driven Programming

  Chapter 20 Events and the Event Flow

  Chapter 21 Interactivity with the Mouse and Keyboard

  Chapter 22 Timers and Time-Driven Programming

  Chapter 23 Multitouch and Accelerometer Input

  Passage contains an image Chapter 20 Events and the Event Flow

  ActionScript 3.0 uses a powerful framework for handling internal communication known as the event framework . Events are messages that are sent between objects when an action, such as a button click, has taken place. This enables you to create functionality that occurs interactively and without the need for direct method calls to other classes.

  The Flash Player API uses events for many purposes in a unified way. Events handle mouse actions, timers, networking, and asynchronous errors. In this chapter you'll learn about how these subsystems use the event framework.

  I'll take a look at how EventDispatcher objects communicate and how the new Event objects are structured. I'll also check out some of the more advanced features of the event framework, including how to create your own custom events and how to use event bubbling.

  Introducing Events

  What exactly is an event? At its core, an event is an object that represents an occurrence and describes the conditions surrounding that occurrence. This includes (but is not limited to) a description of the event, called the event type , and the origin of the event, also known as the event target .

  Events—and the Observer design pattern that the event framework follows—allow one object, called an event dispatcher , to trigger the actions of one or more other objects, called event listeners

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Event Processing in Action

  • Peter Niblett, Opher Etzion(Authors)
  • 2010(Publication Date)
  • Manning

    (Publisher)

  Chapter 2. Principles of event processing

  An apprentice carpenter may want only a hammer and saw, but a master craftsman employs many precision tools. Computer programming likewise requires sophisticated tools to cope with the complexity of real applications, and only practice with these tools will build skill in their use.

  Robert L. Kruse

  In the previous chapter we briefly introduced event processing. In this chapter we explore the technical concepts behind event processing in more detail. The chapter is divided into three main sections:

  • In section 2.1 we look at the event-based programming part of event processing. This covers the event aspect of event processing. The remainder of the chapter then discusses the processing part of event processing.
  • In section 2.2 we introduce the main concepts of event processing, and define the terminology we use to describe them.
  • In section 2.3 we introduce the modeling language that we use in this book to describe the concepts from section 2.2 .

  This chapter focuses on the general principles underlying these topics. In part 2 of this book we show them being used in the Fast Flower Delivery example that we introduced in the previous chapter.

  2.1. Events and event-based programming

  In the first part of this chapter we look more closely at events in computerized event processing, their interactions with application components, and the ways they are distributed between these components. As a lead into this, however we start by looking at how applications components typically interact when they aren’t using events.

  2.1.1. The background: request-response interactions

  Everyone who has used a web browser (figure 2.1

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Software Architecture with Spring 5.0

  Design and architect highly scalable, robust, and high-performance Java applications

  • René Enríquez, Alberto Salazar(Authors)
  • 2018(Publication Date)
  • Packt Publishing

    (Publisher)

  Event-Driven Architectures

  Event-driven architectures (EDA ) are based on commands and events that are created each time an application changes stat e. According to Martin Fowler, there are four patterns that are used to build software systems using this approach. 

  In this chapter, we are going to learn about these four patterns and look at how messaging can be tied together to take full advantage of a programming model based on messages. Even when it's not a requirement, messaging can be used to add more capabilities into applications that are built using an event-driven architectural style. 

  In this chapter, we will look at the following topics:

  • Underlying concepts and key aspects associated with event-driven architectures:
    • Commands
    • Events
  • Common patterns used within event-driven architectures:
    • Event notification
    • Event-carried state transfer
    • Event sourcing
    • CQRS

  Passage contains an image

  Underlying concepts and key aspects

  Before looking into the details of event-driven architectures, we are going to start by learning about some key aspects surrounding them. The applications created using this approach are developed with two different but related concepts in mind: 

  • Commands
  • Events

  Let's look at a brief definition of each of these concepts.

  Passage contains an image

  Command

  A command is an operation performed within an application that emits one or more events as the result of a successful or failed execution. We can think about these as operations that are intended to modify the state of a system.

  Commands are called actions. This makes a lot of sense if we take their intended use into consideration. The following list shows some examples of such commands:

  • Transfer money
  • Update user information
  • Create an account

  It's highly recommended that you use present tense verbs for naming commands, as demonstrated with these examples.

  Passage contains an image

  Event

  An event is the result of a command execution within an application. These are used as a notification mechanism for subscribers who are interested in receiving them. Events are immutable and should not be modified, as they are designed to keep a log that keeps information on how the application state has mutated over time. 

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  An Object-Oriented Approach to Programming Logic and Design

  • Joyce Farrell(Author)
  • 2012(Publication Date)
  • Cengage Learning EMEA

    (Publisher)

  GUI components are excellent examples of the best principles of OOP; they represent objects with attributes and methods that operate like black boxes. l When you create a program that uses a GUI, the interface should be natural, predictable, attractive, easy to read, and nondistracting. It ’ s helpful if the user can customize your applications. The program should be forgiving, and you should not forget that the GUI is only a means to an end. l Developing an event-driven application requires more steps than developing other programs, including creating storyboards, defining objects, and defining the connections between the screens the user will see. l A thread is the flow of execution of one set of program statements. Many applications follow a single thread; using multiple threads of execution is known as multithreading. l You create computer animation by drawing a sequence of images that are shown in rapid succession. Many object-oriented languages contain built-in classes that contain methods you can use to draw geometric figures on the screen. Each component has a horizontal, or x-axis, position as well as a vertical, or y-axis, position on the screen. Key Terms An operating system is the software that you use to run a computer and manage its resources. The DOS prompt is the command line in the DOS operating system. Icons are small pictures on the screen that the user can select with a mouse. An event is an occurrence that generates a message sent to an object. GUI programs are called event-driven or event-based because actions occur in response to user-initiated events such as clicking a mouse button. 362 C H A P T E R 9 Event-Driven Programming with Graphical User Interfaces Copyright 2012 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).

  Sign up to read

  Learn more about book