Engineering Interfaces II: MVC, Multithreading

From CS160 Spring 2014
Jump to: navigation, search



Andrew Fang - 3/1/2014 12:09:29

No, the Android SDK does not use the Model-View-Controller Framework. Instead, there are different elements of the SDK that serve the functionality of the model, of the view, and of the controller. For example, most elements of the UI are formed using XML, and resources in the drawable folders referenced by the XML. However, you can also use java to dynamically create and set UI components. The Activity classes handle most of events, including user input and logic processing. But you can also subclass these activities, or create your own java classes to control the flow of the application. In this way, the java classes form a combination of the controller and the model.

Android has processes and threads: each instance of an app running is a process, and that process can spawn multiple threads. For example, when we want to fetch data from the internet, we need to spawn a new thread and get the data on that thread so it doesn't interfere with the main thread. Here, this thread can be run in the background while our main thread that handles the UI and logic can continue without being blocked. Android also has a class called AsyncTask that allows users to run operations in the background and have it show up in the UI thread without having to explicitly manage threads. However, the thread or AsyncTask should be joined to the main thread if it wants to make changes to the UI. This is similar to the Swing architecture, where most components should be handled from the main event-dispatching thread. In both cases, we can spawn background tasks to run and compute figures, but they all must be merged back into the main thread should we want the user to see the results.

Zhiyuan Xu - 3/4/2014 14:30:31

The Android SDK has some components that are similar to parts of the Model-View-Controller paradigm. The View and ViewGroup classes as well as XML compose the view part of the MVC paradigm, with buttons, text fields and the UI layout. It provides the graphical user interface for an individual to use. The Activity class serves as a controller in the way that it knows when the user modifies the view (by adding Listeners), and can communicate with functions implemented in the back end. In the Android SDK, there isn't a clear class for the model part of the paradigm, but it is possible to represent the data in different data types and to implement the logic in an encapsulated way which could represent the model part of the paradigm.

The Android SDK deals with multithreading in a similar way described in the article. Like Swing, upon application launch, the system creates a single main thread, and requests are sent to the event queue whenever the user interacts with the application. Similar to Swing, tasks are executed sequentially and users will have a hard time cancelling an event because the task will be queued to be executed after the long running process. It is not thread safe, and the Android API recommends to manipulate the main thread from worker threads but keep all UI manipulation in the main thread. The concept of worker threads is different from the way in which Swing handles long-running GUI tasks. In Android, to access the main thread, one can call the main thread using methods such as Activity.runOnUiThread(Runnable), and View.postDelayed(Runnable, long). The Android SDK also offers the AsyncTask class which allows the application to perform asynchronous tasks and publish the results to the main thread. For each background thread, one can create a Handler which will deliver messages and runnables to the thread’s message queue, which will then be executed in order by the thread.

Ziran Shang - 3/4/2014 14:36:35

The Android SDK does not really follow the model view controller paradigm. Instead, there are activities and layouts, as well as user defined classes. The activity performs functions of both the view and the controller, since the activity has listeners for user input, performs the desired actions after receiving that input, and updates the layout. The layout does not have methods to process input; it simply positions the UI elements. This is different than MVC, because in MVC the view communicates input to the controller, which updates the model and view.

Android has many similarities to Swing. Android make use of Executor which is also used in the Swing examples in the reading. Both Android and Swing have a thread pool for background threads. Whereas Swing has SwingWorker, Android has AsyncTask, but these classes are fairly similar in functionality in that both perform background tasks and then give the results to the UI thread.

Charles Park - 3/4/2014 15:59:39

The Android SDK does follow the MVC paradigm, that is, for the views, you use XML files to determine the layout and interfaces as well as other recourses in the res folder. The java files handle the inputs and logic, that is the controller, and finally other java files or classes can also act as the model. Since there are clear distinction between the three different aspects, it does follow the MVC model.

AsyncTask, for instance, is used to create a task that runs processes in the background without interrupting the main thread. Therefore, the main thread is blocked until the workers are done. Android SDK can also create background process to handle long-running executions and background threads which is all pretty similar to the Swing mechanism in terms of how the threading works. Swing is also able to execute short tasks that stay as a part of the event thread and the longer tasks are assigned in a separate thread. Swing does, however, have FutureTask, similar to AsyncTask. A major difference is that while Android is thread-safe, Swing is not.

Michelle Nguyen - 3/4/2014 17:45:36

1. The Android SDK does not follow the Model-View-Controller paradigm. Loosely, we can consider some of the XML files in the resources folder (such as in the layout folder) as a view, since those files are mainly concerned with the presentation of our application. Next, we can think of our java subclasses as part of the data/information for our model. Meanwhile, the activity classes that perform the actions in response to the UI can be the controller. However, in Android, the view and controller are not as decoupled as they should be in the Model-View-Controller pattern. For example, we could have ListActivity or TabActivity, which should be part of the controller. However, it relies heavily on the kind of view being used. In the MVC paradigm, the controller shouldn't rely on the view at all--they should just interact. The activities also often directly reference the UI element as well, such as interacting directly with the TextView or Buttons.

2. To process long-running executions or background threads in Android, you can use Java threads, and most commonly, AsyncTasks. They are different from Swing mechanisms, because Swing is single-threaded. This is because of many deadlock problems with running multithreaded GUI frameworks. This forces Swing to do sequential event processing. However, with AsyncTasks, you can have more than one thread, so many AsyncTasks can run simultaneously. This allows the user to do parallel computations.

Nahush Bhanage - 3/4/2014 18:04:43

1) In my opinion, the Android SDK more or less follows the model-view-controller paradigm. "Model" corresponds to the app's internal state variables (usually maintained in the main activity class) and other resources (drawables, strings, dimens in the res folder) - these elements define the domain model of the app. "View" corresponds to the layout XML and classes that extend the View class - these elements define what to display on the user interface. "Controller" refers to the event listeners (usually defined in the main activity class or another private class) that catch user interactions on the screen and act upon them to update the model elements. Accordingly, the controller updates the view to notify that the changes have been made. Model, view and controller objects in an Android application may not always correspond to distinct classes, though the programmer can do so if there's a need for a strict adherence to the MVC paradigm.

2) Long-running executions, if handled in the main UI thread, could block it and make the application unresponsive. These executions should be handled in separate thread that would work in the background. Android provides multiple ways of achieving multi-threading, which are as follows:

(a) Runnable interface - Tasks which are not instantaneous could be delegated to worker threads created using the Runnable interface. The worker thread would work on the delegated tasks without boggling down the UI thread. The only restriction here is that the worker thread (created as above) cannot access the Android UI elements. Any modifications to these elements have to be done from the UI thread. (b) AsyncTask - Android provides a mechanism called AsyncTask specifically to delegate blocking tasks to a worker thread which updates the UI as required. To use this, the programmer needs to create a separate class which extends AsyncTask and override the doInBackground() callback method, which runs on a pool of background threads. Whenever execute() is called on object of this class from the UI thread, doInBackground() is called in the worker thread. onProgressUpdate() method can be used to update the UI about the task progress. When doInBackground() finishes execution, control goes over the onPostExecute() method which delivers the result from doInBackground() to the UI thread. AsyncTask also provides onCancelled() method to cancel the task execution.

Similarly, Swing provides the SwingWorker class to execute long-running tasks in background threads without affecting the application responsiveness. It includes an Executor which works on a cached pool of threads similar to AsyncTask. It also provides a mechanism called Future which enables task cancellation and progress indications. These classes are generic to Java and can also be used in an Android application.

Seth Anderson - 3/4/2014 21:07:21

1) The Android SDK absolutely follows the MVC paradigm. First, the View can be found in the XML coding of the app: this is the programming done to create the display that will be shown to the user, or, create the "View". In the MVC model, we see that the View is edited and updated by the Controller. Thus, when bringing the paradigm into Android, the Controller can be thought of as the Activities created in the java document. Methods such as onTouchListener wait for user input and can make adjustments to the View as a result, or edit the Model, which here is the underlying data given to the app. The data can be input manually or extracted from the web, but wither way, it is this data (strings, ints, etc.) that the View and Controller (XML files and Activities in java respectively) need to pull from in order to operate.

2) One of the simplest classes in Android that handles background threads and especially asynchronous threads is the AsyncTask class. This class (which can only be used by creating a subclass of it), uses 4 methods to ensure the program will run smoothly with multiple threads. onPreExecute(), which initializes the class, doInBackground(Params...), which preforms background computations that may take a long time, onProgressUpdate(Params...), which displays background progress, and onPostExecute(Result), which is executed after the background task finishes ( This is very similar to the Swing mechanisms, which "set" and "get" background processes. The set is very similar to the execution methods of AsyncTask, while the get is similar to the onProgressUpdate method.

Zack Mayeda - 3/4/2014 21:58:08

1) The Android SDK does follow the MVC paradigm. The view is represented by XML, the controller is represented by the various Activity classes in an app, and the model could be represented by a couple things - data retrieved through an API or data stored locally in a file or with SQLite.

2) Android provides a couple mechanisms to help developers with long-running tasks. One mechanism is the AsyncTask class. It allows programmers to run a background task and update the UI with results upon completion. AsyncTask is good for tasks that take a couple seconds, so mainly items that need to be run in the background but aren't continually running or run for a very long time. Android also provides access to the java.util.concurrent library which has features to customize thread execution. A more straightforward way to run background threads is to use the IntentService class which allows the developer to run a background thread without affecting the UI. To publish the results of the background thread to the UI, the IntentService thread must sent its information to an Activity.

Android is similar to Swing in that there a single thread that controls events/UI. In Android there is a UI thread that handles updates to the UI and in Swing there is an event thread that handles all UI events. The concurrent library and Executor class can be used by both Android and Swing, so they are similar in that respect. The notion of pulling a long-running thread out of the UI/event thread is common to both platforms.

Luke Song - 3/4/2014 22:14:05

The Android SDK easily provides everything that the MVC pattern requires. The View part is easy; Android provides boatloads of different graphical user interface components for the designer to use; from buttons and text boxes to layouts and custom views. The Model can be whatever the implementer wants it to be; the Java language is both powerful and versatile, and the structures that it can support is almost limited only by the imagination. The description of the Controller is a bit shady; it is almost part of the View. The Views are objects that can allow for event handling to be added individually; one can describe the event listeners consumed by the Views to be Controllers. Once the listeners handle the events, the methods called can proceed to update the models or views as expected.

The Android toolkit allows for the creation and running of threads; however, anything that accesses the UI toolkit must be called from within the UI thread. The reason that the single-threaded model for GUI frameworks is common is because of deadlock susceptibility; that's why the toolkit should only be called by one thread throughout the lifetime of the thread. Views and Activities on the Android toolkit provide methods, such as "runOnUiThread" or "post," which allow the programmer to call with a Runnable argument to be processed by the UI thread at some point. This is similar to Swing's "invokeLater" and "invokeAndWait" methods. Android also provides an AsyncTask class, which organizes the programmer's intentions by providing two varieties of methods to be implemented: one to be run on its own thread, and the other which will be called from the UI thread once the first is complete. The Swing analogue of this class would probably be the SwingWorker class.

Sergio Macias - 3/4/2014 22:47:06

1. Android SDK does not follow the Model-View-Controller (MVC) paradigm. One reason is that, in Android SDK, Model and View are combined together. For example, let’s say you create an app which just changes pictures once you click on the current picture. In the MVC paradigm, you would have to have the image and the function which handles the changing of the image as two separate entities. To put it into MVC, I would have to create a new view object to hold the object, then have an on-click listener for when someone click’s the image. The control would then go away from the view object to the controller (which handled the click itself) to the model object which knows how to handle the on-click user action. The model object would retrieve the next image and then update the view object. In SDK, this is not how it works. If I wanted to do the same thing in SDK, it would go as such: Create a new activity which displays an image (model part), then go into that activity class to add a listener (control part) for the button, then define a function for when that specific action, which I am listening for, is called (model part, as it embodies the business logic, i.e. defines the logic and handles the computation that manipulates and processes the data). While you could say that the Android SDK has the MVC paradigm within its components, it would not be true to the MCV paradigm since one of the main points of the paradigm is to keep the three components separate and independent from one another. 2. The mechanisms which one can use to handle long-running executions and backgrounds threads is similar to the swing mechanisms. One way to do it is to implement the runnable interface, in which you put the long-running operation in the run method (which is required to be implemented since the class will implement runnable). The way Goetz implements having a long-running task with user feedback on page 16 is very similar how you could do it with this (implement runnable interface) method. You would just transfer his try-catch in run() of listener to the run() of “this” class (whatever class is implementing the interface), with a few changes to how the other threads are created/handled. Another way to handle background threads is through the use of the AsyncTask class, which creates background threads and syncs them with the main thread once they complete. AsyncTask class is a bit nicer since it supports reporting the progress of the background task to the user, but a disadvantage is that it does not handle configuration changes automatically.

Jay Kong - 3/4/2014 23:31:34

Yes, I believe the Android SDK follows the MVC paradigm in the sense that data and its views are separated. The view in the MVC model essentially dictates how data is presented, or "how to render". In the Android SDK, the "view" of the MVC is controlled with XML layout files, drawable resources, and built-in classes such as RadioButton. These parts of the Android SDK provide the answer to the question "how to render". The "controller" in the MVC model governs user-input/interaction behavior. This is implemented in the Android SDK as activity classes. The activity classes provide logic on what the system will do in response to various inputs. Finally, the "model" in the MVC model is the core structure of the system. In other words, it's "what to render". This is represented by all the classes and functions that implement the logic of the application in Android. The "model" in the Android SDK is very vague in that sense that different parts of the system can all contribute to the "model" of the application.

