Engineering Interfaces I: Layout, Widgets, Events

From CS160 Spring 2014
Jump to: navigation, search


  • Event Handling. Building Interactive Systems. Selections from Chapters 1,3. Olsen. Read through page 66.


Sergio Macias - 2/28/2014 21:44:20

1) The app I will be describing, with respect to the Model-View-Controller architecture, is the default calculator app installed on Galaxy S4. There are multiple buttons on the screen, all corresponding to the buttons of a real world calculator, which is very good for the user in that it makes it easier to create a mental model of the app, and a large box which contains the equation I put in and a result, if called for. Pushing a button, lets say “2”, on the screen will cause the a translation by the controller; it will translate my pressing of the screen (which so happens to be where the image for “2” is at) to saying that the number 2 has been pressed. The model will then receive this action and put a 2 in the equation and will push up to the view which presents me with the button I have pressed, in this case the number 2. I will perceive the number 2 in the white box and see that my action was processed correctly; this will validate my mental model of the app. 2) Event handling in SDK is handled through the use of intents, event listeners, and event handlers. Personally the best way for me to describe how events are handled is through an example. Let’s say I create a new View class object called Fireman. Fireman inherits methods from the View class. Fireman contains several event listeners, which, redundantly put, listen for specific events. Let’s say Fireman contains 2 buttons: “Put out fire” and “call for backup.” Pushing “Put out fire” calls the event listeners for pushing that specific button which then calls the event handler, which is a function written in the Firemen class. I will contrast the SDK method with the Main event and switch method (MES), used in early Macintosh. One similarity is that each event is of a specific type so that way you are able to differentiate between many different events and their corresponding functions. Another similarity is that each event has their own specific functions, i.e. a scrollbar in both event-handling methods will contain “scroll left” and “scroll right”, for example. A difference between the two is that while in the MES method, all “listening” is done by the main event loop which is defined in a single function, the “main” function. In addition all the event actions are described and defined in the “main” function. On the other hand, in SDK, each event has their own class and defines their functions within that class. Other events will then call that event and their respective functions. In addition, because each event is of a specific type, defined outside of each other type, you can find out the list of functions which that event handles (like in Eclipse). While in MES method, you would have to go to the main function and look for that specific event type to see which functions it handles, which would be impossible if you don’t have access to the main function which defines that specific event type in MES. Also it would be annoying to have to look up and down this giant list if you handle many different type of events looking for a specific event type and seeing if handles a specific function.

Andrew Fang - 3/1/2014 11:41:07

A stove top also has a Model-View-Controller architecture. For example, say I want to turn on a stove to start cooking something. My mental model of the stove is formed by the position of the knob next to the stove. If it is in the off position, I know the stove is off. To change the state, say I want to turn the stove to "high heat", I turn the knob. The controller receives this rotation action, and tells the model to make this change. As the model changes its state to "high heat", it automatically notifies the view of this change. In older stoves, the views are the coils on the stove or the fire emitted from the burner. When I see the coils turing red or fire coming out of the burner, I know that a change in state of the stove has been made; that is, the view has told me this information.

Event handling in the Android SDK is taken care of by sensors and listeners. The various hardware sensors such as the touch screen sensor, the accelerometer, and the gyroscope offer data about how the user is interacting with the phone. Inside our applications, we can initialize event listeners to grab data from the sensors. If the event is significant (over a certain threshold), then our listener can fire off a sequence of follow-up events. This is very similar to Olsen's Listener: the generators that he speaks of are the hardware sensors aboard our android devices, and the event listeners are the classes of listeners that we define in our code. He uses a button as an example, and indeed Android buttons have such listeners to catch the "on click" event. However, unlike Olsen's model, we don't need to create private members of generator classes, for these are inherently built into the system.

Ziran Shang - 3/1/2014 21:51:30

Look at the Messages app on iOS. The model holds the information that the user sees, so the model would be a Message object that has attributes such as data, message length, recipient, and time sent. The view presents the model to the user, so the view would draw the app interface and display the message data and timestamp on the screen. The controller handles user actions, so when the user types a message and hits send, the controller would take the typed message and pass it to the appropriate methods to send the message.

Android uses listeners, which is pretty much the listeners model discussed by Olsen. Listeners are very different from the window event tables discussed by Olsen, because listeners wait for events to be performed. You can set several listeners for different event types. On the other hand, when an event occurs, the window event tables model looks through all the windows for the first one with the mouse pointer, and uses that to decide what to do. Android event handling is similar to the delegates model, but delegates can have many different methods to handle different objects of the same type, for example several different buttons with different actions. This is more difficult to do in Android, since there is one listener that is tied to all the buttons, and it could be more complicated to write code in the listener that differentiates between the different desired actions.

Luke Song - 3/2/2014 15:17:45

I often read the required readings for this class with the Adobe Reader app on my phone. This app's internal model is probably quite different from what it presents to the user. For example, the actual information it keeps readily available are the few pages of graphical data that it paints to the screen, position information about the view, and how zoomed in the view is. The information presented to the user by the interface is the graphics on the screen and the ability to scroll and zoom to view different parts of the document. The user's mental model of the information presented is a series of paper pages laid out one after another, seen through a movable window, and when the user moves, the window, this is translated into changes in position and/or zoom that the internal model processes, stores, and updates the view with. However, the gap between the user's mental model and the internal model can be discovered whenever the user quickly scrolls away from the stored position's spatial locality, usually a few pages. Then, the pages take a noticeable time to load, and the illusion is ruined.

I've worked with the Java Swing interface before, and would describe the Android interface to be very similar. The type of event handling used by both are of the event listener variety, and different types of events can be tracked by different listeners or ignored if no listener is instantiated. In Swing there are listeners for things such as key presses, mouse clicks, mouse motion, and window resizing; they are obviously designed for a computer user. The Android, on the other hand, provides listeners for such things as clicks, long clicks, touch, and even multitouch, interactions that are expected to be supported from a touchscreen.

Luke Song - 3/2/2014 15:18:36

I often read the required readings for this class with the Adobe Reader app on my phone. This app's internal model is probably quite different from what it presents to the user. For example, the actual information it keeps readily available are the few pages of graphical data that it paints to the screen, position information about the view, and how zoomed in the view is. The information presented to the user by the interface is the graphics on the screen and the ability to scroll and zoom to view different parts of the document. The user's mental model of the information presented is a series of paper pages laid out one after another, seen through a movable window, and when the user moves, the window, this is translated into changes in position and/or zoom that the internal model processes, stores, and updates the view with. However, the gap between the user's mental model and the internal model can be discovered whenever the user quickly scrolls away from the stored position's spatial locality, usually a few pages. Then, the pages take a noticeable time to load, and the illusion is ruined.

I've worked with the Java Swing interface before, and would describe the Android interface to be very similar. The type of event handling used by both are of the event listener variety, and different types of events can be tracked by different listeners or ignored if no listener is instantiated. In Swing there are listeners for things such as key presses, mouse clicks, mouse motion, and window resizing; they are obviously designed for a computer user. The Android, on the other hand, provides listeners for such things as clicks, long clicks, touch, and even multitouch, interactions that are expected to be supported from a touchscreen.

Myra Haqqi - 3/2/2014 16:49:40

1. In terms of an application of my choice, the Model-View-Controller architecture can be applied to when a user changes the volume on his television set. For example, the model of the volume is delineated as a vertical bar from “min” to “max”, whose length reflects the current volume setting, on the screen of the television whenever the user presses the volume button on his remote. The view draws the image of the volume bar, as well as the position of the min and max, and indicating the current volume. The user perceives that the volume is too low, which is why the user is unable to hear the television. In this case, although the television would currently be at some volume with some faint noise, the user does not hear anything and consequently the user’s mental model varies from the actual model of the volume of the television. There could exist a gulf of evaluation problem if the user does not understand how loud volume max would be and how quiet volume min would be because he is unable to compare these volumes and hear what they would sound like. In order to fix this, there could be numerical values representing the volume. Then, instead of simply depicting the volume bar, there could be numerical values, such as 0 to 100, that show exactly which volume setting the television is currently set to.

The user then clicks the volume button on the remote, pressing the “up” arrow button, in an endeavor to increase the volume. The remote control receives the button-down, button-movement, and button-up events and consequently understands the user wants to increase the volume of the television. The controller calls to the model to make the change of increasing the volume, and the model notifies the view of this change. The view then redraws the volume bar to show that the bar increases in length to reflect that the new volume is now higher. The user perceives this feedback and understands that his action of pressing the volume button has in fact increased the volume. The volume will be raised, allowing the user to hear the television and enjoy his show!

In general, the Model-View-Controller architecture starts with a model of information. The view is what the interface presents to the user about the current status of that information. When changes are made to the information, the view must update itself and reflect those changes through its presentation. When information is presented to the user, the user perceives it and formulates a mental model of the information about the status of the application. This is where the gulf of evaluation can arise, when the user does not properly interpret the presentation and creates a mental model that does not fit with the application in actuality. Based on his mental model, the user will then create a plan of action and will then express his goal to the interface. It is the responsibility of the software to understand what the user expressed and also to translate that’s user’s action into changes in the model. This is when the gulf of execution exists, which transpires when the user knows what he wants to express but is unable to translate it into something that the controller can understand.

Another example of when this occurs when the brightness setting of a computer screen is altered. The model of information is the brightness of the computer screen. The view delineates this to the user by including a horizontal bar that shows the current state of the brightness, and also reflects its position relative to complete darkness and high brightness of the screen. This appears whenever the user presses the brightness key on his keyboard. When the user makes changes to the brightness of the computer screen, then the view must update and redraw itself to show the changing state of the brightness. When this information is presented to the user, the user perceives it and forms a mental model of how he interprets the brightness of the screen. If the user does not understand to what extent the brightness of the screen will change based on the indicator horizontal bar, then there could potentially exist a gulf of evaluation. The user will then, based on his mental model, press the “decrease brightness” key on his keyboard in order to decrease how bright his computer screen is. Had he not known that there existed a “decrease brightness” key, then there would have been a gulf of execution, because the user would know that he wants to decrease the brightness of the screen but he did not know how to translate that into something that the computer would understand. When the user presses the key, the controller registers the key-down, key-movement, and key-up events. Then, the controller translates that action into a change in the brightness of the screen. The model notifies the view and the view redraws the brightness bar, indicating that the brightness is now decreased.

2. Event handling is used in the Android SDK by capturing input events from the specific View object that the user is engaged with. In order to capture how the user interacts with the UI, event listeners are used. An event listener is an interface that is part of the Android View class with a callback method. The event listener interfaces include callback methods depending on the type of interaction that exists between the user and the interface. For example, some callback methods are onClick(), which is called whenever the user touches or focuses on a specified item, and onTouch(), which is called whenever the user does a touch event such as a press, release, or movement gesture on the screen within the bounds of the item. Other callback methods include onLongClick(), onFocusChange(), onKey(), and onCreateContextMenu(). An interface only consists of exactly one of these callback methods. Event listeners are used for listening to how users interact with the interface.

The Android SDK also has event handlers in the event that a designer seeks to create customized components of a View object by extending the View class. The common callbacks used for event handling include onKeyDown(), onKeyUp(), onTrackballEvent(), onTouchEvent(), and onFocusChanged(). There are also ways to handle specific touch events and touch focusing when switching between touch and hitting a directional key or scrolling with the trackball.

In summary, the View class in the Android SDK contains a set of event listeners. These listeners can be registered on View objects. Each event listener also possesses one specific callback method. When a user interacts with the interface, then there is an event queue that contains all of the events, which are handled in order of when they were added to the queue. The view on which the event took place then calls the associated callback method, assuming that the view on which the event occurred has a registered event listener that corresponds to the type of interaction. For example, if the View has an onTouchListener() associated with it and the user touched that View object, then the onTouch() callback method will be called. The callback method then executes the necessary steps for the interaction. Some of the callback methods return boolean values that determine whether or not other event listeners registered by the View need to also handle the event, or if the event should then be disregarded at that point.

An example of how the Android SDK handles events is that if a user clicks on a View object that has a registered onClickListener registered with it, then it will call the callback method onClick(). Then, the onClick() method will execute whatever is needed to transpire when the user clicks on that View.

According to Olsen, the first Event Queue and Type Selection model includes a switch statement on the event type. This is similar to the Android SDK in that it executes different code for each type of event that the user initiates. However, the Android SDK uses specific callback methods for each event listener rather than a single switch statement with many cases.

The Window Event Tables model was built around a tree of windows. When a window is created, a table of events is also set up. The algorithm recursively goes through the tree to search for windows. This is similar to the Android SDK in that only events with an associated event listener that is registered to the View object gets its callback methods invoked, similar to the windows in this model. However, Android SDK uses specific callback methods for each event listener, which differs from this model that has an event table.

The Callback Event Handling model involves the programmer registering event-handling procedure addresses with a descriptive string name. When a window is initialized, then the callback names are looked up to obtain the procedure address for each callback. Then, the procedure address is used as in event tables. This is similar to the Android SDK because the Android SDK has View objects that have registered event listeners, and each event listener has one callback method. Both of these models include callback methods with descriptive string names that specify what they do (e.g. the Android SDK has the onTouch() callback method, which is clearly meant for events when the user touches the interface). However, the Android SDK slightly differs from this model because it has its event listeners registered with View objects, and each event listener has one callback method relevant to the type of input event by the user.

The WindowProc Event Handling model, as described by Olsen, has a switch statement but each switch statement is distinct to a certain type of window, instead of all possible types of windows as described above. This is very similar to the Android SDK, because in the WindowProc Event Handling model, there is just one procedure rather than a table of procedures. This is comparable to how the Android SDK has only one callback method associated with any single event listener that is registered with a View object. However, the Android SDK contrasts with this model because the Android SDK consists of event listeners registered with View objects, while the WindowProc Event Handling model does not have listeners.

Inheritance Event Handling involves a Widget class with a method for each type of input event, and then overriding the desired method. This is very similar to the Android SDK in that Android includes event listeners that all have callback methods. However, the Android SDK designates one single callback method to one type of event listener.

The Object-Oriented Event Loop model designates events to the appropriate window widgets by starting at the root and going to its children. This resembles the Android SDK event handling model because only the specific View object that has a registered event listener invokes its callback method, just as only the appropriate window widget that handles the event gets the designated event. However, the Android SDK differs from this model because it consists of event listeners that each possess a single callback method.

The Listeners model described by Olsen consists of objects that generate events (generators) and objects that are to be notified of events that transpire (listeners). This relates to the Android SDK, because the Android SDK also includes event listeners which listen for user’s interactions with the interface, and then calls the specific callback method associated with that event listener.

The Delegate Event Model described by Olsen contains delegates which incorporate a list of (object, method) pairs. When a delegate is invoked, then the code loops through the list of (object, method) pairs and invokes the method on the object. This differs from the Android SDK, which instead of maintaining a list of (object, method) pairs, has event listeners and callback methods.

Justin Chan - 3/2/2014 16:55:39

The MVC architecture is a widely used software pattern for implementing user interfaces. It is a useful way to cleanly abstract different parts of an application so things don’t get easily cluttered. Take for example the Facebook application. When we observe our newsfeed, we are looking at a view. It really doesn’t take a genius to figure out this out – a view is what we see. But how does the application know what to display? This is where the controller comes in handy. A controller is what handles the “behind the scenes logic” and is able to tell the view what to display. In this instance, the controller queries all of your friends for recent updates, sorts them by time, and then tells the view to display them. Lastly, let’s say you now want to update your status. What happens then? Well, a controller would then notify a model of a state change. Models represent state in the MVC architecture. In this case, an instance of what is probably called the “user” model would be updated with your newly written status. Your “user” model would contain all of your information – your name, your birthday, etc. The model, view, and controller work together to make both your UI and back-end organization smooth endeavors.

Event handling is used in the Android SDK to handle certain events you are listening to. For example, you can wait for someone to click a button, and then you would write an event handle for the application to do something when said action occurs. In general, event handling seeks to respond to a user’s interaction with a View. This is very similar to Olsen’s notion of Callback Event Handling. Each have “individual views” that have predefined event handlers that fire on specific events. This approach allows programmers to “modularize” event handling as opposed to lumping it all into one window. However, Android’s SDK is more complex, as it allows you to assign multiple callbacks in different areas of the same window.

Shana Hu - 3/2/2014 17:32:09

A user has a mental model of where they currently are and where they wish to go. The user's mental model may include a general outline of a map which they remember. More likely, if the user is traveling by foot, she will remember what the street looks like as she travels along it. She uses Google Maps to find directions. As the user turns on the GPS on her phone and then uses text input to choose a destination, the application controller will receive both her current location via GPS and where she wishes to go. The controller will call the model to generate a route from starting point to destination. The controller will also communicate to the model whether the user prefers a certain mode of transit (walking, public transit, car, etc). The model then generates this information and passes it on to the View which generates a map of the route, as well as text directions. The model may match the mental model very well if if the user selects the street-view option.

