Model View Controller and Event Driven UI

From CS1635 Spring 2016
Jump to: navigation, search

Slides

slides

Readings

Reading Critiques

Bogdan Kotzev 11:48:21 1/25/2016

In today's reading I learned about how modern computers make applications in which the user is in control as opposed to the program being in control. The windowing system makes this possible. Windows listen for different events such as mouse clicks, mouse movements, keyboard presses, and more. One way to handle those events is through object oriented design where we have an event handling object. In this design we need to worry about communication between objects, which is resolved by parent-notifications model.

Ish Davis 13:23:56 1/25/2016

I thought the reading was very informative and provided a good background on events. However, I thought it seemed a little outdated and wasn't tailored specifically to android. There was a lot of superfluous information that wasn't necessary conceptually, but it was nice to get an in depth background on what was happening.

Nate Patton 14:40:18 1/25/2016

The reading was very interesting. I never thought of how events and windows work together. What is impressive is how the concept of events and window managing are relatively simple concepts, yet they are able to perform complex tasks.

Jonathan Blinn 16:41:25 1/25/2016

Every time I use the computer, I never really gave much attention to the way the layout is set up. The chapter mentions how everything is made up of nested rectangles which seems to have been the case for as long as I remember. Using any other object seems like it would be a giant waste of space and make designing the layouts much more complicated - imagine redesigning everything using nested circles instead, it sounds horrible. In addition to this, handling input is much more complicated than I had thought. Again, the basics of everything have always made sense - you press a key and the computer performs the appropriate action. Similarly, you double click the mouse and the computer executes a program or opens a file. The way this is actually handled behind the scenes is much more complicated and it gets harder when the user clicks and drags the mouse.

Tiffany Martrano 18:19:38 1/25/2016

This reading for the next lecture focused on handling different types of events. It talked about the different windows, and how to use events for users to interact with them. They talked about the different types of classes that are used to interact with events, and how they can benefit the user.

Yijia Cui 18:47:18 1/25/2016

This article addresses the complexity of communication between interactive objects and the input/output system and discusses the main four issues regarding to event handler. The author first introduces the direct-manipulation interfaces, which is when the user is presented with concrete objects on the display and then manipulates those objects using the interactive devices. Then by comparing the difference of past and present models, the author emphasizes the main reason why the complexity of communication increases, which is that the user, not the program, is in control now. The first main part is about Windowing System, which contains two aspects (a set of software services that allow programs to create and organize windows, and window management). Graphical user interfaces are generally organized in trees of windows. The author then characterizes the windows events, including input events, which are generated by user and carry event records, and windowing events, which is to be received by a window in order to do with managing the window itself. Then the author introduces the main event loop and also event dispatching and handling. From this article, I learned lots of basic concepts about events and also knew how the main program for a graphical application works. A great introduction to event driven UI.

Jason Naughton 19:40:23 1/25/2016

This was an neat journey into windowing systems and event-driven functionality. While the technical details seemed a little out-dated the general mechanics were fascinating. I never considered that different vendors would handle windowing and event management so dramatically differently. Similarly, the section on Macintosh's paradigm being limited because it was based on Xerox's Pascal model, and how this more or less evolved, was interesting.

Andrew Lucas 22:59:07 1/25/2016

The author mentions that event driven interfaces tend to cause a complicated combination of switch statements if the events are not handled in an object-oriented manner. My experience corroborates this, and I don't quite see how object oriented programming would allow the programmer to avoid a massive switch statement. Nonetheless the issues regarding communication between different processes and gui objects is certainly relevant to android programming. In particular, the interaction between different application elements creates the need for careful handling of input events.

John Phillips 0:04:43 1/26/2016

I thought the chapter provided an interesting history of how different methods of event passing evolved. However, I don't think the majority of it is relevant to most developers. Most of the time the platform and programming language dictate which method is used, so the developer is limited in their flexibility. For instance, most modern high level languages such as Java all handle event passing the same way (main UI thread that is monitored for you, using object oriented elements). However, this did give me a good understanding of the pros and cons of this verses other ways of doing it.

Joshua Fisher 0:07:55 1/26/2016

While this article is "older", a lot of the principles with event handling can be used in our projects. Mobile applications require a lot of events because of their size and their uses, so making sure that we understand event handling is crucial. I do feel that some of the stuff discussed is hard to translate to a mobile application (the article mainly focuses on Microsoft and Apple), it was still an interesting article. The part I enjoyed the most was looking at the advantages and drawbacks of the different techniques. We will need to also do this when we create mobile applications.

Max Benson 0:27:55 1/26/2016

It was interesting to learn about window managers--one of those things that are so fundamental that you never really think about how they work, or the degree of complexity that they actually have. I liked how the author presented the main difference between older software UI and event driven UI as the difference between the software being in control and the user being in control--this really emphasizes the fact that event driven UIs have to take into account every action the user could take that doesn't comply with the proper way to use the software.

Michael Oles 1:29:59 1/26/2016

At first I was confused but it seems like an event is any action the user can preform to the computer. We can track these events in android as well as more events that are not mentioned because this book is talking about computers like swiping a screen or shaking the device. I did not realize that there was an event loop in every windows based program. It seems like the best thing to do is wait for each event a program a specific action for each event. The term psuedoevents was also new to me, I did not realize that you could make your own events besides the ones given to you to allow objects to interact.

Chris Fineston 1:49:13 1/26/2016

I've always been worried about the interface design challenge part of any app. The group members each have some unique vision in their heads as to what they think the look and feel of the app should be like. The truth is often that it's much harder to fully realize a fully working design, especially one that performs well and intuitively. Indeed, many of the challenges associated with UI building is in the framework itself. What is the standard app way of showing data? When designing a proper app, it's best to review the built in interfaces and consider what would work best in the scenario. For example, in Mac OS X, the system preferences menu is organized in a way that often allows one to make profiles using list views and to modify them in an adjacent pane. This can be seen in the Printers or Network screens. It's interesting how a simple + button indicates that it will create a new something. It almost invites the user to click it and find out.