In Android, AsyncTask provides a simple way to perform tasks on a background thread. The results are then published on the main UI thread. AsyncTasks are good for tasks that are time consuming and usually run once, such as a file download (this is shown as the example for AsyncTask usage in the Android documentation). However, if you need something to be continuously running in the background, Android provides Services. Services are good for background tasks because they execute even when the corresponding Acitivties aren't open. Android's approach to long running tasks is very similar to that of Swing's. Both Android and Swing are single-threaded subsystems. Long running tasks on the UI thread can easily compromise responsiveness. Therefore, the solution to those tasks is to run them on background threads. Android provides easy ways to do that, while Swing requires more work since it's necessary to put together your own framework.

Andrew Chen - 3/4/2014 23:46:58

1. The Android SDK does follow the Model-View-Controller paradigm. The models are represented by the classes that the developer creates to hold the data of the application. For example, if you have a bitmap that you are coloring, then the bitmap class would be your model. The views consist of the items in the layout that the user can interact with, such as the button class or canvas class. By interacting with these items (the view), the user invokes controller functions, which in this case are the listeners and their respective operations after receiving an event. These can be considered controllers, because they normally will trigger modifications in models or views (depending on which direction the chain is going). 2. In Android, the main mechanism that helps developers with long-running executions and background threads is the AsyncTask class. It provides a way to run an operation on a background thread, and it also provides methods for notifying the UI Thread of progress (either while it is still running or when it finishes). This is similar to the Swing mechanisms, especially the BackgroundTask abstract class. It essentially provides all the same methods, such as keeping track of progress, or polling for cancellation by the user, so on and so forth.

Shana Hu - 3/5/2014 1:07:50

The Android SDK loosely follows the Model-View-Controller paradigm. Each Activity class is similar to a controller in which the program can interpret actions users have made in views. Activity classes are responsible for updating the models, which in Android corresponds to subclasses which encapsulate data. Views in Android are represented by View classes and View subclasses, which the user can directly interact with via the XML layout.

Android has one main thread which queues events that are triggered on the interface and then loops through them. Statements are executed in order by default, but developers can utilize Thread classes to perform asynchronous tasks. Handler classes can register threads to allow concurrency. This is unlike Swing which is solely singlethreaded.

Andrea Campos - 3/5/2014 1:45:05

1. I would say that for the most part the Android SDK does follow the MVC paradigm. The layout xml files correspond to the view, as they arrange what users see on the screen and how information is presented. The source files such as the main activity class correspond to the controller, as they specify what occurs when events take place--this is generally where one places event listeners and handlers, to update information or change the layout of the screen. The "resources" of Android is what largely corresponds to the model, as they are saved pieces of information, such as text, pictures that form the data of an application and may be presented to the user and manipulated.

2. Android, like Swing, handles and dispatches events in a single event thread, and allows you to perform long-running execution in background threads. In Android one can do this by creating a new Thread object. There is also the Async class which allows you to separate the work that must be done in foreground, and the work that must be done in the background, while supporting cancellation/interruption of tasks, as well as progress indication. Swing too supports this functionality through various methods, though Android makes it a lot easier by having the class already provided which one can just extend.

Jimmy Bao - 3/5/2014 1:45:43

1)Yes, the Android SDK does follow the Model-View-Controller paradigm. In an Android application, what the user sees on the screen is the view. The user is able to interact with the application by either touching the screen, inputting text. or something of the sort. These actions correspond to the controller since when the user performs some of these actions, the application has to figure out what the user did and reflect the changes to the view by calling the model. In turn, the model is just the underlying functionalities of the applications that make it work.

2) We learned from the IPA1 that if we want multithreading in Android, we can use Async Task, which allows an application to perform background operations and publish results on the UI thread without having to manipulate threads or handlers. We don't want long-running executions on the main UI thread because that would slow down things too much and could potentially cause the entire app to hang. I think it's similar in the sense that both Android and Swing are implemented as single-threaded systems. However it is also different since in Android, we can use Async Task to be able to run tasks in the background to go beyond the bounds of a single-threaded system.

Juan Pablo Hurtado - 3/5/2014 1:57:29

1. It doesn't follow the MVC per se, but you could say that the model is the server of the app where you store the objects, the controllers are the Activities and the Views are the XML files with the layouts.

2. They have a main thread for the application and UI thread for anything related to the UI and also you have the option to start “workers” which are background threads. It is pretty similar to Swing, because Swing uses a separate thread to the main thread which is called the “event thread” and also it uses helper classes like SwingWorker and/or BackgroundTask for other tasks that need a thread.

Doug Cook - 3/5/2014 2:14:36

The Android SDK does not follow the MVC paradigm (unless you implement it yourself). Rather than explicitly delineating the MVC components, Android’s SDK structures code based on the task the user is performing by means of Activity objects. This organization accomplishes similar goals to the MVC architecture by approaching it from a different perspective. There are some parallels between the two approaches – Android XML files, for example, allow developers to construct their Views and resources. The SDK actually takes care of most of the “view” work by handling drawing based on what resources are defined. The model and controller components of MVC have their lines blurred in Android in that both are implemented in an Activity class. Common ground between the MVC architecture and the Android SDK is found in their reliance on events. Android exposes a robust event and listener mechanism for responding to user input, much like the MVC framework specifies.

Android facilitates long-running executions and background threads slightly differently than Swing. Some of the most accessible components are once again part of Activity objects: the onStop() and onPause() methods (called when an Activity is no longer the front-most view) allow the object to perform work in a different thread than the one currently serving the user (presumably another Activity that took its place). In this sense, Android rotates threads in and out of the “view” role. While one Activity is drawing the UI, another could be executing tedious work in the background without interrupting the user. Swing, by contrast, requires explicit declaration of objects that will oversee the background tasks. It’s worth noting that Android allows this functionality in the form of Services if the developer needs something to persist in the background.

Tien Chang - 3/5/2014 8:49:07

1) I do not believe the Android SDK completely follows the Model-View-Controller paradigm. The view could be the XML file with layouts and the interface of widgets; this is mostly in the res folder of Android SDK. The controller could be the Main Activity Java and other Java files in the src folder. Although one may argue that the creation of classes in Android SDK could act as models, however I don't believe that is enough to fully follow the MVC paradigm.

2) Android's AsyncTask helps developers handle long-running executions and background threads, particularly those that report to the UI thread. Methods of AsyncTask, including doInBackground(), onProgressUpdate(), and onPostExecute(), help to determine what thread to do in the background, what to do when the thread is in Progress, and what to do when the task thread is completed.

Swing follows the Model-View-Controller paradigm and also single-threaded programming, unlike Android SDK. Instead of having multiple threads, Swing has numerous listeners and utilities to invoke waiting or scheduling Runnable tasks.

Allison Leong - 3/5/2014 9:17:55

1. The Android SDK implements a hybrid of the MVC paradigm. It is possible to loosely draw associations between the different classes in the Android SDK and the model, view, and controller paradigm. The model is the information to be rendered, which in Android consists of the resources stored in various XML files. The view deals with how to render the information on a user interface. In Android, this includes the layout XML files that contain UI components as well as the functions in the Activity class that alter the content in the user interface. The definition of the controller in Android is ambiguous. It would be wrong to call the Activity class the controller because views are rendered through the Activity class, but functions of the Activity class do handle events and user interactions in the way that a controller would. Therefore, the Android SDK implements a hybrid of the MVC paradigm in which the Activity class acts as a sort of ViewController.

2. Android and Swing are similar in that they both run their applications in a single thread of execution, known as the “main” thread or the “event” thread respectively. In Android, long-running tasks should be handled in a very specific manner by worker threads. The Android UI toolkit is not thread-safe, so changes to the UI should not be made from a thread other than the main thread. To fix this problem, methods such as Activity.runOnUiThread(Runnable),, and View.postDelayed(Runnable, long) allow access to the UI thread from other threads. Swing uses a similar mechanism called “thread-hopping” in which the event thread calls on worker threads to execute long-running tasks in the background, and once those tasks are completed, pushes a subtask back to the event thread to signal completion. Additionally, Android allows developers to handle more complex worker-thread interactions through the creation of AsyncTasks.

Jeffrey - 3/5/2014 10:47:28

1.) The Android SDK absolutely follows the Model-View-Controller paradigm. The model would be classes in the background like bitFactories, arrays, bitmaps and such that the user never sees. Controller classes are the listeners classes which connect View portions of the paradigm to the model and vice versa. Finally the View portions would be the buttons, text, images, fields and layouts the the users sees.

2.) I have had a little experience on Swing (mostly coding up 30 sided dice and drinking game rules for my own amusement) and it has a thread dispatcher. Android have something incredibly similar called a handler that will allow you to execute run-ables outside the ui thread.

Nicholas Dueber - 3/5/2014 11:27:20

Android allows for the development of a unique Model-View-Controller paradigm with slight differences. In Android, you can define various xml files which could be constituted as a Model and who supply how a view looks, and you create various java classes which interact with the xml files which can be understood as the controllers. However, the controllers may dynamically obtain information and change the view so as to bypass certain model xml files. Android can also instantiate difference activities without the controller/user giving input to do so. This bypasses the MVC model.

Swing is a java library that only supports single threading. In android, you can change the manifest so that it alerts the phone that this program may take up multiple threads to complete the task. Android allows you to have processes running in the foreground as well as in the background.

Gregory Quan - 3/5/2014 11:27:50

In some ways the Android SDK follows the MVC paradigm and in some ways it does not. One could argue that the model corresponds to data in the /res folder such as images, strings, etc., the view corresponds to the layout files, and the controller corresponds to the Activities. However it is not entirely clear whether an Activity should be considered a view or a controller, since it handles both displaying a window to the user and also handles the events of that window. In this sense, it is both a view and a controller. Technically, the idea that something is both a view and a controller is not allowed in the MVC paradigm, so the argument could also be made that the Android SDK does not use the MVC paradigm.

Android has a Runnable class that allows the programmer to run code in its run() method on a separate thread. It is the basis for the FutureTask class that allows code to run for long periods of time on a separate thread. Also, Executors and ThreadPoolExecutors assist with scheduling and executing Runnables. These objects are similar to the Swing mechanisms, and one would expect this to be the case since both Android and Swing are based on Java. In fact, Android implements its methods from the java.lang and java.util.concurrent packages.

Ryan Yu - 3/5/2014 11:49:52

1) Android SDK doesn't really explicitly follow the Model-View-Controller paradigm, although a developer can write classes that essentially structure his/her application into the MVC framework. However, one can see that some classes and files equate more or less to certain facets of the framework -- for instance views are defined in various XML files, as are resources. These can act more or less like the Views and the Models in MVC. Activity classes can act as controllers if the developer chooses to structure them as such; however, there is a fine line between the functionalities that could potentially go in an Activity, which is why Android doesn't really fully model itself after the MVC paradigm.

For instance, in Android SDK, models and other resources can be defined explicitly inside of an Activity -- for instance, a developer could instantiate a button or a spinner inside of the Activity, and it would work perfectly fine. This goes against the principles of separation that MVC is known for; for instance, in Ruby on Rails, where MVC is strongly enforced, all models are defined in their separate .rb files, which are placed explicitly in a "models" folder in the "application" directly. This is true also for the controllers and views to reinforce that all three different resources should be independently working of each other.

However, it is important to note that, as mentioned above, a developer could write classes and code that makes their application fall more along the lines of MVC. They could, for instance, write an explicit controller class (extending Activity) for each View that they have, and vow to only define view objects within their XMLs. By following these guidelines, the developer could moderately easily make their application follow MVC.

2) From what I have read, the best solution to handle complex interactions within multiple worker threads is to use AsyncTask, which allows the developer to perform asynchronous work on the user interface. In fact, it performs the "the blocking operations in a worker thread and then publishes the results on the UI thread, without requiring [the developer] to handle threads and/or handlers [themselves]". Other than this, the activity lifecycle diagram shown here:


maps out some of the methods that an activity can call if they need to be paused, killed, or otherwise modified to make use for other activities/threads. Specifically, an application could pause to make use for another thread, and its onPause() method could be called, which could potentially allocate memory for the other thread to do its work.

Although I believe AsyncTask is specific to Android SDK, the code outlined in the Swing read looks a lot like the code I'm used to seeing within Android SDK -- there are essentially a bunch of methods that outline what to do if a thread/task is interrupted, if an action is performed, etc. For instance, Listing 9.6 outlines the application's functionality if a task's action is interrupted, and makes a call to cleanUpPartialWork() to undo the changes that have already been made. Overall, it looks like the Android SDK's mechanisms that help developers deal with long-running executions and background threads was taken at least in large part from inspiration with Java Swing's complexity -- the reading mentions repeatedly how things can get complicated with 3 or more nested classes inside of one method. I believe that the intent of Android's AsyncTask was the minimize this confusion.

Steven Wu - 3/5/2014 12:18:12

Android does follow the model-view-controller paradigm. In fact, the MVC concept can be adopted to any framework that wants to follow the paradigm. The paradigm is simple. You must have a model that sets the templates and what to render, a view that helps presents the GUI and a controller that can handle user input and realizes what to do with certain user actions. But with all of this, it is important to make sure that the view and the data are not considered interchangeably. Views have the responsibility of processing data. Generally, you have the UI components that are the view, and the Activity classes are your controllers. And with the controller, it bridges the interaction between the model and the view.