The Android SDK uses callbacks for event handling suhc as onKeyDown, onTouchEvent, or onFocusChanged. When events are triggered, the callbacks directly call the corresponding code. This is much more direct than having an event loop or event queue to check event types against. It is most similar to what Olsen calls Callback Event Handling, which simplifies the design process and connects procedures with specific events on views. Having direct callbacks is also less confusing than have a recursive algorithm search a window event table.

Zhiyuan Xu - 3/2/2014 20:25:40

One example of an application which uses the Model-View-Controller architecture is a phone's calculator application. Whenever the user selects the calculator application, he or she will see the view, or the graphical user interface of the program. The user can manipulate this interface by inputting a number or an operation. The controller, acting as a mediator between the view and model, must then call the functions from the model to update the internal state of the program. The model, upon this change, will be able to calculate the desired outcome and notify any of the relevant views (in this case, the calculator screen with the correct user inputs) of the outcome via the controller.

In the Android SDK, there are event listeners, event listeners registration and event handlers. The View class offers event listeners that contain callback methods which will be called by the framework when it has been triggered by a touch event. To register a listener, an anonymous inner class can be used, or an activity class can implement the Listener interface. One can also use the xml file to specify the event handler directly. The event handler will then be able to modify the model and change the view according to the change in the model. To change whether a View can be focused, the Android SDK provides functions such as setFocusable() and setFocusableInTouchMode(). Event handling described by Olsen is written with the screen-keyboard-mouse approach in mind. In terms of the windowing system described by Olsen, mouse focus is very similar to a user’s touch on the screen. Key focus also pertains to some views. Although accelerator keys may not be on the keyboard itself, buttons such as the home button or return button may exist on the phone itself. In terms of input events, every event from the Android application will have an event type and location of where the touch event occurred.

Zack Mayeda - 3/2/2014 20:38:06

1. I will use the Venmo mobile payment app to describe the MVC architecture. In this app, the model is the database that stores all Venmo users and payment transactions. The model is all the data backing the application. The view is the actual Venmo mobile app and Venmo website that users see. The view is the way that the user interprets the app's information and interacts with that data. The controller is the code on Venmo's servers that processes all payments and user requests sent from mobile or web. The controller is the main logic of the application that takes instructions from the user interacting with the view and translates that into actions performed on the model. A simple example for Venmo is if a user clicks to see their current balance, the controller would look up transactions associated with that user in the model and calculate their current balance, then send that info back to the view.

2. Mainly event listeners are used for event handling in Android. UI elements are given IDs in XML, and then custom functions can be written and attached to certain events on those elements. An example would be to create a button and use the onClickListener function to set a custom function to handle the event, performing whatever actions that is desired.

The event listener system used by Android is very different from the window event table system described by Olsen. First, unlike desktops, Android isn't based on a windowed interface so the window event table system doesn't apply well to Android. The window event table system requires the user to take the coordinates of the mouse click and traverse the tree of windows, either starting with the frontmost window or rearmost window. Once the correct window is found, the proper event handling function is called. It can be difficult to debug and difficult for designers to understand. The listener system used by Android differs in that all events don't have to go through this recursive search for an event handler each time an event is triggered. Event listeners are attached to specific objects. Additionally, all event don't have to be processed, only events of interest can be inspected. For example, a button could only listen to the click event, ignoring other events that aren't of interest. One more benefit of event listeners is that multiple objects can listen to a single event.

Rico Ardisyah - 3/2/2014 22:22:53

Driving a car can be an application of MVC architecture. The machine inside the car is the model part. It consists a lot of complicated parts that are combined together so the car can move. The steer, throttle and brake pedals, and gear are the view parts. When the users want to turn left or right, they turn the steer; as well as accelerating and decelerating by hitting the pedals. Hence, the action of turning steer and hitting pedals will be translated by controllers to change the behavior of the model.

In android SDK, there is a queue to store events, and it applies First In First Out rule to perform the events. In the reading, event handling in android SDK refers to the Listener Model. There are listeners that are waiting for the specific physical events like mouse-clicks, touches, and keyboard inputs. The listener will trigger required action. One of the similarities of android SDK and the Olsen’s model is both of them are using FIFO in handling several events that is stored in a queue. Also, both of them are easy and efficient to be implemented. In other hand, there are also some differences such as the approach to event handling. Android has an advance approach, while Olsen uses a primitive one. Also, Android does not require the need to trace down the window tree that contains the mouse.

Ian Birnam - 3/2/2014 22:49:53

1) I chose a calculator app as my application.

Model: All numbers and numerical operations that the user can manipulate via combining numbers with operators to get a resulting number. Also the ability to manipulate the output screen by clearing it.

View: The buttons corresponding to clearing the screen the numbers and operations you can perform on the numbers. Also, the output screen of the calculator, since it presents in real time what happens as the user clicks the buttons.

Controller: The mouse clicking on the buttons translates to numbers appearing on the calculator, or operations being applied either to the number(s) or to the screen itself.

2) I chose the listener model to compare the Android SDK to. The listener model has a conflict if two events require the same name for a method, and thus need to use anonymous functions to fix it. Android can simply register its handlers to its listeners, so naming isnt as much of an issue. Similar to the listener model, Android also makes it so that you don't have to consider all events generated.

Seth Anderson - 3/3/2014 0:01:05

1) The default calculator app on the iPhone is a simple example of the Model-View-Controller architecture. The model is that of a simple calculator: adding, subtracting, multiplying, and dividing numbers based on the input numbers given as well as a chosen operator. The view can be seen both in the digital display of the numbers (both inputs and outputs), and the highlighting of the operation buttons that were pressed. Finally, the controller is found in the touch screen use of the buttons on the calculator, where the user inputs digits and operators to preform their corresponding actions. The view and controller are here very closely connected, as numbers are displayed on the upper portion while operators are highlighted on the keys, while the calculations are performed in the model.

2) Event handling in the Android SDK is used in a large number of ways: the most significant of which is an Event Handler category that takes a large number of inputs. It is very similar to the handling of mouse clicks in its use of the onKeyDown and onKeyUp events, which correspond almost exactly to the mouseDown and mouseUp events. However, Android events take in an int called keyCode, which corresponds to the exact event that must occur in the environment, whereas the mouse is connected to other windows in the system.

Ryan Yu - 3/3/2014 1:53:50

1) Essentially, an MVC architecture can be described simply with the following:

The controller is more or less the traffic patrolman of the application, which directs models where to go and figures out which views to load, and at which times to load them. The models consist of the actual data of the application, such as information about the users, and information about other features and components of the application. Finally, the views are exactly what they sound like: they are views that the user sees that represent the data; generally, the controller calls the view and shows them after interacting with (and maybe modifying) the models. All of this can be exemplified below with the application "Snapchat".

In the application "Snapchat", the model-view-controller architecture is prominently used -- for instance, upon one's first opening of the application, he/she is prompted to sign in using Facebook or through alternate means. When the user logs in, the controller tells the application of this, and the site redirects to the home view. Other actions specified by the controller also respond to user events and redirect to other views -- examples of this include clicking the box to go to your snapchat index, and clicking the camera icon to take a picture.

In the snapchats index, clicking a snapchat activates the "show picture" action in the controller, which then modifies the models to indicate that the corresponding picture has been viewed, which then renders the view that corresponds to the picture.

Clicking the camera icon, on the other hand, actives the "take picture" action in the controller, which then calls the "camera" view and displays it to the user. Once the picture has been captured, it is saved somehow in the model, and is distributed to other users via another controller action, the "send picture" action. This action is run by the user via the "select users" view, which lets the user choose which of his/her friends to send the picture to.

2) Android SDK uses event handling with a variety of different methods and functionalities, some of which are encapsulated into things like listeners. For instance, when implementing IPA1 and IPA2, we had to make use of onClickListeners, onTouchListeners. These listeners interpreted events by the user, such as dragging of a finger across the screen, and activated certain functionalities and effects of the application accordingly. For example, if a user touched a button, the application could react via the listener to start a new intent.

This more or less goes along with the "Input Events" model discussed by Olsen. Button events are handled by onClickListeners, move movement is handled with touchListeners. The "other inputs" that Olsen describes correspond pretty closely with custom gestures that a developer could integrate into his/her application.

Michelle Nguyen - 3/3/2014 2:00:44

1. The calculator that comes with Android is a simple application that has a Model-View-Controller architecture. The model is the information that the user is working with, which in this case, would be the math equations and numbers that they have put into the calculator. When there is a change in the model, the view must update accordingly. The view is the calculator display, which shows the user the equation that they want to compute, and possibly the answer of their equation if they have finished writing their equation. The controller receives the button clicks from the user of which key they want to enter next into their equation. The controller then sends to the model the information of what the user wants to add. What the user has pressed is then added to the equation the user is currently working on and computes the answer. This new information is then relayed to the view to display the new equation and its value that has been calculated.

2. The Android SDK uses event handling mostly to respond to interaction to the device's touch screen. Each view that must respond to a user's touch must implement the corresponding event listener, such as an onClickListener which listens for a user's click. The callback method for that listener must also be implemented, which in our case would be an onClick() method. This method will be called when listener sees that the user clicks the button. This goes hand-in-hand with the callback event handling model, where the programmer corresponds the addresses of their callback procedures with a string name. Each window, which we can think of as our view in the Android SDK, is then given properties. These properties include the names of the callbacks for that window. Thus, when a user interacts with a window, it knows all the procedures it must call. Similarly, in our Android SDK, we associate our views with their respective listeners. When a user interacts with the view, it knows exactly what procedure it needs to call. However, in the Android SDK, only one listener can be associated with each view and it can only call the callback procedure associated with that listener. Another event handling model is the WindowProc event handling. Here, there is only one single procedure for each window. This procedure has a switch statement to handle procedures for a certain kind of window. This is similar to the Android SDK because there is a single procedure for each window/view since each view can only have one listener. However, as in the WindowProc event handling, if we wanted to, we can handle multiple handling cases that can forward to other listeners using switch statements in the callback as well. Also, the WindowProc event handling only has procedures that are associated with the particular window type. This is similar to Android, because each view has listeners and callback names that are associated with the view type. For instance, a button has an onClickListener and a seekbar has an setOnSeekBarListener.

Jay Kong - 3/3/2014 2:29:36

A simple HTML/CSS/Javascript website represents the MVP architecture. Raw HTML, including Javascript, is essentially the "model" of a website, as it represents content and information. The CSS is the "view" of the website. Alterations to the CSS can change the way the model is interpreted or "viewed", while maintaining the same content and information represented by the HTML. The "controller" would be the browser because it collects input from the user and forwards it to the HTML/Javascript, updating the state of the model.

In Android, event listeners are objects that receives notifications when events happens. Events typically happen through user input from the physical interface. Objects received by the event listener is then passed onto event handlers which contains logic that handles the events. The event handling model in Android is similar to the callback event handling model that Olsen describes. In Olsen's model, windowing systems have callback procedures mapped to widgets. In the Android model, the application system have event listeners that use event handlers as a callback mechanism. They're similar in the sense that each input event gets mapped to a predefined method that processes the logic of a particular input.

Jimmy Bao - 3/3/2014 2:40:04

1) Using an alarm clock with physical buttons as the interface of my choice, the user can change the information (e.g. the hour, the minutes, the date even) by pressing the corresponding buttons. Say for example the user wants to increment the current time being displayed on his alarm clock by an hour, the user can press the corresponding buttons that will increase the hour. As the controller receives the button push event, it will call the model to make the change. In turn, the model notifies the view of the change and then the time view is changed to reflect the new value.

2) So far for this class, event handling has occurred mostly in form of event listeners, where each View object can have an Event Listener set to it. The Event Listener will listen for any pre-set inputs (e.g. TouchDown, TouchUp, etc.) and execute the predefined commands.

The "Event Queue and Type Selection" model is similar to event handling in the Android SDK in the sense that switch statements are also used for event handling. The example program showed that there are several cases (e.g. MOUSEDOWN, MOUSEUP) that would be triggered based on the event type. This is very similar to what we have been doing for this class. We have set event listeners to certain View objects and once the user interacts with said object, the program records how the user interacted with the program and from there, see which case it matches up with and then execute the commands inside that case. This doesn't differ to the event handling used in the Android SDK too much, but I think it does differ in the sense that you're not setting up event listeners and event handlers for each specific objects in "Event Queue and Type Selection" model. In Android, if we want event handling, we set it to specific View objects (though this might not necessarily be true since my knowledge of Android is still pretty limited; I'm just talking from what I've learned so far in the course). In the code example of the "Event Queue and Type Selection" model, it just gets input from the system as long as some condition is true and then check the input type from there. While it's not totally different to the Android SDK, I think there's still somewhat of a difference.

Andrew Chen - 3/3/2014 2:43:53

1.) Flipboard is a mobile news feed application with its own special features, especially focused on customization and expert curating. The home screen for a user is usually an array of panels, each displaying the first article in a corresponding subscription. This is the view. The actual data, that is, the articles and subscriptions are the model. The user himself is also a model, and we can say that when the user subscribes or changes his subscriptions, he is changing the user model through a controller. This change via the controller is in turn reflected in the view. The panels will display different articles depending on which magazines the user has subscribed to. 2.) The Android SDK uses Callback Event Handling. This involves registering event-handling procedures during initialization. In a way, this is similar to WindowProc Event Handling, because in WindowProc handling, each event is attached to a handling procedure. However, the difference is that in WindowProc, each type of window has its own set of switch statements, in which each case is an event handler. Also, in the case of callback handling, the binding of procedures to events can be done during runtime, while in the case of WindowProc, it must be done at compile time.

Andrea Campos - 3/3/2014 3:00:48

1. The Model-View-Controller architecture can be seen in the example of a calendar application. The model is the information to be manipulated, in this case the dates and their corresponding saved events that the user inputs into the system. The view is the representation of this information, which in this case may be a graphical view of a calendar with certain days colored in to indicate saved events. The controller is the part of the system responsible for translating user inputs into model changes. In this case the controller would consist of the way in which user's text or selection input for certain calendar days, obtained as through an input form, is added to the model, or if the user deletes certain events, the way in which data is removed from the model. The controller changes the model which subsequently changes the view, and so the graphical calendar view would change to reflect the user's actions.

2. Event handling in the Android SDK is managed through event listeners, which are basically classes that implement an interface for creating methods that act on those events. Essentially the Android SDK uses the same sort of listener model described in the Olsen reading. However, much of the finer details of an event are hidden from the programmer with the Android SDK since it is used with Java, so that one does not have to loop events through various listeners or deal with virtual table pointers as one would may have to do in other languages. Also, listeners can be added at any time and listen for only certain events of interest for particular widgets in Android. This is quite unlike earlier event handling models which would force events through one central loop and compare them to all possible event handling procedures in a switch statement.

Nahush Bhanage - 3/3/2014 4:29:43

1) The model-view-controller architecture can be easily described using an example of a simple car radio. In this case, the model would consist of many integer variables that define the current state of the system. For e.g. Station to indicate the current radio station, Vol to denote the current volume, MaxVol to indicate the maximum possible volume, MaxFreq and MinFreq to maintain maximum and minimum frequencies respectively and so on and so forth. Let us consider a simple use-case, in which the current radio station is 2 and the user wants to switch to station 4. Initially, the view shows "station 2" on the radio display. The user perceives this and presses the button corresponding to station 4. Accordingly, the controller receives a button event. Understanding that the user wants to switch to station 4, the controller instructs the model to modify its state internally (i.e. change Station = 2 to Station = 4) and tune to station 4's frequency. On implementing this change, the model notifies the view that the radio station has been switched. The view then writes "Station 4" on the display in order to communicate to the user that the change has been implemented.

2) The Android SDK handles user input events through event listeners. User interaction with a View object (buttons, checkbox etc) generates events. These events are caught by the Android framework, which in turn calls respective callback functions. The core logic that needs to be executed on user interaction is coded in these callback functions. For example, when the user clicks on a button, its OnClick() method will be called. This is achieved with the help of event listeners, which are public interfaces with callbacks. I would like to draw a comparison between Android's event listening model and the Event Queue and Type Selection model (used in early Mac and Windows applications) described by Olsen. A major similarity between these models is that both are based on the model-view-controller architecture. However, there are certain strikingly significant differences in how these models work. Event Queue and Type Selection requires the programmer to continuously poll the OS/windowing framework to check if there are any new events in the event queue. This is achieved by maintaining an event loop (called message pump in Windows) with a switch statement to handle different event types in the application program. On the other hand, Android's listening model implements event callbacks, thus freeing the programmer from the responsibility of checking for newly generated events. The framework automatically calls the relevant callback method, while the programmer just needs to handle code binding in this method.

Tien Chang - 3/3/2014 8:02:37