Luke Kljucaric 1:55:13 1/26/2016

Although very long, I thought this reading was very interesting. It even seems very dated although still very relevant to what we are doing with android and any other even driven language. Events are what drives the connection between the user and the interactive elements of an application and without them, the application fails to do anything that you would want it to do. If we push a button and there is never an event, what is the point of the button? Event driven programming is definitely different than the traditional step by step execution since the event constantly drive specific loops of our main applications to run. Overall, in any interactive interface, events are very important.

Alex LaFroscia 2:10:38 1/26/2016

I had two connections from my work as a web developer that tied into the reading that we did for class about event handling: The first was the mention of OLE and allowing applications to take responsibility for rendering sections of content with each other. I was at a conference for UX engineers over the summer where the keynote speaker spoke at length about this topic, and the fact that the Internet has no way to achieve this goal. The presenter, Chris Tse, spoke about how he envisions a future for the internet where web applications will share a common data format that are associated with particular applications that know how to handle that data, allowing much greater interoperability between application ecosystems what currently have no means for communication. You can check out the company that he is building around this idea at http://www.cardstack.io. The second connection was at the end of the chapter, when they talk about the three main ways for widgets to communicate with each other. The JavaScript framework that I use most closely aligns itself with the Parent Notification Model, where a component communicates only with its parent, and the parent can pass the message to its parent or to its children. Another popular JS framework, React, doesn't really fit into any of the three characteristics described. Instead of communicating directly, through the parent, or by registering callbacks (which is very common in the JS ecosystem), component typically dispatch events that mutate the data store, and then other components react to their data having changed. However, it seems closest to the callback registration method, which is typical of working with JavaScript.

Casey Nispel 3:44:25 1/26/2016

This reading made me realize how much more complicated detecting and handling events and mouse movements are. Previously I would just invoke an event handler and forget about it, not really caring or understanding how it worked, but it’s thought provoking to understand the work that goes in to identifying and dealing with these events. I found it interesting how the main method for interactive windows is so simple because all it does is provide a loop to listen for events. The actual code that deals with dispatching and then acting upon actions of the user is much more complicated, but the flow of the program is not the kind of program I am used to in that the control flow of the code relies solely on the user and their input rather than on computations within the program itself. The application itself cannot just do something whenever it wants to but must wait until an event occurs to handle it and make any changes.

Daniel Hui 4:23:22 1/26/2016

I hadn't realized the difficulty and complexity that goes into event handling. For instance, the depth of algorithms that are needed for event handling such as the window tree considers the positioning of windows/UI elements to handle dispatching of events. On page 119, this section explains how an eventhandler can have thousands of subclasses which sounds very difficult to maintain as programmers. I believe we take for granted how that even the smallest things in relation to technology can be a very deep and complex problem.

Charlotte Chen 4:29:30 1/26/2016

This article provides a very thorough explanation on event handling and callback models. I understand a lot of these concepts generally from my previous computer science classes (especially web design), but this articles strengthened my understanding in event logics between communications of objects and of devices. The beginning section does not immediately ring a bell because it was talking about windows events (instead of events in web and mobile programming that I’m usually familiar in hearing about), but as I was reading it I realized that events are really interactions and form of communications between users and application interface, between applications, objects, etc. In the end, I found the “Communications between Objects” section to be the most useful for this purpose of our class and Android programming. However the general concept of event handling as discussed throughout this chapter provides a good foundational understanding in programming/designing interactive applications.

adp54@pitt.edu 6:53:07 1/26/2016

User-generated events – Keyboard (key press, key release, autorepeat) – Pointer events (mouse move, button press, button release, button click) – Double-click events Exact information varies depending on event type, windowing system Need to consider appropriate context for interpreting the event

Sarah Dubnik 7:47:24 1/26/2016

It was somewhat shocking to read about how complicated something as seemingly simple as a windows interface could be. This isn't something that normally comes to mind when we interact with our technology. It gave me an appreciation for the standard windows-based interfaces we all use today, but it also made me a bit anxious about how difficult our projects might end up being.

George Claghorn 7:54:12 1/26/2016

I come from a web development background, where developers write handlers for user-initiated events, just as in native app development. It's quite interesting to see the evolution of event-based UI implementation and realize how it's come about organically in both web development and native app development. Events are a naturally way to think about user interactions with software.

Clark Nicolas 8:07:29 1/26/2016

Although I thought the reading was a bit dry, it provided valuable insight for the interactions between the user and the android gui.

John Riesenberger 9:31:38 1/26/2016

Our reading today covered window management and event handling. I feel as though a great deal of this was covered in our other reading already, specifically that blurb of "5 ways to wire an event handler". The content was also quite dated, but still revealed some interesting content. I found the bit about event dispatching interesting, as well as the "main loop", and how in the past there were several hardware limitations that would be a limiting factor in how invasive one could be with watching for events. Object oriented event handling was obviously most pertinent to our android development, and most of what was in that section was again covered with a bit more focus in the earlier reading.

David Fioravanti 11:42:11 1/26/2016

I found the discussion about what goes in to simply creating the functionality of the close button interesting. The button needed to have a mouse button down within the button dimensions but also have button released within the button. This could result in many bugs if not done correctly such as releasing the button overtop of the X but not having pressed down within the X. In UI programming many of the components we use are a lot of built in functionality that we may not appreciate. In java we have built in textfields that have so much functionality such as tabbing from one text field to another. It is important as a UI programmer to understand these features and not take them for granted.