The Goetz et al reading describes threading issues with Java Swing. Android and Swing are very similar in their properties and issues with threading. Android's AsyncTask is a class in Android that manages a long-running or background task. Swing has SwingWorker and BackgroundTask classes with in turn manage the long running/background tasks. The logic behind multithreading in both is similar in this way. Similar functions can be called in both environments like wake and sleep. However Swing has a shortcoming since Swing doesn't provide specification to access UI elements to execute in another thread as easily. Swing only makes it simple for a task to run in the main thread.

Ian Birnam - 3/5/2014 12:32:09

1) The Android SDK does follow the MVC paradigm, though everything is encapsulated inside the Activity class. The view is the XML layout, and any classes that have to do with displaying information to the user (such as the View class, or anything that extends the Activity class). The model is also encapsulated within the Activity class, as that's where all the information and data is kept. Information is also kept in the res library, such as string values. The controller models is done via listeners such as onClick or onTouch. These happen inside the Activity class, and are what control changes in the view to the user, as well as data in the model objects.

2) Android has the class AsyncTask, which can spawn off background threads so that you don't block the UI thread. Much like Swing, Android uses only 1 thread for its UI, so if you want to run a background task without blocking the UI thread, you need to use AsyncTask. However, AsyncTask is only good for short term usage. For long-running executions, you want to use the various APIs in the java.util.concurrent package such as Executor, ThreadPoolExecutor and FutureTask. This can be simpler than Swing, since not as much nesting is involved as is needed for how Swing handles long-running tasks.

Rico Ardisyah - 3/5/2014 12:36:24

Android SDK does not exactly follow Model-View-Controller paradigm. It somehow has MVC paradigm; it has model class and view class, but it does not really have a connector class between this two classes. Following the paradigm, Android SDK has view class, and it is represented by the XML file. All the buttons, output and input for user is shown. The developers can modify it from the code and GUI. The model and controller class are somehow merged into one class, which is Java activity class. Data fetching and data processing happens in this class. Also, the output of the process is also rendered in this class, and it will be passed to view classes. As the matter of fact, the controller role in Android is handled by listener.

Similar to Swing mechanism, Android SDK help developers with long-running executions and background threads using AsyncTask. It can create a task runs in the background without interrupting the main thread, return progress, completion notification, and cancelable option. Hence, It is similar to Swing’s BackgroundTask.

Vinit Nayak - 3/5/2014 12:46:52

Android is a pseudo MVC controller, to where it embodies some of the characters of the framework, but adopts them in a unique way. The view and controller aspects from MVC are present in Android, where the xml files in /res/layouts are analogous to views and .java *Activity files are the controllers corresponding to the xml files. There are similarities such as the user not being able to interact with any part of the Android framework besides the Views that are present on the screen at any given moment. Another similarity is that a view corresponds to one controller, which is the only way for the view to communicate with any of the data of the application. Having said that, this also presents a difference between Android and classic MVC, where in android there is a 1-to-1 relationship between a view and its Activity java class. Multiple controllers (activity classes) cannot be the direct contact of the same view, as is possible in other MVC frameworks, such as Ruby On Rails. This creates a dependency and can be argued to deviate from the modularity provided by the original MVC framework. The Android framework also does not require a model to operate; this design decision depends entirely on the scope of the application. Models in android can be represented as regular Java Classes which represent objects of different entities in the application (User object, Event object, etc). They can also serve to be more complex and have models interact with databases to allow persistent data manipulation on the phone itself or external data sources. However, none of this is necessary and an application can successfully live on simply an xml layout file and a single activity class.

Android has multiple background threading systems, some which are part of the original Java SDK. Android specifically provides "Services" for any kind of background running process. This is not to be confused with running a background thread, as a service will run on the thread it was launched from (application's main thread, usually) and if it consumes too much CPU, can possible block UI. To create it as a separate process, Java allows the developer to manually create new threads using the Thread class or other abstractions such as the ExecuterService class, which allows for each thread spawning and management. Android specific versions of this include the AsyncTask, which are used for shorter term background tasks which run in their own process without blocking UI. Android is similar to SWING in that there is only one main UI thread running (the same thread that runs the entire application process), and like SWING is controlled by an event firing queue running on a single thread. Android also follows the "Swing single thread rule" as described in the text, meaning simply spawning an AsyncTask or manually creating a separate thread will not allow you to manipulate UI toolkit elements. Technically speaking, the access/manipulation of UI elements will be possible and the application might not immediately crash, but the Android system has not made multiple UI thread accesses thread safe, which could result in undefined behavior of the application (and in the worst case, a crash or ANR).

Lauren Speers - 3/5/2014 13:15:25

The Android SDK follows the Model-View-Controller paradigm without explicitly relying on a Model class. The classes that extend the View Class, like ImageButton and Spinner, collectively correspond to and create the view. The Activity classes, which allows programmers to attach behavior to the view objects, correspond to the controller for an application. Finally, the collection information contained in custom instance variables and the logic contained within custom methods and classes correspond to the Model.

Android helps developers handle long-running executions in three main ways. First, programmers can assign a component to a process other than the main UI process in the manifest. They can also manually start additional worker threads to handle long-running processes, but these worker threads can neither block the UI thread nor access the Android UI toolkit. Finally, Android programmers can extend the AsyncTask class to handle long-running processes without manually starting and handling worker threads. These mechanisms are very similar to the Swing mechanisms – they place similar restrictions on what objects can be accessed and manipulated by non-UI threads, and they provide similar functionality. However, unlike the Swing mechanisms, the Android AsyncTask class allows the programmer to abstract away the implementation details of using multiple threads.

Additional Source:

Anju Thomas - 3/5/2014 13:15:39

Does the Android SDK follow the Model-View-Controller paradigm? If so, what classes correspond to the model, the view, the controller? If not, how is the Android SDK different?

The Android SDK follows the Model View Controller paradigm. For instance, Android SDK follows the Spring Model View Controller. It consists of three main sections: the Model, the View and the controller. The model represents the data managed for the application. It is a representation that organizes data into a model. For example, in an application such as the costco android app can have models java classes that represent each item in the store and its details. For instance, Item Name : “Cornflakes”, Description : “Type of Cereal” and Cost : $7.00.

The next section View represents the classes that directly involve user interaction and update of the view. For instance, the res section includes layouts and other drawable folders. The layouts are usually implemented in XML format but can also be manipulated by the programmer graphically and using Java code. An example of the view would be the list of item purchases made by the user -for ex: purchases.xml - which would be updated on the site every time the user tracks their payment history. This allows the user to receive instant feedback and satisfies one of the heuristics described by Olsen.

The Controller Section of the application includes the main classes in Java src folder. These classes usually include event handling. For example, a class such as could include event handlers such as onClickListeners that senses user action and handles the response of the button click. For instance, the Main Activity class could redirect to another page, such as items list when the user clicks the tab in the Home site. It determines the main control of the application.After the user action the controller usually directs the View and Model section to update to reflect the necessary user changes.

2. What are the functions, objects and mechanisms in Android that help developers with long-running executions and background threads? Are they similar or different to the Swing mechanisms?

There are various functions, objects and mechanisms in Android that help developers with long-running executions and background threads, which are similar to most of the Swing mechanisms. Android’s AsyncTask method is similar to Java Swing’s Swing Worker and can also be used to perform necessary operations and uses the same UI thread to display the output. By using the AsyncTask method, the programmer has greater freedom by having loose control on the handlers. In this way, the task becomes more straightforward for the programmer and enhances the learning process with which the programmer can handle events on the UI thread. This also simplifies the control flow. Another strategy is to create a thread in the main method that will run() the application.

There are four main methods carried out by an asynchronous task. onPreExecute(), which is run on the UI thread. This method displays a progress bar and steps up the task. doInBackground takes in the arguments for the asynchronous task and does computation that result in long time process. The onProgress Update shows the user interface progress status and logs. OnPostExecute started on the UI thread as well. Takes in the final result of the background computation.

Android and Swing are also very similar though Swing is more predated. For instance, the events in Android are similar to the way events are handled in Swing. Both of the mechanisms are single threaded rather than multithreaded and is applicable to a broad spectrum of applications. Though there are some similarities between Android and Spring, there are also some differences. For instance, Android is more flexible in providing cancellation mechanisms as an alternative to unresponsiveness. Swing usually however the cancellation is sometimes handled by shutting the program.

Another example is that Android takes some steps to make an application thread safe. It resolves it by having message queues which handles each message. A single thread takes messages one by one from the queue. A similar notion was used in Swing to resolve such problems, which consists of Event dispatching thread and SwingUtilites.invokeLater() function.

Alexander Chen - 3/5/2014 13:34:19

Android has a pseudo-MVC framework. When I refer to MVC, I'm talking about a component that provides persistent data storage, a component that renders the interface for the user, and a component that manages events, the view, and the model.

The "layout" xml could be considered part of the view. It provides a structure for designers to create the presentation of widgets they want to display for the user. However, a gray line exists, because a default view class exists, and can be extended and dynamically added to the interface by the controller. Widgets in the view provide callbacks to allow the controller to perform the appropriate action, updating the model or view if necessary.

The "resource" xmls are part of the model component. These files store data that is passed to the view via the controller to be displayed to the user. Additionally, libraries that allow the application to use a local, lightweight database, like SQLite also exist for Android. The database also makes up another part of the model.

Finally, activity classes and other modules that make changes to the database or case the view to update can be considered part of the controller component.

There are some quirks to the "MVC" in Android. If the model and controller aren't instantiated in the application class, changing the orientation from landscape to portrait might cause these two to be recreated. From ""

Android provides the abstract class, AsyncTask, to help designers move long running processes to another thread, to ensure the UI is responsible during the task. This was shown in IPA1, where the task of fetching the latest bitcoin and dogecoin exchange rates needed to be run on a separate thread from the UI thead. Any attempt to run the exchange rate fetch on the UI thead would case the android framework to throw errors.

Swing's BackgroundExec class allows designers using the framework to do the same thing as AsyncTask in Android. This class starts another thread to allow the long running task to take place without sacrificing responsiveness from the UI thread. Additionally, Swing allows for designers to easily give visual feedback, 'like a progress bar" , and gray out certain widgets during the long-running task. Cancellation of the task is simple too- the designer only needs to provide a methods to "clean up" the changes that the long-running task had made before the cancel interrupt.

Andrew Dorsett - 3/5/2014 13:41:15

I don't think Android SDK necessarily follows the MVC but you can implement something similar. You can say that the XML file is the view. It's what the user sees and knows the positions of objects. The code we write is the controller. We decide what to do when a button is pressed, what values to use, when to draw, etc. The main problem is I don't believe there is something that's similar to a standard model. You could consider the Android file system to be the model, but I feel like that is a little bit of a stretch.

There are the event listeners, the widgets, and our functions. We create or place those. The reading broke it down into multiple stages involving listening and executing on different threads (background and event). Android supports typical Java threads but also Handlers and AsyncTask. Handlers binds to a particular thread and allows you to send and receiving information. AsyncTask is similar to the reading's explanation of long-running tasks. It lets you access the UI thread and perform background operations and then publish the results.

Tristan Jones - 3/5/2014 13:44:51

1) I don't think this is the right question to ask. Android doesn't force programmers to follow the Model-View-Controller paradigm, but contains enough features to allow programmers to follow it if they wanted to. A programmer can choose if he/she wants to follow this design paradigm or not. So, to answer the question, Android does not follow the MVC paradigm: it implements a superset of the MVC paradigm and programmers can choose if they want to use it or not.

Elizabeth Y Lin (talk) Elizabeth Y Lin (talk) 08:22, 17 March 2014 (PDT) 08:22, 17 March 2014 (PDT)

2) For short UI tasks, a feature Android provides for background threads is AsyncTask. It's very convenient to use: you can call it from a UI thread, it initiates a task in background thread, and when it finishes, it automatically updates the UI thread. You can also check its current process.

The API for this fellow is as follows: doInBackground() -- Call this in your UI thread, and it runs in the background onProgressUpdate() -- Check how this thread is doing onPostExecute() -- Called when the background thread is finished, it can update the UI thread

There are other features that help Android programmers with long running tasks. This includes creating creating special Threads and Handlers using the java.util.concurrent package (which takes effort to use). You can also use the NDK I believe to make fast background tasks.

The Android implementation is very similar to the Swing mechanism. Both of them are have single threaded GUI implementations for the reasons discussed in the reading: writing a concurrent GUI implementation is hard for API designers, and hard for programmers to implement without verbose docs or strong API implementation understanding.

Daniel Haas - 3/5/2014 14:00:19

1) Though the Android SDK does not explicitly encourage the use of MVC (as iOS does), MVC can be implemented on top of the Android SDK. View classes in android correspond to MVC views (and can be defined in code or XML) and Activities correspond to MVC controllers, which pass updated state to views and cause them to redraw themselves. There is no explicit definition of models in the android SDK, but it is easy to implement arbitrary model classes which are updated by activities and notify other activities when they change by firing events. Of course, android developers don't need to follow the MVC paradigm: views can be listeners for events fired by other views, and activities can maintain their own private "model state".