1) An example of Model-View-Controller is a calculator. A user would have a preconceived notion of what a Model calculator would do. The application of a calculator should have a Model that is similar to what a user would need or want. The calculator application should contain a View to display inputs and outputs to the user. This feedback helps a user to determine whether he or she is inputting correct values and functions and what the outputs are. The Controller must understand what the user is requiring of the calculator; for example, the calculator must determine if it follows the PEMDAS convention. If the Model does not, then a user could input incorrectly and the Controller would misunderstand the user's input.

2) In Android SDK, event handling is used such that each event has an action, or a Listener. The windowing system will take this event and any other inputs to perform an action. The view and model will be updated to reflect the event and action. This is similar to the Inheritance Event Handling model discussed by Olsen. Unlike Event Queue, Android SDK does not group all possible events with a single loop and switch statement to determine which action to perform. As stated earlier, each event has its own action.

Anju Thomas - 3/3/2014 9:19:43

1) Describe the Model-View-Controller architecture using an application of your choice.

The model view controller paradigm represents how the information is presented and user interaction with it. Divided into 3 main section, the paradigm describes a model as the representation of information to be used. It includes the data of the application, the functions implemented, and the main logic used in the program. Its primary purpose is to inform the controller and the view of a change in state taken place. This helps the other elements of the model view controller to refresh the view and allows the controller to update the set of commands. An application view is simply the display presented to give the user feedback on the status change or currrent status. The main role of a controller is to send model instructions to refresh the system’s current status. It can also instruct the view on making necessary changes to help the user detect the current status.

An example of an application that uses Model View Controller is netlims. NetRx is an web application that allows pharmacies and stores to create online orders and bills for the customer while updating the details of patients, items and manufacturers in the table. It uses the Model View Controller paradigm where the Model represents how the designer can add classes to represent a model. For instance, ,a various models where used throughout the application, such as an Item class that represents the various item details such as cost, type of item and date purchased.

The application especially used various views such as images in the drawable folder of the res directory. It also used layouts and XML files which allowed the programmer to make create a template of the user interface that will be presented to the user. The view can be created using graphics by directly manipulating and adding widgets or by typing in the xml code for it. For instance, the application used home.xml and item page’s xml layout to represent the home page and the item selection page presented to the user when using the application.

The controller is the main folder of the application represented by the contents of the src folder. It allows the user to manipulate certain events. For an example, the applications triggers an onclicklistener which listens for user click on a button and redirects to another page or allows another mental mechanism. The controller then gives the view and the model section of the application instructions on updating them to represent the current state. The controller is the main section that adds functionality to the program .

2. How is event handling used in the Android SDK? Discuss similarities and differences to at least one of the event handling models discussed by Olsen.

Events are usually handled in android sdk through the use of listeners which sense a certain user action and responds. For instance when an event is to be carried out, such as a specific user action - an example includes loggin in to a facebook on android. In this case, after the user has typed in necessary details into the text portion of the application, they are then expected to click submit. Clicking the submit button will trigger an onClickListener that has sensed user action. The on click listener will then perform a certain action depending on the user intention - for instance redirecting to your personal profile in facebook. Once you have logged in, the event triggered also gives the user necessary feedback by displaying a prompt such as “You have successfully logged in” to update the user of their current status and that the event has been triggered. This helps the user keep track with the progress of certain events generated by their actions.

There are various similarities and differences to the event handling methods presented by Olsen. For instance, various differences exist in the Event queue model, where it presents a straightforward concept and its performance can depend on specific resources available on the device. Despite the differences the event queue also presents some similarities such as an effective conceptual model for handling events. It is also presents an easily learned model for the programmer as it matches their idea on what should happen when events are triggered.

An example includes the delegate model which includes similarities such as preventing big methods that handle events while looping over various methods with an event is triggered. It also prompts an object to respond to only the event that appeals to the object enabling user freedom. A difference includes that the delegate model prevents implementations from colliding while the other allows two different generators to use the same interface.

Another model that has similarities and differences to Olsen’s includes Android. It differs in the use of OOPS object oriented model. It also consists of different use patterns. For instance it is more common in current applications. Another difference is that it describes a more hierarchical trend. Possible similarities in the event handling model once again includes a good conceptual model for the programmer. The designer easily understand the control flow of the program. Along with the model the user can also perform various action by simply triggering one event. This is possible through the use of binding many actions to one event.

Albert Luo - 3/3/2014 10:13:37

An example of the Model-View-Controller architecture would be a simple web application of a movie database. Through the web application, the user can add movies, edit movie information, and delete movies. These functionalities make up the model, which is basically the data and the rules governing the data. The View is the application itself, which presents an interface between the model and the user. Now, the controller is the SQL or PHP or whatever other method is used by the view to send messages to the model. The controller controls all communication between the model and the view.

There are several event handlers in Android SDK. There is touch input, key input, and audio input. How it handles all the input is very similar to the Inheritance Event handling used in the Smalltalk-90 system, that it uses objects as the basis for event handling. The difference is that each handler is an object, rather that an interface that all objects implement.

Armando Mota - 3/3/2014 10:43:08

1) I will use the iPhone weather app AccuWeather as my application of choice to help explain the model-view-controller architecture. The model, which is the underlying information that is being presented and modified, is usually the weather data, like temperature, wind speed, whether it’s day or night, low, high, etc. When you first open the app it presents you with a view, or presentation, of the model - you see a night sky graphic to let you know it’s night time, it shows the temperature in fahrenheit and the “real feel”, it lets you know what time it was last updated, and tells you how windy it is. I, the user, interpret these graphics and numbers/words as the weather information I was seeking - there is a low gulf of evaluation because the night sky looks exactly as the natural night sky does, and printed numbers are a ubiquitous and common representation of temperature. If I would like to see a daily forecast for the next 7-10 days, I express a command to the app which it must then translate - I press the screen above the on-screen button “daily” and the controller must translate that into a command it gives to the model to change its information. The model changes its information to the forecast information for the next 7-10 days, the view is updated and the new model data is represented, and I, the user, can see the result of my request.

2) Android uses events to store information about the ways in which a user has interacted with the interface (touch events, their location, etc…), and these events are all stored in a first-in-first-out priority queue. Thus, these events are dealt with in the appropriate order by, for example, passing the event to the appropriate View, which then uses its listener and event handler to complete the process. This methodology involves setting a listener and registering the listener with an event handler, which classes like View have. Classes like View also have a callback method, which allows them to “show” the user it has been augmented/touched.

    Contrasting this with the old Window Event Tables model, the WET model is a bit less-specific with its handling.  In this model, the windowing system maintains a tree of of windows, 	each connected to its child windows through pointers, and when a touch event comes in, the windowing system looks through the tree to find the highest priority (highest depth in the tree) window that encapsulates the pixels of the mouse position.  Each one of these windows has a list of pointers pointing to procedures based on input type, which it would then execute.  Both models have a framework (that is not part of a view or window) that delegates events to their correct views/windows, however the Android SDK keeps a queue of these and the WET framework does not, it just processes them immediately upon reception.  The Android SDK model also allows views to be arranged in ViewGroups, which gives a group of views the ability to “intercept”an event at the topmost parent level first, and then decide what to do with it.  The WET model does not allow for this kind of intermediate decision making.  Besides that, both models do 

Sol Park - 3/3/2014 11:23:37

1. I believe google map is one of the Model-View-Controller architecture application. There is a model showing user's current location. When user speaks destination's address, controller takes the input and changes from user's current location to destination. When the location is changed, view displays the destination with graphical map. With this Model-View-Controller, user can choose to navigate to the destination.

2. A listener of an object is event handling used in the Android SDK. It listens an incoming event from an event from another object. An object could be a widget. For a widget, if a status receives a user input, the object sends an event to the target object. If an object receives an event, its listener listens the event. Most of events handling is not a interrupter. The events are passed whenever the user gave an input to a widget. However, some events work as an interrupter, forcing another ongoing process to stop. For example, if there is a battery warning sent from the mobile operating system, some of work in lower priority can be interrupted.

Conan Cai - 3/3/2014 13:10:16

The model-view-controller separates the functions of an application into 3 distinct groups. Using a car as an example, the model-view-controller applies to the 3 functional parts of a car: speedometer, accelerator pedal and engine. For a car, the speedometer acts as the view. It serves as a display to communicate the car's current speed back to the user. Using the accelerator as a controller, the user is able to communicate the intention to speed up - in this case by pushing down on the pedal. The engine of the car is the model. It receives the input from the accelerator (controller) and changes the state of the car by speeding up. This change in state is then sent back to the speedometer (view) and the user is informed that there was a change in state - the car sped up.

In the Andoid SDK, event handling is accomplished through "On___" methods. The functionality of the Android app is defined through a series of event handling methods that tells the app what do do under a specific case or event. It uses input handing. When a user creates an input, Android determines the type of input and then runs the appropriate method for that input eg,"OnClick", "OnKey", "On Touch"...Android knows exactly which method to run based on what type of input. In a windowing system, when the input is received, the position of the input is determined to figure out which window/widget to send the input to. Here there is a hierarchy of windows that much be searched for to find the appropriate window to send the event to. In the Android handler, events are sent directly to methods that handle a specific type of event - like directly mapping an input to a function. The window system means that the same input could be directed to multiple windows depending on the current view while the Android system would send the same input to the same function regardless of the current view. Both categorize inputs (one by location, one by type) to determine which window/function the event gets passed on to.

Peter Wysinski - 3/3/2014 13:30:21

The Model-View-Controller architecture, “divides a given software application into three interconnected parts, so as to separate internal representations of information from the ways that information is presented to or accepted from the user.” Let’s break down this condensed statement down by describing the MVC paradigm using the Google Voice app for Android. The app in-conjunction with the Android OS act as the controller, monitoring for user touch input. Once a user taps a message and replies to a text message the controller registers this actions and passes it to the model which executes the command by sending the message to the recipient. Once the send action is performed the view is notified of said action and the message dialog is updated with the message the user has just sent. This serves as confirmation for the user that the action he had performed was carried out successfully. Event handling is used in the Android SDK to to deal with actions ranging from touch input to device orientation. In IPA2 I used callback event handling to trigger changes of the canvas image when a button was pressed. As described by Olsen I had to, “register any event-handling procedure … with a descriptive string name.” However, unlike described by Olsen in his Windows example, the Android OS does not use a a registry as it is nix based. Furthermore, if no callback exists for a button a verbose error does not appear — the button simply does not do anything. Android also uses inheritance event handling to deal with touch input. All Android apps share the common interface of handling touch events and we as developers do not need to know about the method’s implementation. Default method behavior is used in ‘onTouchEvent()’ to figure out when a user is pressing a screen and where his finger is positioned. Unlike what’s described in Olsen’s example, Android does not use processMouseEvent() but rather it uses onTouchEvent() due to the different means of interaction among the Windows and Android operating systems.

Doug Cook - 3/3/2014 13:49:12

The Model-View-Controller architecture is implemented in many modern applications and can be explained through examples like Apple’s Mail desktop app. There are three components to the architecture. The model contains the actual data and describes its organization. In Mail, the data consists of the user’s emails and any folder structures they’ve used to sort them. The view is the visual layout displayed to the user – the list of emails, document display, and action buttons in Mail’s app window. The last piece of the MVC architecture is the controller, which takes input from the user as they interact with the view and translates it into changes in the model. For example, when the user selects the “forward” action while viewing an email, Mail’s controller generates a new copy of that email and updates the model, and then the cycle continues as the View updates to show that new email.

The Android SDK relies heavily on events and employs the listener-based approach described by Olsen. Developers can leverage the different types of events by applying event listeners during the initialization of their objects. Android Activities, for example, are a type of object that can receive events. In this way, Android shares similarities to the Java object-oriented system described by Olsen as well as the approach of using listeners. A slight difference from the approaches described in the text arises due to Android’s complexity. The many different types of events all have different characteristics and properties – and although they implement a common interface, some knowledge of their nature is needed to use events successfully. For example, to successfully register a touch event listener, the developer must also implement an onClick() callback method in their class because the listener will expect it. Thankfully the Android SDK alerts developers of these subtleties for the most part.

Cory McDowell - 3/3/2014 14:10:27

I’ll describe the Model-View-Controller architecture using Snapchat. Snapchat most likely has three models: users, snaps, and friendships. Snapchat’s main view is the screen where users view their snapchats. When a user wants to send a snap, he or she takes a picture, and selects who to send it to. This information is inputted in the view. Then, the controller will create a new entry in the snap model, and will map that snap from senders to receivers. Then, on the receiver’s end, the controller will query the database models for snaps sent to the user, and the view will display the results.

In Android, event handling is taken care of by the views present on an application’s screen. Each view has its own onTouchEvent, onSelect, onDraw, or onClick methods. The developer decides what the application will do when one of these events occur. This is similar to the Windowing System’s top-down strategy. In windows, when an event happens on the screen, the OS starts at the top and goes down until a window responds to said action. In android, when an event happens, android finds which view was on top of where the touch happened, and then it takes the corresponding action. Android is different, as it can instantly find the desired view that is being operated on, as android’s mobile OS does not have windows or layers to its application.

Shaina Krevat - 3/3/2014 14:13:23

1. The model is the information to be manipulated by the user interface. On the iTunes or music app on a smartphone, this is made up of the playlist, song, volume, etc. The view (which represents the information to the user for feedback) is made up of various text (such as the song title, the playlist title, etc.), a slide bar (for the volume), as well as the song the user is hearing and the volume of said song. The controller is made up of the various buttons, such as the next or previous song, the slider that can be changed, and the play/pause button, which is how the user controls/changes the model.

2. Event handling in Android is closest to the Inheritance Event Handling Model described by Olsen, where each object has various OnClickListeners, OnResume, etc. to be programmed in order to decide how each view (Olsen calls each a widget) responds to various events. The main difference is that all of the widgets do not have the same event handlers as suggested in the reading. New listeners are added based on the functionality of the view. For example, an activity (which acts how a window normally would) would have OnCreate or OnResume when a button, which doesn’t respond to those events, doesn’t.

Charles Park - 3/3/2014 14:21:22

The Model-View-Controller is a chi architecture that includes three components. There is the model which the information that is to be manipulated. This information then is presented in the view (the state of the model as well as updates in response to the model’s changes) and finally the controller takes in the user’s expression and translates that into the model for changes. For example if I use a music app, the view will be what I see as well as all the options that I will be able to choose. If I want to listen to the next song in queue, I will press the next button in the view. Then the controller will take that request and update the model in which it will change the current song to the next song. Once the model is changed, it will return the newest status which will then be available to me, the user, in the view.

Event handling in Android SDK is done by listeners which pick up on events created by a numerous amounts of ways it is produced, for instance buttons or inputs, and acts accordingly (implemented through interfaces). This is similar to the inheritance event handling mentioned by Olsen where each class has a set of event methods that specifically handle the associated behavior. There are some differences, however, in that they are simply methods that are called to invoke a particular behavior rather than an event + listener. In addition to this comparison, Android event handling’s events are not grouped together via a single loop that has a switch statement like the event queue. Instead, each case has an associated method to call. However, both do differentiate how to handle different events via difference parameters.

Kaleong Kong - 3/3/2014 14:34:40

I am trying to describe Model-View-Controller architecture using a car. My model contains the speed: max:200 mile/hr, current: 60 mile/hr, min: 0 mile/hr The View is a dashboard that indicates current speed to the driver. The controller is the pedal and brake. When the driver wants to speed up, he presses on the pedal (Express). The controller which is the pedal feels the pressure produced by the press (Translate). Then it signal the model which is an engine to increase the current speed. The pointer on the dashboard increases its value. Then the driver sees the changes on the dashboard and knows that the car is accelerating.

In android, event handler is triggered by an event listener. When an event listener like OnClickListener notice a corresponding event is happened, the listener will pass the event to the handler and let the handler interact with this event. Similarity: Olsen’s event handler and android event handler are very similar. They both need to wait for an event to pass into the method in order to take action. They both need a listener to tell them whether the user took an action. Difference: Then event handler that Olsen talking about is for window and the interaction takes place between a user and the monitor and mouse. However, android event handler usually takes place between a user and a touchscreen. Since Olsen’s event handler and android event handler are implemented on different platform. There are a lot handler method that they don’t have in common. For example, Android doesn’t have WindowProc Event Handling.

Kevin Johnson - 3/3/2014 14:45:37

For a Windows file system, the Model is the actual structure of data on the hard drive. The View represents that data visually as "files" and "folders". The Controller is usually Windows Explorer, which provides click functionality to directly access the contents of a file or folder, and right-click functionality to change its properties or access it in unusual ways.

The Android SDK follows the model used by Java, using listeners, focus elements, and a top-down approach to direct events where they need to go. Unlike the original Mac system, it uses virtual tables to direct input efficiently.

Bryan Sieber - 3/3/2014 14:58:03