2) In Android, the primary mechanism for executing long-running or background tasks is the AsyncTask class, which forks a new thread, runs the task's code in the background, and syncs with the UI thread (with the onPostExecute() method). The use of AsyncTasks is highly structured, in that it expects defined types for input and output values of the task, and it handles progress update syncing with the UI thread (onProgressUpdate() ). This is highly similar to Swing's SwingWorker class, which also takes structured types for intermediate state and output values of the type (but not input--SwingWorker.doInBackground() takes no arguments) and handles progress updates, cancellation and other event firing during background processing. Both Android and Swing also allow lower-level control over background threads if desired: android uses Handlers and the method to execute specific runnables on non-UI threads, and in Swing you can simply build your own thread pools and run new threads as desired. These lower-level methods are trickier to implement, of course, as proper synchronization with the UI thread must be handled in user code.

Kevin Johnson - 3/5/2014 14:02:03

Android does not exactly use the Model-View-Controller paradigm. The Model is comfortably contained within the backend functionality of the program. Though elements of the View are found in the XML files which specify the application layout, the Activity class functions as a hybrid of a View and a Controller; it performs event handling and processes user input, but it is also in charge of determining how output is displayed.

Android and Swing both uses a multi-threaded approach, with a single thread devoted to GUI interactions. Android makes multithreading easier with Handlers and AsyncTasks, but they have similar principles.

It is odd that the reading questions focus so exclusively on Android mechanics when the readings did not discuss Android at all. Is independent research supposed to be part of "reading responses"?

Emily Reinhold - 3/5/2014 14:25:59

1. The Android SDK does not fully follow the model-view-controller paradigm. It can be broken down in a similar way, but the model-view-controller paradigm requires that the view objects are decoupled from the model objects. This requirement is not enforced in the Android SDK, since the classes that implement the logic for the application (ie. the "model") can directly manipulate the "view" in order to perform some action.

For example, in the drawing application, we created a custom view to represent a canvas. This class contained logic to perform the drawing action that directly altered what the user saw appear on the screen. In that way, the "model" and the "view" were not decoupled at all. There was no middle man (ie. "controller") that needed to communicate the change in the UI when path.lineTo(x, y) was called, for example. That call directly changed what was seen on the screen. The MVC paradigm requires that all communication between the model and the view be conducted through a controller, so the Android SDK does not completely abide by this paradigm.

2. When an Android application is launched, a process is created with a single thread of execution (called the main thread). If there exists a compelling reason for why a particular application should use more than one process, the developer can specify that he wants separate components of his application to run in separate processes using the android:process attribute in the manifest. When an application is not currently being used by a user, the process controlling the application becomes a "background process", which can be killed to make room for currently in-use applications.

In Android, there is a single UI thread, called the main thread. Any interaction that the user has with the user interface is processed in this UI thread. Because of this, the Android SDK requires that the UI thread never get blocked, or else it will seem that the UI is unresponsive to the user. As a result, any action that might require a long time to execute should be executed in a separate thread so as not to block the UI thread. These separate threads are referred to as "background" or "worker" threads.

Background threads should not directly affect the UI, so the Android SDK provides means of communication between separate threads and the UI threads with functions like This allows the user to create a runnable object that runs in a separate thread, but the results of running this in a separate thread are then posted to the UI thread (thread that can directly alter the View).

To prevent programmer mistakes that attempt to directly alter the UI from separate threads, Android provides AsyncTasks, which requires the programmer to specify what is done in the background thread (in the doInBackground() method), and then communicates this to the UI thread with the onPreExecute(), onPostExecute(), and onProgressUpdate() methods.

The thread confinement in Android is essentially equivalent to that in Swing: Android does not permit threads other than the single UI thread to directly alter the UI, as Swing does not permit threads other than the event thread to directly alter the UI (with a few exceptions). Further, Android allows simple functions to be performed straight in the UI thread, just as Swing does with the event thread. More complicated (and time-intensive) functions in Android ought to be conducted in an AsyncTask, just as Swing suggests offloading complicated tasks to separate threads. However, as I mentioned, Android already provides a nice way to execute functions in separate threads with AsyncTask. Swing requires that the developer implement his own Executor to process time-intensive tasks.The reading suggests that the programmer make his own SwingWorker that essentially provides functionality like the AsyncTask in Android.

Ravi Punj - 3/5/2014 14:34:58

1) The Android SDK does follow the MVC paradigm. The model can be implemented through any number of Java classses, the View class provide the implementation for the Views, and the Activity and Fragment classes corresponds to the Controller.

2) In the Android SDK, you have Async and Background Tasks (through IntentService) to deal with long-running executions and background threads. They are somewhat similar to Java Swing's mechanisms, as both of them are single-threaded UI frameworks, but both of them provide for background processing i.e. running non-UI threads in the background, so that the UI thread doesn't get blocked on long tasks.

Will Tang - 3/5/2014 14:37:20

1) The Android SDK does somewhat follow the MVC paradigm, albeit with some differences. The java classes and declared variables can be seen as the model of the application, and the activity classes can be seen as the controllers. The xml layout files are the view. The differences are that there is less of a distinction in the Android SDK between models and controllers. Activity classes can have methods that are in charge of handling user inputs, or can have variable declarations that are representative of the model. Value xml files such as strings.xml can have variables associated with the model, as well as variables associated with aspects of the view.

2) Like Swing mechanisms, Android UIs run on a single main thread called the UI thread. In addition, Android dictates that the Android UI toolkit should only be accessed from the UI thread, just like how Swing mechanisms achieve thread safety by only accessing GUI objects from the main event thread. Since instantiating all UI components on a single thread can cause blocking or performance issues, Android allows developers to run non-instantaneous operations on worker/background threads. A developer may run an operation in a background thread through the call "new Thread(new Runnable()) {}". Since accessing UI components from outside the UI thread can cause blocking problems, Android also provides several methods of accessing the UI toolkit from worker threads. the calls "Activity.runOnUiThread(Runnable)", "", and "View.postDelayed(Runnable, long)" allow developers to access the UI toolkit without issue from worker threads. Android also supports a class called AsyncTask, which takes care of blocking operations in a worker thread and publishes to the UI thread without requiring the developer to handle threads.

Emily Sheng - 3/5/2014 14:39:04

It could be argued that the Android SDK follows the MVC paradigm. The view could be the XML files that define how a certain activity layout appears. The model could be the resources defined in XML files (which pictures, files to use). The controller could be where the user extends and defines new activity classes. In this way, the controller implements the business logic, the model tells the app where to get resources and what exactly to render, and the view displays layouts for the user.

In Android, there is AsyncTask, which runs processes on a background thread. AsyncTask has various methods (doInBackground(), onPostExecute()) that provide functionality for a background thread. This is similar to Swing mechanisms which has an event thread for executing short-running tasks, and other threads for executing longer-running tasks. These mechanisms are similar so that the user can still get feedback from the app while the longer task is running in the background.

Sang Ho Lee - 3/5/2014 14:52:24

Christopher Echanique - 3/5/2014 15:08:53

The Android SDK does follow the Model-View-Controller design pattern. The model is represented by classes created by the developer that contain the properties and characteristics of the developer’s data model to be presented to the user. The view corresponds to the XML document used to position elements of the user interface. The controller corresponds to the Activity class, which formats the view to display the model’s data and handles user input.

The Android SDK provides two main mechanisms that help developers with long-running executions: the Handler class and the AsyncTask class. The Handler class is used to register to a thread and provides a simple channel to send data to this thread. The AsyncTask class is used to encapsulate the creation of a background process and the synchronization with the main thread as well as support reporting progress of the running tasks. Android employs the same approach as Swing in regards to user interface elements. Both platforms require that the user interface elements be confined to the main event thread so that any code that accesses these objects must run in this thread.

Everardo Barriga - 3/5/2014 15:10:57

Sort of. I think the model can be whatever the programmer wants the model to be. For example you can create your own classes in Java to make the model be whatever you want it to be like a canvas for drawing or a database that holds books. The view can be seen as the XML, relative/linear layouts. This is what gets viewed and updated by the user based on how they interact with the view. You can change the view without ever getting into the “back-end” of your code, namely you don’t have to change any Java to update your interface. The controller can be the activities or listeners. This is how the communication between the model and the view is facilitated. Basically if the user presses a button, a listener will listen to that button press, talk to the model and then update the view according to whatever action the button corresponds to.

I looked up background threads for Android on google, and found something called AsyncTask. I believe this class allows you to run processes in the background while synchronizing with the main thread. I believe it also gives you progress about the background the thread you are running. Async seems to run similarly as the SwingWorker class defined in the reading, although Swingworker allows for cancellation and I’m not entirely sure if Async does.

Sang Ho Lee - 3/5/2014 15:20:11

1. The Android SDK by default doesn't strictly implement or enforce the MVC paradigm. However, the MVC paradigm is implementable. There are classes for views which are extendable to create custom views, such as the SurfaceView class which we use in IPA3. While in our past projects, the model and the controller were both encapsulated in single Activity classes, it is possible to define separate classes to hold the application's state and data apart from the controller classes. Most of the hardware controllers are given to us in the SDK, but controllers relating to more software and UI logic must be written. It is entirely feasible to put the code for controllers in separate classes and then put everything together in an overarching Activity class. Also by separating assets in resources and using Intents to separate user input from the View to the Model through the controller function) the Android SDK implicitly is similar to the MVC pattern.

2. Android applications start with a main UI thread that dispatches events to different worker/background threads. The Android SDK requires that the UI thread not be modified in worker threads. This is to avoid blocking the UI and resulting in deadlock or race conditions. Java Swing doesn't enforce this rule however. The goal of modifying UI components by background threads in Android works by using AsyncTasks which separates the work that should be done in the worker thread from the UI thread. It allows the coder to not worry about threadsafe behavior. There is not such an abstraction in Swing as in Android.

Gavin Chu - 3/5/2014 15:25:56

1. The Android SDK does follow the MVC paradigm.

The model is the actual data, for example a database of contacts. The users can modify these data through interactions with the app, but not everything in the database is always displayed on the screen. Models can be objects, which are implemented in the java classes.

The view is basically all the xml layouts with various widgets (like TextViews and Buttons). This view is what the user see. The view selects which data from the model to display. For example the model contains an array of strings, and the view will only display one of those strings.

The controllers are the specific widgets on the screen that the user can interact with, such as buttons. The default device buttons such as the power button and volume buttons are also part of the controller. Android developer can define what each of these controls do inside each Activity's java class, for example using onClickListener(). The controllers can directly manipulate the view such as re-positioning an image on the screen, or it can notify changes to a specific model, which will then update something on the view.

2. Android provides AsyncTask objects for performing long-running executions and background treads. You can define a set of instructions to perform in the method doInBackground(), which will run in a separate thread from the main UI thread. Once the task is completed, the method onPostExecute() can then modify any changes or simply show a "progress complete" message on the main UI thread.

Android's AsyncTask allows for a multithreaded GUI framework, whereas Swing uses a single-threaded GUI framework. Multithreading is avoided in old systems such as Swing because deadlocks can easily occur if the framework is not setup carefully. Events in single-threaded framework are handled sequentially, so there are no possibility of mixing up orders of operations. The drawback to this is that long-running executions will basically freeze the app GUI. The Android SDK carefully handles multithreading to avoid GUI freezes. Obviously having more threads can make a system run more efficiently, especially reducing time of total operations, but its complexity also increases. Android SDK is powerful enough that it can handle these complications and allow for a better app user experience. .

Munim Ali - 3/5/2014 15:32:09

1. From the reading it is apparent that iOS explicitly follows the Model-View-Controller paradigm. The Android SDK, on the other hand, can be said to follow the MVC paradigm to a certain extent. The model is encapsulated by program state encoded in the logic, content providers , data structures, resources that can be edited by users, etc. The View is encoded in the XML template files (the GUI that the user sees). The controller can be encapsulated by the various listeners - that react to user events by manipulating the program state. However, Android does intertwine a lot of these components, thus making it difficult to say that it definitively follows the MVC paradigm.

2. Android provides the AsyncTask to developers in order to perform background operations. These tasks can be cancelled too. AsyncTasks are best suited for short-running tasks. However, for long-running operations Android suggests using the APIs provided by the java.util.concurrent package (includes Executor, ThreadPoolExecutor, FutureTask, etc.).

This is very similar to the swing mechanism. We have swingUtilities to perform background operations just like AsyncTask in Android. Events are also processed from the event queue sequentially in both frameworks.

Dalton Stout - 3/5/2014 15:40:19

I think that the Android SDK is similar to the Model-View-Controller paradigm in some ways but with marked differences. It seems clear that the role of the View is represented in Android by the layouts/XML files. This is where all of the physical attributes that the user sees on screen are defined and styled. Not much else processing is done in these files (which is consistent with the properties of a traditional MVC view). It is defining the Model and Controller components of Android that is more difficult. According to the MVC paradigm, the Controller should be the intermediary between the Model and the View, with distinct and separate functionality from the Model. In Android, it seems that the Activity files perform much of the same functionality as both the Model and the Controller. For example in an Activity one can define an onClick listener for buttons (which is a Controller specific task) but one can also define a new data structure or class (which is a Model specific task). The Model and Controller are intertwined within the Android SDK.

According the the Android Developer page "Processes and Threads" there is one main UI Thread that is solely responsible for accessing the User Interface toolkits for the app. If a programmer wants to run a long-running or background thread they have several options. One is using the built in methods provided by Android to access the UI Thread (for example, Activity.runOnUiThread(Runnable) ). The second is using AsyncTask, which is a class that allows the programmer to create background operations and push the results to the UI thread. Async is usually only good for background tasks that are of short duration, so for longer tasks a programmer could use a java.util.concurrent package like Executor or FutureTask. The Android mechanisms are similar to that of Java Swing. They both only have one main UI thread to avoid bugs/glitches. They both use Executors for long running tasks and have ways for background threads to access the main UI thread. Rather than solving the hard problem of having multiple threads running at the same time, both Android and Swing have made it easier for threads access the main UI thread.

Erik Bartlett - 3/5/2014 15:43:07

1) The Android SDK almost follows the MVC architecture, but not completely. The main difference is how the model is represented. In the traditional MVC architecture the model is the data separated away from all the other sections of the interface. It gives itself as an object to the controller/view for them to present the data as it should be expressed, while in Android the data is usually implemented in parallel with the view or the controller. For example in my Grey Scale painting application for IPA2, the data about the bitmaps, image location, brush size, and any other information about the image were held inside my custom Canvas view. In Android the views also implement a lot of the functionality of the controller, by implementing their own Listener functions and callback functions - a role usually fulfilled by the controller on its own. The controller is also semi-implemented in the main application thread, seemingly a nod to the MVC architecture; but overall the model, view, and controller abstraction barriers are not implemented in the Android SDK.

2) Android provides developers with AsyncTask class extensions and event listeners for callback functions. The listeners in Android are almost exactly like the listeners in Swing. Swing adds listeners for a specific events that have executables that run when they’re called while Android adds listener objects that have methods that are called for a given type of action performed on the view. Extending AsyncTask allows the application to run in the background or in conjunction with the application, assuming the computation or thread can run without depending on the state of the main application thread. This is similar to the way that Swing has executables run in its listener’s callback functions.

Albert Luo - 3/5/2014 15:43:21

Android SDK doesn't really follow the Model-View-Controller paradigm. Instead, it provides a bunch of pre-built templates that the programmer can choose to extend from, such as Layouts, Listeners, etc. These templates often contain functionality from one or several of each component of MVC.

Android provides classes like Runnable, and utils like Concurrent that help developers with long-running executions and background threads. They are different to Swing mechanisms, however, because none of them are meant to be part of the user interface. User Interface in Android has its own thread, but in Swing there are many threads managing the user interface.

Conan Cai - 3/5/2014 15:49:13

I think that the Android SDK is not able to strictly follow the Model-View-Controller in that all the views in Android are taken care of in a static layout.xml file. An Activity needs an associated layout to even be instantiated. In this respect, the Activity and layout file are closely related to each other. In Android, the Activity seems to take care of input (Controller) as well as updating views (View). An Activity serves the dual function of both Controller and View which violates the MVC principle of keeping the logic of each separate. In Android, you define "On___" methods which directly update a view with R.getElementByID.___. All the controller and update logic is intertwined.

Android separates tasks into different threads. A developer is allowed to execute tasks on a different thread than the UI thread. In this way, the UI thread is not blocked and there is no interruption to the user. In the same way Swing, executes the GUI on a single thread while moving heavier tasks to another thread. In both, the central tenant is to not interfere with the thread the GUI is running on.

Anthony Sutardja - 3/5/2014 15:51:32

Although the Android SDK does not explicitly structured to follow the Model-View-Controller (MVC) paradigm, the Android SDK can somewhat resemble a MVC program structure if desired. In other MVC frameworks, the models, views, and controllers are more explicitly defined. However, in the Android SDK, there is a lot of flexibility in where the models, views, and controllers can be defined (e.g. UI components can be defined in the Activity logic).

That being said, if we were to classify which portions of Android identify with the MVC architecture, we would categorize as follows. The views would be contained in the XML template files. The controller would be contained in purely the Activity and Fragment logic. Lastly, the models, which are not explicitly defined, can be defined through extra Java files that are separate from the Activities and Fragments.

The Android SDK provides an application component called a Service that can perform long-running executions and background threads. Many blocking calls like MP3 playback, camera functionality, and HTTP requests can be processed off a separate thread not on the main UI thread. They are very similar to the long-running GUI tasks described in the Swing documentation. The main thread can communicate with the service threads by binding to them manually or with predefined listeners that are provided by the Android SDK.

Sol Han - 3/5/2014 15:56:42

The Android SDK somewhat follows the Model-View-Controller paradigm. For instance, Android's XML files that designate the layouts/resources/widgets can be considered the "view", while entities that encapsulate the program data (often in the form of custom classes) can be considered to comprise the "model". However, Android SDK does contain some characteristics that problematize this association. Particularly, it uses an Activity class, which contains both traits of a "view" (handles displayed windows and events) and a "controller" (acts as an intermediary between the view and the model by relaying information back and forth). Because Android SDK doesn't decouple these components, it is hard to clearly distinguish each component.

Android SDK's mechanisms are similar to those of Swing in that Android uses thread confinement for event handling to avoid issues caused by multithreading. Swing has helpers like SwingWorker and BackgroundTask, which allow features such as cancellation, progress indication, completion indication. Similarly, Android offers tools to help developers with long-running executions and background threads. As with Swing, Android allows developers to use the Executor class to handle Runnables (with execute()). Android also has classes such as AsyncTask to help with shorter tasks.

Armando Mota - 3/5/2014 15:58:52

1) The Android SDK contains elements of the MVC paradigm, however it doesn’t follow it exactly. The closest parallels Android has to these distinctions would be as follows: Model - often located in the onCreate method of views, this is where the info is stored. Classes like arrays, lists, dictionaries, etc. store data. View - the xml file specifying the formatting, the View object being used to present the data, or a bit of both Controller - realized as the event handler or event framework These distinctions can be blurred a bit in Android. For example, you can find both View and Model elements sitting side by side in the same view class (and even method).

2) In Swing you can create your own executor and use a cached thread pool, use a Future object, and use the Background task class which supports progress indication In Android, you have Activity.runOnUiThread(Runnable),, and View.postDelayed(Runnable, long) which allow you to access the UI thread from other threads. You also have AsyncTask and its doInBackground() and onPostExecute() methods, which allow you to perform asynchronous work on your UI. It basically separates the work that should be done on the UI thread and the work that should be done on the worker thread. From what I can tell, Swing’s Background Task class is similar to this.

As a side note, I found the content of this reading difficult to grasp and ground in reality, and I hope you guys cover it in detail in both lectures and section.

Peter Wysinski - 3/5/2014 16:02:05

Although Android does not follow the Model-View-Controller paradigm in a traditional sense, it does have a compartmentalizable application design pattern which breaks up the interface from the program logic. Developers define the user interface in XML files, this can be seen as our ‘view’ as it defines the screen the user sees while they are interacting with the application. When developing Android applications we also create classes which carry out the logic -- the classes which we've defined can be thought of as ‘models’ since they are responsible for performing the application functions. In the traditional MVC sense, the controller responds to events and user input, in Android we have classes such as OnTouchListener() which respond to user input and pass it over to the application ‘model’ for processing.

The Android OS does permit for developers to have long-running executions and for their applications to run background threads. AsyncTask creates a task that, “is defined by a computation that runs on a background thread and whose result is published on the UI thread.” This is useful as it permits for the display to show one thing while the application can process new data to display in the background -- such execution of code reduces the user’s perceived loading time since changes appear to be more instantaneous as data is loaded in as needed. As in Swing, in Android it is not advisable to put all of your application code into the main class which gets loaded when the application first starts up. The user should not be forced to wait while screens which they may never end up using in the application are loaded. As such, secondary screens and application actions that are called later in the flow should be placed into separate classes which gets called at a later point in the app and may even execute in the background while the user is performing another action.

Cheng-yu Hong - 3/5/2014 16:04:05

1. The Android SDK has some elements of the Model-View-Controller paradigm, but does not strictly follow the paradigm. Generally, the model consists of predefined or user-defined object classes, the view is displayed through the View class and user-interface XML files, and the controller actions are mostly done through the Activity class. However, the Activity class also handles displaying windows and listening to the associated events, such as onCreate or onPause, which are technically jobs for the View. Therefore, a closer description of the various roles in Android SDK would be using the Model-View-Presenter pattern, where the Presenter retrieves data from the model and formats it for display.

2. Long-running executions and background threads in Android are usually implemented using the AsyncTask or Executor classes. The AsyncTask class enables easy usage of the UI thread to perform background operations. The Executor class executes submitted Runnable tasks and is used for threads that need to run for long periods of time. Similar to the Android SDK, Swing also includes an Executor class to process long-running tasks and background threads.

Liliana(Yuki) Chavez - 3/5/2014 16:07:01

1. I think that the Android SDK can follow the Model-View-Controller paradigm. The controller is the activity class which enables the user to change a particular aspect of the app to change the parameters of the Model. The View of the android sdk is the view class by which you can design and determine how to project the information in the Model to the user.

2. The functions/objects/mechanisms available to programmers in Android to help with background threads and long-running executions are classes such as Thread.

Justin MacMillin - 3/5/2014 16:08:46

Yes, the Android SDK implements the MVC paradigm although not in an explicit or obvious way. Each component of MVC is controlled by a small piece of Android development. There is a process for interacting with the interface, for communication between parts of the interface, and finally a piece for displaying the interactions/computations. The Model piece are classes and other implementations that hold the critical information to the system. The Controller is what handles how these different pieces interact by using intents and listeners to later calculate what is asked for by the user. Finally, parts of the Activity class are what handle the View part of the MVC. There are also user created classes that extend View to further help display information for the user. When developing with Android it is not entirely obvious to approach applications using the MVC model but that does not mean it cannot be done.

Both Swing and Android are both single threaded. This means that each event that is processed is put onto a single thread 'queue' and executed in order from there. In this way the program can avoid data races and deadlock, problems that multiprogramming applications run into. However the problem arises when a long process is taken off the queue it can leave the user unsure if the application has crashed or not. There isn't a way for the user to know if the app is computing because that would require the app to create an event to alert the user, but no events will be created until the long event has completed execution. Swing remedies this problem by allowing worker threads to be created if long processes are taken off of the queue. This alerts the user the program is still running because it allows for more processes to execute on the event thread.

Myra Haqqi - 3/5/2014 16:19:52

1. Yes, the Android SDK does follow the Model-View-Controller paradigm. The Model-View-Controller paradigm consists of the model, which contains the data; the view, which delineates the data; and the controller, which is the link between the model and view. In the Android SDK, the classes that the designer creates make up the model layer. This is because the classes contain the data for the application. They also define the logic and computation in order to use this data. The layout of the application (the XML files), and the Views are what the users see and interact with, and therefore compose the view. Furthermore, this view does not interact with the model directly, in line with the MVC paradigm. The controller is represented by the Activity class. The Activity class in Android communicates by interpreting the user’s interaction with the view, and also communicating changes to the model, while also communicating changes from the model to the view in order to depict the updated view.

An example of this is having an Activity called MainActivity, which is the intermediary between the model and the view. The model, which contains the data, is some custom class that the designer creates called CustomClass. The view is the layout and user interface of the application, which is what the user interacts with. More specifically, the user touches buttons and other Views on the application interface.

An analysis of the Model-View-Controller paradigm includes how model objects possess the data, logic, and computation necessary to manipulate the data of an application. The model, however, does not directly interact with the view. The model is also not associated with the user interface and presentation of the interface to the user. The controller communicates with the model by notifying it when the view updates or changes. When the model changes, such as when the model receives new data, then the controller communicates these changes to the view, which updates accordingly. View objects respond to user interaction, and also enable editing of data, in addition to portraying the data for the user. It is decoupled from the model, and is notified of any data changes in the model via the controller. Furthermore, it communicates any changes brought about by the user to the controller, which in turn notifies the model. The controller object facilitates communication between the model and the view, which communicate via the controller rather than with each other directly. The controller objects also coordinate tasks for the application.

2. When an activity in Android starts a long-running operation, it starts a service for that operation, as opposed to simply starting a working thread. A Service is a component in an Android application that executes long-running tasks in the background without providing a user interface. Some long-running operations are executed via worker threads (or possibly an asynchronous request).

The AsyncTask class is one of the best ways to use worker threads. It allows the performance of background operations while publishing results on the UI thread without having to manipulate threads or handlers. More specifically, an asynchronous task involves a computation that runs on a background thread, with its result being presented on the UI thread in Android. In android, the three possible types that an asynchronous task can be defined on are Params, Progress, and Result, and the four steps are onPreExecute, doInBackground, and onPostExecute. AsyncTask is very useful for background threads.

The IntentService is a base class for the aforementioned Services. The IntentService handles asynchronous requests, or Intents in Android, on demand. This is particularly valuable in the event that one desires to create background services.

They are somewhat similar to and somewhat different than the Swing mechanisms. Android compares to Swing in that AsyncTask and SwingWorker are very similar. Handling events in components in Swing and in Views in Android are also very comparable. However, Android is different from Swing because Android applications include Intents as asynchronous requests.

Justin Chan - 3/5/2014 16:29:45

The Android SDK in my opinion isn’t really “out of the box” MVC, but for all intents and purposes, is pretty close to the real deal. The most obvious one for me is Activities == Controller. Activities dictate what happens when you load a page, click a button – basically all of the back end logic. The other relatively obvious parallel is that Views == View (they even share the same name like wow). You have layouts in Android that aggregate all of these views into pages, dictating what the user will see. The last parallel is the one that gave me a bit of trouble – I’m more familiar with Rails, where there are literally things called models, views, and controllers. For me, models in Android correspond to Application and/or subclasses of Application. For all intents and purposes, Model == some sort of state, and Application in Android allows you to do such a thing. What I will say again is that although the Android SDK isn’t perfectly MVC per se, it has a lot of parallels that make it pretty darn close.