1. The Model-View-Controller architecture is used on every application. It is one of the most basic and essential parts to interactive systems. The user is presented with the View, the user then perceives the presentation and forms a mental model of how the application works. After forming a mental model the user then expresses an action for a certain outcome on the Controller, the Controller then attempts to translate the expression into something that underlying application could understand and implement. This changed expression is then passed to the Model. The Model makes sense of the expression and if the user and application have the same Model, what the user desired to happen will happen. To notify the user of the changes, the Model informs the View of the changes and it redraws itself with the new outcome. This can be clearly seen through most popular applications nowadays. One such example is Flappy Bird. At the Title screen we are presented with the Title, and then three buttons that we can push: “[Rate]”, “[Play Button]”, and “[Ranking System].” When a user pushes the [Ranking System] button, the application takes the touch event and the desired leaderboards are presented to the user. Pressing the [Done] button in the top right corner, takes you back to the Title screen. Pressing [Play] starts the game. The game’s Start screen now gives a brief “tutorial” of how the game is played: “Tap.” After initially tapping, and perhaps dying, a user formulates a model of how the application works. After each tap the Controller receives the tap input, and informs the Model that the bird must flap up. The Model then informs the View to be redrawn to show the changes with the Model. The user may then again tap, and the cycle continues.

2. Within the Android SDK input events are handled in many different ways. Events are captured within a specific View object. Within many of the View classes you will find methods useful for UI handling, such as public callback methods. In order to intercept certain events you must extend specific classes and override the methods (for example the Button View and the onTouchEvent()). This is one approach that can be become tedious at times; fortunately, the View class allows nested interfaces, also known as event listeners. One of the event-handling models Olsen mentioned was the Callback Event Handling. Unlike in Android, where the programmer doesn't need to register the event procedures with unique descriptive names, in callback handling the programmer must do this. In Android most of the events are pre-registered with an Event class that can come back as multiple different Event types. In callback-handling, windows contain properties which contain names of procedures to call. The names are looked up in a registry and the procedure to be done is passed to the system. Just like in Android programming each View, or window, would only have to pay attention to the properties that is included in the code, one View doesn’t need to worry about all the other View’s and what events they need, this is the same for call-back event handling.

Nicholas Dueber - 3/3/2014 15:14:07

I will look at a weather application to describe the Model-View-Controller architecture. First of all, the model is all of the weather information and the location of the weather. I am presented with a view of the current temperature of three locations and there current levels of precipitation if any. If I want to add a specific location, I can tap on a text box and input a zip code, this is a controller. When I select this new location, the model is modified. I am now presented with additional information based on my input. The view has changed a result to reflect my controller manipulation.

In Android SDK, there are event listeners. So you can choose what type of events can happen and how you would like to respond to those events. There is an on click listener for buttons in Android SDK, we will look at the similarities and differences to the top-down strategy. A difference is that for Android, the on click listener listens directly to the interface. where as for the top-down strategy, it will go through multiple steps to figure out what it clicked and where it will go from there. For example it has to figure out the location of the mouse and then it looks to see what window it is clicking on, and so on and so forth. for the android. there is only one window, so you only need to worry about where the click takes place on the screen and what the user interacts with. Similarly, to the top-down strategy, once the interface recognizes what was interacted with on the screen, then the listener responds and the listener manipulates the model if need be, and hence the view may be changed as a result.

Gregory Quan - 3/3/2014 15:17:12

The MVC architecture divides a program into three components. The model consists of application data and logic, the view is a representation of the data for the user, and the controller takes input from the user and interprets it for the view or model. As an example, consider a simple paint application such as MS Paint. The drawing canvas is a grid of pixels with color values for each coordinate, and these values are stored in the model as a three dimensional array of integers representing the red, green, and blue intensities at each pixel coordinate of the canvas. The view is the canvas, which shows the pixels being drawn in a format familiar to the user: a bitmap image. The controller takes mouse and/or keyboard input from the user, such as a brush stroke (mouse drag event), and interprets this input for the view and model. The view changes pixel values corresponding to the location of the brush stroke, and the array of integer pixel values is simultaneously updated in the model.

Event handling in Android is implemented with event listeners. Activities in Android implement various listener interfaces such as onClickListener. The onClick event handler is passed an instance of the View that triggered the event. This behavior is similar to the discussion about listeners on page 59-60.

Since Android devices do not typically use mouse and keyboard input devices, Android must handle slightly different types of events than those associated with mouse input, such as “onLongClick” and “onTouch.” In addition, Android devices must handle multiple simultaneous touch inputs by having an integer index value for each input. Traditional mouse/keyboard interfaces are not usually equipped to handle multiple pointer inputs.

Sijia Li - 3/3/2014 15:20:39

1. According to Olsen's Model-View-Controller architecture, the interactions between users and computer/device, both the input from users and the output to users, are mainly displayed on a view for users. For example, Microsoft's Windows operating systems take advantages of the Window Views to present the interactions between the user and the computer.

2. The Android SDK uses Listeners to address Event handlings. For example, Touch Event is handled by OnTouch Listeners. The similarity is that the design of OnTouchListeners does follow from the general implementations of "Event Listeners" (Page 59), which is easy for users to use and for developers to implement. The difference is that Event Handlings in Android SDK are not in the style of the "top-down" approach, which is not ideal for Android, since Android's main feature is the touch events, which are handled by its OnTouch Listeners. The "Top-Down" approach would be too slow and too consuming for Android, since it requires a certain amount of processing power.

Jeffrey DeFond - 3/3/2014 15:33:14

1. Consider an app that will allow one to edit text documents. There is the model, which would likely be a file with the text information. The view would be text edit box with the text in question represented. The controller would be some form of keyboard which would the be used to edit the model file, which would then alter the view.

2. Event handling in the Android SDK is handled using the general event listening that java follows. It relies on classes having required implemented methods as well as class hierarchies. The xml formatting is where the standard java event/listener makes a little less sense.

Emily Sheng - 3/3/2014 15:35:05

My application of choice is the weather app on iphones. The view is the list of dates and weathers of a certain city that is displayed when the user first enters the app. Browsing different weathers for different cities requires switching between different views. When the user first opens the app, the most current weather forecast for a city is loaded into the view. When the user hits "refresh," the controller register it and communicate to the model to update the weather and the model will pass in the new weather values to the view to display. When the user selects a new city's weather to display, the controller will tell the model to create a new entry for the city, and the model will fill in the city's values and pass them to the view to display.

The Android SDK has event listeners to listen to different input events (ex: button, keyboard, touch etc). It is kind of similar to inheritance event handling in that different types of widgets often need to handle the same type of input (touch, keyboard), so different widgets will often be able to extend the same kind of listener. The Android SDK is not very different from the inheritance event handling, as that is how event handling is used in Android SDK.

Daphne Hsu - 3/3/2014 15:39:35

The Model-View-Controller architecture can be seen in Facebook Chat. The model is the messages from one person to another - the data. The controller sends messages to each other, adding new messages. It accepts input (text), and outputs it to the view or model. The view shows each new message, in which either user can react to.

Android has event handlers such as buttons, listeners, etc. Android waits for an event to happen, such as pressing a button, touching the interface, or swiping down, then triggers the appropriate response based on the action and other variables at the time of the action. The difference between listeners and Olsen's models is that listeners are attached to the objects that trigger them. Both models allow for smooth event handling by avoiding big methods that have all the logic. They have similar methods, such as onClick, mouseDown, mouseUp, and onTouch.

Jeffrey Butterfield - 3/3/2014 15:46:13

1. Flow is a popular mobile game for Android, iOS, and Windows Phone. Each round of the game starts with a square grid of some size that contains some number of colored chip pairs that are distributed within the cells of the grid. The chips are not movable, and the user’s objective is to connect each like-colored chip pair with a path, such that a) all pairs of chips are connected by a path that does not overlap with any other paths, and b) all cells of the grid either contain part of a path or an original colored chip. Flow’s simple premise allows for a clear understanding of the Model-View-Controller architecture.

In this example, the Model part of the Model-View-Controller is the underlying implementation of the application, essentially how the state of the game is structured, maintained, and understood by the machine. As gaining insight into this structure requires access to the game’s source code, there is no way for consumer’s to assess the program’s model directly. To make up a possible example, the model might be a two dimensional array of integers, where 0 represents blank, 1 represents red, 2 represents blue, and so on. The program might have functions that, should appropriate input events occur, update integer values in the cells of the array to reflect the current state. Because the game congratulates the user immediately upon finding the winning path arrangement, each change to the array might involve a function that checks if the new arrangement is a winner. Again, this proposed model is completely hypothetical. Not knowing the details of the implementation only hurts the user when the disparity between his understanding of the model and the actual model causes an unexpected result (i.e. when a “Gulf of Evaluation” forms).

Flow’s View is the colorful representation of a boardgame-like grid displayed on the screen. Each chip is a colored circle, and each piece of path is either a vertical or horizontal colored rectangle. The View informs the user of the status of the game and is helpful for visualizing possible moves/choices that will win.

Finally, Flow’s Controller translates user inputs into appropriate modifications to the state of the game, as maintained by the game’s underlying Model. The game allows the user to change the state of the board by swiping, on a touch screen, from a colored square to a non-chip square. The Controller facilitates the touch input, recognizing the coordinates of the start and current location of the path, and calls the aforementioned functions in the Model for updating the “two-dimensional array” so that the new state can be checked for victory and, finally, the View can be updated to reflect the change.

2. Android uses an “event listener” paradigm to allow programmers to handle events, some of which are set off by user input. Android includes a fundamental class called the View, “a rectangular area on the screen…responsible for drawing and event handling” (Android API Level 1). Oftentimes, the class of an Android UI element (which inherit from a view) will implement certain methods that take a “listener” as an argument (e.g. onClickEvent( OnClickListener lstnr)). This method associates the listener with this UI element, meaning that when an event that the listener is listening for occurs and that event is properly associated with the UI element (e.g., a click happens and the coordinates of the click occur within the View of the UI element), the function that denotes how to respond to the event is called.

This system is essentially the same as the Listeners section in the reading that refers to Java and Swing elements. It is drastically different from the programmer-implemented Event Queue, described in the readings as the requiring of programmers to create an “event loop” that goes through all important events (and the conditions that determine if they are noteworthy, like the coordinates of a click) and to respond accordingly. While this method is very straightforward, it puts an undue burden on the programmer to create something over and over again that she will always need.

Erik Bartlett - 3/3/2014 15:49:04

1) The MVC architecture is very apparent in the iOS Photos application. The data model the user gets is that all of their photographs are in “albums” (essentially collections based on some grouping) for them to flip through. Each album has its own spot in the table. This is represented in the view by thumbnails of the most recent photos included in each album. The user then selects to look at an album by pressing on its table cell, telling the controller that this is the one that the user wants to see. The controller then adapts the model by giving it a specific album to show. The model is then changed to be individual pictures instead of albums, and the model then tells the view how to update itself and display each of the photos in the album in a tiled table display the user can scroll through. The user then selects a photo, notifying the controller of its selection. The controller then alerts the model of the selection, changing it to represent a full and singular image. The model then notifies the view to update itself, and the view then displays the photo to the user.

2) Android uses the Listener Model for event handling, which is an adaptation of the inheritance model. Callback event handling and the listener model are quite similar. A listener for a given input is, in essence, a callback function. It is the method that should be called given a particular input. The main difference is that the listener model allows for multiple objects/widgets/windows to listen for a given event and react to it, while the callback model only allows for a 1 to 1 mapping of event to method. While this 1-to-1 mapping is helpful for speed (as you don’t have to iterate through all of the potential listeners), it can create more dependencies in code if the specific event is responsible for causing changes in multiple objects/models. The listener model also makes it easier to ensure the bubbling up of events, as adding a listener to a higher part of the window tree ensures it will be called, where as in the callback, the callback would have to reference the different methods it wishes to call.

Sol Han - 3/3/2014 15:54:32

The Model-View-Controller architecture underlies human-computer interaction. It consists of three components: the model (which stores representative data), the view (which displays this data to the user), and the controller (which lets the user manipulate the data). A good interface will minimize the gulf of evaluation (disparity between the actual model and mental model as a result of a poor view) and the gulf of execution (disparity between actual action and intended action as a result of a poor controller).

One example of an app that demonstrates the MVC architecture is Shortyz, a crossword puzzle application. For a given puzzle, the model stores data about each cell (the inputted letter, the correct letter, whether I used a hint for that cell, etc.). I can perceive the puzzle in different ways by switching between two views: The first is the standard view (displays all cells), which lets me easily visualize my progress and see where different items overlap; the second is a list view (displays a list of items in numerical order), which helps me more easily find a particular item. The controller involves use of the keyboard to enter letters into cells and the touch screen to select a particular cell or item to edit.

Event handling in Android SDK can be visualized by using the MVC architecture as a reference. The view provides a windowing system, which displays/updates information from the model and dispatches events to the widgets. The controller takes in input events, which can be characterized by the event type, location of where the event occurred, and modifier button infromation. Another example of event handling models discussed by Olsen is that of the early Macintosh, where the event/code binding was achieved by writing a switch statement that determined the event type. The simplicity of this mechanism makes it a good choice for smaller applications with limited speed and space, compared to the more complex mechanism used by Android SDK. This is in contrast to Android SDK's event handling system, which is more modular and utilizes tools like listeners to listen for events and act accordingly.

Dalton Stout - 3/3/2014 16:00:06

The Model-View-Controller architecture can demonstrated well by the iTunes application. At the center of the iTunes app is the Model which contains important variables/data structures that represent the current internal state of the app. For iTunes, this would probably be variables representing the Current Song, Seek Position, Shuffle?, Repeat?, and various other settings necessary for a music player. The Model may be a good internal representation for iTunes, but it has no way to present or receive information from the user. This is where the iTunes View comes in; it presents the user with an interface that displays the current track player, the tracks position, and other important information about the current artists/album/etc. The the state of the iTunes Model changes (like the song is skipped) the View is updated to reflect the changes to the user. These changes of state can happen automatically or can be enacted by a user using the iTunes Controller. The Controller is the piece of the architecture that interprets the user's hardware commands and sends the interpreted commands in the form that the Model will understand. In iTunes, if a user double clicks on a new song, the Controller interprets this action as a desire to play this song and tells the Model "set Current Song to: Song XX" and "set Seek Position to: 0:00". The View sees a value has changed in the Model and updates the screen to show that the new song has currently started from the beginning. The user sees this update and the feedback loop is complete.

Android handles events as they occur. Each event is placed on a queue and handled on a FIFO basis. When an event pops off the queue, the View is passed the event notification as well as important information about the event (the x,y coordinates of a touchEvent, for example). In order to properly handle the event, the View must have an appropriate Event Listener. The types of Event Listeners range from things like onClick, onTouch, onCreate, etc. When one of these Listeners is activated by a proper Event, the listener code is dispatched and the event is finally triggered. The Android approach has some differences with the Object-Oriented Event Loop in which the window tree is directly integrated with the widget tree. What this means is that when an event is registered, it invokes the proper method on the root widget of the window. This widget can either execute the method or pass the event to one of its children. This is different from Android model in that it directly introduces the idea of inheritance to Event handling. Rather than having specific listeners placed in the View, the appropriate method used to dispatch a specific event is inherited from parent windows and widgets.

Christopher Echanique - 3/3/2014 16:07:27

Considering a simple currency converter application, the model of this application includes the different types of currencies to be converted, the currency conversion rates, and the formula used to convert these rates from one currency to the other. The view is the interface that displays the information from the model for the user to perceive and interact with. In this case, the view could be a touch screen display showing the two different types of currencies that are changeable and a text field for the user to enter the amount to be converted. The controller is what receivers the input from the user (in this case the user’s touch) and translates it to actions that the model performs such as computing the new currency using the conversion rate. The controller is also responsible for updating the view with this new information as a result of a change in the model’s data.

Event handling in the Android SDK is performed through the use of action listeners. The class that is interested in processing an action event implements the ActionListener interface and objects created in that class are registered to an action listener component. When an action is performed by the user (i.e. pressing a button on the interface), the object executes code associated with that action. This is similar to Olsen’s windowing system event handling model, since it involves acquiring a user’s input from the mouse or keyboard and executing the appropriate action associated to the window in focus. The main difference is the type of input that the event handling supports; Android supports multi-touch inputs whereas windowing systems support mouse and keyboard inputs. Furthermore, Olsen discusses the use of top-down and bottom-up strategies for relating events to an appropriate window. Since the Android platform does not rely on multiple layers of windows to display views of different applications, these strategies do not apply.

Vinit Nayak - 3/3/2014 16:08:03