One function in Android that allows developers with long running executions is the ability to have cached thread pools. Assuming that you don’t have that many long-running tasks, using a cached thread pool isn’t a big deal because there’s low risk that you’ll expand it beyond management. Secondly, you can also bind execution of said tasks with some sort of progress indicator to let the user know the task is actually running. In everyday life, we see this manifested as color spinning thing on Macs, progress bars, etc. In the reading, there is an example where a button has an action listener that disable/enables it depending on the progress of the task. There are also options for developers to cancel tasks if they are running too long. Again, in the reading, there is an example where a button is given a listener that allows it to cancel a running task. With regards to Swing, Swing is cool if you want vanilla tasks to run on the event thread. Where it fails is when you want tasks to run on other threads. No can do for Swing there. 

Aayush Dawra - 3/5/2014 16:32:09

While it is fair to say that the Android SDK largely embodies the characteristics and ethos of the MVC pattern, when observed more scrutinizingly, several key differences support its counterargument, which is why it cannot be said with definitiveness that Android SDK follows the MVC pattern. Consider for instance the fact that the View aspect of MVC is mirrored by the XML layout files in Android and the Controller aspect of MVC is mirrored by the Activity files. The Android framework can also sustain an application without a model, depending on the needs and the scope of the application. If a model were to exist, it can be represented as a Java class in Android, which may represent different entities in the application. More complex scenarios may arise as well, involving cloud storage of databases, like Google App Engine, and persistent data manipulation in the form of local storage on the phone itself, all of which mirror the Model aspect of MVC. Also, the user interaction with the data in Android is solely through the View. All of these observations lead us to believe that perhaps the MVC modularity does indeed exist in the Android framework. Having said that, implying that a static XML file is the view and that the Activity is the controller ignores a core aspect of the MVC pattern, which is the decoupling of the main components, in this case the View and the Controller, since a user cannot instantiate an Activity without talking to the View in Android. Hence, it can be argued that in some sense, although the MVC architecture is largely mirrored in Android, the strong coupled nature of MVC reflected in the Android SDK is a very poor embodiment of the MVC pattern, especially if the user wishes to unit test an Android project.

There are several background threading systems available in Android, some of which have been derived from the Java SDK. For instance, Android offers 'services' to accomplish a process running in the background, which should not be confused with a background thread, since a 'service' is associated with the parent thread that spawned it, which is usually the application's main thread. This also leads to the possibility of deadlock, for if the 'service' consumes too many CPU resources or ones that other threads are waiting on, it can induce block the UI or lead to deadlock. Users can utilize the Thread class, including its abstractions (ExecuterService etc.), to spawn and manage threads in Java. In Android, the parallel offerings of such functionality include AsyncTask class, which allow for thread management and spawning in the background and avoidance of deadlock. The notion of a single thread running that runs the entire application on Android exactly mirrors the behavior of SWING which, too, is controlled by an event firing queue that runs on a single thread. This behavior implies that manually spawning a thread or an AsyncTask does not allow the user to manipulate the UI elements, however, since the Android framework has not made multiple UI accesses thread safe, unsupervised manipulation of UI by separate threads may result in undefined behavior of the application, which could be potentially undesirable for the application. Once again, this lack of thread safety is mirrored by SWING, and invoking SWING objects from multiple threads risk thread interference or memory inconsistency errors, exactly like the Android UI toolkit elements.

Christina Guo - 3/5/2014 16:40:48

1. The android SDK somewhat follows the Model-View-Controller paradigm. The xml files in the SDK, which include subcomponent views like TextView and buttons, are the same as the View in MVC such that they deal with what the user can see, and separate the UI of the application from the background logic. Activities are like the controllers, because they operate the logic behind the UI, taking the user throughout the app in the appropriate designated ways. Though there is no direct parallel for the Model portion of MVC, developers may create custom classes to organize the data objects within their application, which would correspond to Models.

2. Between applications, developers can use functions like onPause() and onResume() to deal with logic when their application is running but not in the foreground. Within a single application, developers can use Java threads and runnables to run background logic without slowing down the UI. This is similar to Swing, which is organized such that components and models can only be modified or queried from the event dispatching thread. The UI is dealt with through Activities and Views at the foreground, where the main thread is acting as an event dispatching thread, and Executors or threads can be used to run background processes.

Chirag Mahapatra - 3/5/2014 16:44:14

In the case of Android, the Activity class does not extend the View class. However it handles events of the window like onCreate, onPause as well as displaying the window to the user. In this case, it comes down to the designer whether he perceives Activity as a controller or a view. This is because the controller is generally the entry point of the application and in Android, the Activity class is the entry point to the application. While it is debatable, I believe Android is not a MVC. While we can have a model and view in the traditional sense, the Activity class is not a controller in the traditional sense.

In android, the components of a given application generally run in the same process. The user can mention the process in which the component should run in the manifest. The Android system generally tries to keep the process alive for as long as possible. However, there are times it will need to free up memory which is required by processes which are more important. To decide the importance of processes, Android maintains a importance hierarchy based on the components it runs and uses it to decide which processes to eliminate first. E.g. the foreground process is very important and is given high priority. Similarly, a visible process has high priority. Contrast to this, a service, background and empty process has low priority.

Daphne Hsu - 3/5/2014 16:55:36

The Android SDK does not follow the MVC paradigm. You define your user interface in XML files, which is kind of like a view in the MVC, but don't communicate with a controller. The closest thing to controllers are activities in Android. The biggest difference between Android and MVC is that there are no "models" in Android. There is data displayed in the view which acts like a model, but doesn't do the things an MVC model does.

In Android, there is AsyncTask, which can run code in the background and get called back in the UI thread, like a Swing BackgroundTask. Both Swing and Android have Executors, Threads, and FutureTask to manage threads. Both make use of the Java frameworks for handling threading.

Stephanie Ku - 3/5/2014 16:58:05

1. The Android SDK does not have a specific Model-View-Controller paradigm, but we can follow the pattern using the following. For the View, Android allows programmers to set up xml files that are displayed to the user. Now, from the model/controller, the programmer is able to update the ‘view’ (e.g. change text) to show the user the latest changes. In terms of the model, Android does not have a specific ‘class’ dedicated to these. However, normal Java classes can be utilized to capture state. Similarly, one can also capture state within an Activity in Android, which is essentially used as the Controller. So in this sense, the ‘model’ implementation is up to the discretion of the programmer as it could be hybrid (implemented within the controller), or separate.

2. Android has worker (background) threads, and AsyncTask that allows you to perform background operations and publish results on Android’s main UI thread without having to manipulate threads. They are only similar to Swing mechanisms to a certain degree. Like Android’s main UI thread, Swing has a single event thread that processes tasks from the event queue. Where they differ however, is in what the article called thread confinement. In Swing, tasks that run in the event thread do not need to worry about synchronization when it comes to accessing the presentation objects. However, this also means that one is unable to access them from another thread at all. Unlike Swing, as mentioned previously, AsyncTask in Android does allow the user to manipulate and perform background operations on Android’s main UI thread.

Matthew Deng - 3/5/2014 16:58:36

I believe that the Android SDK follows the Model-View-Controller paradigm, but not completely. The model corresponds with the .java file -- for example, -- and the view corresponds with the layout main.xml file. In the .java file, objects are represented and values are stored, much like the model in the MVC design. In the layout file is the layout of the application, including where the objects are and indications that the objects can be manipulated. Finally, there is the controller. The controller of the Android SDK is the event listeners. Event listeners are notified when objects in the view are manipulated, and then tell the model what to do and communicating changes back to the view.

I am not at all familiar with Android, but upon research I found that long-running executions and background threads are typically dealt with through AsyncTask and IntentService. These are similar to Swing mechanisms because both Android and Swing use single thread models. Like the StringWorker class, AsyncTask also includes cancellation, completion notification, and progress indication. The difference between AsyncTask and IntentService is that AsyncTasks are more geared towards the current activity, whereas IntentServices are meant to run on a schedule in the background.

Diana Lu - 3/5/2014 16:59:12

1. No, the Android SDK does not strictly follow the Model-View-Controller paradigm. However, there are things in the Android SDK that represent the model, view, and controller. In terms of views, the Android SDK has XML files/layouts to determine user interface, which would be the equivalent of the view. The classes in which all of the onClickListeners and Intents are defined would be the controllers, where the logic is performed relative to a user's interaction with the interface. Models are not strictly defined in the Android SDK, but can be equated to the resources and activities that are displayed via the View.

2. For long-running executions, Android has cancellation for applications that have become non-responsive. Android's AsyncTask also helps developers with long-running executions and background threads because it is designed to allow the programmer to run tasks in the background, and developers do not have to worry about synching threads themselves. With Swing, long-running tasks are done using an Executer. The functions are similar to Swing mechanisms, but differ slightly.

Bryan Sieber - 3/5/2014 17:00:04

1) So, the Android SDK follows the paradigm, slightly, not fully. The View’s would be the XML layout files. Both the Model and Controller are the Java files. By using Java as the Model, the data/state of the model is stored in the variables. Also, Java is the link between the data and the View, getting gestures and setting the data variables via the getter and setter methods: OnTouchListener()’s or setContentView(), and many others. However, the whole MVC can be done in solely the Java files: the View can be set up because java has methods corresponding to the XML files, and the Controller and Model have methods like those aforementioned. But this makes it so the Android code lacks modularity.

2) Android also has a main thread of execution. The programmer can use alternate threads in two forms: using a worker thread or using AsyncTask. If using the worker thread, when the process is completed the worker can re-access the main UI thread safely by using runOnUiThread(Runnable) and post(Runnable). The alternate option is, like previously mentioned, using AsyncTask and using the method doInBackground() which places the task in an alternate thread and allows the method to jump back to the main UI with onPostExecute() also gaining the acquired info. The SwingWorker framework is similar but has a few additional options, such as: cancellation, completeness notification, and progress indication. This allows updates to be filled with more info, allowing for a more fluid UI. Perhaps a custom WorkerThread class could allow for this, but AsyncTask does not.

Jeffrey Butterfield - 3/5/2014 17:01:17

1. The Android SDK does follow the Model-View-Controller paradigm. The View component of the paradigm is evident by the number of UI classes available in the Android SDK. These classes, such as buttons, canvases, and progress bars, correspond to act with literal components that are present in the view part of the paradigm. They give the user a sense of what the underlying model is and what the state of the model is, depending on the component. The Controller part of the paradigm is present in Android’s capabilities to facilitate user input through a variety of ways, including touch gestures on the screen, sound via a microphone, and changes in tilt via the accelerometer. In Android, the Controller is seen in the SDK’s interfaces like View.OnClickListener or View.OnTocuhListener. Finally, the model can be implemented in the Java code present in classes such as Activities. An Activity can reference UI elements and have listeners for certain input and respond appropriately, such as updating the view in some way all of these components make up the Model-View-Controller model with reference to Android.

2. Every application has at least a single thread associated with it called the “main thread” or UI thread. It takes care of dispatching events to the interface. By default, every component of the application runs on the UI thread, but this can be changed by the developer. This functionality is important because sometimes a process that is perhaps initiated by the user by pushing a button can be computationally intensive (e.g. fetching a very large resource). You can create worker threads by just using the class Thread. To use the example of fetching the resource—perhaps a video file—all the programmer must do is a) find the handler of the event (like the onClick function of a listener), b) instantiate a Thread object in that onClick function, c) pass a new Runnable class (an anonymous class that implements the run() method), d) put the file fetching code in the body of the run() method, and e) call the Thread’s start() method. This is similar to the tools available in the Swing framework because Swing usually uses a single thread (an “event thread”) to handle UI work and uses background threads to handle processor-intensive tasks to avoid affecting the performance of the UI. Classes like SwingWorker and BackgroundTask are examples of tools in Swing that help accomplish this.

Maya Rosecrance - 3/5/2014 17:03:44

The Android SDK follows the MVC framework. The model is the data in the classes and resources folder, the view is the xml files which display the model and the controller is the bulk of the code from the event and button listeners to the data manipulation done within the classes.

Android uses Activity lifecycles to helps with long-running executions. Android provides some methods to automatically kill activities but otherwise the developer has full control over the ability to pause or resume activities. Android also allows for the use of Runnables much like Java to support multithreading. However unlike Swing it doesn't have an Executor or a cached thread pool.

Prashan Dharmasena - 3/5/2014 17:04:40

1) It sort of does. The View can be layed out either in XML or in Java code. One can even make their own view classes, like we did in IPA2, by extending the View class. As for Controller, the Listener classes handle input from the user and differentiate between different kinds of input. The Activity classes and any other code that handles any of the application's logic fit under the Model umbrella.

2) Android's AsyncTask class allows developers to run long processes without freezing the rest of the application by running the process in a background thread. An example of this is in the first IPA. Making a HTTP request to fetch data can take a long time, so in order to keep the app responsive, we must make the request inside of an AsyncTask. This is similar to Swing's ExecutorService class that functions just like AsyncTask, letting you call the run() method of a Runnable.

Seyedshahin Ashrafzadeh - 3/5/2014 17:05:22