An application that can benefit well from having a Model-View-Convtroller (MVC) architecture is Piazza. The View is the most straightforward aspect of the architecture, and it consists of all of the pages the user gets to see. This ranges from the welcome screen, to the QA forum for an individual class, user settings page and many others. The user sees these views and can interact (unknowingly) with the models and controllers via the elements on the views. The controller for Piazza is any framework that is running which listens to any HTTP requests (GETS/PUTS), etc. that the view executes based on user action, such as submitting a form. The controller, once handling the request evaluates it and chooses an action for it. This may or may not involve the model and/or the view, it could be a simple redirect or it could update the database and give the user information back. The models for an application like Piazza could include the different users, question types and administrative roles which interact with the app. Each of these models have their own database which they use to update/store information. An example of a run through the MVC architecture would be that a user is using the a view which allows him/her to post a new question. Once the user types up the question and clicks submit, the controller gets the request and then uses the Question model to insert the question into the database, and could potentially use the User model to associate that user to the question. Once the model has changed, the controller decides the next view to show the user and the user is redirected to the appropriate page.

The Android event handling mechanism is most similar to that of the listener pattern described by Olsen. In android, mostly all of the events that need to be handled are related to the UI and the user interacting with the screen, such as clicking, dragging, long touching, etc. For each of these actions, the elements on the screen have to be register with the main event handler and provide a callback function that the event handler can execute once the event is received. The main event receiving and processing is abstracted away from the developers of Android apps for simplicity and they only have to worry about providing the listeners with the appropriate callbacks. The similarities are many, in terms of having to register specific functions to handle the events for each different type of event possible (or at least the events the app cares about). The one difference present between the Android event handlers and the listener pattern presented by Olsen the order in which the events are processed. The listener pattern implies that there are different mediums for the events to be processed so they can occur concurrently, whereas the Android event handler users a queue of events that get processed in a first in first out (FIFO queue) manner. This could mean that event processing is slower in Android.

Liliana (Yuki) Chavez - 3/3/2014 16:10:45

1. The Model View Controller architecture can be illustrated through an explanation of a banking web application. The model in this example is the account balance, and what if you have credit cards with the same company, the amount due (and other relevant information like account number, account owner name, etc.). The Controller is the web application itself which provides means to which to change information or check information (i.e. process a payment, or pay a balance). The View would also be the web application as it would enable you to view the changes that you would make once you have made them.

2. Event handling in Android is usually executed in many ways, one of which is through event listeners that are placed throughout java code, and then executed if a certain condition is met.

Juan Pablo Hurtado - 3/3/2014 16:11:28

1. Facebook: Model - would be the people, profiles, photos, events, groups.

Controller - would be the layer that'll update the view given the model, for example when the user writes a wall post, the controller would be the one that saves the post to the model and displays it on the wall.

View - is what the user sees, in Facebook's case it would be, for example, the profile page.

For example, editing an event name the controller will recognize the input, change it in the event model and then the view will display it to the user.

2. Android, because is based on Java uses the Listener model for event handling.

Given that one of the differences is that the Delegate model (the one used in C#) is more lighter than the Listener model, this is because when adding delegates, individual methods are added rather than whole classes with specially declared interface definitions.

One similarity is that you also have to add/remove delegates as you added/removed listeners.

Haley Rowland - 3/3/2014 16:12:22

1) I will consider the MVC architecture of a shower. The user has a mental model of pushing the shower knob up or down to turn on or off the water and turn the knob clockwise or counterclockwise to get hotter or cooler water. The user expresses their intent to turn on the shower by moving the knob up. The shower’s controller (the knob) sends a signal to start the flow of water and the view is updated by the presence of water flowing from the shower head. The user then perceives the temperature of the water and decides to change it based on their temperature preference. The user expresses this intent by turning the knob clockwise (for example), then the controller sends a signal to the shower’s model to increase the flow of hot water, which the user then perceives through feeling the temperature of the water.

2) The Android SDK uses listeners and inheritance event handling. For example, buttons in the Android SDK can be set to have an onClick attribute that corresponds with a function that will handle the event. Alternatively, the Android SDK allows a programmer to declare listeners that will alert the appropriate function when an event occurs. Because Android only features one widget at a time, its windowing system would be best described as focused since the window in view is the widget that receives the intent.

Sangeetha Alagappan - 3/3/2014 16:21:16

1. Human computer interaction has an architecture that follows a Model-View-Controller system, to help define clear responsibilities and communication between the three primary components of Model, View and Controller. Take for example, a calculator Android application. A calculator application’s model would be the state of the calculator - a model of the information to be manipulated. The view is what is displayed by the application - the calculator interface with buttons for numbers, mathematical operations, and input field; a rendering of the current state or model of the calculator. The view uses XML and other layout files to accomplish this representation. The Controller listens for input from the user, understands the user expression (button clicks to signify strings of numbers and operations) and sends any change to the model to refresh the state of the calculator (and any changes to the model ensures changes to the view are made - to reflect the change to the user). Therefore when a user inputs 1+1= (each part of that expression will trigger a cycle through MVC as the calculator refreshes for each input), the controller will send the change to the model which will perform the calculation or necessary storage and send the changes for the view to render - the user can then see the output or relevant feedback.

2. An event in Android is generated in response to an action by a user, like a touch event. In the Android SDK, an event queue is maintained where events are placed as they occur and removed and processed in a first in, first out basis. The event is then passed on to the view at the position on the screen where the event took place (in the case of touch) and along with this notification, information relevant to the event (coordinates of touch event, etc.) are passed in. In order to handle events, the view needs to register the right event listener (such as onTouchListener that detects touch events) and implement the corresponding callback (such as onTouch() ). In the Olsen reading, Callback Event Handling is discussed, which seems similar to Android SDK event handling. Both use the notion of callbacks when an event occurs. However unlike the callback system in the Android SDK which relies on a specific event handler, the Callback Event Handling requires the system to look up all the callback names in the Registry and retrieve the procedure address for the callback once the window is initialised and also has defined functions like (CallWindowProc, DefWindowProc and WindowProc ) to manipulate callbacks. Also unlike the Android SDK, if no callback exists, it generates an error that is easily understood. Like the Android SDK, it handles many different kinds of events.

Aayush Dawra - 3/3/2014 16:22:17

The Model View Controller architecture is a modular architecture used in the design of several application and consists of three parts: the model, which essentially represents knowledge, the view, which is a visual representation of the model and the controller, which is the link between the user and the system. To understand this more in depth, we look at the example of Facebook. A model in the case of Facebook would be it's users and all the information pertaining to a user would be contained in the user model. It helps to think of the model as a table in your database, where every row corresponds to one object, which in the case of Facebook's user model would be one single user. In the case of Facebook's user model, the user's profile that the user sees when he logs in would be the view. A view is attached to a model and gets the data necessary for presentation by asking the model, in this case the Facebook user model, questions and thereby acting as a presentation filter that selectively displays the relevant information to the user. Moving on the controller, in the case of the Facebook user profile, the tabs on the top (About, Photos, Likes etc.) are considered the controller, since they provide the user with input, in this case the tabs, and the relevant views present themselves appropriately based on the user input. So, the controller is essentially a medium between the user and the system and allows the user to express himself in the View by giving commands through menus, buttons and other UI elements after which the controller receives the user input, translates it into the appropriate messages and passes these messages onto one or more of the views.

From amongst the patterns described by Olsen, the android event handling mechanism mirrors the Listener Pattern the most. In android, the majority of the events that are to be handled, like dragging, clicking et al., are essentially related to the UI and the user interacting with the touchscreen. The UI elements related to each of these actions need to register with the main event handler and provide a callback function that the event handler may execute once the event is received. As far as the underlying mechanism for receiving the event and processing it goes, it is under the hood for Android developers and all that the developers need to worry about is to provide the listeners with appropriate callbacks. As has been discussed so far, there are a multitude of similarities between the Android event handlers and Olsen's Listener Pattern. For instance, registering specific functions to handle events for all the multiple events that are possible in Android is exactly in parallel to the Listener Pattern. Having said that, there are also certain differences between the two. Consider for instance the order in which events are processed. The Android event handler uses a FIFO queue of events which is in stark contrast to Olsen's Listener Pattern, which postulates that there are multiple mediums for the events to be processed so they may occur concurrently, thereby leading to swifter event processing as compared to the Android event handling mechanism. With these observations it becomes increasingly clear that the Android event handling mechanism and Olsen's Listener Pattern are very closely aligned to each other, however both of them continue to have certain idiosyncrasies that differentiate them from one another.

Anthony Sutardja - 3/3/2014 16:27:52

The model view controller architecture is often applied to the structure of web applications. For the sake of example, let us consider a web blogging application. The model of the web application is what backs a user's blogging content. In particular, the models could be stored in some datastore (database, text files, etc) that contain data in a particular structure. The data is usually organized into particular fields like a blog post's title, date, content, author, and other information. The controller logic allows access to view, add, and edit the blog posts. In general, the controller applies the appropriate logic given some interaction by the user and performs the necessary actions to interact with the models in order to serve the user. The view of the web application is typically the templates that are involved in displaying the web page to the user in a web browser. The display of these views is what matters to the end user.

Android SDK event handling is primarily used for external input targeted towards the device. This includes a wide variety of motion gestures on the touch screen, key presses, and many physical interactions.

That being said, event handling is not only for external input. Event handling can be triggered through expected/unexpected system statuses. Low-battery indication, indication of cell service/Wi-Fi, and other interrupts are examples of system interrupts that other programs may need to know about in order to handle these events correctly.

The Android event handling system is similar, if not the same, as the Callback Event Handling scheme described in the reading. The developer must register certain callbacks (which Android calls event listeners) that will handle what a particular event should do when it is enacted. This event handling scheme is allows the developer to worry about implementing callbacks that can only be applied to a particular component.

Opal Kale - 3/3/2014 16:29:02

Very Basic Painting App:

Model:stores points and color, where the point object has instances that are coordinates.

View: the paint panel is in the center of the screen, the choices for colors are on the left hand side. It has class constants for the selected color and titles that are displayed.

Controller: implements the touch motion listener interface that accounts for the touch moving action, and a list selection listener, which accounts for a list of colors to use when painting and will update the view when the user chooses a selected color.


In the Android framework, there is a specific event queue that handles events. The events are removed from the queue in a first in, first out basis. If there is some touch event that occurs, the touch event is passed to the view positioned at the location on the screen where the touch took place. There is also information that is passed on about the nature of that event; for example, coordinates of where the touch event happened are potentially passed on in some cases.

To handle an event, there must be a listener. A view will then use both an event listener and implement a callback to that click event. For example, if a button is the method used to respond to a click event, two things must happen: it will register the View.onClickListener event listener, and implement the onClick() method. If a click event is detected, the onClick() method will be called when the event is removed from the event queue.

Olsen’s model also has a callback feature that is key to event handling, and listeners. However, they differ, for example, in that Android SDK does not have a GIGO/Canvas system because GIGO relies on C programming language (that relies on pointers for procedures that are lower level).

Matthew Deng - 3/3/2014 16:32:52

I will be describing the Model-View-Controller architecture using the iPhone Clock application, specifically the Stopwatch. the model consists of Total Time, Current Time, and a list of Lap Times. The view shows the Total Time and Current Time values, and also shows the list of Lap Times. When the user presses the Lap Button, this is sent to the controller, which attaches the Current Time to the list of Lap Times, and resets the Current Time to 0. This is updated in the model and then presented in the view to the user, so that the user can see each individual lap time as well as the total amount of time that has passed.

Event handling is used in the Android SDK to take in user input and respond with the application. Events are handled similarly to the Listener model. The widgets are defined in the layout xml file, and just like described in the model, the widgets in the Android SDK implement ActionListeners, and can take in a variety of input types. This is beneficial because each widget does not need to implement interfaces that are irrelevant to its function, and different widgets can listen to the same input, adding easier functionality.

Will Tang - 3/3/2014 16:36:04

1) One example of a fairly simple MVC implementation is the "Pooped" app. This is a gag app that allows users to drop pins on locations where they have dropped other things. The model is fairly simple, and is just a map with preserved locations. This could have been easily implemented with <latitude,longitude> data points. The view is a very close representation of the model, and shows a map with the user's current location as well as all the previously dropped pins. The view can be shown using multiple maps, such as satellite view and street name view. The controller is an interface that allows a user to swipe around in the map, accompanied by a button labelled "bombs away" that drops a pin in the user's current location. The controller translates directional swipes on the map to movement within the map, and translates the pressing of the button to the creation of a new datapoint in the model.

2) In the Android SDK, the screen is split into multiple windows including the source code window, the file hierarchy window, the toolbar window, and the console window. Depending on which source window is currently open, the user may either input text mouse clicks to select regions of code in the case of a java file, or drag and drop UI components in an xml file. When editing text, mouse clicks are handled as placement for the cursor, and keyboard inputs are handled as text input. When editing the text of an xml file, the events are handled the same way. When editing the design of an xml file, mouse clicks are handled as selections for UI components, and mouse click+drag actions are handled as movement for components. Keyboard input is not used until a component is selected, in which case keyboard input can be used to edit the information in another window with component info. Mouse clicks in any of the other windows such as the toolbar and the file hierarchy are handled as selections of different actions. The Android SDK event handling model is similar to Inheritance Event Handling in that every window shares a common interface for the basic inputs such as mouse clicks, keyboard inputs, and mouse drags. Depending on how each window implements the handling of these inputs, the resulting actions may differ. A possible difference could be the fact that keyboard inputs for certain keys don't seem to yield very different results. Pressing the letter keys in any of the windows almost always results in some form of word formation. This seems to imply that the letter keys always serve the same purpose in representing the entering of a letter. Whether this is in the file hierarchy where typing letters will select similarly named files, or in the text interface where typing letters will insert the letters into the file.

Emily Reinhold - 3/3/2014 16:40:48

1) The Nest Application has a very clear model-view-controller architecture. While I interned at Nest Labs over the summer, I learned how the interactions that a user performed on the mobile application got communicated to the server to make the input data persistent. I will describe these interactions in terms of models, views, and controllers below:

The Model: essentially a large database that stores the information about users based on their unique account information.

The View: mobile application client that displays a User Interface allowing the user to perform actions such as raising or lowering the temperature on their Nest thermostat, setting target temperature set points on their schedules, changing information about their home's features and location, etc.

The Controller: Interprets inputs from the user and sends the appropriate action, along with parameters to the server (model).

Now I will describe a typical flow of data within the Nest application:

1. User opens the Nest mobile application on her mobile device 2. User sees the 'View' -- the main thermostat deck, for example, showing an image of what the thermostat looks like in real life so the user's mental model of how the application accepts interactions is familiar to what they know about interacting with the physical Nest thermostat. The current temperature of the home is displayed on the thermostat -- this data was read from the model (as the Nest thermostat communicates to the model to report the current temperature). 3. User taps on the up arrow displayed on the thermostat view, in hopes of raising the temperature in her home. 4. The controller interprets this tap on the up arrow, and sends a request to change the information in the model to increase the temperature in this user's home by one degree. 5. The model communicates this change to both the thermostat view and the mobile application view. The user now sees that the target temperature displayed in the physical thermostat and the virtual thermostat in the mobile application have increased by one degree.

The model-view-controller architecture works well for this type of application, in which multiple clients need to have one consistent source of information. In the case of Nest, there are three different clients that communicate with the same model: the physical Nest thermostat, the Nest mobile application, and the Nest web application. In order to show the user the same information on all clients, each client communicates to the model. Whenever a change is made on the model, the model sends out a 'message' to the three clients so they can update their views.

2) The Android SDK handles events using event handlers and event listeners. Event handlers are used when the developer wants to define default event behaviors for a particular UI element. Event listeners are used to define what happens (in code) when the UI senses a particular type of event. Below I will compare the Android event handling to various models discussed by Olsen:

  • Event Queue and Type Selection:

This model is similar to Android in that it distinguishes between different types of events. The two models differ, though, in that event queue/type selection must compare the event that occurred to all of the other types of events before deciding which code path to follow, while Android defines different event listeners for every type of event, and decides which code path to follow based on which event listener sensed an event.

  • Window Proc Event Handling:

This model is similar to event/queue and type selection, except instead of having to compare the event that occurred to every single possible type of event, the comparisons are limited to the types of events that are possible within the active window proc. This is similar to android in that different types of events are possible on different types of views, and Android does not listen for events on a particular view that are no appropriate for that view.

Clearly, the model that most closely matches the Android event handling model is the Listener model. This model is the most effective when the developers wish to handle thousands of events because it is easy to define event listeners for each type of event, and the code does not need to sift through thousands of event types before deciding which code path to take.

Tristan Jones - 3/3/2014 16:57:08

1) A model-view-controller architecture example could be a remote controlled car. Using a remote, you push the accelerate/brake buttons and turn left/right buttons to make the car move around. In this case, the Model is the processors in the controller and remote control car. Whenever it receives an input from the controller, it performs the corresponding action to the car's motors. The View in this situation is the physical location of the car. The user can see where the car is located/how its moving, and choose a new action to send to the car's controller. The Controller in this case are the physical buttons on the remote controller. When these buttons move, they correspond to changes in electrical activity and these changes are picked up by the Model. This then begins the infinite recursion.