1) In Android SDK, we define the user interface and resources in various XML files. So the XML files define our view. In activities, we define how we handle data and process it as well as we bind the event handling procedures. So the activities define the model as well as some of the controllers. We can extend the view class and create a subclass in Android SDK and inflate it in an activity class. Also, it is possible to bind an event handling procedure in an XML file. So the line between XML files, activities, and other classes is not very clear in regard to model, view and controller. Therefore, I don't think that Android SDK is totally a Model-View-Controller architecture. 2) Similar to Swing mechanisms, Android SDK is also a single thread model. If the app performs a long running execution, the model will yield poor performance and the UI will be blocked. In this case, no event can be dispatched and the application appears to hang. It is very important to make the application very responsive by not blocking the UI thread. If we need to do an operation that is not instantaneous, we need to do the operation in a background or worker thread. In Android, we can create a new thread by new Thread(new Runnable()). However, we can not simply access the UI thread toolkit from outside the UI thread because it can cause unexpected and undefined behavior due to race conditions and deadlocks. In order to do this, we can use the following methods: Activity.runOnUiThread(Runnable),, or View.postDelayed(Runnable, long). By using these methods, we can have a thread-safe implementation. Another mechanism is to use AsyncTask. This allows us to perform the long operations in a worker thread and publishes the results on the UI thread. To use it, we must subclass the AsyncTask class and implement the doInBackground() method. And to update the UI, we need to implement the onPostExecution() method. The same thing can also be done in Swing by binding a backgroundExec to a visual component.

Haley Rowland - 3/5/2014 17:05:35

1) The Android SDK does follow the MVC paradigm. The Model portion corresponds to the actual implementation of the program’s logic flow in Activity classes. The view is implemented by View objects and the model can update these views by calling their onDraw method. The controller portion of the MVC paradigm is implemented by Listener objects. Listeners translate a user’s events into a signal that can be processed by the model’s logic, which will in turn update a view object accordingly.

2) Android runs its UI on a single thread, like Swing. And like Swing, it has the potential to lag the GUI if a long-running computation blocks the UI thread, so Android allows for new threads to be created and access the UI thread. The AsyncTask class of Android allows the model to perform asynchronous work on the UI. Android includes methods such as doInBackground() that will execute automatically on a worker thread to prevent long-running processes from creating lag. Like the "Future" Swing mechanism, Android allows for tasks to be cancelled at any time from any thread.

Meghana Seshadri - 3/5/2014 17:07:24

(1) The Android SDK does implement the Model-View-Controller paradigm, however, it is done in its own unique way that is different from other platforms. While there are a number of ways to implement the MVC framework in Android, it maintains true to the purpose of each idea in the MVC pattern:

Models are objects that contain the information and business logic that belongs to the application and remains unchanged and unconcerned with the user interface or presentation itself. Model objects in Android can be managed through ContentProviders, which are objects used for organizing and managing persistent data. They can also be regular classes that interact with databases and access the information from them. The model has nothing to do with the layout or presentation of the application itself.

The View is the user interface portion of the application and provides functionality as well as different ways of displaying the data and allowing users to manipulate that data from the model. Controllers act as the intermediary between the View and the Model, and update the both accordingly to the user’s input. In Android, the Activity class or subclasses of the Activity class can function both as the View as well as the Controller. The Activity has links to Views and also facilitates the communication between the View and the Model. Because of this, Android is commonly known to combine these two portions of the MVC framework and denote it as the View-Controller. The Activity class consists of view components with which the user interacts with and that also have the ability to create events and accept user input. Furthermore, the Activity responds to events and manages the flow of the views, which is how it acts as a controller.

(2) There are a variety of systems in Android that help developers with long-running executions and background threads. In order to allow applications to be running in the background, Android employs the usage of Services. As the Android application grows more complex over time with server connections, data transferring and storage, etc, these operations can interrupt and block the UI thread to operate (such as user moving through a screen while a background thread is obtaining and storing data). Android takes care of this problem by using the AsyncTask class, which enables a more proper and easier use of the UI thread. This class allows the background tasks to perform without having to interrupt the UI thread. It allows background tasks to perform and results to publish on the UI thread without having to create and manage new threads or handlers manually, which is what Java does in order to solve this issue. Android and Swing share similarities in that for long-running GUI tasks, there is only one main event or UI thread running tasks on it. Swing creates a separate thread for processing long-running tasks, and doesn’t provide any mechanism for executing code on other threads or manipulating the elements for the UI.

Namkyu Chang - 3/5/2014 17:09:47

1. Does the Android SDK follow the Model-View-Controller paradigm? If so, what classes correspond to the model, the view, the controller? If not, how is the Android SDK different?

No, the Android SDK does not follow the Model-View-Controller paradigm, but it is possible to implement it depending on how you develop your application. Recall from the March 3rd reading, that Olsen classifies the model as the “what” to be manipulated, the view as “presentation” to the user, and the controller as the “translator” between the user and the model.

In terms of Android, the controller can be seen as each activity; I have a mainActivity class which has code on how to act to certain user inputs (e.g. click the start button to a video). Then, the model (the “what” to be manipulated) will be the video file stored somewhere within the app will receive the input and start playing. This will then change the view (defined by the xml files under res/layout/main or wherever), to show the user the video.

2. What are the functions, objects and mechanisms in Android that help developers with long-running executions and background threads? Are they similar or different to the Swing mechanisms?

For background threads, Android API provides the developer with classes such as AsyncTask which perform operations in the background without having to manipulate threads. The Android documentation shows that this is a helper class around Thread and Handler, but does not constitute a generic threading framework. In addition, this is only for short operations (e.g. hitting a button does something very simple while the AsyncTask was listening in the background).

For some long-running executions, the Android documentation suggests using APIs from the java.util.concurrent package, like Executor and ThreadPoolExecutor. As an example, the executor submits a Runnable task, which may or may not be executed in the same thread as the caller’s thread.

Note that Android *does* allow creation of additional threads, as mentioned in their doc, “different components in your application [can] run in separate processes, and you can create additional threads for any process.” (

From Goetz’s “Java Concurrency in Practice,” he mentions Swing as a good example of a GUI that is single-threaded. A contrast to this mechanism compared to Android is that Android allows additional threads to be created (see above paragraph). However, the similarity between the 2 systems are also evident because both platforms’ GUI manipulation *are* done on a single thread. From the Android Doc: “ Andoid UI toolkit is not thread-safe… [you must] do all manipulation to your user interface from the UI thread. Thus, there are simply two rules to Android's single thread model: 1. Do not block the UI thread 2. Do not access the Android UI toolkit from outside the UI thread.” (

Presumably, the Android designers knew that multi-threaded GUIs often lead to disasters (from the reading, this is evident), and knew that although to have a good smartphone OS it has to allow multi-threading for performance purposes. However, the UI can only be manipulated by a single thread for reasons stated by Goetz.

Sol Park - 3/5/2014 17:10:44

1. I believe Android SDK follows the Model-View-Controller paradigm. A model is what to display, a view is how it is displayed and a controller is formatting the model for display and handling events like user input. Models in Android SDK are implemented as classes at user's discretion. Views are resources and layouts in res folder. Data files and layouts in res folder describe of how it is supposed to be laid out. Controllers are activities that interact with the view to handle events like user input. The activities collects the information from the models, creates view and sets up the event triggers needed.

2. AsyncTask is an Android mechanism to help handle long operations that need to report to the UI thread. We can subclass AsyncTask and implement doInBackground(). This runs in a pool of background threads. We can implement onPostExcute() to update the UI which delivers the result from doInBackground() and runs in the UI thread so UI can safely updated. Then we can implement execute() to run the task. Android is similar to Swing mechanism since both are single threaded subsystems. (Android applications run in single thread so above mentioned methods and functions should be used for long-running executions and background threads.) Hence, long-running tasks both in Android and Swing should be handled carefully.

Hao-Wei Lin - 3/5/2014 17:12:10

1. Yes. The API library is equivalent to the model part of the paradigm. The View class is equivalent to the view in the paradigm, and the controller in Android SDK is the various type of Listener. a. model – the actual code of the APIs and functionality b. View – the View class in Android APIs c. Controller – Listeners

2. Android system, unlike Swing, doesn’t run in a singlethreaded system. In singlethreaded system like Swing, tasks can only be processed sequentially, and managing to figure out how to order them can be hard, erroneous and time-consuming. This also means that in singlethreaded system, one cannot stop a particular task until the whole sequence is finished. In contrary, Android has function such as onPause(), onResume(), onCreate() to deal with pausing and resuming tasks while switching between tasks. It also allow certain tasks to be ended while the other ones are running. Android also allows developers to implement background process through the Manifest file.

Sangeetha Alagappan - 3/5/2014 17:13:39

1. Yes, the Android SDK follows the Model-View-Controller. The Model is the data that we are modelling with the application, like data from the web. This is often modelled as an Object. The View is the presentational aspect of the application that is carried out with Layout Classes (often implemented in XML files or graphically) in Android. This View presents the information and provides a surface for the user to interact with. The Controller gets the data, manipulates it and sends it back to be rendered in the View and in Android, this is taken care of by the Activity class. As an example, take our greyscale drawing application, where we have a View with an onDraw method. When this View detects a touch, it communicates to the Controller that processes the information about the coordinates of the touch, fires the required Activity and communicates it to the model to manipulate the picture that the model holds. The manipulated model is then sent back by the Controller to the View to display.

In Android, the communication between the model, view and controller is such that if one were to be replaced with different functionality/data (yet retain the same abstraction and “contracts”), the app would still be intact.

2. Android modifies the UI and handles inputs through the main thread while collecting events in an Event Queue and processes an instance of the Looper class. Thus, Android supports concurrency (by providing the java.util.concurrent package) to avoid running all processes in the main thread, executing every statement one after each other, which greatly helps when performing long-running executions (otherwise the application would have to wait for the entire operation, such as accessing a database, to finish before doing any other task). It also supports long-running executions tasks by using the ThreadPools and Executor classes.

Android also helps with long-running executions and especially, background threads by allowing asynchronous tasks to ensure that slow running operations won’t stagnate the flow of the application. Android does this by supporting the AsyncTask and Thread class which allows asynchronous processing.

Android also provides for a Application Not Responding dialog to stop unresponsive activities.

The Android mechanisms share both similarities and differences with the Swing mechanisms. Unlike the multi-threaded Swing mechanisms, the Android UI toolkit is not thread-safe and the UI toolkit works on a single thread model. In the Android SDK, all components that run in the same process are instantiated in the UI thread, and system calls to each component are dispatched from that thread, making work intensive application perform poorly. Like the Swing mechanisms, Android supports asynchronous tasks and provides progress and completion indicators, along with the facility of cancellation.

Andrew Lee - 3/5/2014 17:13:39

1. The Android SDK doesn't necessarily force the use of the MVC paradigm, but it's quite straightforward to follow it. In a nutshell, the VIEW can be achieved by the XML layout files, the CONTROLLER is typically implemented by an Activity, and the MODEL can be any Java class(es) as necessary. However, it is true that it is just as easy to disregard the separation and, for example, shove everything into one Activity that contains the data model and the business logic, and procedurally generates the UI.

2. The main kind of object that Android provides for long-running executions and background threads is the service (the actual extendable class being IntentService). To start the service, an Intent can be created and then the Activity can call startService with that Intent. To handle events fired by the background task, a BroadcastReceiver can be extended and then registered by a LocalBroadcastManager. They're relatively similar to what the Swing mechanisms provide.

Shaina Krevat - 3/5/2014 17:14:00

1. The Android SDK almost follows the Model-View-Controller paradigm, except that on it’s own it only provides the View and the Controller. The view classes are obvious, as any object that is shown on the screen would be a part of the view, such as Buttons, Layouts, Images, etc. The controller section is a bit trickier, but the OnClickListeners and classes that help the view respond to events are part of the controller. The model would be made up of classes that individual programmers decide on, depending on what kind of application they are building. If it’s a game, then it might be the individual characters in the application, or the GPS information for a map application. While the SDK provides ways to access this information, it doesn’t provide the classes themselves.

2. AsyncTask is an Android class that allows background threads to run. Its functions, such as execute, doInBackground, ProcessUpdate, etc. help users run tasks that would delay the main UI (such as audio processing) in the background so the UI can still function. Swing has the main “event” thread, that handles cases where the GUI needs to responds to events, and an objects called “Future” and “FutureTask” that act in a similar way to AsyncTask

Cory McDowell - 3/5/2014 17:14:44

1. The android SDK does not exactly follow the Model-View-Controller paradigm, but it has similar aspects. It does follow the view component, with the Layouts folder. Here, one can use XML to specify how the application will be laid out, and how it will look. The actions that will correspond to events occurring in the view are specified by Android’s version of a Controller, the Activity files in the source folder. Here, we specify what the application will actually do, and what effect events will have in our application. Finally, the closest thing android has to a Model, is the values folders. In these folders, we specify images, strings, and other values. These values are then manipulated and displayed by the controller. They are not that similar to database model entries, but they are similar in the fact that they are manipulated by the controller and displayed by the view.

2. In android, when an app is launched, a main thread is created. Android provides background processes at well, and keeps them in an LRU list, where swing abides by the Swing single-thread rule, which states that swing components and models should be created, modified, and queried only from the event dispatching thread.

Insuk Lee - 3/5/2014 17:17:00

1. The Android SDK is made up of XML files, resources, and different activity files and classes. It does not fit the MVC paradigm exactly but if we were to match up as closely as possible, the model and view would be meshed together into XML files/activity files and the controller would be the resources and activity files. It's quite different because in the Android paradigm we have XML files that lay out the basics or foundations of our view and we control/change/edit everything in the activity files.

2. In Android development, there are things such as AsyncTask that help with long-running executions. AsyncTask for example allows to perform background operations and forward results to the UI thread without having to manipulate threads or handlers. Swing has similar mechanisms, such as SwingUtilities that lets the user schedules or blocks threads (invokeLater or invokeAndWait).

Max Dougherty - 3/5/2014 17:17:06

1. While the Android SDK does allow adherence to the MVC paradigm, it does not include any strict enforcement. The view of the Android application is written in XML and displays information consistent with actions taken by the controller. The Android controller, is considered an Activity and reacts to input in the view via Event Listeners/Handlers. This highly dependent relationship violates a traditionally decoupled MVC. Conversely, the model, which manipulates persistent data can be written separately from the Android SDK with its own API, closely resembles that of a more traditional MVC framework.

2. Although few exist, a major difference between Swing and the Android SDK is focus on power consumption. Android attempts to reduce unnecessary processor and memory usage, by allowing code to behave dynamically with defined load on the system. An example of this is the “onLowMemory” method, which can define specific activity when the program does not have space to run normally. Long-running and background threads are handled in a similar fashion in Android and Swing. In both cases, threads are forked from the main event thread. However, Android has AsyncTask objects which allow the designer to perform operations in the background and easily produce results in the UI thread. Similarly, Swing uses SwingWorkers and runOnUiThread. These are implemented using Executors, which are more processor intensive. This is exacerbated by the inherent multithreading of Swing apps, a condition that Android does not inherently enforce.

Brenton Dano - 3/5/2014 17:19:14


Android does follow the MVC paradigm. The file corresponds to the controller, the MainActivity.xml file corresponds to the view, and other user made classes that correspond to special objects or utility classes is the model. Of course, a user can simply stick all the logic in the file and not create separate classes for model logic, but this would be violating the MVC paradigm. Basically, the user has freedom to follow strict MVC if they want to, and ideally both Android and iOS programmers should follow the MVC paradigm.


The IntentService class in Android helps developers run a long-running process in a background thread. This class helps users do operations on a background thread without affecting the responsiveness of the UI. IntentService like GUI's built with Swing, is single threaded and work requests run sequentially one at a time, and the next operation can go only when the previous one is completely finished. Some other mechanisms Swing uses besides single threaded sequential event processing are thread confinement (all Swing components are only able to be accessed through code that runs in the event thread), the ability to differentiate between short and long running tasks, and the ability to cancel long running tasks.

Opal Kale - 3/5/2014 17:21:46

The Android SDK does follow the Model-View-Controller paradigm in general ways. The model corresponds to the classes that implement application logic, while the view corresponds to the XML Layouts, resources, widgets (EditText) and built-in classes (buttons from android.view.View). Finally the controller corresponds to the Activity class. However, the one things that is debatable whether or not the Activity class fully falls under being a controller or not— although the Activity doesn’t extend the View class, it still does things related to View in in the MVC paradigm. For example, the Activity class will handle events of the window, but also handle displaying that window to the user (i.e. the use of setContentView).

For threads running for longer periods of time, the APIs provided by the java.util.concurrent package such as Executor, ThreadPoolExecutor and FutureTask are probably best. Swing doesn’t help for long running executions and background threads. We create our own Executor for processing long-running tasks; a cached thread pool is an example. One example of this is when a listener is called in the event thread and submits a Runnable to execute in the thread pool, which works in a “fire and forget” manner, where there cannot be presentation objects accessible in the background thread, to the complement of the task submits to another task to update the UI. Another way, is when the action listener dims the button to let the user know that the task is in progress, and then submits a task to the background executer, which eventually reenables the button, letting the user know that the task is completed.

Swing is similar in that many of the features developed in the few examples above are actually provided my the SwingWorker class, such as cancellation, completion notification, and progress indication (the latter two I have expanded on above).

Emon Motamedi - 3/5/2014 17:23:54

1) The Android SDK follows the Model-View-Controller (MVC) paradigm to a certain degree. The view is represented through the XML files that reflect the layout and interface to the user. These XML files correspond to the view as they take certain information from the model and present it to the user in a way that the user can understand and use to shape his or her own mental model of the application. The controller in the MVC paradigm can be seen as the java files within the Android SDK. These files contain event listeners that react and interpret the actions of the user and influence the program accordingly, as does the controller. The aspect of the MVC paradigm that is less clearly reflected is the model. Within the Android SDK, I would argue that the java files also loosely play the role of this model. They hold the values of different variables within the system and can have those values changed via the controller (event listeners). The java files can then affect what is being output by the XML files (the view) through code.