2) In the android SDK, we as programmers attach an event listener to Views through either the XML or programmatically in our onCreate() function. This is very similar to the Listener Class structure talked about by the Olsen guy on page 64 of the reading we did. He shows an example of how he created a ActionListener() to a button using the AddActionListener() method. This seems very similar to the way we do this normally in android. But, in his example, you cannot declare a listener through the XML like android. So this is this different in that respect.

Sources used: file:///Users/tj/Desktop/Android%20Event%20Handling%20and%20App%20Frameworks%20Handouts.pdf

Justin MacMillin - 3/3/2014 17:00:15

1. The Model-View-Controller architecture is a system used to describe how a user interacts with an application or object. For example, imagine the user is attempting to set an alarm on a clock radio (the object, not an application on a phone). Before interacting with the system, the user’s mental model of the clock involves what time they see on the display and buttons on the clock to interact with it. To set an alarm, the user has to hold down the “Alarm” button and push “Hour” and “Minute” until they reach their desired time. For now, the alarm clock’s model is at the default midnight time. First off, the user interacts with the Controller aspect of the MVC architecture. The controller controls the system’s Model. The controller in this particular example is comprised of the buttons on the clock itself for the user to interact with. The controller can edit the Model of the clock. The Model then communicates with the View aspect, which displays the information in the model. In this case, the View displays the time for the user to perceive and make a new mental model.

2. Event handling is controlled by event listeners in the Android SDK. For example, the device will listen for a touch, click, long click, change in focus, etc. to handle various events. The programmer is able to tell the system how to behave with each event based on what it receives. One event handling model discussed by Olsen is “Key Focus” where the windowing system keeps a pointer to the application that is currently in focus. For this to work, an application can get the key focus, lose it, request it, and there exists a tab order as well. In this handling, a keyboard input is sent to the application (widget) that currently has the key focus. The tab input is convenient because then the user can quickly switch between different applications. It becomes difficult when the system has to store the order of how it will switch to various open applications. Key focus is similar to listeners in that they both have a way of performing an action based on an input. An on-click event triggers an action from a listener just as an on-click event in key focus transfers the focus from one application to another. The main difference with the Android SDK is that it offers much more freedom to the user to interact with widgets and interact with more than one at one time.

Hao-Wei Lin - 3/3/2014 17:00:44

a. We can understand the model-view-control architecture through the yelp app for iPhone OS, particular the search function. Looking at the search function in Yelp, the model is the automatic ranking of the search results, usually ranked based on distance plus ranking. This model is then shown to the viewer through either the view of a map or a view of a list by the ranking (the users can switch back and forth). The user can then use the controller part of the architecture (in this case, the “Filter” function in Yelp search to refine/filter the search to change the ranking criteria (e.g. “Hot & New”, “Offering a Deal”, and “Accepts credit Cards”. This alteration caused by the controller then causes a change in the model of the architecture, which is the updated list of business ranked by the new criteria. The updated model then is presented as a view again to the user, and this loop goes on while the user is using the application and changing the filter.

a. An example of how event handling is used in Android SDK is the onTouchListener. It “tags” a potential event of interest, and whenever the user makes a pressing action on the tagged button/window, the changes are made correspondingly. Basically, the Listener gets called whenever the button/window is pressed. In contrast, in GIGO, the event handling is built in the form of a tree (of windows). Every event in this model carries the position of the mouse with it. Each window has a table of procedure pointers marked by the event type. Correct event handling in this model is accomplished through traversing through the tree according to where the location of the mouse is and where the mouse clicks.

Steven Wu - 3/3/2014 17:02:18

To describe the model-view-controller architecture, I have chosen "Dots", a mobile app game. Initially opening up the application the View is a title screen, where the user then perceives what is presented on the screen and uses his own mental model to think of the functionality. Later the user will be able to express his thoughts and translate them into input for the Controller by tapping on the screen's three icons: Timed, Moves, Endless, all to select the game's mode and then pressing play now to confirm the mode selection. All these user inputs are taken from the controller and used as input for the model portion of the model-view-controller architecture. One particular instance of how this application then notifies the View is when the game begins. Here the View is now the game screen and the again this cycle of the model-view-controller architecture repeats.

Event handling is used in the Android SDK with listeners. It is used to by a developer to register user input and allow the controller to pass along the input provide onto the proper functions. For each type of widget, there are events and event listeners associated with them. When something has happened to an event, then the event listener will call it so that something is done. To tie this better with Olsen, we can observe the idea of Inheritance Event Handling as mentioned in the reading. Each class has a set of event methods and handles an associated behavior. Instead of having the event action and a listener, this is different by noticing in that they are simply methods that are called upon to invoke a particular behavior. Again we can look at another even handling model, event queue. The Android event handling differs when you have all possible events not grouped together by a single loop. Instead each event has it's own object and associated methods to invoke. To find a similarity, these still have separate cases to handle different events.

Sang Ho Lee - 3/3/2014 17:03:45

The MVC architecture is apparent in how Apple's Siri works. The model contains all the common knowledge and actions programmed into the Siri database and a way to supplement the database with the Internet's searchable knowledge. The user inputs voice commands into Siri, and the controller takes the input, processes it into an understandable query for Siri's database. The model then prioritizes and finds the appropriate response and sends it to the view. The view which is Siri's voice, responds by synthesizing the response into speech. In the Android SDK, event handling is done similarly to the Listener model in Java. Each object that handles IO is handed a Listener object that individually deals with IO events that have to do with it independently. This is different than the singular event processor that relies a list of switch statements because there is not only single entity that dispatches methods based on the IO event. It is however similar to C#'s and C++'s virtual method invocation mechanism, which allows tables of methods to be inherited between classes and subclasses so that events are handled similarly between inherited classes and their ancestors.

Brian Yin - 3/3/2014 17:04:28

1) The MVC architecture for lights in a room could be as follows. The model contains two states for the lights (either on or off). The view would be the actual light bulb which communicates whether or not a user's actions have been successful when turning the light on our off. The controller is represented by the switch, which translates the user's intention to turn the light on or off to the actual execution.

2) The Android SDK uses a system of Event Listeners and Event Handlers. Specific methods are called based on the type of input and which object an action is operated on. The Android SDK has a similar structure to the Inheritance Event Handling model, where all UI elements inherit from a single View class and can call this super classes' event listeners. Each view element handles its own events. This is different from say the Event Queue model which listens for every possible event and then dispatches instructions to a view.

Meghana Seshadri - 3/3/2014 17:05:02

(1) The model of this application is the information to be manipulated is the texts that the user sends and receives. The view presents the state of the model, or in other words, the current state of the application’s information. It also updates the presentation in response to model changes from the user or some other activity. This update is handled automatically on Google Voice, or the user can pull down on the screen in order to update their message inbox. The Google Voice application allows the user to click on buttons visible on the screen that will send a new text, reply to texts they have received, edit their message inbox, and other functionalities. The controller translates users actions and inputs into model changes. When a user swipes down on the message inbox screen, the model knows that it needs to update its information in regards to texts in the inbox, and the view will update accordingly. When a user wishes to reply to a text they have received, the controller translates the user clicking on the reply box on the bottom of the specific message screen into allowing the user to use the mobile phone’s keyboard to begin typing a message. After sending the message, the model will input the changes, and the view will update the message screen accordingly to include the latest text that was sent.

(2) Event handling in the Android SDK is most commonly used for input events, or in other words, the interaction between the user and the touch screen of the mobile device. Android maintains an event queue where events can be placed as they happen during the interaction, and the queue works accordingly to the first-in, first-out methodology. An example input event is a user touching the screen, and the view obtains a notification of this event as the location on the screen where the touch occurred. The view also obtains further background about the type of event. In order to process the event information that it has been given, the view must have an event listener. There are a variety of event listener interfaces in the Android View class, and each have an abstract declaration for a callback method. Hence, the view must implement the corresponding event listener in order to accommodate the event.

Olsen similarly discusses input events in his writing. Olsen also discusses how there are different types of events that can occur, and how each have their type name, the location of where the touch occurred, and some other modifier button information. Furthermore, Olsen also describes how most event/code binding is based on the event type, which ties into the idea of view’s implementing the proper event, depending on the event type, where each event type has an abstract declaration for a callback method.

In another section under Event/Code Binding, Olsen discusses the ideas behind Listeners. Olsen describes how advanced user-interface toolkits user a listener model for handling events, which is exactly what the Android SDK uses. Using class inheritance as an event model, users can define a class that contains all the methods needed for a specific event that occurs on the interface, which can then be implemented in various ways. While Olsen further discuses listeners by using polymorphism in object-oriented languages, Android SDK framework maintains an event queue, where events are captured as they happen and then removed.

Gavin Chu - 3/3/2014 17:07:23

1. A television set has a very clear Model-View-Controller architecture. First off, there's a physical remote control that allows to user to interact with the television such as changing channels, volume, settings, etc. This controller sends a signal to the television, which is a model that contains a bunch of stuff such as different TV channels. Based on the signal, a specific channel is selected to be displayed on the screen, which is the view part of the architecture. The user finally sees the changes on the screen, and the cycle is complete. Most televisions have alternative controllers as well, for example a touch screen TV or buttons on the side of the TV. No matter which controller is used, the model remains the same, and the view will depend on the input of the controller. As television has become more and more complicated now days, not only does the controller change, but also the view selection becomes more complicated because there are more features to be displayed.

2. There are many events to be handled in the Android SDK. Some examples are Button clicks, EditText edits, touch/gesture detection, intent (activity) calls, and AsyncTask operations. Handling events that involves interaction with Android components usually uses some kind of listener interface such as onClickListener() for buttons. A user can use addTextChangedListener() to EditText, which allows the user to manipulate the interface based on each text entry, for example processing a search algorithm after each character input. Olsen also discussed the listener class structure where you only need to assign listeners to events of interests.

We've handled touch events in IPA2 using onTouchEvent(). Note that we used onTouchEvent() on multiple canvas view, which are just a views on top of the root view. Each of these views can have its own onTouchEvent(), which means some sort of inheritance is at work. Olsen mentions that inheritance is important because object-oriented programming is a very useful model for event handling. Each subclass can inherit methods from its super class and method calls will depend on which class it is called from. Normally, a method from a subclass will only be called if it's not implemented in the current subclass; however, the Android SDK offers an alternative way to call methods from a super class. The onTouchEvent() is a good example. This method returns a boolean to indicate whether this method should be executed at from this view (sub-views in Android inherit its view container). For example if you want to touch a view below your top canvas view, you can have the onTouchEvent() of the canvas view return false, then the onTouchEvent() of the view below it will be called. Using a boolean is just one way that Android handles events regarding inheritance.

Handling intents in Android is a bit different from listeners. All intents are defined in the manifest, so the system knows where to map each activity when a new page needs to be viewed. AsyncTask is another form event handling in Android SDK. Because accessing network information or other complicated operations requires more time, Android provided AsyncTask so those operations can be run in the background while the user can do other things with the app. AsyncTask offers a callback function that returns data from whatever operation was done. An Android interface that access the network will have to deal with this type of event handling.

Alexander Chen - 3/3/2014 17:07:48

The MVC architecture is the default method for developing iOS applications as well as Rails based websites. It includes a persistent data storage module, known as the model; code that mediates between user input, changes to the model, and updating the view, known as the controller; and the view, which is the interface presented to the user.

To describe MVC, let's look at it in the context of DoodleJump. This is a game that takes the tilt of the iDevice as input. This input determines the next position of Doodle, and whether he can hop on a ledge and continue his journey up.

First, a delegate (iOS version of listener) takes in user touch input, such as a button press to "start game". The controller notifies the view to draw the game onto the screen and begins executing code relevant to gameplay. At this point another delegate would take the accelerometer data as input, the controller would calculate where Doodle would land on the next hop, and it asks the view to draw the updated location of Doodle. Finally, when the user makes a blunder and causes Doodle to fall down in despair, the controller keeps track of the user's score (and, perhaps their name) and asks the model to record it. The controller then asks the view to display a interface that presents the sad news that Doodle had perished and shows a "try again" button, which the user could click on to continue in this quasi-infinite loop.

In the Android SDK, the event handling is OO because the fundamental language is Java. In addition, the approach is top down, where the View in focus first receives input, If it doesn't have the appropriate callback method to processes the input, the input propagates to the view behind it, until a view does something based on the input, or all the views have been given an opportunity to respond, but no callback method was invoked. This contrasts with the bottom up dispatch, mentioned by Olsen. In this scenario, only the view in focus would receive the input and get an opportunity to respond to it. These two event handling styles could produce the same effect, but top-down can provide the system designer with more flexibility.

In our IPA2, it is clear that top-down event handling was a key property of the Android system. Since we had many canvases and views that contained these canvases, yet we wanted the non focused view to receive and operate on the input, we depend on top-down event handling. In this case we took the input into a blank canvas on the non focused view to calculate which pixels to change in the focused view. The controller would then take the paint color, brush size, and stroke and update the bitmap image, then it would ask the focused view to update and display the new bitmap image. This is not possible with the bottom-up event handling methodology.

Gavin Chu - 3/3/2014 17:08:28

1. A television set has a very clear Model-View-Controller architecture. First off, there's a physical remote control that allows to user to interact with the television such as changing channels, volume, settings, etc. This controller sends a signal to the television, which is a model that contains a bunch of stuff such as different TV channels. Based on the signal, a specific channel is selected to be displayed on the screen, which is the view part of the architecture. The user finally sees the changes on the screen, and the cycle is complete. Most televisions have alternative controllers as well, for example a touch screen TV or buttons on the side of the TV. No matter which controller is used, the model remains the same, and the view will depend on the input of the controller. As television has become more and more complicated now days, not only does the controller change, but also the view selection becomes more complicated because there are more features to be displayed.

2. There are many events to be handled in the Android SDK. Some examples are Button clicks, EditText edits, touch/gesture detection, intent (activity) calls, and AsyncTask operations. Handling events that involves interaction with Android components usually uses some kind of listener interface such as onClickListener() for buttons. A user can use addTextChangedListener() to EditText, which allows the user to manipulate the interface based on each text entry, for example processing a search algorithm after each character input. Olsen also discussed the listener class structure where you only need to assign listeners to events of interests.

We've handled touch events in IPA2 using onTouchEvent(). Note that we used onTouchEvent() on multiple canvas view, which are just a views on top of the root view. Each of these views can have its own onTouchEvent(), which means some sort of inheritance is at work. Olsen mentions that inheritance is important because object-oriented programming is a very useful model for event handling. Each subclass can inherit methods from its super class and method calls will depend on which class it is called from. Normally, a method from a subclass will only be called if it's not implemented in the current subclass; however, the Android SDK offers an alternative way to call methods from a super class. The onTouchEvent() is a good example. This method returns a boolean to indicate whether this method should be executed at from this view (sub-views in Android inherit its view container). For example if you want to touch a view below your top canvas view, you can have the onTouchEvent() of the canvas view return false, then the onTouchEvent() of the view below it will be called. Using a boolean is just one way that Android handles events regarding inheritance.

Handling intents in Android is a bit different from listeners. All intents are defined in the manifest, so the system knows where to map each activity when a new page needs to be viewed. AsyncTask is another form event handling in Android SDK. Because accessing network information or other complicated operations requires more time, Android provided AsyncTask so those operations can be run in the background while the user can do other things with the app. AsyncTask offers a callback function that returns data from whatever operation was done. An Android interface that access the network will have to deal with this type of event handling.

Diana Lu - 3/3/2014 17:08:55

1. The model view controller architecture can be seen in all applications. Let's look at the model view controller architecture through the Venmo application. The view is obviously what is displayed to the user. The controller links the view to the controller. For example, when a user presses Pay to pay a certain amount of money to a friend, the controller will translate that to the model and subtract that amount of money from the payer's account and add it into the receiver's account. This change is then reflected back into the view, as the user can see that his balance has depleted after paying.

2. Event handling is handled in the Android SDK by the utilization of event listeners. Objects that the user can interact with, such as buttons, spinners, etc will create events. The listeners then will react to these events (ie: a button being clicked) and the code that is written in the listener will be executed. This event handling is very similar to the callback event handling that is described by Olsen, where each event contains properties for various events. They are similar in that both require a listener that is specified, and when said event is called upon, the listener is used.

Robin Sylvan - 3/3/2014 17:09:50

The model-view-controller is a way of separating the different parts of an application to help understand human computer interaction. The model is the underlying information and data stored in the program, the view turns this data into something visible to the user, and the controller is what translates between commands the user initiates and modifies the model. One common example of an MVC architecture is expressed in Ruby on Rails. When coding a Ruby on Rails app, the user defines the model as specific information and constraints for the applications data. The views are used to create HTML representations of various pages the user goes to interact with. Controller functions are then defined, generally causing database operations or modifying the current users session of interaction. Event handling in Android SDK is handled by event listeners. A user creates a new event listener class with a handle event function, and this listener is added to a list of event listeners from each widget. When an event occurs, the event listener's handle event function is called with information about the event. An alternative method discussed in the reading was the event queue and type selection of early Macintosh. Their event handling system had a single thread that constantly looped while asking for system input. This system then had a switch statement for each event type, and then responded to events accordingly. This is similar to the event listener format because sometimes there are event listeners that take multiple types of events and from different sources, and have to make switch statements based on the source or type of event. This is very dissimilar at the same time in terms of function selection – the event listener format creates events from widgets who then pass this information to their list of event handlers. Mac's original system was much more rigid, but at the same time more fast efficient for processing window events. While less efficient, event handlers enable much more flexible interaction with interfaces.

Andrew Dorsett - 3/3/2014 17:12:02

The MVC architecture can be explained using the Facebook Messenger app for Android. The user sees several different screens, including a floating message ball and, when that's pressed, a chat screen. The ball and the chat screen are the app's views, what we see. The floating ball is most likely a transparent view with a floating button. If you click somewhere on the screen the view sends the position of the press to the controller. The controller, which makes decisions based on input, then has to determine if that position is where the floating ball is. If it isn't it needs to pass that event down to the application below. If it is then it sends a request to the model for all the current chat information. The model, which handles the data, needs to retrieve data based on parameters the controller sends (such as user name). The model sends the data to the view who then displays it in a way that is familiar to the user. I did find the reading's explanation of MVC weird because I've always been told not to have the view and controller interact directly.

I would guess that Android handles events from a top-down approach. You have one main view for each activity. Inside that view you can have child views. So when you press somewhere on the page the information is sent to the primary view and from their it decides where to send the request based on the positioning of the press. They also mentioned how subclass can overwrite events, which is something that you do in Android to customize event handling. Though I was a little confused by the explanation all together.

Stephanie Ku - 3/3/2014 17:12:17

1. An example of an application that uses the Model-View-Controller is the entertainment system in my car. The ‘View’ shows me on a graphical display what songs and radio stations are available to play. Let’s say that I am currently on FM 94.9 and I want to switch to a different radio station. I turn the dial (changing the station to FM 95.2), which then interacts with the ‘Controller’ letting it know that I now want to be playing FM 95.2 instead. The Controller, which deals with the logic, will now make this change and also tell the ‘Model’, which holds the state, that the radio station is now FM 95.2. The ‘Model’ then goes back and tells the ‘View’ to show/display to me that the station has now been changed to 95.2 through its graphical display. In summary, the ‘Model’ holds the current state (so in this case there could be ‘Radio Station: 95.2’, ‘Volume: 5’, etc.). The ‘View’ is what is displayed to me on the dashboard in my car, and the ‘Controller’ contains and executes the logic behind it all (i.e. changing radio stations).

2. Event handling is used in several ways in the Android SDK. Firstly, we have Intents that can be passed on from one Activity to another, letting know the Activity know what their ‘intent’ is. For example, I pressed a button from the home screen that supposedly will launch a different task. Behind the scenes, that button could be sending an Intent to another Activity that will perform this other task. We also have BroadcastReceivers that can receive these ‘Intents’ and act upon receiving them.

If we compare Window Events Tables with Android SDK’s event handling, we will find similarities where procedures will forward events to other ‘windows’. They also have individual processes to handle errors. If we take a look at Inheritance Event Handling, we will find similarities where in Android you can extend certain classes, such as BroadcastReceivers, and overwrite certain functions that will allow different handling. However, Android really differs the Callback Event Handling, as it does not have event tables in which procedure addresses are stored.

Max Dougherty - 3/3/2014 17:13:28

1. The MVC architecture allows modular development of an application by separating key components into abstracted “black boxes”. Take, for example, the google doc used to submit this quiz. When the URL request is sent, the router parses the URL and calls on the correct method in the defined controller to begin the necessary set-up of the rendered form by requesting the appropriate information from the model. The model, which serves to communicate with the database, returns to the controller the questions associated with that form. The controller then renders the view and populates the dynamic content in the HTML of the view. This creates the content of the HTML displayed to the user and completes the URL request. Upon filling out the form, the user clicks the submit button and the information in the fields of the form are packaged into the URL request and used by the controller to reformat and save that information in the model’s database. Upon successfully saving, the user is served a new view with the confirmation of successful submission.

2. Events in Android are handled when the an external operation acts on one of the view objects. Event listeners capture the actions initiated by the user and if desired, can cause an event handler to initiate a behavior for this action. Similar to Olsen’s model, event handling behavior is inherited and thus often simpler to implement. As Android is an extension of Java, it takes advantage of the object oriented design hierarchy, which differs from the Window Event table described by Olsen. Furthermore, the Window Event table uses a “top-down” approach to listen for events, as opposed to the more “bottom-up” convention used in Android, which allows an individual listener for each interactive element. This allows many simultaneous activities, which is not necessarily possible in the Olsen Window Event model.

Emon Motamedi - 3/3/2014 17:13:57

1) Using the Dictionary application as my example, the application begins with an empty model since no word has been inputted yet. The app presents this blank model through the view of a blank search screen, which the user perceives and uses to fuel his mental model of the application. If this mental model is not accurate with the actual model of the system (i.e. he thinks a word has already been searched for), then there is a gulf of evaluation problem.

If there is no gulf of evaluation and the user correctly perceives that no word has yet been searched for, he can then use his keyboard to input the letters of the word he wishes to search for. However, each character he types also goes through the Model-View-Controller architecture. After using the keyboard to input one character, the controller must translate the keyboard input into a change in the model. The controller captures the specific key that was pressed, and adds the corresponding character to the model for the key being pressed. If the controller fails at the translation and adds the wrong character, there is a gulf of execution problem. Then the cycle continues: the model updates the view to present the user with a view that illustrates the added character, the user perceives this view and incorporates it with his mental model, and then continues adding more characters until he finishes writing the word, repeating the cycle each time.

Finally, when the user has finished typing the word and presses enter to search for the definition, the controller processes the "Enter" key along with the word currently in the model to search for and fill the model with the definition. This definition is then presented to the user once the model has updated the view and the user can perceive the definition and add it to his mental model. From there, he can choose to look up a new word, repeating the Model-View-Controller architecture.

2) In the Android SDK, there are certain callback methods that can be utilized as event handlers. These include onKeyDown (which is called on new key events, onKeyUp (which is called on key up events), onTouchEvent (which is called on motion on the touch screen), and onFocusChanged (which is called on the gain or loss of focus of certain views). This is only a subset of the methods as they vary in functionality and complexity.

While event handlers are useful in custom cases, the Android SDK also contains event listeners which are used for more common instances of user interaction. These also contain callback methods which are called when the listener's View is activated as a result of the user's interaction with the certain item in the interface. Some of these methods include onClick(), onFocusChange(), and onTouch(). Within the bodies of these methods, the programmer can dictate what occurs when the event occurs.

The mechanism of the Android SDK has various similarities and differences to the bottom-up input event dispatch model within the windowing system outlined by Olsen. Like the Android SDK, this system contains types of "Views" called windows. These windows are all based around a window tree. Also similar to the Android SDK, the selected window dictates the event that occurs when the tree is selected.

The implementations differ in the selection of the window. Unlike the Android SDK, which triggers Views based on the specific event, the bottom-up approach uses the mouse location to select the lowest and frontmost window in the tree that has the mouse location. The event then corresponds to this window that is below the mouses location, and usually triggers its widget. Thus, while similar in their structure, the Android SDK differs from this model described by Olsen in the actual implementation surrounding these Views/windows.

Lauren Speers - 3/3/2014 17:14:06

In the Model-View-Controller architecture, the system maintains a Model of the information that the user can manipulate which is displayed to the user through the View and changed by the user through the Controller. For example, consider the Facebook Messenger mobile application. The application’s Model includes the set of the user’s ongoing conversations and details about each conversation (participants, read/ unread, thread of messages, etc). The View displays a list of the user’s current conversations (sorted by recency and bolded if unread), and once a conversation is selected, the thread of messages is presented such that the messages sent by the user are displayed in blue and the messages received are displayed in white.

The main way a user can interact with the information in the Model is by sending a new message. If a user inputs text and presses “Send,” the Controller follows the translate-change-notify-present cycle to process the user’s action – the Controller translates the “Send” action to understand that the user wants to transmit the message to the other users in the conversation. It then calls the Model to update the message thread and message details. Next it calls the View to update to display include the most recent message in the display thread. And finally, the user sees their message appear in blue in the thread of messages displayed by the View.

As I understand it, the Android SDK relies on callback methods for event handling. In the onCreate() method of a Widget class, the programmer can call setListener() methods to prepare the application to listen for certain events.  When an awaited event occurs, the application calls the Listener() object passed as an argument in the setListener() method which responds to the event.  This method is similar to the Callback Event Handling described by Olsen in the sense that both methods allow applications to respond to a wide variety of events and that the widget is prepared during initialization to respond to specific user events.  However, in the case of Callback Event Handling, tables of procedure addresses are created during initialization to match events to procedures, rather than setting Listeners().  

Patrick Lin - 3/3/2014 17:14:12

Models represent information consisting of objects, views are the visual representations of models, and controllers are the links between the model and the user, exchanging system output and user input. Web pages, for example, store data in HTML code, present them in views primarily with CSS and HTML formatting, and are controlled through web browsers. These browsers render code for the user to view and direct input through the appropriate JavaScript.

Android handles events like user input through listeners. These capture interaction with specific parts of the UI by waiting for an action like a click or button press and then executing some corresponding action. Android also has a surface, window, and activity manager, which includes an implementation of the windowing system presented in the reading. The windowing system dispatches input events to the correct processes, which in turn update the view presented to the user. Android’s additional managers, however, split the work described in the reading and assist with tracking different processes as activities, associating them with the correct intents (spawning new activities), and managing activity lifecycles.

Maya Rosecrance - 3/3/2014 17:14:45

For an app such as instagram the model is the information of the app, in this case, a list of photographs of the user with the appropriate filters attached. The view is the presentation of the model in this case the various pages of the app and the visual representation of the photographs and filters. The controller is the link between a user’s interactions and the app and interprets a user’s screen taps to make changes to the model. Almost all aspects of the app can be filed under one of these three categories and to some degree even in code the implementation of the three parts are separate (the photos are in a file, xml displays the view, and code manipulates the photos).

Android uses event generators(like buttons) and event listeners(which trigger on finger taps, etc). In contrast Window Event tables uses recursion to find the frontmost window with the mouse inside its bounds. From there the correct event handling procedure can be chosen and implemented. The methods of event identification differ in these instances as event generators use Object Oriented programming to create objects like buttons which have event listeners built into their creation while Windows Event tables has to use recursion to identify the foremost window which then has a pointer to the correct event to implement. However both the events handlers use the location of the mouse or finger tap to identify the correct window/button which can then trigger the correct event.

Prashan Dharmasena - 3/3/2014 17:17:11

1) For an in-car radio, we can split the system up into it's MVC components. The Model would be two variables that represent the station and the volume. Most cars have two knobs, one for changing volume and one for changing the station. These would make up the Controller portion of the MVC. The View would be a display that shows the current station and the current volume on a progress-bar-esque display. As you rotate each knob, the variable associated with that knob in the Model updates (either increases or decreases based on which way you rotate), and the View updates it's presentation of the variable (updating the station number or filling/emptying the volume bar).

2) Event-handling in Android is very much like the early Macintosh system. There are listeners for different types of input such as OnClickListener, OnTouchListener, OnTextChangedListener, etc. While the listeners handle these broad categories, within the listener you must use a switch statement to handle specific actions. This is also similar to the WindowProc model described by Olsen, where there are listeners for input events for each window, but in this case we use a different listener for both different Views and different types of input. For example, when implementing an OnTouchListener, you must have cases for MotionEvent.ACTION_DOWN, MotionEvent.ACTION_MOVE, etc.

Namkyu Chang - 3/3/2014 17:17:36

1. Describe the Model-View-Controller architecture using an application of your choice.

In Olsen’s “Building Interactive Systems: Principle for Human-Computer Interaction”, he describes the Model-View-Controller architecture in detail. Specifically, he refers to a system having a model of the information to be manipulated.

An example of such a model is iMessage app on my iOS. This information is static (e.g. document editing application) compared to some other examples the author mentions (e.g. the state of a robot, stock market, etc.), where the information is constantly changed by independent events. In my case, the information is the messages that have been sent and received by my phone, with the mode of interaction being text input and visual output.

Continuing on the architecture of interactive systems is the View, which is the software presenting the current state of its information model to the user. This view presents the current state of the model and also updates its presentation in response to model changes from me or some other activity.

On the example of the iMessage app, the View, aka the current state of the model, are all messages sent and received by me so far in my conversation with another user. We can also see that the view is updated when the model changes as a response to a change by me or the person I’m having a conversation with. This update is handled automatically for iMessage, as a new text bubble pops up whenever a new message is sent and/or received.

Finally, there’s the Controller in this architecture. Whenever a system is interacting with a human, by definition, the human also has some inputs for the system. The human has a mental model of the system, which attributes to what Norman calls the “Gulf of Evaluation” Whatever the depth of that gulf may be, it is the controller’s job is to interpret the user’s inputs and translate the expression into model changes. However, because a controller that understands all forms of human expressions and translates them accurately is impossible to create with current technology, this attributes to what Norman coined as the “Gulf of Execution”.

With iMessage, this controller is the backend software for the application, which reads what the user types into the text box on the “Send” button has been pressed, and sends that information to the other user in the conversation. The software interprets the back button as an input which forces it to send the message, and updates the view accordingly by putting an extra speech bubble in the user’s conversation. Because of the simplicity of the model, there is very little “Gulf of Execution” for this application, as the controller only has to interpret a very limited set of inputs.

2. How is event handling used in the Android SDK? Discuss similarities and differences to at least one of the event handling models discussed by Olsen.

The Android SDK uses event handling to interact with the user by gathering input through the view, giving properties to widgets such as “OnClick” to determine what should occur with such an input, etc. An event handling model Olsen discusses is the Callback Event Handling, which is very similar to the Android SDK. The model uses the notion of “callbacks.” Each element in the View has properties for its various events, and is used when the user invokes that property.

An example of this is in the Android SDK is the stock messaging app that comes installed with most Android phones. When the user clicks “Send” in the texting application, when the property of the button likely has “OnClick”. The property that’s been pre-defined will allow the message to be sent using the backend controller of the application.

Munim Ali - 3/3/2014 17:18:59

1. The Model-View-Controller architecture is a design technique in HCI which separates an application into 3 components: the model (encapsulates underlying data and state), the view (what the user sees), the controller (the part that manipulates the model based on user input). An example of an application that follows the MVC architecture is the famous 'Flappy Bird' mobile game. Here the model is the data that encodes the game state (possibly a quadtree implementation to encode the position of the bird, the position of obstacles, collision detection, level information, is the bird dead or alive, etc.). The View is the GUI that the user sees, (we see the little bird sprite, the pipes, the background, etc.). The Controller here is activated by the touchscreen interface (when the user taps on the screen, the controller signals a change in game state and manipulates the model to change the position of the bird and determine the resulting consequences.

2. Event handling in android is handled by pairing events with listeners (OnTouchListner, OnClickListner, etc.). Android also allows events to be linked to Views through the XML - so when an event occurs on the view (say a button click) a partucular method in the Java code is called. This is very similar to the callback event handling procedures described by Olsen. It is also similar to the WindowProc event handling method, which associates every window with a procedure that handles events (similar to listeners for views). However, in android we have various kinds of listeners for multiple events instead of an all-embodying procedure as seen in WindowsProc.

Seyedshahin Ashrafzadeh - 3/3/2014 17:21:01

1) For this question, I'm going to describe the model-view-controller architecture of the camera app in a smart phone. The model of this application is the bitmap of the canvas. The controller is either a touch event or pressing the button that corresponds to "taking photo". This controller (action) changes the exposure by controlling the shutter. This changes the model and create a new bitmap. After taking the picture, the taken picture is shown on the screen. In this application, the screen and the GUI of the application are the view, which shows the picture. The new bitmap notifies the view and the GUI changes according to the new bitmap and as a result the view renders the new picture.

2) One of the similar event handling models that olsen explained to the event handling used in Android SDK is the Callback event handling, Based on Olsen's explanation, the programmer needs to register event handling procedure address with a descriptive string name. The properties of each window contains the name of the procedures to call. When a window is initialized, the system looks up the callback names and retrieve the procedure addresses. This would leave the binding between the names and procedure calls until the run time. In this model, each widget would have properties for the events that it can generate and it doesn't need to pay attention to the other widgets. This is similar to the event handling in Android SDK. The programmer specifies event handling procedures for each widget.

Steven Pham - 3/3/2014 17:21:03