2) Android and Swing have similar mechanisms as both use a single GUI thread to help ensure that deadlock does not occur. Even though the Android Development Guide warns against it, Android, like Swing, can use forked threads to access the GUI elements. They also use very similar methodologies to run background tasks by starting new threads. Android does this through the AsyncTask class, which uses the backgroundJob() method to accomplish the Swing equivalent of using a runnable that has the background task with the starting of a new thread, and an onExecute() method which does the Swing equivalent of using the runnable to update the GUI through the invocation of a GUI-thread method. A main difference though is that is is meant to be utilized for shorter operations.

Derrick Mar - 3/5/2014 17:26:40

1. Saying that the Android SDK follows the MVC paradigm is arguable. In my opinion, it doesn’t because it is not as clear as some other MVC frameworks (e.g. rails which clearly has models, views, and controllers that handle their requirement independently). In Android, there isn’t really a MVC model because different entities do several tasks. For example, activities in Android not only act as controllers (containing the business logic of the application like dealing with user input), but they can also render views and other widgets as well. Additionally, in activities also can represent the models with android.util packages. So in essence, the activity portion itself in android can do most of the requirements in a MVC paradigm. Now add XML files (also part of views), resources (can be considered part of the model in MVC), and databases and you have a lot of different components that do different parts of the MVC paradigm. Since this is the case, I would say Android does not follow the MVC model but more of an Activity centric model.

2. Some of the mechanisms Android provides for long-running executions and background threads include defining new threads in activities and using the android:process attribute in your XML file. For example, you can call a new thread by calling new Thread(new Runnable() etc… Then you can specify which widgets and actions will run on this new thread. Java Swing sort of has the same mechanisms by creating a new Runnable through the GuiExecutor. In this sense, they are very similar because we are using a class in java to declare a new thread to run separately from the UI/main one.

Brian Yin - 3/5/2014 17:27:08

1) The Android SDK somewhat follows the MVC paradigm. The android SDK uses SQL to store information, which can be used as a model. Activities can be used as controllers which have the code which handles calls to the database and UI. View objects can be represented by the View classes and the xml file. However, the architecture of the android SDK does not make this very clear cut. For example, controllers often need to instantiate the views and also have the ability to add new Views to the UI. Thus, the Activity class can also be thought of as a View, in addition to a controller.

2) Android includes classes which allow for background processes (i.e. IntentService, Service classes) and AsyncTask class for threading and long run execution. Swing are single threaded whereas android supports multithreading.

Robin Sylvan - 3/5/2014 17:28:40

The Android SDK can be said to follow the Model-View-Controller paradigm. While it's not as direct as many web frameworks such as Ruby on Rails, various aspects of it can be said to reflect the different pieces of the paradigm. The layout resources paired with classes inheriting from View reflect the view of the system. Activities hold the main data for the application, and can therefore be said to reflect the model. EventListeners could represent controller actions. A click on the view spawns an event, and the event listener then modifies data in the activity and model, which then updates the view. At the same time, Android SDK is a bit blurry in terms of separating models and views. Widgets themselves hold pieces of data, such as which item is selected, and that model data tends to be used in applications, making them sometimes be used both as a view as well as a model. Android has very similar tools to Swing to help users with long-running executions and background tasks. Android gives us the AsyncTask class to help developers simplify running background tasks in Android. When a user creates an AsyncTask class, they specify the data type of its parameters, data type of its progress updates, and data type of its result. The main thread of the AsyncClass is then started, and in that thread they can call publishProgress which passes information to its onProgressUpdate function. The onProgressUpdate function is run by the GUI thread, so its safely able to modify the model of the program. This toolkit isn't built into basic Swing. In the reading we saw how to construct a very similar BackgroundTask class using Future runnables, but this required accessing the GUI thread and running the thread-safe tasks manually.

Patrick Lin - 3/5/2014 17:28:40

The Android SDK does follow the MVC model in a way. The view corresponds to the XML and view used to format layouts, the activities and main code portions serve as the controller because they handle user input and other logic, while the model is whatever data the Android app uses, generally stored as files in the resources directory. Although each portion is organized separately, Android does not strictly abstract away the three components because communication is universally done through XML code and ID references, both of which route through the layout files.

Android supports Java threading and implements Handler, Loader, and AsyncTask classes to help with synchronization and background application lifecycles. One application may run in the foreground at a time, but any number of other apps could be processing in the background or remain cached in memory to quickly switch between programs. Swing confines model objects and GUI elements to a specific event thread so that any user action, such as a button click, avoids having to deal with synchronization and stays within the same thread. Actions that require more processing must run in the background while the GUI remains responsive, however, and can support early cancellation and status indication. Android similarly wants to run slow processes in the background and not all on the main thread, utilizing Handler and Looper classes to communicate between apps that are in the foreground, visible, or background. There is a dedicated UI thread that cannot be interrupted and must be interfaced with AsyncTask to handle background processing.

Sijia Li - 3/5/2014 17:29:34

1. Yes. The Android SDK does follow the Model-View-Controller paradigm's principle.

The XML file in Android SDK serves as the View; it builds the template which characterizes the layout of the View. The Controllers could be Activities, which control and manage data. For example, when the user makes a move by touching on the screen or typing on the screen, the move will be captured by the corresponding Activities and will be reflected on the View. The Models could be the subclasses created in the Android SDK; they process and respond to data and events (e.g. touch event) according to their own settings and rules.

2. The crucial part to notice is that the EventListeners (e.g. OnTouch Listener) respond to users' motions only one at a time. They will move to the next execution only after the current one is done. From this perspective, the Swing and Android SDK are very similar.

Cheng Sima - 3/5/2014 17:37:29

1) The Android SDK does not exactly follow the MVC model. It is similar because one could think of the XML layout as the View. The event handlers such as the listeners are the controllers, and other parts of the Activity class is the model. However, these three elements are not really decoupled in Android SDK. Both the Model and the Controller are essentially the Activity class. The model could be any data structure that the program uses to store and represent the data and state. It is very hard to separate specific classes for the View, Controller, and Model. Although the View objects are set in the XML layout but these objects are also in the Activity class to store information and respond to change. Therefore, since the display element, the view, and the controller and model, are intertwined, Android SDK does not exactly follow the MVC model.

2) In Android, there are mechanisms that help developers with long-running executions and background threads. There is an AsyncTask class that allows performing background operations and publish results on the UI thread without having to manipulate threads (See This is similar to the SwingWorker in the Swing mechanism, as the thread handling is abstracted into a defined class/object. There are also methods such as Activity.runOnUiThread that allow access to the UI thread.

Aman Sufi - 3/5/2014 17:39:10

1. The Android SDK doesn’t follow the MVC programming pattern to the dot, but it does have some similar aspects, and may be described as being closer to the Model-View-ViewModel (MVVM) paradigm where the ViewModel serves as the middle man to the Model and View. In regards to the MVP paradigm, we could say that the XML documents hold the view, although a good amount of presentational logic may also be held in the code as well. The controller could be said as the Java Android Activities which present the logic and listeners for UI interaction. The model is usually also held within those files in separate classes as well due to its object oriented nature, although they need not necessarily be distinguished from the controller as far as the programmer is concerned, unless some of the model is present on the cloud and the application controller interfaces with that to supply the view with information. In general, it is possible to develop using an MVP approach for Android but it doesn’t seem to be designed to follow a specific framework very rigidly and is adaptable.

2. Android offers the AsyncTask class to run tasks in the background which don’t interrupt the main thread. Worker threads can also be created independent of the main thread. These are quite similar to Java Swing in functionality, and both go off of a basic idea of having a single-threaded event queue. Other common mechanisms are FutureTask and Executor which have methods to cancel processes and notify upon completion.

lisa li - 3/5/2014 17:52:44

1. Yes. It follows the Model-View-Controller paradigm although not strictly. I think Layout corresponds toView, Activity correspond to Controller and the class implements application logics correspond to Model.

2.They are similar to Swing mechanism since they are all single-threaded, also the way Android handles event is similar to Swing.

Romi Phadte - 3/5/2014 18:28:03

1. It kinda follows the paradigm. It depends on how you interpret activities. It is possible to create a model class to hold your data separately from model and view (though it isn't enforced or encouraged by the android model). Additionally, your view elements can be stored. The only thing is that activities can be interpreted as both a view and a controller. This kind of makes the model view controller paradigm a little awkward.

2. There are multi threading principles. Usually all graphical and UI data is run on an event loop that is run on the main thread that is self contained. If there is a long running execution is is sent to another thread and given a call back for which sets up an event in the event (main ui) thread which returns control and gives feedback regarding the completion of a task. This is a little different from swing mechanisms which are a single thread executor. This means that new tasks are put on the event loop and are executed by a single thread in a linear way that seems parallel.