1. I choose to use the Mail iPhone app. Every e-mail contains similar data like sender, message, subject, etc which is stored in a model. The views displays this information in various ways. For example in the list of emails view, each individual view of an e-mail shows the sender of the email, subject, as well as a snippet of the message. If tap on an e-mail and open it, the new view now displays time sent, recipients of the email and all of the message. Those are the various ways the mail apps displays the same data. The model changes the views from list view to individual email view as well as feeding these views the information when requested. It also takes care of syncing the models from the server.

2. Android's SDK is similar in that it there is no main program. Instead the main setups up the views and waits for user interaction. If there is a listener for a particular even, the callback function will be called.

Ravi Punj - 3/3/2014 17:22:38

1. In the default Android Calculator app, the view is a textbox and buttons for entering numbers and mathematical numbers, as well as a parameter to keep track . The model is a stack that tracks the operands and operations, and the controller listens for user input through the buttons or text entry, and appropriately updates the model. The view is updated on text entry and pressing button.

Everardo Barriga - 3/3/2014 17:23:52

1.The older version of the Kinect can be described using the Model-View-Controller. I would use it to flip through some of my apps in the Xbox interface. To change between pages filled with applications I could move my hand towards the arrow at the bottom of the screen, the view which was the representation of the direction I wanted to go would fill up with color to indicate to me that my action was being performed and processed. The controller was the physical action of my hand that I would move towards the edge of the screen to flip to the next page. This was then translated sent to the model and the model would let me know that the page had been flipped by showing me an animation of the tiles sliding and then showing me my next page.

2.The Android SDK handles events that are usually related to outside inputs like a touch screen. Android then maintains an event queue and processes the events as they occur. For the event to occur the view must have a listener in place. For example to process a clicking event it must process the View.clicklistener and have implemented the onClick method correctly.

This is very similar to the listener method Olsen describes, but varies to the focus method. Focus deals more with the location of a particular pointer in their case, a mouse. The focus can change and the user can alter that by, for example, pressing the tab key. There is no listening involved. Android relies heavily on listening and gathering information by listening to the user and then processing the events in a FIFO manner.

Allison Leong - 3/3/2014 17:25:43

1. I will describe the Model-View-Controller architecture using a simple Ruby on Rails application that I just completed from an online tutorial. The application allows users to sign into the website and create microposts similar to microposts on Twitter. In this simple application, the model is the component that stores the information on each user and each micropost in various tables. This includes the users’ logins, passwords, microposts, as well as information on who created the micropost. The information that is stored in the model is displayed to the users in the view of the application. Any changes that are made to the information as well as what information is presented to the user is mediated by the controller component of the application. For instance, users can create new microposts and delete old ones. These options are presented to the user by the presence of a delete button and micropost creation form on the view of the application. When the user enters a comment into the form field and clicks the “create micropost” button on the page, the controller picks up on this user interaction with the view and sends the comment to the model to save and displays the new post back onto the view. In summary, the model stores the information in an application, the view displays the information and ways to manipulate the information to the user, and the controller translates interactions made with the view into the proper changes that need to be made to the model, which in turn notifies the view of what has been changed.

2. Event handling is used in the Android SDK to recognize user input in order to trigger the correct response to the user input. In the Android SDK, event listeners provide an interface in the view class containing callback methods called when interactions are made with the view. Each method listens for a specific type of interaction (e.g. onClick(), onTouch(), etc.). Having specific methods for specific interaction prevents the need for one method to process all interaction. This is different from an event handling model such as WindowProc Event Handling in which one method picks up all signals of interaction and deals with each unique type based on a series of switch statements specific to each type of interaction. This model is less modular, but both models allow for the processing of different types of events.

Aman Sufi - 3/3/2014 17:26:52

1. MVC architecture can be demonstrated in pushing the accelerator in a car. The driver pushes down the accelerator pedal, delivering a message to increase the engine’s RPM to the controller given that the driver has started the car and the car is in a driving gear. In this case, the car’s interior, particularly its interface with the driver such as the accelerator pedal and the ignition keyhole/button, serves as the view the driver interacts with. The controller then calls the model to increase the engine’s RPM to accelerate the car, which the driver perceives through perception of movement as well as indicators on the dashboard.

2. Event handling in Android is done through event listeners which are interfaces usually attached to the view such as buttons or sound input. This is essentially an Object-Oriented Event Loop implementing the Listener model, allowing for applications and the OS to respond to certain events that take place. When an event takes place, the listener object derived from and inheriting from a listener class calls a function in the model that corresponds to the event. Procedure addresses are hidden in abstraction and the programmer only needs to worry about implementing that particular listener. This is similar to Callback event handling, although that method of event handling does not inherit listeners from a class and instead needs a full table of procedure addresses for each new activity/window.

lisa li - 3/3/2014 17:29:36

1. For example for the recent popular game Flappy Bird: Model should be the central piece of this game, which stores all the data, the rules of the game, the logics behind the game (how to determine win or lose, what are the logics behind generating different length of pipes, etc). And then Model updates View and tell View what should be displayed on the screen at a certain stage of the game.

View would be the interface that show the bird flying and the pipes. Also, view should also gives players feedback on the bird's position whenever they make a move.

Controller translates the players' input into model changes. In this game, whenever the player touches the screen, the bird should fly up for a certain height. Therefore, Controller is responsible to update Model and tell it that the user wants to make the bird fly higher.

2. Android SDK also maintains an event queue into which events are placed as they occur. In mobile devices, there are no mouse so all the mouse-related events Olsen talks about in the text does not exist in Android. Touch Screen movements replaced mouse movements.

Derrick Mar - 3/3/2014 17:29:53

1. I’m super stoked about this first question because MVC architecture is so prevalent not only in HCI, but in many application frameworks themselves. I think MVC is a great way to learn and write code that is understandable and clear. For example, let’s take the web application framework Ruby on Rails that utilizes the MVC architecture (and let’s say we want to create a web app that allows users to view today’s UC Berkeley events on campus). As stated in the reading, a model allows for information to be manipulated. In this case, we need to manipulate a model of “events” and also define what information these events will hold (even further, we need a database to be able to remember this information). Hence, we can create a model in rails that defines what information encompasses an event (e.g. title, description, location attributes) and can also specify how this information can be changed (e.g. validations, a title can’t be blank, etc…).

But now one may ask how do we actually see these events on a website? This is where the view comes in. The view for this particular application will allow a user to browse the events on campus. If we wanted to make our web app more comprehensive, we can provide a way for a user to manipulate an event or add information (e.g. favorite an event). While the view provides the “visual representation” to do this, we need the controller to be able to actually handle this input from the user and manipulate the model.

And finally, this is where the controller comes in. The controller allows us to handle the user’s expression (e.g. favoriting an event) and manipulate the model accordingly (in terms of rails for favoriting an event, this functionality would probably imply that we need a favorite Boolean attribute in the event as well as an association between a User model and events). Thus, I think the MVC architecture is a very intuitive way to build applications which is why many frameworks use the.

2. Event handling is based on the MVC architecture. A user is presented with a view that he/she can interact with. This view also has additional widgets that the user sees. The programmer can then place event listeners on widgets, which is the controller part of the MVC. In an event listener you can have instructions that manipulate actual models.

One of the event handling models discussed by Olsen is input events. When comparing to Android, the model discussed by Olsen are strikingly similar. Olsen emphasizes the three pieces of information in an input event: the event type, the location, and modifiers. All three are also present in Android (e.g. event type: you have different event handlers such as click or drag, location: you have different widgets placed in different places, modifiers: you have some modifiers like the shift key to capitalize letters). The only stark difference is that Olsen takes Input Events from the perspective of a desktop computer. He talks about mouse movement and keyboard events with modifiers such as Control and Shift and left-click which are not really present on a touch screen interface (e.g. you don’t often use a Control modifier).

Andrew Lee - 3/3/2014 17:32:40

1. I will use the Google+ mobile app as my example. In particular, I will examine the lightbox screen (the single-photo viewer).

The model consists of the current photo and its metadata, such as its caption, its owner, the +1's it has, comments, etc. If the current photo is part of a multiple-photo album, then the model also consists of the other photos in the album and their associated metadata.

The view consists primarily of the photo, along with a snippet of the caption, a +1 button, a share button, and a comment button. A card that looks like a normal Google+ post can be summoned, which consists of the full caption, the photo's owner, a reshare button, and the existing comments.

The controller mainly accepts taps and swipes on the touchscreen. Tapping the +1 button lets you toggle your +1 on the photo. Tapping the share button lets you share the photo through other apps on your phone. Tapping either the caption or the comment icon brings up the aforementioned card, which also lets you enter your own comment. This card can be dragged downward to dismiss it (pressing the back button does the same thing). Tapping the photo itself toggles fullscreen mode, so the screen isn't cluttered with UI while viewing. Swiping horizontally can let you move between photos in an album.

2. In the Android SDK, event handling is largely bottom-up. The most specific View gets the event. In some cases, the view can declare that they have not consumed the event, so that parent views can handle the event as needed. In the case of hardware buttons, events are propagated top-down.

Andrew Lee - 3/3/2014 17:35:27

1. I will use the Google+ mobile app as my example. In particular, I will examine the lightbox screen (the single-photo viewer).

The model consists of the current photo and its metadata, such as its caption, its owner, the +1's it has, comments, etc. If the current photo is part of a multiple-photo album, then the model also consists of the other photos in the album and their associated metadata.

The view consists primarily of the photo, along with a snippet of the caption, a +1 button, a share button, and a comment button. A card that looks like a normal Google+ post can be summoned, which consists of the full caption, the photo's owner, a reshare button, and the existing comments.

The controller mainly accepts taps and swipes on the touchscreen. Tapping the +1 button lets you toggle your +1 on the photo. Tapping the share button lets you share the photo through other apps on your phone. Tapping either the caption or the comment icon brings up the aforementioned card, which also lets you enter your own comment. This card can be dragged downward to dismiss it (pressing the back button does the same thing). Tapping the photo itself toggles fullscreen mode, so the screen isn't cluttered with UI while viewing. Swiping horizontally can let you move between photos in an album.

2. In the Android SDK, event handling is largely bottom-up. The most specific View gets the event. In some cases, the view can declare that they have not consumed the event, so that parent views can handle the event as needed. In the case of hardware buttons, events are propagated top-down.

Brenton Dano - 3/3/2014 17:35:36

1. Describe the Model-View-Controller architecture using an application of your choice.

In my currency converter app, the view was the MainActivity.xml file which displayed the text fields, the selected radio buttons, the images that corresponded to which currencies were being converted, and the numbers which makes up the main screen that was displayed to the user of the app. The controller is the Android keyboard that pops up when the user decides to enter a currency and also the radio buttons which they select which currency to convert from and to. The model, consists of the backend code that fetches the live exchange rates from CoinExchange and takes input from the controller, processes it (does the conversion calculation) and then displays it in the view.

2. How is event handling used in the Android SDK? Discuss similarities and differences to at least one of the event handling models discussed by Olsen.

Event handling in the Android SDK is handled with listeners. When I want to see when a button is clicked I can attach a listener to that button and whenever it is clicked I can trigger some function call. This is slightly different than the delegate model which was discussed in the reading. For the button example with delegates, the button object should declare a delegate type which describes the parameters and return type of a specific delegate. A delegate has delegate variables which can be called as methods whenever the click happens. The delegate model loops through all registered delegates for the button automatically.

Daniel Haas - 3/3/2014 17:35:37

1) I will use the application of chess as an example. The computer starts with a model (the initial state of the board, lists of captured pieces), and the view presents that state in the familiar form of a chess board. I have seen some interfaces that draw out the captured pieces as well, so that when players see the view, their mental model is exactly consistent with the computer's model. This prevents gulfs of evaluation where the user doesn't realize that a piece has been captured. Regardless, players perceive the view, then express their move by clicking on a piece, dragging it to a new location, and releasing the mouse. The controller translates those actions into an actual chess move (e.g. "Knight to d6"), then changes the model, informing it that the knight is now on d6. The model notifies the view of this change, and it redraws the chess board with the knight in its new location. Subsequent moves trigger further model changes and view notifications to redraw the board. In this way the MVC architecture presents a consistent view of the computer's model to the user, and allows the user to specify changes to the model using the interface.

2) Event handling in the Android SDK follows the interface/listener model discussed by Olsen quite closely. That is, views that need to be notified of events implement a set of methods defined in an interface like OnClickListener, and the listener interface's own definition handles the registration of listening views at compile and the dispatch of events to the views at runtime. However, on android, building custom listeners (event handlers) is more flexible: event handlers take direct user and system input events like onTouchEvent(), but can also intercept inputs like touch before they reach the parent views in the window tree (e.g. Activity.dispatchTouchEvent() ).

Cheng Sima - 3/3/2014 17:48:57

1) Describe the Model-View-Controller architecture using an application of your choice.

I will describe the Model-View Controller architecture of the mobile application "Talking Tom Cat". This interface uses both speech and graphics as its interactive medium. The view shows the graphics of a Tom Cat who will repeat the sound input from the user. The user speaks to provide sound input to the controller. The controller will capture and interpret the sound input and tell the model that this is the next sound to output. The model then tells the view to repeat the sound in a cat voice. The view's graphics will then change to a cat talking, and the sound will be a repetition of the captured sound input but in a funny cat voice.

2) Event handling in the Android SDK.

Event handling in the Android SDK uses a lot of listeners. There are many types of possible events such as click events, touch events, etc. Different listeners are set to respond to different events, and they activate methods in response. These listeners have a single callback method for each associated View object. For example, we can have an OnClickEventListener for a button view. When the button is clicked, the listener will activate and execute the action specified in the OnClick() method.

We can compare the Android SDK event handling with Olsen’s “Event Queue and Type Selection Model”. Olsen’s model involves a single switch statement to handle the events. The switch statement will execute the appropriate action based on what type of event it is. This is similar to the Android SDK in that a coded action is matched with and triggered by a specific event. Also, an onOptionMenuSelected method also has a switch statement to determine which menu option is selected and execute the appropriate action. However, there are many differences too. In Android, we can have a listener specific to a view object, so that there is an action associated with this object, not the type of object. For example, different button clicks can have different actions. Thus the listener model can handle more complex events, which is good for advanced user-interface devices such as the smart phone.

Cheng-yu Hong - 3/3/2014 18:04:48

1. The Model-View-Controller architecture separates applications into three parts: the models of the underlying data, the perceptions of the information, and plans of action. For example, in an application to notify the user of the next bus, the models would be the schedules of each bus route in addition to the GPS information of nearby buses. The views would include the input page to choose the bus route/stop information and the display page to show the time in minutes and seconds until the desired bus would arrive at the chosen stop. The controllers would include the code to parse the user input and query the database for the relevant information.

2. The Android SDK handles events through event listeners. Event listeners are objects specifically designed for event notification, and are associated with generic widgets such as mouse or buttons with methods to signify events such as mouse clicks or button presses. This event handling model is similar to the inheritance event handling model in that it also uses an object oriented structure. However, the difference is that the listener model associates events with the listener objects while the inheritance model associates events with the widgets. The event listener model generally separates the events into more specific groups, such as mouse and keyboard events, for easy code readability. The inheritance model includes a hierarchy of objects, such as the quit button that inherit from the button class, to allow for high code reuseablility.

Romi Phadte - 3/3/2014 18:38:14

1. For a given excel program, the view will be a grid of cells on which you can click. The controller would receive the click and allow you to edit the cells. Then the controller would give the data to the model which actually stores this cell data in a complex data structure, updating these values. The change in values will be immediately updated in the view where the user can perceive the effect of his or her actions.

2. Event handling used by android is inspired by smalltalk and control loops and callbacks. Basically classes that respond to input implement functions such as mousePressed, mouseMoved, ect (android is touch instead of mouse). These are listeners in android. The listeners call event handlers which are essentially callbacks. Control loops are used to record input from interfaces and call the appropriate method associated with that interface using a FIFO (first in first out) basis.

Chirag Mahapatra - 3/3/2014 19:09:40

Model View Controller helps isolate the business logic from the rest of the user interface. It has three parts in it: Model, View and Controller. The model manages the data and the behavior of the application. E.g. in a Google Search application the model would be a database of the indexes of all the web pages. The model responds to requests of information, changes in state and can notify observers. The view renders the data from the model and presents it to the user. This is the part which the user gets to see. In the Google search application, the view will be the results of the search which the user gets to see. The controller is the part which receives the user inputs and controls the model and view to perform appropriate action. In this case the input on the search bar goes to the controller which performs the search and returns the data to the view.

Events are used to collect data from the user about the interaction of the user with different elements of the interface. There are Event listeners, Event listener registrations and event handlers. Android maintains an event queue where events move in and out in a FIFO fashion. Event listeners are derived from the View class and look for user actions which is generally handled by a onClick action. Event Registration is the process by which an Event Handler gets registered with an Event Listener so that the handler is called when the Event Listener fires the event. The author mentions a top down approach to event handling. This does not happen in Android because it can take a long time for the user to get feedback while the tree is being traversed.